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 often happens 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, you may lose a lot of data. Hence the importance of data backup verification. Not many companies do backups, and even less verify them. To make the verification problem easier, we have added a “verify” command to the TwinDB Backup Tool.

What the command does is that 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 if the recovered database is healthy. You can verify the backups either on the 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 the 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 the backup was taken from. If you run it without specifying the hostname, it will use the hostname of the local machine.
  • dst is a directory for restored 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 the archive.

This feature works transparently with both full and incremental backups.

Besides, if you configure the twindb-backup tool on export data to DataDog (watch out 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 from version 2.15.0 which you can install from our packages repository.

Previous Post Next Post