1. Verify MySQL Backups with TwinDB Backup Tool

Verify MySQL Backups with TwinDB Backup Tool


If you don’t verify backups you may safely assume you don’t have them.

It happens often that MySQL backups can be invalid or broken due to a software bug or some hidden corruption. If you are lucky enough hours and days will be needed to resurrect a database from a bad backup copy. If you ran out of luck quota – it may lead to data loss, hence it is very important to verify your backups. Far from all companies do backups, even less do verify them. To make the verification problem easier we have added a “verify” command to the TwinDB Backup Tool.

What the command does is it takes a backup copy, restores it, prepares(applies redo logs, fixes permissions and so on) and runs a MySQL instance on it. Then it checks that the recovered database is healthy. You can verify the backups either on a same server where the backup was taken or on a dedicated “verification” machine.


  • backup_copy is a backup copy name. You can get it from twindb-backup ls output.  Or you can pass latest for verifying the most recent MySQL backup.
  • hostname . If you verify the backup on another machine you have to specify what host was the backup taken from. If you run it without specifying the hostname, it will use a hostname of the local machine.
  • dst is a directory for restore mysql backup. By default it’s /tmp.

For example:

To verify a backup, twindb-backup gets it from destinations such as S3, SSH, or Local. After this, twindb-backup runs innobackupex to restore the backup from archive.

This feature works transparently with both full and incremental backups.

Besides, if you configure twindb-backup tool on export data to DataDog (watch for our next post :)), you can monitor restore time and alert your team about invalid backups or if restore time breaks SLA.

The Backup Tools supports verification starting starting from version 2.15.0 that you can install from our packages repository.

Previous Post Next Post