(2) xtrabackup_binlog_info —— mysql服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置。

 (若系统没开binlog则不会有这个文件)

(3)xtrabackup_binlog_pos_innodb —— 二进制日志文件及用于InnoDB或XtraDB表的二进制日志文件的当前position。

(4)xtrabackup_binary —— 备份中用到的xtrabackup的可执行文件；

(5)backup-my.cnf —— 备份命令用到的配置选项信息；

在使用innobackupex进行备份时，还可以使用--no-timestamp选项来阻止命令自动创建一个以时间命名的目录；如此一来，innobackupex命令将会创建一个BACKUP-DIR目录来存储备份数据。

2.全备恢复： 准备(prepare)一个完全备份,

之后，我们就可以根据backup-my.cnf中的配置把数据文件复制回对应的目录了，当然你也可以自己复制回去，但innobackupex都会帮我们完成。在这里，对于InnoDB表来说是完成“后准备”

动作，我们称之为“恢复(recovery)”，而对于MyISAM表来说由于备份时是采用锁表方式复制的，所以此时只是简单的复制回来，不需要apply log，这个我们称之为“还原(restore)”。

需要停库，可以备份一下之前损坏的数据库。

cd /var/lib

mv mysql mysql.old

mkdir mysql

chown mysql.mysql mysql

一般情况下，在备份完成后，数据尚且不能用于恢复操作，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。因此，此时数据文件仍处理不一致状态

。“准备”的主要作用正是通过回滚未提交的事务及同步已经提交的事务至数据文件也使得数据文件处于一致性状态。

innobakupex命令的--apply-log选项可用于实现上述功能。如下面的命令：

 innobackupex --defaults-file=/etc/mysql/my.cnf  --apply-log    /home/data/backup/full/2017-03-06_16-16-49

在实现“准备”的过程中，innobackupex通常还可以使用--use-memory选项来指定其可以使用的内存的大小，默认通常为100M。如果有足够的内存可用，可以多划分一些内存给prepare的过程，以提高其完成速度。

 innobackupex --defaults-file=/etc/mysql/my.cnf  --apply-log  --use-memory=5G  /home/data/backup/full/2017-03-06_16-16-49

 innobackupex --defaults-file=/etc/mysql/my.cnf  --apply-log --use-memory=5G --host=172.30.1.110  /home/data/backup/full/2017-03-06_16-16-49 （可选）

170213 17:14:06  innobackupex: Starting ibbackup with command: xtrabackup  --defaults-file="/home/data/backup/2017-02-13_17-11-22/backup-my.cnf"  --defaults-

group="mysqld" --prepare --target-dir=/home/data/backup/2017-02-13_17-11-22 --apply-log-only --use-memory=5G

xtrabackup: Starting InnoDB instance for recovery.

xtrabackup: Using 5368709120 bytes for buffer pool (set by --use-memory parameter)

InnoDB: Using atomics to ref count buffer pool pages

InnoDB: The InnoDB memory heap is disabled

InnoDB: Mutexes and rw_locks use GCC atomic builtins

InnoDB: Memory barrier is not used

InnoDB: Compressed tables use zlib 1.2.7

InnoDB: Using CPU crc32 instructions

InnoDB: Initializing buffer pool, size = 5.0G

InnoDB: Completed initialization of buffer pool

InnoDB: Setting log file ./ib_logfile101 size to 5 MB

InnoDB: Setting log file ./ib_logfile1 size to 5 MB

InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0

InnoDB: New log files created, LSN=31405539763

InnoDB: Highest supported file format is Barracuda.

[notice (again)]

  If you use binary log and don't use any hack of group commit,

  the binary log position seems to be:

xtrabackup: starting shutdown with innodb_fast_shutdown = 1

InnoDB: Starting shutdown...

InnoDB: Shutdown completed; log sequence number 31405539852

170213 17:14:07  innobackupex: completed OK!

使用copy-back来恢复数据文件。

innobackupex  --defaults-file=/etc/mysql/my.cnf  --copy-back  /home/data/backup/full/2017-03-06_15-31-05/

可以看到innobackupex在复制备份的文件到数据库的数据目录中

12g的文件，很快就完成了，1分钟左右。

innobackupex: Copying '/home/data/backup/full/2017-03-06_15-31-05/ZLECUBE/BTC_Order_Base_Info.ibd' to '/var/lib/mysql/ZLECUBE/BTC_Order_Base_Info.ibd'