The XtraBackup Backup Program

The XtraBackup tool is an open-source alternative to the venerable InnoDB Hot Backup tool that
is a program developed by Innobase Oy. InnoDB Hot Backup is a quality tool that allows an
administrator to create consistent backups of a running server without causing major system
slowdowns due to tables being locked. In addition to duplicating the functionality of InnoDB Hot
Backup, XtraBackup aims to bring additional features and functionality that will make the
database administrator’s life even easier.

There are two components of XtraBackup: xtrabackup and innobackupex. The xtrabackup
component is used to manage the actual backup of the InnoDB datafiles. The innobackupex
component is a Perl script that acts as a wrapper to xtrabackup and also manages MyISAM
tables, the InnoDB .frm files, triggers and views.

Hot backups with XtraBackup can be run with MySQL® Server versions 5.0 and 5.1 and any
version of InnoDB (5.0, 5.1, 1.0-plugin) or the XtraDB storage engine. MyISAM tables can also be
backed up although a read lock is placed on the MyISAM tables for the duration of the copy. This
means that users could be blocked from accessing these tables during the backup.

Limitations
The limitations of XtraBackup are very few and can be managed in most production setups. As
previously noted only InnoDB and XtraDB tables can be backed up without blocking modifications
to the tables being backed up.

New Features
In addition to implementing a non-blocking, consistent backup of InnoDB tables, XtraBackup
currently adds three major additional features over the InnoDB Hot Backup tool it is modeled
upon:

• Streaming backups

• I/O throttling

• Incremental backups

A streaming backup allows a server to push the backup files to another server for storage. This
can potentially solve two problems: the server being backed up does not have enough storage
space to save the backup and the need for remote storage to satisfy disaster recovery
requirements. Another use for streaming backups is the swift configuration of a server as a slave
or for development and testing.

While XtraBackup does not block connections from interacting with the database(s) being backed
up, the backup itself can cause problems because of its use of server I/O. To help resolve this
problem XtraBackup can throttle the amount of I/O used by the backup program.

The addition of incremental backups is a great feature to reduce your storage needs. For
example, many backup plans consist of a full backup one a week and then nightly incremental
backups for the other six days of the week. With a large database this can save a tremendous
amount of space and yet give you the security of knowing that backups are being performed
every night.
Installation of XtraBackup
XtraBackup is available as either source code or binaries. Binaries are available at
http://www.percona.com/mysql/xtrabackup. Currently the binaries cover Red Hat Enterprise
Linux versions four and five, a Debian package, FreeBSD, OS X and a generic GNU/Linux binary.
All are 64-bit versions. Installation is as simple as installing the appropriate package, or
unzipping the binary and copying the files to a good location.

Source compilation
Compiling the XtraBackup program is fairly easy, although a little different than a typical
compilation. To begin you will need the source code for both XtraBackup and MySQL® Server.
The source code for XtraBackup is available here at https://launchpad.net/percona-xtrabackup
while MySQL® Server source code is available at http://dev.mysql.com/downloads.

To begin you download and unzip the source code:

[root@mordor mysql_build]# wget http://www.percona.com/mysql/xtrabackup/0.8/source/xtrabackup-0.8-src.tar.gz
--16:50:47-- http://www.percona.com/mysql/xtrabackup/0.8/source/xtrabackup-0.8-src.tar.gz
Resolving www.percona.com... 66.135.55.221
Connecting to www.percona.com|66.135.55.221|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 61393 (60K) [application/x-gzip]
Saving to: `xtrabackup-0.8-src.tar.gz'

100%
[===============================================================================================================
=====>] 61,393 347K/s in 0.2s

16:50:47 (347 KB/s) - `xtrabackup-0.8-src.tar.gz' saved [61393/61393]

[root@mordor mysql_build]# gunzip xtrabackup-0.8-src.tar.gz

[root@mordor mysql_build]# tar -xvf xtrabackup-0.8-src.tar
xtrabackup-0.8-src/
xtrabackup-0.8-src/Makefile
xtrabackup-0.8-src/fix_innodb_for_backup.patch
xtrabackup-0.8-src/xtrabackup.c
xtrabackup-0.8-src/tar4ibd_libtar-1.2.11.patch
xtrabackup-0.8-src/innobackupex-1.5.1
xtrabackup-0.8-src/utils/
xtrabackup-0.8-src/utils/build51tree.sh
xtrabackup-0.8-src/utils/buildtree.sh
xtrabackup-0.8-src/utils/xtrabackup.spec
xtrabackup-0.8-src/utils/prepare_tree_for_rpm.sh
xtrabackup-0.8-src/utils/deb/
xtrabackup-0.8-src/utils/deb/Makefile
xtrabackup-0.8-src/utils/deb/description-pak
xtrabackup-0.8-src/fix_innodb_for_backup51.patch
xtrabackup-0.8-src/BUILD.txt
[root@mordor mysql_build]# wget http://dev.mysql.com/get/Downloads/MySQL-5.0/mysql-
5.0.83.tar.gz/from/http://opensource.become.com/mysql/
--16:52:21-- http://dev.mysql.com/get/Downloads/MySQL-5.0/mysql-
5.0.83.tar.gz/from/http://opensource.become.com/mysql/
Resolving dev.mysql.com... 213.136.52.29
Connecting to dev.mysql.com|213.136.52.29|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://opensource.become.com/mysql/Downloads/MySQL-5.0/mysql-5.0.83.tar.gz [following]
--16:52:22-- http://opensource.become.com/mysql/Downloads/MySQL-5.0/mysql-5.0.83.tar.gz
Resolving opensource.become.com... 64.124.85.129
Connecting to opensource.become.com|64.124.85.129|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 35937401 (34M) [application/x-gzip]
Saving to: `mysql-5.0.83.tar.gz'
100%
[===============================================================================================================
=====>] 35,937,401 392K/s in 1m 50s

16:54:13 (318 KB/s) - `mysql-5.0.83.tar.gz' saved [35937401/35937401]

[root@mordor mysql_build]# gunzip mysql-5.0.83.tar.gz

[root@mordor mysql_build]# tar -xvf mysql-5.0.83.tar
mysql-5.0.83/
mysql-5.0.83/BUILD/
mysql-5.0.83/BUILD/compile-darwin-mwcc
mysql-5.0.83/BUILD/compile-pentium-gcov
mysql-5.0.83/BUILD/compile-pentium-debug-no-bdb
mysql-5.0.83/BUILD/Makefile.am
mysql-5.0.83/BUILD/compile-pentium-icc-valgrind-max
mysql-5.0.83/BUILD/compile-pentium64-gcov
mysql-5.0.83/BUILD/compile-alpha
mysql-5.0.83/BUILD/compile-pentium-mysqlfs-debug
mysql-5.0.83/BUILD/compile-amd64-gprof
mysql-5.0.83/BUILD/compile-pentium64-valgrind-max
mysql-5.0.83/BUILD/compile-ia64-debug-max
mysql-5.0.83/BUILD/compile-amd64-debug-max
mysql-5.0.83/BUILD/compile-ppc-debug
mysql-5.0.83/BUILD/compile-pentium
mysql-5.0.83/BUILD/compile-solaris-amd64-forte-debug
mysql-5.0.83/BUILD/compile-ppc-max
mysql-5.0.83/BUILD/Makefile.in
mysql-5.0.83/BUILD/compile-amd64-max-sci
. . . . . cut for brevity!!! . . . .
[root@mordor mysql_build]#
Once this is done you will need to copy either the fix_innodb_for_backup or
fix_inndob_for_backup51 patch file (for server versions 5.0 and 5.1 respectively) from the
xtrabackup directory to the base directory of your MySQL® source code:

[root@mordor mysql_build]# cp xtrabackup-0.8-src/fix_innodb_for_backup.patch mysql-5.0.83/

You also need to copy the XtraBackup source directory to the innobase directory in the MySQL®
source code. Once this is done you can patch the innobase files with the included patch:
[root@mordor mysql_build]# cp -R xtrabackup-0.8-src/ mysql-5.0.83/innobase/
[root@mordor mysql_build]# cd mysql-5.0.83
[root@mordor mysql-5.0.83]# patch -p1 < fix_innodb_for_backup.patch
patching file innobase/buf/buf0buf.c
patching file innobase/buf/buf0rea.c
patching file innobase/fil/fil0fil.c
patching file innobase/include/mem0mem.h
patching file innobase/include/mem0mem.ic
patching file innobase/include/srv0start.h
patching file innobase/include/ut0byte.ic
patching file innobase/log/log0log.c
patching file innobase/log/log0recv.c
patching file innobase/mem/mem0mem.c
patching file innobase/os/os0file.c
patching file innobase/os/os0thread.c
patching file innobase/srv/srv0start.c
patching file innobase/trx/trx0trx.c
There are minimal prerequisites for the build. I needed the gcc-c++ and ncurses-devel rpm
packages on a stock Red Hat 5.3 64-bit server installation.

Once this is done you should begin the build process:

[root@mordor mysql-5.0.83]# ./configure; make
When this part of the process completes (which could take a while) you will need to finish up the
compilation by running make in the xtrabackup directory:
[root@mordor mysql-5.0.83]# cd innobase/xtrabackup-0.8-src/

[root@mordor xtrabackup-0.8-src]# make

cc -O2 -g -fmessage-length=0 -D_FORTIFY_SOURCE=2 -I. -I.. -I./../include -I./../../include -DUNIV_LINUX

-DMYSQL_SERVER -c xtrabackup.c

cc -O2 -g -fmessage-length=0 -D_FORTIFY_SOURCE=2 xtrabackup.o ../usr/libusr.a ../srv/libsrv.a

../dict/libdict.a ../que/libque.a ../srv/libsrv.a ../ibuf/libibuf.a ../row/librow.a ../pars/libpars.a
../btr/libbtr.a ../trx/libtrx.a ../read/libread.a ../usr/libusr.a ../buf/libbuf.a ../ibuf/libibuf.a
../eval/libeval.a ../log/liblog.a ../fsp/libfsp.a ../fut/libfut.a ../fil/libfil.a ../lock/liblock.a
../mtr/libmtr.a ../page/libpage.a ../rem/librem.a

../thr/libthr.a ../sync/libsync.a ../data/libdata.a ../mach/libmach.a ../ha/libha.a ../dyn/libdyn.makea

../mem/libmem.a ../sync/libsync.a ../ut/libut.a ../os/libos.a ../ut/libut.a ../../mysys/libmysys.a
../../strings/libmystrings.a -lpthread -o xtrabackup

Once the compilation process is completed successfully, you will have a binary executable called
xtrabackup in this directory. In addition, there is a copy of the innobackupex script. Copy both
of these to the desired location on your system and you are ready.

Incorporating XtraBackup
There are two parts to any backup scenario: the backup and the restore. They are equally
important! Do not forget the restoration process and you should always be performing test
restores. This is especially true if you are just getting started with XtraBackup.

Backup
The primary function of XtraBackup is to perform a backup. Doing so proves to be fairly easy. In
the following example the innobackupex script is used in order to show how XtraBackup can
interact with MyISAM tables. A username/password for access to the MySQL® server must be
specified along with a directory in which to store the backups:
-bash-3.2$ /usr/bin/innobackupex-1.5.1 --user=root --password=pa$$W0rd /backup/full_backup

InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy.

All Rights Reserved.

This software is published under

the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.

IMPORTANT: Please check that the backup run completes successfully.

At the end of a successful backup run innobackup
prints "innobackup completed OK!".

innobackupex: Using mysql Ver 14.12 Distrib 5.0.45, for redhat-linux-gnu (x86_64) using readline 5.0
innobackupex: Using mysql server version 5.0.45

innobackupex: Created backup directory /backup/full_backup/2009-07-08_10-05-00

090708 10:05:00 innobackupex: Starting mysql with options: --unbuffered --password=pa$$W0rd --user=root
090708 10:05:00 innobackupex: Connected to database with mysql child process (pid=4044)
090708 10:05:04 innobackupex: Connection to database server closed

090708 10:05:04 innobackupex: Starting ibbackup with command: xtrabackup --backup --suspend-at-end --target-
dir=/backup/full_backup/2009-07-08_10-05-00
innobackupex: Waiting for ibbackup (pid=4051) to suspend
innobackupex: Suspend file '/backup/full_backup/2009-07-08_10-05-00/xtrabackup_suspended'

xtrabackup Ver rc-0.7 for 5.0.83 unknown-linux-gnu (x86_64)

xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: Target instance is assumed as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 5242880
>> log scanned up to (0 375363931)
Copying ./ibdata1
to /backup/full_backup/2009-07-08_10-05-00/ibdata1
>> log scanned up to (0 375363931)
...done

090708 10:05:12 innobackupex: Continuing after ibbackup has suspended

090708 10:05:12 innobackupex: Starting mysql with options: --unbuffered --password=pa$$W0rd --user=root
090708 10:05:12 innobackupex: Connected to database with mysql child process (pid=4058)
090708 10:05:16 innobackupex: Starting to lock all tables...
>> log scanned up to (0 375363931)
>> log scanned up to (0 375366249)
>> log scanned up to (0 375366355)
>> log scanned up to (0 375366361)
090708 10:05:32 innobackupex: All tables locked and flushed to disk

090708 10:05:32 innobackupex: Starting to backup .frm, .MRG, .MYD, .MYI,

innobackupex: .TRG, .TRN, and .opt files in
innobackupex: subdirectories of '/var/lib/mysql'
innobackupex: Backing up files '/var/lib/mysql/mysql/*.{frm,MYD,MYI,MRG,TRG,TRN,opt}' (52 files)
innobackupex: Backing up files '/var/lib/mysql/sakila/*.{frm,MYD,MYI,MRG,TRG,TRN,opt}' (36 files)
090708 10:05:32 innobackupex: Finished backing up .frm, .MRG, .MYD, .MYI, .TRG, .TRN, and .opt files

innobackupex: Resuming ibbackup

xtrabackup: The latest check point (for incremental): '0:375366361'

>> log scanned up to (0 375366361)
xtrabackup: Stopping log copying thread.
xtrabackup: Transaction log of lsn (0 375363931) to (0 375366361) was copied.
090708 10:05:37 innobackupex: All tables unlocked
090708 10:05:37 innobackupex: Connection to database server closed

innobackupex: Backup created in directory '/backup/full_backup/2009-07-08_10-05-00'

innobackupex: MySQL binlog position: filename '', position
090708 10:05:37 innobackupex: innobackup completed OK!
-bash-3.2$
With the innobackupex script, by default, the backup is created in a subdirectory that
corresponds to the date/time when the backup was executed in the specified backup directory.
Notice that the backup records the last checkpoint used by InnoDB. This could be used to create
an incremental backup where the incremental backup would begin from the point where this full
backup ended. This checkpoint is also stored in the file xtrabackup_checkpoints in the root of
the specified backup directory.

Restore
You can create a backup by either running the innobackup script or the xtrabackup command.
Of course, you need to keep in mind that the xtrabackup command will ONLY backup InnoDB or
XtraDB tables. In either case, in order to perform a restore, you must run xtrabackup a second
time to “prepare” the backup files. Preparing the backup files is done by using the --prepare
option with xtrabackup. This step recreates the ib_logfile* files. Once this step is complete,
you are ready to move the backup files into place. The following shows a restore of the previous
full backup using the innobackupex script. Once the restore is done it is moved into place using
the copy-back option:

-bash-3.2$ innobackupex-1.5.1 --apply-log /backups/full_backups/2009-07-14_19-15-03/

innobackupex: Warning: Your perl is too old! Innobackup requires
innobackupex: Warning: perl 5.0.5 or newer!

InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy.

All Rights Reserved.
This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.

IMPORTANT: Please check that the apply-log run completes successfully.

At the end of a successful apply-log run innobackup
prints "innobackup completed OK!".

090714 19:16:38 innobackupex: Starting ibbackup with command: xtrabackup --prepare --target-
dir=/backups/full_backups/2009-07-14_19-15-03

xtrabackup Ver rc-0.7 for 5.0.83 unknown-linux-gnu (x86_64)

xtrabackup: cd to /backups/full_backups/2009-07-14_19-15-03
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(0 1111680534)
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: Log scan progressed past the checkpoint lsn 0 1111680534
090714 19:16:39 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Doing recovery: scanned up to log sequence number 0 1111684469 (0 %)
090714 19:16:39 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: (space:52 is deleted) (space:52 is deleted)14 15 16 17 18 19 20 21 22 23 24 25 26
27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 530, file name ./mysql-bin.000003
090714 19:16:40 InnoDB: Started; log sequence number 0 1111684469

[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 530, file name ./mysql-bin.000003

xtrabackup: starting shutdown with innodb_fast_shutdown = 1

090714 19:16:40 InnoDB: Starting shutdown...
090714 19:16:41 InnoDB: Shutdown completed; log sequence number 0 1111684469

090714 19:16:41 innobackupex: Restarting xtrabackup with command: xtrabackup --prepare --target-
dir=/backups/full_backups/2009-07-14_19-15-03
for creating ib_logfile*

xtrabackup Ver rc-0.7 for 5.0.83 unknown-linux-gnu (x86_64)

xtrabackup: cd to /backups/full_backups/2009-07-14_19-15-03
xtrabackup: This target seems to be already prepared.
xtrabackup: notice: xtrabackup_logfile was already used to '--prepare'.
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 67108864
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
090714 19:16:41 InnoDB: Log file ./ib_logfile0 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile0 size to 64 MB
InnoDB: Database physically writes the file full: wait...
090714 19:16:43 InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 size to 64 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
090714 19:16:45 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Last MySQL binlog file position 0 530, file name ./mysql-bin.000003
090714 19:16:45 InnoDB: Started; log sequence number 0 1111684620

[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 530, file name ./mysql-bin.000003

xtrabackup: starting shutdown with innodb_fast_shutdown = 1

090714 19:16:45 InnoDB: Starting shutdown...
090714 19:16:46 InnoDB: Shutdown completed; log sequence number 0 1111684620
090714 19:16:46 innobackupex: innobackup completed OK!
-bash-3.2$

When performing a restore, it will be necessary to remove any old data files. Of course the
MySQL® daemon must be shut down before this process begins. Once the restore is done you
should check the permissions of the restored directories, modify as necessary and then you
should be able to start up the MySQL® server.
-bash-3.2$ innobackupex-1.5.1 --copy-back /backups/full_backups/2009-07-14_19-15-03/
innobackupex: Warning: Your perl is too old! Innobackup requires
innobackupex: Warning: perl 5.0.5 or newer!

InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy.

All Rights Reserved.

This software is published under

the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.

IMPORTANT: Please check that the copy-back run completes successfully.

At the end of a successful copy-back run innobackup
prints "innobackup completed OK!".

innobackupex: Starting to copy MyISAM tables, indexes,

innobackupex: .MRG, .TRG, .TRN, .ARM, .ARZ, .opt, and .frm files
innobackupex: in '/backups/full_backups/2009-07-14_19-15-03'
innobackupex: back to original data directory '/var/lib/mysql'
innobackupex: Copying file '/backups/full_backups/2009-07-14_19-15-03/xtrabackup_binlog_info'
innobackupex: Copying file '/backups/full_backups/2009-07-14_19-15-03/xtrabackup_checkpoints'
innobackupex: Copying directory '/backups/full_backups/2009-07-14_19-15-03/test'
innobackupex: Copying directory '/backups/full_backups/2009-07-14_19-15-03/mysql'
innobackupex: Copying directory '/backups/full_backups/2009-07-14_19-15-03/sakila'
innobackupex: Copying directory '/backups/full_backups/2009-07-14_19-15-03/employees'

innobackupex: Starting to copy InnoDB tables and indexes

innobackupex: in '/backups/full_backups/2009-07-14_19-15-03'
innobackupex: back to original InnoDB data directory '/var/lib/mysql/'
innobackupex: Copying file '/backups/full_backups/2009-07-14_19-15-03/ibdata1'

innobackupex: Starting to copy InnoDB log files

innobackupex: in '/backups/full_backups/2009-07-14_19-15-03'
innobackupex: back to original InnoDB log directory '/var/lib/mysql/'
innobackupex: Copying file '/backups/full_backups/2009-07-14_19-15-03/ib_logfile0'
innobackupex: Copying file '/backups/full_backups/2009-07-14_19-15-03/ib_logfile1'
innobackupex: Finished copying back files.

090714 19:20:50 innobackupex: innobackup completed OK!

-bash-3.2$

At this point you just start up the MySQL server and you are done with a full backup and restore.
In the example the database server contained the sakila and employees sample databases:
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| employees |
| sakila |
+--------------------+
4 rows in set (0.00 sec)

Note
If you run the innobackupex and xtrabackup programs as the same user who runs the MySQL®
server daemon you should not have permissions issues. While this can take more planning up
front, it will create a smoother restore process.

Streaming backup
Being able to stream your backup gives you the option to perform a backup on one server and
store it on a second server. If you had a 500 gigabyte database and only have 50 gigabytes of
free space on the server you need to be able to stream the backup to a second server. The
option for this is --stream. Here is an example of a streamed backup:

-bash-3.2$ innobackupex-1.5.1 --user=root --password='passwd' --stream=tar | ssh ip_add:/backup “tar xfi –“

In order to use ssh for streaming of your backup you will need to configure a password-less log in
using ssh keys.

Creating ssh keys

Creating ssh keys is done using the ssh-keygen program. The following shows the creation of a
keypair:
-bash-3.2$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/backup/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/backup/.ssh/id_rsa.
Your public key has been saved in /home/backup/.ssh/id_rsa.pub.
The key fingerprint is:
d6:38:c8:f8:39:13:1d:36:c5:be:e0:77:e7:c0:40:c3 backup@p2036938.pubip.peer1.net
-bash-3.2$ ls
id_rsa id_rsa.pub
-bash-3.2$ ls -la
total 16
drwxr-xr-x 2 backup backup 4096 Jun 23 10:04 .
drwxr-xr-x 12 backup backup 4096 Jun 23 09:59 ..
-rw------- 1 backup backup 1671 Jun 23 10:04 id_rsa
-rw-r--r-- 1 backup backup 412 Jun 23 10:04 id_rsa.pub
-bash-3.2$
The id_rsa file is the private key that must be secured on your server where the backups will be
performed. Notice that it is only readable and writeable by the owner of the file (the backup user
in this case). The id_rsa.pub file is the public key and can be read by anyone with no security
implications.

In this case, the content of file id_rsa.pub is

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEArkwv9X8eTVK4F7pMlSt45pWoiakFkZMw
G9BjydOJPGH0RFNAy1QqIWBGWv7vS5K2tr+EEO+F8WL2Y/jK4ZkUoQgoi+n7DWQVOHsR
ijcS3LvtO+50Np4yjXYWJKh29JL6GHcp8o7+YKEyVUMB2CSDOP99eF9g5Q0d+1U2WVdB
WQM= backup@p2036938.pubip.peer1.net
This file should be copied to the system on which you want ssh access without being prompted for a password
and saved in the file authorized_keys in the .ssh directory for the user.

For example, if Bob wants to access the server db1.company.com using the username bob from his
workstation ps12.company.com he would run ssh-keygen on ps12.company.com and then added
the public key to the authorized_keys file in the .ssh directory located in his home directory. If Bob
had not configured any other servers for password-less ssh access he would need to create the .ssh directory in
his home directory and copy the public key file to /home/bob/.ssh/authorized_keys.

I/O throttling
While the backup process does not lock the database if only InnoDB tables are used there is
another potential problem. The I/O activity of the backup itself can cause slowness of the server.
If this is a problem with your backup, you can use the I/O throttling option in order to control the
amount of I/O generated by the backup. The I/O throttling option is --throttle. You specify the
number of IOPS (Input/Output Operations a Second) based on the capabilities of your database
server. For example, you might want to limit the IOPS to 50 in order to keep the backup from
interfering with the normal server operation. To do this you could run something like this:
-bash-3.2$ innobackupex-1.5.1 --user=root --password='password' --throttle=50 /backup/
It is possible to throttle the backup so much that it actually can’t go any faster than the ongoing
updates to the system. In this case your backup would actually never finish. While this is a very
useful option for XtraBackup, use it with care and careful initial testing.

Incremental backups
An incremental backup is a backup of the data that has changed since a previous backup (either
a full backup or an incremental backup). Incremental backups can be used to reduce the
amount of time it takes a backup to be performed. It does this at the expense of requiring a
longer restoration time.

When XtraBackup is run it outputs the last LSN value used by InnoDB. An LSN is a Log Sequence
Number that is used to create checkpoints in the InnoDB log files. During a full backup of a
MySQL® server the LSN of the last checkpoint is recorded as part of the backup. When
performing an incremental backup this LSN is used so that only the changes that occur after this
LSN are recorded.

The following shows the command used to perform a full backup:

-bash-3.2$ innobackupex1.5.1 user=root password='pa$$w0rd' /backup/full_backup

The next time a backup is run the LSN value, which is stored in the xtrabackup_checkpoints file
of the full backup, can be used to tell XtraBackup where to begin:
-bash-3.2$ cat xtrabackup_checkpoints
backup_type = fullprepared
from_lsn = 0:0
to_lsn = 0:469826382

As you can see the LSN value at the end of the full backup was 469909878. To record all
changes since the end of the full backup:
-bash-3.2$ xtrabackup --user=root --password='pa$$w0rd' --backup --incremenetal_ lsn=0:469826382
--targetdir=/backup/incremental_one

To restore your incremental backup you do something like the following:

-bash-3.2$ xtrabackup --prepare targetdir=/backup --incrementaldir=/backup/incremental_one

This must be done after your full backup is restored. If you have multiple incremental backups
they must be restored in order (Monday's backup first, then Tuesday etc). And do not forget to
test the restoration process! All the backups in the world will not do you any good if they are
corrupted by being incorrectly performed or the restoration fails because of a problem with
syntax. Take the time now to understand your system before it becomes necessary.

Summary
When first looking at XtraBackup, it can be quite intimidating. Like the late night commercials, it
seems like it is a continual “but wait . . . there’s more!!” The good news is that every feature is
designed to make backups better and more flexible. There is nothing extra here, everything is
about backups. Take the time to learn XtraBackup and the available options and it will serve you
well. There is nothing more important to a database administrator than performing backups (and
the attendant restores). XtraBackup is an open source tool that can make performing backups as
painless and powerful as possible.

Resources
XtraBackup wiki http://www.percona.com/docs/wiki/percona-xtrabackup:start
XtraBackup binary downloads http://www.percona.com/mysql/xtrabackup/
XtraBackup source code https://launchpad.net/percona-xtrabackup
XtraBackup newsgroup http://groups.google.com/group/percona-discussion

Sakila sample database http://dev.mysql.com/doc/

Employees sample database http://dev.mysql.com/doc/employee/en/employee.html