Transition Technology: Ticket #499: MySQL backup dump error on puffin

milestone set

ed — Wed, 08 May 2013 16:45:15 GMT

milestone set to Maintenance

hours, totalhours changed

chris — Fri, 15 Nov 2013 14:02:53 GMT

hours changed from 0.0 to 0.25
totalhours changed from 0.0 to 0.25

This issue is still to be resolved, the suggestion in a thread on mysql.com, "use a replication slave and stop him for consistent backups" seems sensible, this would probably make sense to be combined with a dedicated MySQL server for the existing 3 virtual machines.

Of course there is no need to backup the performance_schema database but since we don't want to list all the databases to be backed up in /etc/backup.d/20.mysql as this would result in new databases not being backed up by default, it's best left as it is, dumping them all each night, with an error each night.

status changed

chris — Fri, 15 Nov 2013 14:07:25 GMT

status changed from new to accepted

cc, status changed; resolution set

chris — Mon, 02 Jun 2014 09:43:40 GMT

cc jim removed
status changed from accepted to closed
resolution set to worksforme

This is nolonger an issue, the last backup email:

From: root@puffin.webarch.net (root)
Date: Mon, 02 Jun 2014 01:11:47 +0100
To: root@puffin.webarch.net
Subject: backupninja: puffin.webarch.net
success -- /etc/backup.d/10.sys
success -- /etc/backup.d/20.mysql