3.3.3 Making a Compressed Backup

To save disk space, you can compress InnoDB backup data files by using the --compress option of mysqlbackup. Compression lets you keep more sets of backup data on hand and save on transmission time when sending the backup data to another server. The downside includes the extra CPU overhead during the backup itself and the extra time needed for the restoration process for uncompressing the data.

The backup compression feature works only for InnoDB tables. After the InnoDB tablespace files are compressed during backup, they receive the .ibz extension rather than the usual .ibd extension. To avoid wasting CPU cycles without saving additional disk space, --compress does not attempt to compress already-compressed tables that use the Barracuda file format; such tablespace files keep the usual .ibd extension.

Note

When there is unused space within an InnoDB tablespace file, the entire file is copied during an uncompressed backup. Perform a compressed backup to avoid the storage overhead for the unused space.

You can only use the --compress option for full backups, but not for incremental backups.

You can also select the compression algorithm to use by the --compress-method option and, when using the ZLIB or LZMA compression algorithm, the level of compression by the --compress-level option. See Section 5.1.7, “Compression Options” for details.

This is a sample command for making a compressed backup:

mysqlbackup --defaults-file=/etc/my.cnf --compress --compress-level=5 backup

This is a sample command for making a compressed single-file backup:

mysqlbackup --defaults-file=/etc/my.cnf --compress --compress-level=5 \
  --backup-image=backup.img backup-to-image

Next steps:

Make a note of the LSN value in the message at the end of both the full and incremental backups (for example, in the line mysqlbackup: Was able to parse the log up to lsn LSN_number). You specify this value when performing incremental backups of changes that occur after this full backup.
Apply the log to the compressed backup files, so that the full backup is ready to be restored at any time. You can move the backup data to a different server first, to avoid the CPU and I/O overhead of performing this operation on the database server.
After applying the log, periodically take incremental backups, which are smaller and can be made faster than a full backup.