XtraBackup(1)

NAME
Percona XtraBackup

DESCRIPTION

Percona XtraBackup is an open-source hot backup utility for MySQL that doesn't lock your database during the backup. It can back up data from InnoDB, XtraDB, and MyISAM tables on MySQL 5.0 and 5.1 servers, and it has many advanced features. Commercial support is available(http://www.percona.com/support/mysql-support-maintenance/).

Percona XtraBackup is a combination of the xtrabackup C program, and the innobackupex Perl script. The xtrabackup program copies and manipulates InnoDB and XtraDB data files, and the Perl script enables enhanced functionality, such as interacting with a running MySQL server and backing up MyISAM tables. XtraBackup works with unmodified MySQL servers, as well as Percona Server with XtraDB. It runs on Linux, Windows, and FreeBSD.

Summary of features:

Hot backups. Backups are online, and queries and transactions continue to run without interruption.

Backs up MyISAM. MyISAM tables are read-only while they are being backed up.

Partial backups. You can select which tables and databases to back up.

High performance. XtraBackup is fast and low-impact. It takes special care not to disrupt your database server. It can copy files in parallel (in multiple threads) for even higher performance.

Remote backups. You can make local backups, you can stream the backups to other programs, or you can securely copy your backups to a remote host after completion.

Compressed backups. You can stream a backup into a compressed format. There is a companion program tar4ibd that understands how to work with InnoDB's data format.

Incremental (delta) backups. You can back up only the data pages that have changed since the last backup.

Point-in-time recovery. You can recover a backup, and then use binary logs to roll forward to a point in time.

Percona XtraBackup User Manual
This page explains how to use Percona XtraBackup. XtraBackup is really a set of three tools:

* xtrabackup - a compiled C binary, which copies only InnoDB and XtraDB data

* innobackupex - a wrapper script that provides functionality to backup a whole MySQL database instance with MyISAM, InnoDB, and XtraDB tables.

* tar4ibd - tars InnoDB data safely. It is possible to use the xtrabackup binary alone, or to use only the innobackupex wrapper script and let it execute xtrabackup for you. It might be helpful to first learn how to use xtrabackup , and then learn how to use innobackupex for convenience and added functionality.

  How XtraBackup Works
XtraBackup is based on InnoDB's crash-recovery functionality. It copies your InnoDB data files, which results in data that is internally inconsistent; but then it performs crash recovery on the files to make them a consistent, usable database again. This works because InnoDB maintains a redo log , also called the transaction log. This contains a record of every change to InnoDB's data. When InnoDB starts, it inspects the data files and the transaction log, and performs two steps. It applies committed transaction log entries to the data files, and it performs an undo operation on any transactions that modified data but did not commit. XtraBackup works by remembering the log sequence number (LSN) when it starts, and then copying away the data files. It takes some time to do this, so if the files are changing, then they reflect the state of the database at different points in time. At the same time, XtraBackup runs a background process that watches the transaction log files, and copies changes from it. XtraBackup needs to do this continually because the transaction logs are written in a round-robin fashion, and can be reused after a while. XtraBackup needs the transaction log records for every change to the data files since it began execution. The above is the backup process. Next is the prepare process. During this step, XtraBackup performs crash recovery against the copied data files, using the copied transaction log file. After this is done, the database is ready to restore and use. The above process is implemented in the xtrabackup compiled binary program. The innobackupex program adds more convenience and functionality by also permitting you to back up MyISAM tables and .frm files. It starts xtrabackup , waits until it finishes copying files, and then issues FLUSH TABLES WITH READ LOCK to prevent further changes to MySQL's data and flush all MyISAM tables to disk. It holds this lock, copies the MyISAM files, and then releases the lock. The backed-up MyISAM and InnoDB tables will eventually be consistent with each other, because after the prepare (recovery) process, InnoDB's data is rolled forward to the point at which the backup completed, not rolled back to the point at which it started. This point in time matches where the FLUSH TABLES WITH READ LOCK was taken, so the MyISAM data and the prepared InnoDB data are in sync. The xtrabackup and innobackupex tools both offer many features not mentioned in the preceding explanation. Each tool's functionality is explained in more detail on its manual page. In brief, though, the tools permit you to do operations such as streaming and incremental backups with various combinations of copying the data files, copying the log files, and applying the logs to the data.

The xtrabackup Binary
The xtrabackup binary is a compiled C program that is linked with the InnoDB libraries and the standard MySQL client libraries. The InnoDB libraries provide functionality necessary to apply a log to data files, and the MySQL client libraries provide command-line option parsing, configuration file parsing, and so on to give the binary a familiar look and feel. The next step is to --prepare your backup so it is ready to restore. The xtrabackup tool runs in either --backup or --prepare mode, corresponding to the two main functions it performs. There are several variations on these functions to accomplish different tasks, and there are two less commonly used modes, --stats and --print-param xtrabackup if you don't want to. It is quite easy to use by itself for most purposes. This manual section explains how to use xtrabackup in detail.

Creating a Backup
To create a backup, run xtrabackup with the --backup option. You also need to specify a --target_dir option, which is where the backup will be stored, and a --datadir option, which is where the MySQL data is stored. If the InnoDB data or log files aren't stored in the same directory, you might need to specify the location of those, too. If the target directory does not exist, xtrabackup creates it. If the directory does exist and is empty, xtrabackup will succeed. xtrabackup will not overwrite existing files, however; it will fail with operating system error 17, 'file exists.' The tool changes its working directory to the data directory and performs two primary tasks to complete the backup:
  - It starts a log-copying thread in the background. This thread watches the InnoDB log files, and when they change, it copies the changed blocks to a file called xtrabackup_logfile in the backup target directory. This is necessary because the backup might take a long time, and the recovery process needs all of the log file entries from the beginning to the end of the backup.
  - It copies the InnoDB data files to the target directory. This is not a simple file copy; it opens and reads the files similarly to the way InnoDB does, by reading the data dictionary and copying them a page at a time. When the data files are finished copying, xtrabackup stops the log-copying thread, and creates a files in the target directory called xtrabackup_checkpoints , which contains the type of backup performed, the log sequence number at the beginning, and the log sequence number at the end. An example command to perform a backup follows:
xtrabackup --backup --datadir=/var/lib/mysql/ --target-dir=/data/backups/mysql/
This takes a backup of /var/lib/mysql and stores it at /data/backups/mysql/ --target-dir option deserves special explanation. Because the backup is performed from the data directory itself, the target directory is relative to the data directory unless you specify an absolute path. If you specify a relative path such as --target-dir=backups , for example, don't look for the backup in the directory from which you executed xtrabackup -- it will be a subdirectory of the --datadir directory instead! During the backup process, you should see a lot of output showing the data files being copied, as well as the log file thread repeatedly scanning the log files and copying from it. The last thing you should see is something like the following, where the value of the <LSN> will be a number that depends on your system:
xtrabackup: Transaction log of lsn (<SLN>) to (<LSN>) was copied.
After the backup is finished, the target directory will contain files such as the following, assuming you have a single InnoDB table test.tbl1 and you are using innodb_file_per_table :
/data/backups/mysql/ibdata1
/data/backups/mysql/test
/data/backups/mysql/test/tbl1.ibd
/data/backups/mysql/xtrabackup_checkpoints
/data/backups/mysql/xtrabackup_logfile
The backup can take a long time, depending on how large the database is. It is safe to cancel at any time, because it does not modify the database.

Preparing the Backup
After you make a backup with --backup , the next step is to prepare it. The data files are not point-in-time consistent until they've been prepared, because they were copied at different times as the program ran, and they might have been changed while this was happening. If you try to start InnoDB with these data files, it will detect corruption and crash itself to prevent you from running on damaged data. The prepare step makes the files perfectly consistent at a single instant in time, so you can run InnoDB on them. During the prepare operation, xtrabackup boots up a kind of modified InnoDB that's embedded inside it (the libraries it was linked against). The modifications are necessary to disable InnoDB's standard safety checks, such as complaining that the log file isn't the right size, which aren't appropriate for working with backups. These modifications are only for the xtrabackup binary; you don't need a modified InnoDB to use xtrabackup for your backups. The prepare step uses this "embedded InnoDB" to perform crash recovery on the copied datafiles, using the copied log file. The prepare step is very simple to use: you simply run xtrabackup with the --prepare option and tell it which directory to prepare, for example, to prepare the backup previously taken,
xtrabackup --prepare --target-dir=/data/backups/mysql/
When this finishes, you should see an "InnoDB shutdown" with a message such as the following, where again the value of <LSN> will depend on your system:
101107 16:40:15  InnoDB: Shutdown completed; log sequence number <LSN>
Your backup is now clean and consistent, and ready to restore --prepare a second time, xtrabackup will create the log files for you, and output status text such as the following, which is abbreviated for clarity. The value of <SIZE> will depend on your MySQL configuration.
$ xtrabackup --prepare --target-dir=/data/backups/mysql/
xtrabackup: This target seems to be already prepared.
xtrabackup: notice: xtrabackup_logfile was already used to '--prepare'.
101107 16:54:10  InnoDB: Log file ./ib_logfile0 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile0 size to <SIZE> MB
InnoDB: Database physically writes the file full: wait...
101107 16:54:10  InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 size to <SIZE> MB
InnoDB: Database physically writes the file full: wait...
101107 16:54:15  InnoDB: Shutdown completed; log sequence number 1284108

Restoring a Backup
The xtrabackup binary does not have any functionality for restoring a backup. That is up to the user to do. You might use rsync or cp to restore the files. You should check that the restored files have the correct ownership and permissions. Note that xtrabackup backs up only the InnoDB data. You must separately restore the MySQL system database, MyISAM data, table definition files (.frm files), and everything else necessary to make your database functional.

How-To and Recipes
This page is a quick-reference list of recipes for the xtrabackup tool. It doesn't mention the innobackupex tool; that is documented separately. In all of the below examples, we assume the following:

* You are backing up a server whose data is stored in /var/lib/mysql/ , which is the standard location for most distributions

* You are storing the backups in /data/backups/mysql

* You have a my.cnf file in a standard location, such as /etc/my.cnf , with at least the following contents:
[mysqld]
datadir=/var/lib/mysql/
[xtrabackup]
target_dir=/data/backups/mysql/

  Making a Backup
Making the backup copies the InnoDB data and log files to the destination. Preparing the backup makes the data files consistent and ready to use.

* Make a backup:
xtrabackup --backup

* Prepare the backup:
xtrabackup --prepare

* Prepare again, to create fresh InnoDB log files:
xtrabackup --prepare
Success Criterion

* The exit status of xtrabackup is 0.

* In the second --prepare step, you should see InnoDB print messages similar to "Log file ./ib_logfile0 did not exist: new to be created", followed by a line indicating the log file was created. Relevant Configuration

* You might want to set the --use-memory option to something similar to the size of your buffer pool, if you are on a dedicated server that has enough free memory.

  Making an Incremental Backup
Making an incremental backup requires a full backup as a base.

* Create a full backup as above, but do not run the --prepare command yet

* Suppose the full backup is on Monday

* Create an incremental backup on Tuesday:
  xtrabackup --backup --target-dir=/data/backups/inc/tue/     --incremental-basedir=/data/backups/mysql/

* Create an incremental backup on Wednesday:
  xtrabackup --backup --target-dir=/data/backups/inc/wed/     --incremental-basedir=/data/backups/inc/tue/

* Prepare the base backup from Monday:
  xtrabackup --prepare --apply-log-only --target-dir=/data/backups/mysql/

* Roll Monday's data forward to the state on Tuesday:
  xtrabackup --prepare --apply-log-only --target-dir=/data/backups/mysql/     --incremental-dir=/data/backups/inc/tue/

* Roll forward again to the state on Wednesday:
  xtrabackup --prepare --apply-log-only --target-dir=/data/backups/mysql/     --incremental-dir=/data/backups/inc/wed/

* Follow the steps for a normal backup to complete the preparation stage so the backup is ready to restore

  Restoring the Backup
Because xtrabackup doesn't copy MyISAM files, .frm files, and the rest of the database, you might need to back those up separately. To restore the InnoDB data, simply do something like the following after preparing:
cd /data/backups/mysql/
rsync -rvt --exclude 'xtrabackup_checkpoints' --exclude 'xtrabackup_logfile'   ./ /var/lib/mysql
chown -R mysql:mysql /var/lib/mysql/

Limitations of xtrabackup
The xtrabackup binary has some limitations you should be aware of to ensure that your backups go smoothly and are recoverable.

* If the xtrabackup_logfile is larger than 4GB, the --prepare step will fail on 32-bit versions of xtrabackup. This limitation also applied to some older 64-bit versions of xtrabackup ( FIXME what versions?).

* xtrabackup does not currently create new InnoDB log files (ib_logfile0, etc) during the initial --prepare step. You must prepare the backup a second time to do this, if you wish.

* xtrabackup copies only the InnoDB data and logs. It does not copy table definition files (.frm files), MyISAM data, users, privileges, or any other portions of the overall database that lie outside of the InnoDB data. To back up this data, you need a wrapper script such as innobackupex

* xtrabackup doesn't understand the very old --set-variable my.cnf syntax that MySQL uses. See configuration

Configuring xtrabackup
This page explains how to configure xtrabackup and how to configure your system to support xtrabackup correctly.

  Configuring xtrabackup
All of the xtrabackup configuration is through options, which behave exactly like standard MySQL program options: they can be specified either at the command-line, or through a file such as /etc/my.cnf. The xtrabackup binary reads the [myslqd] and [xtrabackup] sections from any configuration files, in order. That is so that it can read its options from your existing MySQL installation, such as the datadir or some of the InnoDB options. If you want to override these, just specify them in the [xtrabackup] section, and because it is read later, it will take precedence. You don't need to put any configuration in your my.cnf if you don't want to. You can simply specify the options on the command-line. Normally, the only thing you might find convenient to place in the [xtrabackup] section of your my.cnf file is the target_dir option, for example,
[xtrabackup]
target_dir = /data/backups/mysql/
This manual will assume that you do not have any file-based configuration for xtrabackup , so it will always show command-line options being used explicitly. Please see the option and variable reference for details on all of the configuration options. The xtrabackup binary does not accept exactly the same syntax in the my.cnf file as the mysqld server binary does. For historical reasons, the mysqld server binary accepts parameters with a --set-variable=<variable>=<value> syntax, which xtrabackup does not understand. If your my.cnf file has such configuration directives, you should rewrite them in the --variable=value syntax.

  System Configuration and NFS Volumes
The xtrabackup tool requires no special configuration on most systems. However, the storage where the --target-dir is located must behave properly when fsync() is called. In particular, we have noticed that NFS volumes not mounted with the sync option might not really sync the data. As a result, if you back up to an NFS volume mounted with the async option, and then try to prepare the backup from a different server that also mounts that volume, the data might appear to be corrupt. You can use the noasync mount option to avoid this problem.

The xtrabackup Option Reference
This page documents all of the command-line options for the xtrabackup binary.

  --print-defaults
Print the program argument list and exit. Must be given as the first option on the command-line.

  --no-defaults
Don't read default options from any option file. Must be given as the first option on the command-line.

  --defaults-file
Only read default options from the given file. Must be given as the first option on the command-line. Must be a real file; cannot be a symbolic link.

  --defaults-extra-file
Read this file after the global files are read. Must be given as the first option on the command-line.

  --apply-log-only
This option causes only the redo stage to be performed when incremental backups

  --backup
Make a backup and place it in --target-dir creating a backup

  --create-ib-logfile
This option is not currently implemented. To create the InnoDB log files, you must prepare the backup twice at present.

  --datadir
The source directory for the backup. This should be the same as the datadir for your MySQL server, so it should be read from my.cnf if that exists; otherwise you must specify it on the command line.

  --export
Create files necessary for exporting tables. See [[export and import]].

  --incremental-basedir
When creating an incremental backup , this is the directory containing the full backup that is the base dataset for the incremental backups.

  --incremental-dir
When preparing an incremental backup , this is the directory where the incremental backup is combined with the full backup to make a new full backup.

  --incremental-lsn
When creating an incremental backup , you can specify the log sequence number (LSN) in high:low format as two 32-bit integers instead of specifying --incremental-basedir

  --innodb-miscellaneous
There is a large group of InnoDB options that are normally read from the my.cnf configuration file, so that xtrabackup boots up its embedded InnoDB in the same configuration as your current server. You normally do not need to specify these explicitly. These options have the same behavior that they have in InnoDB or XtraDB. They are as follows:

* --innodb-adaptive-hash-index

* --innodb-additional-mem-pool-size

* --innodb-autoextend-increment

* --innodb-buffer-pool-size

* --innodb-checksums

* --innodb-data-file-path

* --innodb-data-home-dir

* --innodb-doublewrite-file

* --innodb-doublewrite

* --innodb-extra-undoslots

* --innodb-fast-checksum

* --innodb-file-io-threads

* --innodb-file-per-table

* --innodb-flush-log-at-trx-commit

* --innodb-flush-method

* --innodb-force-recovery

* --innodb-io-capacity

* --innodb-lock-wait-timeout

* --innodb-log-buffer-size

* --innodb-log-files-in-group

* --innodb-log-file-size

* --innodb-log-group-home-dir

* --innodb-max-dirty-pages-pct

* --innodb-open-files

* --innodb-page-size

* --innodb-read-io-threads

* --innodb-write-io-threads

  --log-stream
Makes xtrabackup not copy data files, and output the contents of the InnoDB log files to STDOUT until the --suspend-at-end automatically.

  --prepare
Makes xtrabackup perform recovery on a backup created with --backup , so that it is ready to use. See preparing a backup

  --print-param
Makes xtrabackup print out parameters that can be used for copying the data files back to their original locations to restore them. See scripting with xtrabackup

  --stats
Causes xtrabackup to scan the specified data files and print out index statistics

  --suspend-at-end
Causes xtrabackup to create a file called xtrabackup_suspended in the scripting with xtrabackup

  --tables-file
A file containing one table name per line, in databasename.tablename format. The backup will be limited to the specified tables. See partial backups

  --tables
A regular expression against which the full tablename, in databasename.tablename format, is matched. If the name matches, the table is backed up. See partial backups

  --target-dir
This option specifies the destination directory for the backup. If the directory does not exist, xtrabackup creates it. If the directory does exist and is empty, xtrabackup will succeed. xtrabackup will not overwrite existing files, however; it will fail with operating system error 17, 'file exists.' Note that for --prepare , relative paths are interpreted as being relative to the current working directory.

  --throttle
This option limits throttling a backup

  --tmpdir
This option is currently not used for anything except printing out the correct tmpdir parameter when --print-param is used.

  --use-memory
This option affects how much memory is allocated for --stats innodb_buffer_pool_size

  --parallel
This option specifies the number of threads to use to copy multiple data files concurrently when creating a backup. The default value is 1 (i.e., no concurrent transfer). Currently, the option only works for local backups.

Exporting and Importing Tables
In standard InnoDB, it is not normally possible to copy tables between servers by copying the files, even with innodb_file_per_table innodb_file_per_table to be used on both servers, and requires innodb_expand_import to be enabled on the destination server. It only works on individual .ibd files, and cannot export a table that is not contained in its own .ibd file. Let's see how to export and import the following table:
CREATE TABLE export_test (
  a int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

  Exporting the Table
This table should have been created in innodb_file_per_table mode, so after taking a backup as usual with --backup , the .ibd file should exist in the target directory:
$ find /data/backups/mysql/ -name export_test.*
/data/backups/mysql/test/export_test.ibd
when you prepare the backup, add the extra parameter --export to the command. If you do not have innodb_file_per_table in your my.cnf, you must add that to the command-line options. Here is an example:
xtrabackup --prepare --export --innodb-file-per-table --target-dir=/data/backups/mysql/
Now you should see a .exp file in the target directory:
$ find /data/backups/mysql/ -name export_test.*
/data/backups/mysql/test/export_test.exp
/data/backups/mysql/test/export_test.ibd
These two files are all you need to import the table into a server running Percona Server with XtraDB.

  Importing the Table
On the destination server running Percona Server with XtraDB, with innodb_expand_import enabled, create a table with the same structure, and then perform the following steps:
  - Execute ALTER TABLE test.export_test DISCARD TABLESPACE;
    - If you see the following message, then you must enable innodb_file_per_table and create the table again: "ERROR 1030 (HY000): Got error -1 from storage engine"
  - Copy the exported files to the test/ subdirectory of the destination server's data directory
  - Execute ALTER TABLE test.export_test IMPORT TABLESPACE; The table should now be imported, and you should be able to SELECT from it and see the imported data.

Incremental Backups
The xtrabackup tool supports incremental backups, which means that it can copy only the data that has changed since the last full backup. You can perform many incremental backups between each full backup, so you can set up a backup process such as a full backup once a week and an incremental backup every day, or full backups every day and incremental backups every hour. Incremental backups work because each InnoDB page (usually 16kb in size) contains a log sequence number , or LSN. The LSN is the system version number for the entire database. Each page's LSN shows how recently it was changed. An incremental backup copies each page whose LSN is newer than the previous incremental or full backup's LSN. Incremental backups do not actually compare the data files to the previous backup's data files. In fact, you can use --incremental-lsn to perform an incremental backup without even having the previous backup, if you know its LSN. Incremental backups simply read the pages and compare their LSN to the last backup's LSN. You still need a full backup to recover the incremental changes, however; without a full backup to act as a base, the incremental backups are useless.

  Creating an Incremental Backup
To make an incremental backup, begin with a full backup as usual. The xtrabackup binary writes a file called xtrabackup_checkpoints into the backup's target directory. This file contains a line showing the to_lsn , which is the database's LSN at the end of the backup. Create the full backup with a command such as the following:
xtrabackup --backup --target-dir=/data/backups/base --datadir=/var/lib/mysql/
TIP: If you want a usable full backup, use innobackupex since xtrabackup itself won't copy table definitions, triggers, or anything else that's not .ibd. If you look at the xtrabackup_checkpoints file, you should see some contents similar to the following:
backup_type = full-backuped
from_lsn = 0
to_lsn = 1291135
Now that you have a full backup, you can make an incremental backup based on it. Use a command such as the following:
xtrabackup --backup --target-dir=/data/backups/inc1   --incremental-basedir=/data/backups/base --datadir=/var/lib/mysql/
The /data/backups/inc1/ directory should now contain delta files, such as ibdata1.delta and test/table1.ibd.delta xtrabackup_checkpoints file in this directory, you should see something similar to the following:
backup_type = incremental
from_lsn = 1291135
to_lsn = 1291340
The meaning should be self-evident. It's now possible to use this directory as the base for yet another incremental backup:
xtrabackup --backup --target-dir=/data/backups/inc2   --incremental-basedir=/data/backups/inc1 --datadir=/var/lib/mysql/

  Preparing the Backups
The --prepare step for incremental backups is not the same as for normal backups. In normal backups, two types of operations are performed to make the database consistent: committed transactions are replayed from the log file against the data files, and uncommitted transactions are rolled back. For technical reasons, you must skip the rollback of uncommitted transactions when preparing a backup that will be used as the base for an incremental backup. You should use the --apply-log-only option to prevent the rollback phase. WARNING: If you do not use the --apply-log-only option to prevent the rollback phase, then your incremental backups will be useless. After transactions have been rolled back, further incremental backups cannot be applied. Beginning with the full backup you created, you can prepare it, and then apply the incremental differences to it. Recall that you have the following backups:
/data/backups/base
/data/backups/inc1
/data/backups/inc2
To prepare the base backup, you need to run --prepare as usual, but prevent the rollback phase:
xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base
The output should end with some text such as the following:
  101107 20:49:43 InnoDB: Shutdown completed; log sequence number 1291135 The log sequence number should match the to_lsn of the base backup, which you saw previously. This backup is actually safe to restore as-is now, even though the rollback phase has been skipped. If you restore it and start MySQL, InnoDB will detect that the rollback phase was not performed, and it will do that in the background, as it usually does for a crash recovery upon start. It will notify you that the database was not shut down normally, but the recovery phase should be nearly instantaneous, because the redo log has already been applied to the data files. To apply the first incremental backup to the full backup, you should use the following command:
xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base   --incremental-dir=/data/backups/inc1
This applies the delta files to the files in /data/backups/base, which rolls them forward in time to the time of the incremental backup. It then applies the redo log as usual to the result. The final data is in /data/backups/base, not in the incremental directory. You should see some output such as the following:
incremental backup from 1291135 is enabled.
xtrabackup: cd to /data/backups/base/
xtrabackup: This target seems to be already prepared.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(1291340)
Applying /data/backups/inc1/ibdata1.delta ...
Applying /data/backups/inc1/test/table1.ibd.delta ...
101107 20:56:30  InnoDB: Shutdown completed; log sequence number 1291340
Again, the LSN should match what you saw from your earlier inspection of the first incremental backup. If you restore the files from /data/backups/base, you should see the state of the database as of the first incremental backup. Preparing the second incremental backup is a similar process: apply the deltas to the (modified) base backup, and you will roll its data forward in time to the point of the second incremental backup:
xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base   --incremental-dir=/data/backups/inc2
If you wish to avoid the notice that InnoDB was not shut down normally, when you have applied the desired deltas to the base backup, you can run --prepare again without disabling the rollback phase.

Partial Backups
xtrabackup supports taking partial backups when innodb_file_per_table is enabled. There are two ways to create partial backups. For the purposes of this manual page, we will assume that there is a database named 'test' which contains tables named 't1' and 't2'.

  Using the --tables Option
The first method is with the --tables option. The option's value is a regular expression that is matched against the fully qualified tablename, including the database name, in the form databasename.tablename To back up only tables in the 'test' database, you can use the following command:
  xtrabackup --backup --datadir=/var/lib/mysql --target-dir=/data/backups/ --tables="^test[.].*" To back up only the table 'test.t1', you can use the following command:
  xtrabackup --backup --datadir=/var/lib/mysql --target-dir=/data/backups/ --tables="^test[.]t1"

  Using the --tables-file Option
The --tables-file option specifies a file that can contain multiple table names, one table name per line in the file. Only the tables named in the file will be backed up. Names are matched exactly, case-sensitive, with no pattern or regular expression matching. The table names must be fully qualified, in databasename.tablename format.

  Preparing the Backup
When you use the --prepare option on a partial backup, you will see warnings about tables that don't exist. That is because these tables exist in the data dictionary inside InnoDB, but the corresponding .ibd files don't exist. They were not copied into the backup directory. These tables will be removed from the data dictionary, and when you restore the backup and start InnoDB, they will no longer exist and will not cause any errors or warnings to be printed to the log file. An example of the error message you will see during the prepare phase follows.
InnoDB: Reading tablespace information from the .ibd files...
101107 22:31:30  InnoDB: Error: table 'test1/t'
InnoDB: in InnoDB data dictionary has tablespace id 6,
InnoDB: but tablespace with that id or name does not exist. It will be removed from data dictionary.

Analyzing Table Statistics
The xtrabackup binary can analyze InnoDB data files in read-only mode to give statistics about them. To do this, you should use the --stats option. You can combine this with the --tables option to limit the files to examine. It also uses the --use-memory= option. You can perform the analysis on a running server, with some chance of errors due to the data being changed during analysis. Or, you can analyze a backup copy of the database. Either way, to use the statistics feature, you need a clean copy of the database including correctly sized log files, so you need to execute with --prepare twice to use this functionality on a backup. The result of running on a backup might look like the following:
<INDEX STATISTICS>
  table: test/table1, index: PRIMARY, space id: 12, root page 3
  estimated statistics in dictionary:
    key vals: 25265338, leaf pages 497839, size pages 498304
  real statistics:
     level 2 pages: pages=1, data=5395 bytes, data/pages=32%
     level 1 pages: pages=415, data=6471907 bytes, data/pages=95%
        leaf pages: recs=25958413, pages=497839, data=7492026403 bytes, data/pages=91%
This can be interpreted as follows:

* The first line simply shows the table and index name and its internal identifiers. If you see an index named GEN_CLUST_INDEX , that is the table's clustered index, automatically created because you did not explicitly create a PRIMARY KEY.

* The estimated statistics in dictionary information is similar to the data that's gathered through ANALYZE TABLE inside of InnoDB to be stored as estimated cardinality statistics and passed to the query optimizer

* The real statistics information is the result of scanning the data pages and computing exact information about the index.

* The level <X> pages: output means that the line shows information about pages at that level in the index tree. The larger <X> is, the farther it is from the leaf pages, which are level 0. The first line is the root page.

* The leaf pages output shows the leaf pages, of course. This is where the table's data is stored.

* The external pages: output (not shown) shows large external pages that hold values too long to fit in the row itself, such as long BLOB and TEXT values.

* The recs is the real number of records (rows) in leaf pages.

* The pages is the page count.

* The data is the total size of the data in the pages, in bytes.

* The data/pages is calculated as (data / (pages * PAGE_SIZE)) * 100%. It will never reach 100% because of space reserved for page headers and footers.

Throttling Backups
Although xtrabackup does not block your database's operation, any backup can add load to the system being backed up. On systems that do not have much spare I/O capacity, it might be helpful to throttle the rate at which xtrabackup reads and writes data. You can do this with the --throttle option. In --backup mode, this option limits the number of pairs of read-and-write operations per second that xtrabackup will perform. If you are creating an incremental backup , then the limit is the number of read IO operations per second. By default, there is no throttling, and xtrabackup reads and writes data as quickly as it can. If you set too strict of a limit on the I/O operations, the backup might be so slow that it will never catch up with the transaction logs that InnoDB is writing, so the backup might never complete.

Working with Binary Logs
The xtrabackup binary integrates with information that InnoDB stores in its transaction log about the corresponding binary log position for committed transactions. This enables it to print out the binary log position to which a backup corresponds, so you can use it to set up new replication slaves or perform point-in-time recovery.

  Finding the Binary Log Position
You can find the binary log position corresponding to a backup performing the --prepare process. If your backup is from a server with binary logging enabled, xtrabackup will create a file named xtrabackup_binlog_pos_innodb in the target directory. This file contains the binary log file name and position of the exact point in the binary log to which the prepared backup corresponds. You will also see output similar to the following during the prepare stage:
InnoDB: Last MySQL binlog file position 0 3252710, file name ./mysql-bin.000001
[notice (again)]
  If you use binary log and don't use any hack of group commit,
  the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 3252710, file name ./mysql-bin.000001
The output should contain the same file name and position as the xtrabackup_binlog_pos_innodb file. The message about hacking group commit refers to an early implementation of emulated group commit in Percona Server. FIXME is this still uncertain, or do we know that it works correctly now?

  Point-In-Time Recovery
To perform a point-in-time recovery from an xtrabackup backup, you should prepare and restore the backup, and then replay binary logs from the point shown in the xtrabackup_binlog_pos_innodb file.

  Setting Up a New Replication Slave
To set up a new replica, you should prepare the backup, and restore it to the data directory of your new replication slave. Then in your CHANGE MASTER TO command, use the binary log filename and position shown in the xtrabackup_binlog_pos_innodb file to start replication.

Scripting Backups With xtrabackup
The xtrabackup tool has several features to enable scripts to control it while they perform related tasks. The innobackupex script is one example, but xtrabackup is easy to control with your own command-line scripts too.

  Suspending After Copying
In backup mode, xtrabackup normally copies the log files in a background thread, copies the data files in a foreground thread, and then stops the log copying thread and finishes. If you use the --suspend-at-end option, instead of stopping the log thread and finishing, xtrabackup continues to copy the log files, and creates a file in the target directory called xtrabackup_suspended xtrabackup will continue to watch the log files and copy them into the xtrabackup_logfile in the target directory. When the file is removed, xtrabackup will finish copying the log file and exit. This functionality is useful for coordinating the InnoDB data backups with other actions. Perhaps the most obvious is copying the table definitions (the .frm files) so that the backup can be restored. You can start xtrabackup in the background, wait for the xtrabackup_suspended file to be created, and then copy any other files you need to complete the backup. This is exactly what the innobackupex tool does (it also copies MyISAM data and other files).

  Generating Meta-Data
It is a good idea for the backup to include all the information you need to restore the backup. The xtrabackup tool can print out the contents of a my.cnf file that are needed to restore the data and log files. If you add the --print-param option, it will print out something like the following:
# This MySQL options file was generated by XtraBackup.
[mysqld]
datadir = /data/mysql/
innodb_data_home_dir = /data/innodb/
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /data/innodb-logs/
You can redirect this output into a file in the target directory of the backup.

  Agreeing on the Source Directory
It's possible that the presence of a defaults file or other factors could cause xtrabackup to back up data from a different location than you expected. To prevent this, you can use --print-param to ask it where it will be copying data from. You can use the output to ensure that xtrabackup and your script are working on the same dataset.

XtraBackup Exit Codes
The xtrabackup binary exits with the traditional success value of 0 after a backup when no error occurs. If an error occurs during the backup, the exit value is 1. In certain cases, the exit value can be something other than 0 or 1, due to the command-line option code included from the MySQL libraries. An unknown command-line option, for example, will cause an exit code of 255. When an error happens in the main() function of xtrabackup.c , when xtrabackup is preparing to perform the backup, the exit code is -1. This is usually because of a missing or wrong command-line option, failure to open a file or directory that the user specified as a command-line option, or similar. This behavior is changed in xtrabackup 1.4 and later, so it always returns 0 or 1. (However, the MySQL libraries might still exit with a code of 255.)

Implementation Details
This page contains notes on various internal aspects of the xtrabackup tool's operation.

  File Permissions
xtrabackup opens the source data files in read-write mode, although it does not modify the files. This means that you must run xtrabackup as a user who has permission to write the data files. The reason for opening the files in read-write mode is that xtrabackup uses the embedded InnoDB libraries to open and read the files, and InnoDB opens them in read-write mode because it normally assumes it is going to write to them.

  Tuning the OS Buffers
Because xtrabackup reads large amounts of data from the filesystem, it uses posix_fadvise() where possible, to instruct the operating system not to try to cache the blocks it reads from disk. Without this hint, the operating system would prefer to cache the blocks, assuming that xtrabackup is likely to need them again, which is not the case. Caching such large files can place pressure on the operating system's virtual memory and cause other processes, such as the database server, to be swapped out. The xtrabackup tool avoids this with the following hint on both the source and destination files:
  posix_fadvise(file, 0, 0, POSIX_FADV_DONTNEED) In addition, xtrabackup asks the operating system to perform more aggressive read-ahead optimizations on the source files:
  posix_fadvise(file, 0, 0, POSIX_FADV_SEQUENTIAL)

  Copying Data Files
When copying the data files to the target directory, xtrabackup reads and writes 1MB of data at a time. This is not configurable. When copying the log file, xtrabackup reads and writes 512 bytes at a time. This is also not possible to configure, and matches InnoDB's behavior. After reading from the files, xtrabackup iterates over the 1MB buffer a page at a time, and checks for page corruption on each page with InnoDB's buf_page_is_corrupted() function. If the page is corrupt, it re-reads and retries up to 10 times for each page. It skips this check on the doublewrite buffer.

AUTHOR
Percona LLC and/or its affiliates. http://www.percona.com/

REPORTING BUGS
Report bugs to https://bugs.launchpad.net/percona-xtrabackup/+filebug

LICENCE
GPL version 2