一、 简单介绍
我们知道。针对InnoDB存储引擎。MySQL本身没有提供合适的热备工具，ibbackup虽是一款高效的首选热备方式，但它是是收费的。
好在Percona公司给大家提供了一个开源、免费的Xtrabackup热备工具，它可实现ibbackup的全部功能，而且还扩展支持真正的增量备份功能，是商业备份工具InnoDB Hotbackup的一个非常好的替代品。
Xtrabackup包括两个主要工具：Xtrabackup和innobackupex：
Xtrabackup仅仅能备份InnoDB和XtraDB两种引擎表，而不能备份MyISAM数据表。
innobackupex则是參考InnoDBHotbackup的innoback脚本改动而来的一个perl脚本。它封装了xtrabackup，主要是为了能方便的同一时候备份InnoDB和MyISAM引擎表。但在处理MyISAM时须要加一个读锁。这会堵塞线上服务的写操作，所以数据库中MyISAM表越少越好。
另外，该工具还加入了一些其他使用选项。比方slave-info，能够在备份中记录一些Slave须要的信息，依据这些信息，能够非常方便的利用备份重做Slave。
通过Xtrabackup，不但可在线（热）备份整个库的InnoDB、XtraDB表，还可在上一次整库备份的基础上做增量备份（InnoDB only）。其工作原理例如以下：
首先完毕一个全然备份。并记录下此时检查点的LSN（Log Sequence Number）；在进行增量备份时，比較表空间中每一个页的LSN是否大于上次备份时的LSN，假设是，则备份该页，同一时候记录当前检查点的LSN。
注意：在增量备份时。作为备份基础的全备文件不能压缩，否则备份失效。另外，增量备份期间。表结构变更的话。变更部分的备份也会失效。
二、安装
Pecona官方站点提供了Xtrabackup源代码包、二进制包以及RPM包三种安装包，下载地址为：http://www.percona.com/downloads/XtraBackup/ 本文选择最简单方便的RPM包安装，例如以下：
[root@db ~]# rpm -ivh percona-xtrabackup-2.0.5-499.rhel5.x86_64.rpm
warning: percona-xtrabackup-2.0.5-499.rhel5.x86_64.rpm:Header V4 DSA signature: NOKEY, key ID cd2efd2a
Preparing... ########################################### [100%]
1:percona-xtrabackup ########################################### [100%]
安装完毕后，会在/usr/bin/文件夹下生成例如以下命令工具：
[root@db ~]# cd /usr/bin/
[root@db bin]# ls xtr* inno*
innobackupex innochecksum xtrabackup_51 xtrapchar xtrapinfo xtrapproto xtrapstats
innobackupex-1.5.1 xtrabackup xtrabackup_55 xtrapin xtrapout xtrapreset
当中：
innobackupex 是备份时直接使用的工具，它是一个perl脚本，内部封装xtrabackup。
innobackupex-1.5.1 是innobackupex文件的一个软链接；
xtrabackup 是备份Innodb引擎的脚本；
xtrabackup_51 xtrabackup运行时须要调用的工具，适用于MySQL 5.1版本号；
xtrabackup_55 xtrabackup运行时须要调用的工具，适用于MySQL 5.5版本号；
三、Xtrabackup的使用
首先来学习使用Xtrabackup这个命令工具。前面提到：它仅仅能备份InnoDB和XtraDB两种引擎表，不能备份MyISAM数据表。
通过--help參数查看该命令的使用方法。例如以下：
Usage: [xtrabackup [--default-file=#] --backup | xtrabackup [--defaults-file=#] --prepare] [OPTIONS]
參数解读例如以下：
| --defaults-file=# | 标识默认的配置文件，可显式手工指定，也可不设置；若不设置，则Xtrabackup缺省将从以下文件夹查找配置文件： |
| /etc/my.cnf | |
| /etc/mysql/my.cnf | |
| /usr/local/etc/my.cnf | |
| ~/.my.cnf | |
| 然后从中读取[mysqld]和[xtrabackup]配置段。[mysqld]中仅仅需指定datadir、innodb_data_home_dir、innodb_data_file_path、innodb_log_group_home_dir、innodb_log_files_in_group、innodb_log_file_size这6个參数就可以让Xtrabackup正常工作。 | |
| --defaults-extra-file=# | 假设使用了该參数，则会在读取了全局配置文件后，再读取这里指定的配置文件 |
| --target-dir=name | 备份文件的存放路径 |
| --backup | 运行备份操作。将备份文件存放到target-dir指定的文件夹下 |
| --prepare | 对备份文件运行恢复前的准备（生成InnoDB logfile） |
| --print-param | 打印备份或恢复时须要的參数 |
| --use-memory=# | 该參数在prepare的时候使用。控制prepare时innodb实例使用的内存量 |
| --suspend-at-end | 在target-dir文件夹下产生一个xtrabackup_suspended文件，将xtrabackup进程挂起，不停地将数据文件的变化同步到备份文件。直到用户手工删除xtrabackup_suspended文件 |
| --throttle=# | 每秒钟IO次数，限制backup时使用的I/O操作量。使备份对数据库正常业务的影响最小化 |
| --log-stream | 该參数在backup时使用。将xtrabackup_logfile的内容输出到标准输出，使用该參数时会自己主动使用suspend-at-end參数，innobackupex脚本的stream模式会使用该參数。 |
| --incremental-lsn=name | 增量备份时仅仅拷贝LSN比该參数指定值新的ibd pages。前次备份到了哪个LSN能够看前次备份集的xtrabackup_checkpoints文件 |
| --incremental-basedir=name | 该參数在backup的时候使用，备份比该參数指定位置的备份集新的idb pages |
| --incremental-dir=name | 该參数在prepare的时候使用，指定prepare时产生的delta文件和日志文件的存放路径 |
| --tables=name | 在备份file-per-table类型的文件时使用，使用正則表達式指定须要备份的innodb表 |
| -h, --datadir=name | MySQL数据库的数据文件文件夹 |
演示样例1：全然备份与恢复(InnoDB)
(1)备份
脚本内容：
[root@db xtrabak]# more xtra_backup.sh
# 2014-04-29
mkdir -p /data/xtrabak/bak_`date +%F`/
echo "backup begin" `date`
xtrabackup --defaults-file=/etc/my.cnf --backup --target-dir=/data/xtrabak/bak_`date +%F`/
cp -r /var/lib/mysql/test /data/xtrabak/bak_`date +%F`/
注意：xtrabackup仅仅备份数据文件，并不备份数据表结构文件（.frm）。所以还需手动拷贝一下，以便xtrabackup恢复时使用
运行备份脚本：
[root@db xtrabak]# sh xtra_backup.sh
backup begin Tue Apr 29 15:22:09 CST 2014
xtrabackup version 2.0.5 for Percona Server 5.1.59 unknown-linux-gnu (x86_64) (revision id: 499)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql/
xtrabackup: Target instance is assumed as followings.
xtrabackup: innodb_data_home_dir = /var/lib/mysql
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = /var/lib/mysql
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 5242880
>> log scanned up to (1830807)
[01] Copying /var/lib/mysql/ibdata1 to /data/xtrabak/bak_2014-04-29/ibdata1
[01] ...done
xtrabackup: The latest check point (for incremental): '1830807'
xtrabackup: Stopping log copying thread.
.>> log scanned up to (1830807)
xtrabackup: Transaction log of lsn (1830807) to (1830807) was copied.
从输出能够看出，备份过程首先记录LSN。然后拷贝数据文件（注意。并没有备份表结构文件.frm），最后拷贝并记录LSN。备份完毕后，在指定目标文件夹除了拷贝过来的数据文件ibdata1及表结构文件夹test外，还生成了另外两个文件，分别记录日志及检查点。例如以下：
[root@db xtrabak]# cd bak_2014-04-29/
[root@db bak_2014-04-29]# ls
ibdata1 test xtrabackup_checkpoints xtrabackup_logfile
恢复
删除库test，然后通过备份文件运行恢复，例如以下：
脚本内容：
[root@db xtrabak]# more xtra_prepare.shxtrabackup --defaults-file=/etc/my.cnf --prepare --target-dir=/data/xtrabak/bak_`date +%F`/
cp -r /data/xtrabak/bak_`date +%F`/test/ /var/lib/mysql/
rm /var/lib/mysql/ib*
cp /data/xtrabak/bak_`date +%F`/ib* /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql
service mysql restart
说明：脚本中步骤依次为：
实施对备份文件进行恢复前的准备。
从备份文件拷贝数据表结构到默认的数据文件夹；
删除默认数据文件夹中相应的数据文件并复制备份的数据文件到默认数据文件夹。
改动默认数据文件夹权限并重新启动MySQL服务
运行恢复脚本：
[root@db xtrabak]# sh xtra_prepare.sh
xtrabackup version 2.0.5 for Percona Server 5.1.59 unknown-linux-gnu (x86_64) (revision id: 499)
xtrabackup: cd to /data/xtrabak/bak_2014-04-29/
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(1830807)
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: 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: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
140429 15:28:34 InnoDB: Initializing buffer pool, size = 100.0M
140429 15:28:34 InnoDB: Completed initialization of buffer pool
140429 15:28:34 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
140429 15:28:34 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 85912, file name ./mysql-bin.000026
140429 15:28:34 Percona XtraDB (http://www.percona.com) 1.0.17-12.5 started; log sequence number 1830807
[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 85912, file name ./mysql-bin.000026
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
140429 15:28:34 InnoDB: Starting shutdown...
140429 15:28:34 InnoDB: Shutdown completed; log sequence number 1832037
Shutting down MySQL.... [ OK ]
Starting MySQL. [ OK ]
运行完毕后，检查发现test库已成功恢复。
演示样例2：增量备份与恢复
增量备份是以全然备份或上一次增量备份为基础的备份。适合数据库非常大的情况，支持在线热备。备份期间不锁定表，不影响用户使用。备份恢复效率都比較高。
以下我们来模拟一次增量备份：
（1） 全然备份
如今test库有三张表。运行一次全然备份
－－脚本内容：
[root@db xtrabak]# more xtra_full_bak.sh
# 2014-04-29
mkdir -p /data/xtrabak/full_bak_`date +%F`/
xtrabackup --defaults-file=/etc/my.cnf --backup --target-dir=/data/xtrabak/full_bak_`date +%F`/
cp -r /var/lib/mysql/test/ /data/xtrabak/full_bak_`date +%F`/
－－运行脚本
[root@db xtrabak]# sh xtra_full_bak.sh
xtrabackup version 2.0.5 for Percona Server 5.1.59 unknown-linux-gnu (x86_64) (revision id: 499)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: Target instance is assumed as followings.
xtrabackup: innodb_data_home_dir = /var/lib/mysql
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = /var/lib/mysql
xtrabackup: innodb_log_files_in_group = 3
xtrabackup: innodb_log_file_size = 67108864
>> log scanned up to (1653514)
[01] Copying /var/lib/mysql/ibdata1 to /data/xtrabak/full_bak_2014-04-29/ibdata1
[01] ...done
xtrabackup: The latest check point (for incremental): '1653514'
xtrabackup: Stopping log copying thread.
.>> log scanned up to (1653514)
xtrabackup: Transaction log of lsn (1653514) to (1653514) was copied.
运行完毕后，查看备份文件
[root@db xtrabak]# cd full_bak_2014-04-29/
[root@db full_bak_2014-04-29]# ls
ibdata1 test xtrabackup_checkpoints xtrabackup_logfile
（2） 增量备份
向test库中加入一张新表，然后运行增量备份
－－脚本内容：
[root@db xtrabak]# more xtra_delta_bak.sh
# 2014-04-29
mkdir -p /data/xtrabak/delta_bak_`date +%F`/
xtrabackup --defaults-file=/etc/my.cnf --backup --target-dir=/data/xtrabak/delta_bak_`date +%F`/ --incremental-basedir=/data/xtrabak/full_bak_`date +%F`/
cp -r /var/lib/mysql/test/ /data/xtrabak/full_bak_`date +%F`/
说明：这里须要再次拷贝test库的表结构文件，由于期间可能会添加或删除表
－－运行脚本
[root@db xtrabak]# sh xtra_delta_bak.sh
xtrabackup version 2.0.5 for Percona Server 5.1.59 unknown-linux-gnu (x86_64) (revision id: 499)
incremental backup from 1653514 is enabled.
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: Target instance is assumed as followings.
xtrabackup: innodb_data_home_dir = /var/lib/mysql
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = /var/lib/mysql
xtrabackup: innodb_log_files_in_group = 3
xtrabackup: innodb_log_file_size = 67108864
>> log scanned up to (1660436)
[01] Copying /var/lib/mysql/ibdata1 to /data/xtrabak/delta_bak_2014-04-29/ibdata1.delta
[01] ...done
xtrabackup: The latest check point (for incremental): '1660436'
xtrabackup: Stopping log copying thread.
.>> log scanned up to (1660436)
xtrabackup: Transaction log of lsn (1660436) to (1660436) was copied.
运行完毕后，查看备份文件
[root@db xtrabak]# cd delta_bak_2014-04-29/
[root@db delta_bak_2014-04-29]# ls
ibdata1.delta ibdata1.meta xtrabackup_checkpoints xtrabackup_logfile
注意：在增量备份文件夹下，数据文件是以.delta结尾的。增量备份仅仅备份上一次全然备份后被改动过的page；当然，若再次运行增量备份，能够上一次全然备份为基础，也能够第一次增量备份为基础，每次增量备份的文件夹都是须要改动的。
（3） 恢复
删除test库。模拟故障，然后通过全然备份及增量备份文件运行恢复。
－－脚本内容：
[root@db xtrabak]# more xtra_delta_prepare.sh
xtrabackup --defaults-file=/etc/my.cnf --prepare --target-dir=/data/xtrabak/full_bak_`date +%F`/
xtrabackup --defaults-file=/etc/my.cnf --prepare --target-dir=/data/xtrabak/full_bak_`date +%F`/ --incremental-dir=/data/xtrabak/delta_bak_`date +%F`/
cp -r /data/xtrabak/full_bak_`date +%F`/test/ /var/lib/mysql/
rm /var/lib/mysql/ib*
cp /data/xtrabak/full_bak_`date +%F`/ib* /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql
service mysql restart
－－运行脚本
[root@db xtrabak]# sh xtra_delta_prepare.sh
xtrabackup version 2.0.5 for Percona Server 5.1.59 unknown-linux-gnu (x86_64) (revision id: 499)
xtrabackup: cd to /data/xtrabak/full_bak_2014-04-29/
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(1653514)
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: 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: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
140429 18:28:21 InnoDB: Initializing buffer pool, size = 100.0M
140429 18:28:21 InnoDB: Completed initialization of buffer pool
140429 18:28:21 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
140429 18:28:21 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 2596, file name ./mysql-bin.000043
140429 18:28:22 Percona XtraDB (http://www.percona.com) 1.0.17-12.5 started; log sequence number 1653514
[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 2596, file name ./mysql-bin.000043
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
140429 18:28:22 InnoDB: Starting shutdown...
140429 18:28:22 InnoDB: Shutdown completed; log sequence number 1653514
xtrabackup version 2.0.5 for Percona Server 5.1.59 unknown-linux-gnu (x86_64) (revision id: 499)
incremental backup from 1653514 is enabled.
xtrabackup: cd to /data/xtrabak/full_bak_2014-04-29/
xtrabackup: This target seems to be already prepared.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(1660436)
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 = /data/xtrabak/delta_bak_2014-04-29/
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
xtrabackup: page size for /data/xtrabak/delta_bak_2014-04-29//ibdata1.delta is 16384 bytes
Applying /data/xtrabak/delta_bak_2014-04-29//ibdata1.delta to ././ibdata1...
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 = /data/xtrabak/delta_bak_2014-04-29/
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: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
140429 18:28:22 InnoDB: Initializing buffer pool, size = 100.0M
140429 18:28:22 InnoDB: Completed initialization of buffer pool
140429 18:28:22 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
140429 18:28:22 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 2703, file name ./mysql-bin.000045
140429 18:28:22 Percona XtraDB (http://www.percona.com) 1.0.17-12.5 started; log sequence number 1660436
[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 2703, file name ./mysql-bin.000045
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
140429 18:28:22 InnoDB: Starting shutdown...
140429 18:28:23 InnoDB: Shutdown completed; log sequence number 1660436
Shutting down MySQL... [ OK ]
Starting MySQL..... [ OK ]
运行成功后，检查发现test数据库已成功恢复。
四、 Innobackupex使用
前面提到，Innobackupex可同一时候备份InnoDB和MyISAM引擎表。所以通常都直接使用innobackupex。须要注意的是my.cnf中必须加上datadir这个參数。由于要依据它来定位InnoDB引擎的数据文件位置。
innobackupex也包括一系列參数，可通过innobackupex --help命令查看。此处不逐一说明了。
以下我们通过一个完整的演示样例来演示其使用方法。例如以下：
（1） 备份
－－脚本内容：
[root@db xtrabak]# more backup.sh
# 2014-04-29
mkdir -p /data/xtrabak/bak_`date +%F`/
echo "backup begin" `date`
log=innobackupex_`date +%F`.log
str=bak_`date +%F`
innobackupex --user=root --password=root123 --defaults-file=/etc/my.cnf --stream=tar /data/xtrabak/$str/ 2>/data/xtrabak/$log | gzip>/data/xtrabak/$str/base.tar.gz
echo "backup end" `date`
cp /etc/my.cnf /data/xtrabak/my_`date +%F`.cnf
－－运行脚本：
[root@db xtrabak]# sh backup.sh
backup begin Wed Apr 30 16:15:02 CST 2014
backup end Wed Apr 30 16:15:27 CST 2014
[root@db xtrabak]# cd bak_2014-04-30/
[root@db bak_2014-04-30]# ls
base.tar.gz
运行完毕后。生成备份文件的压缩包
（2） 增量日志备份
由于数据库不停的对外提供服务。备份之后的操作会记录到binlong日志文件里。所以我们还应备份兴许的日志文件。
此处删除几张表，并切换日志以模拟真实环境。备份完整的binlog日志文件；然后关闭数据库，删除数据库全部文件，以便模拟故障。
－－脚本内容（binlog备份到远程机器）:
[root@db xtrabak]# more binlog_bak.shcd /var/lib/
DATE=`date -d '-1 hour' +%Y%m%d%H00`
touch -t "${DATE}" starttemp
echo "$DATE"
umount /mnt_log>/dev/null 2>&1
mount -t nfs 192.168.3.108:/logcenter /mnt_log
find /var/lib/mysql/mysql-bin.* -newer starttemp|xargs -I {} cp -p {} /mnt_log/mysql-binlog/192.168.3.28/
# umount -t nfs /mnt_log
（3） 恢复
－－脚本内容：
[root@db xtrabak]# more prepare.sh
# 2014-04-30
service mysql stop
mkdir -p /data/xtrabak/prepare_`date +%F`/
tar -ixzvf /data/xtrabak/bak_`date +%F`/base.tar.gz -C /data/xtrabak/prepare_`date +%F`/
innobackupex --apply-log --user=root --defaults-file=/etc/my.cnf /data/xtrabak/prepare_`date +%F`/
innobackupex --copy-back --user=root --defaults-file=/etc/my.cnf /data/xtrabak/prepare_`date +%F`/
chown -R mysql:mysql /var/lib/mysql/
rm -rf /var/lib/mysql/xtrabackup_binlog_pos_innodb
service mysql restart
－－全然备份恢复后，通过binlog进行增量恢复
[root@db test]# mysqlbinlog start-position=****** /mnt_log/mysql-binlog/192.168.3.28/mysql-bin.000052 |mysql -uroot -proot123
注意：start-position的位置可通过解压后的备份文件查看，例如以下：
[root@db xtrabak]# cd prepare_2014-04-30/
[root@db prepare_2014-04-30]# more xtrabackup_binlog_infomysql-bin.000047 1472
或者
[root@db prepare_2014-04-30]# more xtrabackup_binlog_pos_innodb./mysql-bin.000047 1472
成功恢复后，MySQL就可以正常使用。