概述
摘抄
xtrabackup是基于InnoDB存储引擎的灾难恢复。它copy InnoDB数据文件，尽管数据文件在内部不一致，但在执行灾难恢复时候保证这些文件的一致性。这是因为，InnoDB维护一个redo日志文件，也可以称为事务日志文件。它包含了InnoDB数据的每一个记录的变更。当InnoDB启动时，他检查数据文件和事务日志文件并执行两个步骤。它应用已经提交的事务日志到数据文件，并且执行已经修改过但是没有提交的数据进行回滚操作。
xtrabackup在启动时候会记住日志序列号log sequence number(LSN),并且复制远处的数据文件，他会消耗一些时间来做这些事情，如果数据文件修改了，数据库将会处于一个不同的时间点。同时，xtrabacku运行一个后台进程，来监视事务日志文件，并且从中复制最新的修改。xtrabackup需要持续的做，因为事务日志是轮转重复的写入的，在一个时间后可以覆盖复用。所以xtrabackup自启动执行时，就需要将数据文件修改的每个事务日志记录下来
以上的过程在xtrabackup的编译二进制程序中实现。程序innobackupex可以允许我们备份MyISAM表和frm文件从而增加了便捷和功能。Innobackupex会启动xtrabackup，
直到xtrabackup复制数据文件后，然后执行FLUSH TABLES WITH READ LOCK来阻止新的写入进来并把MyISAM表数据刷到硬盘上，之后复制MyISAM数据文件，最后释放锁。
备份MyISAM和InnoDB表最终会处于一致，在准备（prepare）过程结束后，InnoDB表数据已经前滚到整个备份结束的点，而不是回滚到xtrabackup刚开始时的点。
这个时间点与执行FLUSH TABLES WITH READ LOCK的时间点相同，所以MyISAM表数据与InnoDB表数据是同步的。类似Oracle的，InnoDB的prepare过程可以称为recover（恢复），MyISAM的数据复制过程可以称为restore。
备份过程
innobackupex 在启动后，会先 fork 一个进程，启动 xtrabackup进程，然后就等待xtrabackup 备份完 ibd 数据文件；xtrabackup 在备份 InnoDB 相关数据时，是有2种线程的，1种是 redo 拷贝线程，负责拷贝 redo 文件，1种是 ibd 拷贝线程，负责拷贝 ibd 文件；redo 拷贝线程只有一个，在 ibd 拷贝线程之前启动，在 ibd 线程结束后结束。xtrabackup 进程开始执行后，先启动 redo 拷贝线程，从最新的 checkpoint 点开始顺序拷贝 redo 日志；然后再启动 ibd 数据拷贝线程，在xtrabackup
拷贝 ibd 过程中，innobackupex 进程一直处于等待状态（等待文件被创建）。xtrabackup 拷贝完成idb后，通知 innobackupex（通过创建文件），同时自己进入等待（redo 线程仍然继续拷贝）;innobackupex 收到 xtrabackup 通知后，执行FLUSH TABLES WITH READ LOCK (FTWRL)，取得一致性位点，然后开始备份非 InnoDB 文件（包括 frm、MYD、MYI、CSV、opt、par等）。拷贝非 InnoDB 文件过程中，因为数据库处于全局只读状态，如果在业务的主库备份的话，要特别小心，非 InnoDB 表（主要是MyISAM）比较多的话整库只读时间就会比较长，这个影响一定要评估到。当 innobackupex 拷贝完所有非 InnoDB 表文件后，通知 xtrabackup（通过删文件） ，同时自己进入等待（等待另一个文件被创建）；xtrabackup 收到 innobackupex 备份完非 InnoDB 通知后，就停止 redo 拷贝线程，然后通知innobackupex redo log 拷贝完成（通过创建文件）；innobackupex 收到 redo 备份完成通知后，就开始解锁，执行 UNLOCK TABLES；最后 innobackupex 和 xtrabackup 进程各自完成收尾工作，如资源的释放、写备份元数据信息等，innobackupex 等待xtrabackup 子进程结束后退出。
示意图：
增量备份
PXB 是支持增量备份的，但是只能对 InnoDB 做增量，InnoDB 每个 page 有个 LSN 号，LSN 是全局递增的，page 被更改时会记录当前的 LSN 号，page中的 LSN 越大，说明当前page越新（最近被更新）。每次备份会记录当前备份到的LSN（xtrabackup_checkpoints 文件中），增量备份就是只拷贝LSN大于上次备份的page，比上次备份小的跳过，每个 ibd 文件最终备份出来的是增量 delta 文件。
MyISAM 是没有增量的机制的，每次增量备份都是全部拷贝的。
示意图
增量备份过程和全量备份一样，只是在 ibd 文件拷贝上有不同。
恢复过程
如果看恢复备份集的日志，会发现和 mysqld 启动时非常相似，其实备份集的恢复就是类似 mysqld crash后，做一次 crash recover。
恢复的目的是把备份集中的数据恢复到一个一致性位点，所谓一致就是指原数据库某一时间点各引擎数据的状态，比如 MyISAM 中的数据对应的是 15:00 时间点的，InnoDB 中的数据对应的是 15:20 的，这种状态的数据就是不一致的。PXB 备份集对应的一致点，就是备份时FTWRL的时间点，恢复出来的数据，就对应原数据库FTWRL时的状态。
因为备份时 FTWRL 后，数据库是处于只读的，非 InnoDB 数据是在持有全局读锁情况下拷贝的，所以非 InnoDB 数据本身就对应 FTWRL 时间点；InnoDB 的 ibd 文件拷贝是在 FTWRL 前做的，拷贝出来的不同 ibd 文件最后更新时间点是不一样的，这种状态的 ibd 文件是不能直接用的，但是 redo log 是从备份开始一直持续拷贝的，最后的 redo 日志点是在持有 FTWRL 后取得的，所以最终通过 redo 应用后的 ibd 数据时间点也是和 FTWRL 一致的。
以上属于摘抄部分。。。。。。。。。。。。。。
代码部分
将当前的数据库完整备份到 /xtra 目录中
mkdir /xtra
innobackupex -uroot /xtra
使用innobackupex进行增量备份
innobackupex --incremental /increment/ --incremental-basedir=/increment/2018-09-23_23-00-57
#--incrementa 增量备份目录
--incremental-basedir依照上一次备份做出增量备份。
需要注意的是，增量备份仅能应用于InnoDB或XtraDB表，
对于MyISAM表而言，执行增量备份时其实进行的是完全备份。
“准备”(prepare)增量备份与整理完全备份有着一些不同，尤其要注意的是：
(1)需要在每个备份(包括完全和各个增量备份)上，将已经提交的事务进行“重放”。
“重放”之后，所有的备份数据将合并到完全备份上。
(2)基于所有的备份将未提交的事务进行“回滚”。
innobackupex --apply-log --redo-only /xtra/2018-09-23_22-59-26
innobackupex --apply-log --redo-only /xtra/2018-09-23_22-59-26 --incremental-dir=/increment/2018-09-23_23-00-57/
恢复之前，对 事务日志 做一个预处理
一般情况下，在备份完成后，数据尚且不能用于恢复操作，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务因此，此时数据文件仍处理不一致状态。“准备”的主要作用正是通过回滚未提交的事务及同步已经提交的事务至数据文件也使得数据文件处于一致性状态。
innobackupex --apply-log /xtra/2018-09-23_22-59-26
从一个完全备份中恢复数据
innobackupex --copy-back=/xtra/2018-09-23_22-59-26/
面的命令需要保证数据库目录是空的，否则会失败，因为目录里有binlog日志，要么移走，要么就用手动复制需要的文件。所以说日志不要和数据放在一起！
恢复数据之后，要修改一下目录的权限，（例如/mysql是我数据库所在的位置）
chown -R mysql:mysql /mysql