openvz6 ploop backups and mysql innodb corruption [message #53204] |
Mon, 12 March 2018 19:06 |
Jcats
Messages: 15 Registered: May 2011 Location: FL
|
Junior Member |
|
|
Hello,
We are suffering from a critical issue with ploop backups.
Basically, in some instances, when restoring a ploop backup, MySQL fails to start because of Innodb corruption, example:
2018-03-12 18:04:35 7fd3d4864900 InnoDB: Error: page 818 log sequence number 71622558711
InnoDB: is in the future! Current system log sequence number 71620133300.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recove ry.html
InnoDB: for more information.
We use the following method to perform the backups:
https://openvz.org/Ploop/Backup#Image-based_backup
What would be the proper way to perform the backups to ensure we do not run into this problem? We fear if we ever had fatal issue with the node where all containers needed to be restored we would be stuck with many containers with innodb corruption.
[Updated on: Mon, 12 March 2018 19:06] Report message to a moderator
|
|
|
|
|
Re: openvz6 ploop backups and mysql innodb corruption [message #53289 is a reply to message #53254] |
Sat, 19 May 2018 01:33 |
wsap
Messages: 70 Registered: March 2018 Location: Halifax, NS
|
Member |
|
|
This has now been tested and I can confirm that:
1. If you copy the ploop drive without first snapshotting, it *will* be marked dirty and refuse to mount
2. If you snapshot prior to copying, the backup/dupe *will* be mountable and data is fully intact and restorable
3. You can simply ignore the snapshot files (granted skipping them during backup will mean bandwidth and storage savings). You can simply mount the ploop disk file directly (ignoring the snapshots) or to recover the whole container, edit the XML file and remove the snapshot references.
|
|
|