Posted on

Verify MySQL Backups With TwinDB Backup Tool

By Maksym Kryva.

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.

Usage

# twindb-backup verify mysql --help
Usage: twindb-backup verify mysql [OPTIONS] [BACKUP_COPY]
 
  Verify backup
 
Options:
  --dst TEXT       Directory where to restore the backup copy  [default:
                   /tmp/]
  --hostname TEXT  If backup_copy is latest this option specifies hostname
                   where the backup copy was taken.
  --help           Show this message and exit.
  • 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:

twindb-backup verify mysql \
    /path/to/twindb-server-backups/master1/hourly/files/_home-2017-11-13_16_43_17.tar.gz \
    --dst /var/lib/mysql

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 TwinDB Backup Tool supports verification starting from version 2.15.0 which you can install from the source code.