When doing the backup of InnoDB tables it’s possible to omit the secondary index pages. This will make the backups more compact and this way they will take less space on disk. The downside of this is that the backup prepare process takes longer as those secondary indexes need to be recreated. Difference in backup size depends on the size of the secondary indexes.
For example full backup taken without and with the --compact option:
#backup size without --compact 2.0G 2013-02-01_10-18-38 #backup size taken with --compact option 1.4G 2013-02-01_10-29-48
Compact backups are not supported for system table space, so in order to work correctly innodb-file-per-table option should be enabled.
This feature was introduced in Percona XtraBackup 2.1.
To make a compact backup innobackupex needs to be started with the --compact option:
$ innobackupex --compact /data/backups
This will create a timestamped directory in /data/backups.
You can use the innobackupex --no-timestamp option to override this behavior and the backup will be created in the given directory.
If you check at the xtrabackup_checkpoints file in BASE-DIR, you should see something like:
backup_type = full-backuped from_lsn = 0 to_lsn = 2888984349 last_lsn = 2888984349 compact = 1
When --compact wasn’t used compact value will be 0. This way it’s easy to check if the backup contains the secondary index pages or not.
Preparing the compact require rebuilding the indexes as well. In order to prepare the backup a new option --rebuild-indexes should be used with --apply-logs:
$ innobackupex --apply-log --rebuild-indexes /data/backups/2013-02-01_10-29-48
Output, beside the standard innobackupex output, should contain the information about indexes being rebuilt, like:
130201 10:40:20 InnoDB: Waiting for the background threads to start Rebuilding indexes for table sbtest/sbtest1 (space id: 10) Found index k_1 Dropping 1 index(es). Rebuilding 1 index(es). Rebuilding indexes for table sbtest/sbtest2 (space id: 11) Found index k_1 Found index c Found index k Found index c_2 Dropping 4 index(es). Rebuilding 4 index(es).
Since Percona XtraBackup has no information when applying an incremental backup to a compact full one, on whether there will be more incremental backups applied to it later or not, rebuilding indexes needs to be explicitly requested by a user whenever a full backup with some incremental backups merged is ready to be restored. Rebuilding indexes unconditionally on every incremental backup merge is not an option, since it is an expensive operation.
To process individual tables in parallel when rebuilding indexes, innobackupex --rebuild-threads option can be used to specify the number of threads started by Percona XtraBackup when rebuilding secondary indexes on –apply-log –rebuild-indexes. Each thread rebuilds indexes for a single .ibd tablespace at a time.
innobackupex has a --copy-back option, which performs the restoration of a backup to the server’s datadir
$ innobackupex --copy-back /path/to/BACKUP-DIR
It will copy all the data-related files back to the server’s datadir, determined by the server’s my.cnf configuration file. You should check the last line of the output for a success message:
innobackupex: Finished copying back files. 130201 11:08:13 innobackupex: completed OK!
For general inquiries, please send us your question and someone will contact you.