How innobackupex Works

innobackupex is a script written in Perl that wraps the xtrabackup and tar4ibd binaries and performs the tasks where the performance and efficiency of C program isn’t needed. In this way, it provides a convinient and integrated approach to backing up in many common scenarios.

The following describes the rationale behind innobackupex actions.

Making a Backup

If no mode is specified, innobackupex will assume the backup mode.

By default, it starts xtrabackup with the --suspend-at-end option, and lets it copy the InnoDB data files. When xtrabackup finishes that, innobackupex sees it create the xtrabackup_suspended file and executes FLUSH TABLES WITH READ LOCK. Then it begins copying the rest of the files.

If the --ibbackup is not supplied, innobackupex will try to detect it: if the xtrabackup_binary file exists on the backup directory, it reads from it which binary of xtrabackup will be used. Otherwise, it will try to connect to the database server in order to determine it. If the connection can’t be established, xtrabackup will fail and you must specify it (see Choosing the Right Binary).

When the binary is determined, the connection to the database server is checked. This is done by connecting, issuing a query, and closing the connection. If everything goes well, the binary is started as a child process.

If it is not an incremental backup, it connects to the server. It waits for slaves in a replication setup if the option --safe-slave-backup is set and will flush all tables with READ LOCK, preventing all MyISAM tables from writing (unless option --no-lock is specified).

Note

Locking is done only for MyISAM and other non-InnoDB tables, and only after Percona XtraBackup is finished backing up all InnoDB/XtraDB data and logs.

Once this is done, the backup of the files will begin. It will backup .frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSM, .CSV, .par, and .opt files.

When all the files are backed up, it resumes ibbackup and wait until it finishes copying the transactions done while the backup was done. Then, the tables are unlocked, the slave is started (if the option --safe-slave-backup was used) and the connection with the server is closed. Then, it removes the xtrabackup_suspended file and permits xtrabackup to exit.

It will also create the following files in the directory of the backup:

xtrabackup_checkpoints
containing the LSN and the type of backup;
xtrabackup_binlog_info
containing the position of the binary log at the moment of backing up;
xtrabackup_binlog_pos_innodb
containing the position of the binary log at the moment of backing up relative to InnoDB transactions;
xtrabackup_slave_info
containing the MySQL binlog position of the master server in a replication setup via SHOW SLAVE STATUS if the --slave-info option is passed;
backup-my.cnf
containing only the my.cnf options required for the backup. For example, innodb_data_file_path, innodb_log_files_in_group, innodb_log_file_size, innodb_fast_checksum, innodb_page_size, innodb_log_block_size;
xtrabackup_binary
containing the binary used for the backup;
mysql-stderr
containing the STDERR of mysqld during the process and
mysql-stdout
containing the STDOUT of the server.

If the --remote-host was set, innobackupex will test the connection to the host via ssh and create the backup directories. Then the same process will be applied but the log will be written to a temporary file and will be copied via scp with the options set by --scpopt (-Cp -c arcfour by default).

After each copy the files will be deleted. The same rationale is for the --stream mode.

Finally, the binary log position will be printed to STDERR and innobackupex will exit returning 0 if all went OK.

Note that the STDERR of innobackupex is not written in any file. You will have to redirect it to a file, e.g., innobackupex OPTIONS 2> backupout.log.

Restoring a backup

To restore a backup with innobackupex the --copy-back option must be used.

innobackupex will read from the my.cnf the variables datadir, innodb_data_home_dir, innodb_data_file_path, innodb_log_group_home_dir and check that the directories exist.

It will copy the MyISAM tables, indexes, etc. (.frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSM, .CSV, par and .opt files) first, InnoDB tables and indexes next and the log files at last. It will preserve file’s attributes when copying them, you may have to change the files’ ownership to mysql before starting the database server, as they will be owned by the user who created the backup.

Alternatively, the --move-back option may be used to restore a backup. This option is similar to --copy-back with the only difference that instead of copying files it moves them to their target locations. As this option removes backup files, it must be used with caution. It is useful in cases when there is not enough free disk space to hold both data files and their backup copies.

Percona XtraBackup
Call Us
+1-888-316-9775 (USA - Sales)
+1-208-473-2904 (USA - Sales)
+44-208-133-0309 (UK - Sales)
0-800-051-8984 (UK - Sales)
0-800-181-0665 (GER - Sales)
+1-877-862-4316 (Emergency)
+1-855-55TRAIN (Training)
+1-925-271-5054 (Training)

Table Of Contents

Previous topic

Point-In-Time recovery

Next topic

The innobackupex Option Reference

This Page



© Copyright Percona LLC and/or its affiliates, 2009-2013.
Except where otherwise noted, this documentation is licensed under the following license:
CC Attribution-ShareAlike 2.0 Generic
Created using Sphinx 1.2.2.
This documentation is developed in Launchpad as part of the Percona XtraBackup source code.
If you spotted innacuracies, errors, don't understood it or you think something is missing or should be improved, please file a bug.
]]>