+1-208-473-2904 (USA - Sales)
0-800-051-8984 (UK - Sales)
0-800-181-0665 (GER - Sales)
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, 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:
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/. The --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. Here is an example that shows the log thread scanning the log in the background, and a file copying thread working on the ibdata1 file:
>> log scanned up to (3646475465483) >> log scanned up to (3646475517369) >> log scanned up to (3646475581716) >> log scanned up to (3646475636841) >> log scanned up to (3646475718082) >> log scanned up to (3646475988095) >> log scanned up to (3646476048286) >> log scanned up to (3646476102877) >> log scanned up to (3646476140854)  Copying /usr/local/mysql/var/ibdata1 to /usr/local/mysql/Backups/2011-04-18_21-11-15/ibdata1  ...done
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 MySQL’s innodb_file_per_table option:
/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.
The next step is getting your backup ready to restored: Preparing the backup.