Percona XtraBackup 安裝介紹篇已經對Percona XtraBackup的功能和安裝做了比較詳細的介紹，那么本篇我們直接進入主題，如何使用XtraBackup做備份、還原，下面主要介紹XtraBackup備份還原操作的細節和場景，疏漏之處難免存在，如有不足，敬請指出。本篇暫時不做原理介紹，后續篇章"Percona XtraBackup 原理分析篇"再做介紹。
XtraBackup完整備份
備份的權限
使用XtraBack做備份，需要連接到數據庫服務器並在服務器上有相關目錄操作權限，所以必須要有數據庫的相關操作權限以及相關目錄執行READ、WRITE以及EXECUTE（執行innobackupex 或xtrabackup 命令）的系統權限。下面我們來簡單介紹一下：
數據庫所需的一些權限請參考下面表格，細節部分可以參考官方文檔。此處不詳細闡述！
| MySQL 數據庫權限 |
權限描述 |
| RELOAD/ LOCK TABLES |
RELOAD權限是管理員級別權限，用來執行flush-hosts, flush-logs, flush-privileges, flush-status, flush-tables,flush-threads, refresh, reload等命令的權限。XtraBackup在復制文件之前，必須先執行 FLUSH TABLES WITH READ LOCK和 FLUSH ENGINE LOGS等 |
| REPLICATION CLIENT |
此權限是為了獲取二進制日志位置（Position） |
| CREATE TABLESPACE |
此權限是為了導入表 |
| PROCESS |
此權限是因為要運行SHOW ENGINE INNODB STATUS命令，以及查看服務器上所有運行的線程。 |
| SUPER |
此權限是為了開啟、關閉復制環境中的slave threads |
| CREATE |
不是必須，Percon Server數據庫才需要的。創建PERCONA_SCHEMA.xtrabackup_history的需要 |
| INSERT |
不是必須，跟上面權限一樣，需要往PERCONA_SCHEMA.xtrabackup_history插入記錄 |
| SELECT |
不是必須，跟上面權限一樣，需要查詢ERCONA_SCHEMA.xtrabackup_history中的記錄 |
當然所需的最小權限如下所示，注意：這個僅僅是最小權限，實際情況中最好根據實際需求授予最小權限。不要放大不必要的權限。
mysql> use mysql;
Database changed
mysql> CREATE USER 'backuser'@'localhost' IDENTIFIED BY 'kkk123456';
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT RELOAD, LOCK TABLES,PROCESS, REPLICATION CLIENT ON *.* TO 'backuser'@'localhost';
Query OK, 0 rows affected (0.00 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
mysql>
如果上面的權限不夠的話，可以使用下面授權語句。
GRANT RELOAD, LOCK TABLES,PROCESS, REPLICATION CLIENT, CREATE TABLESPACE,SUPER ON *.* TO 'backuser'@'localhost';
系統賬號授權相關目錄的操作權限。如下所示：
[root@DB-Server ~]# chown -R mysql:mysql /data
[root@DB-Server ~]# su - mysql
-bash-3.2$
完整備份
常用的完整備份（全備）命令如下所示
innobackupex --user=backuser --password=kkk123456 /u02/mysql_backup/full/
innobackupex --user=root --password=123456 /u02/mysql_backup/full/
innobackupex --defaults-file=/usr/my.cnf --user=backuser --password=kkk123456 /u02/mysql_backup/full
innobackupex --defaults-file=/usr/my.cnf --socket=/var/lib/mysql/mysql.sock --user=backuser --password=kkk123456 /u02/mysql_backup/full
參數--no-timestamp 表示不生成帶時間戳的目錄
innobackupex --user=backuser --password=kkk123456 /u02/mysql_backup/full/ --no-timestamp
注意：如果你指定了參數--defaults-file，那么此參數就必須位於第一個，否則就會報“--defaults-file must be specified first on the command line”
我們先在測試數據庫MyDB創建一個測試表，插入幾條數據，后面做還原測試驗證使用。
mysql> use MyDB;
Database changed
mysql> create table test(id int primary key);
Query OK, 0 rows affected (0.13 sec)
mysql> insert into test
-> values(1000);
Query OK, 1 row affected (0.01 sec)
mysql> insert into test
-> values(2000);
Query OK, 1 row affected (0.01 sec)
mysql> insert into test
-> values(3000);
Query OK, 1 row affected (0.01 sec)
mysql>
我們使用下面命令對MySQL做了一個完整備份，那么默認就會在目錄/u02/mysql_backup/full/下生成一個日期時間格式的全備文件2017-07-19_17-22-45
$ innobackupex --defaults-file=/usr/my.cnf --user=backuser --password=kkk123456 /u02/mysql_backup/full
那么備份出來的文件以及內容是什么樣的呢？ 如下所示，你可以檢查xtrabackup_checkpoints、xtrabackup_binlog_info、xtrabackup_info三個文件了解備份的一些詳細信息，例如備份類型、是否壓縮等等。
[root@DB-Server 2017-07-19_17-39-56]# ls -lrt
total 12380
drwxr-x--- 2 mysql mysql 4096 Jul 19 17:39 test
drwxr-x--- 2 mysql mysql 4096 Jul 19 17:39 performance_schema
drwxr-x--- 2 mysql mysql 4096 Jul 19 17:39 mysql
drwxr-x--- 2 mysql mysql 4096 Jul 19 17:39 MyDB
-rw-r----- 1 mysql mysql 12582912 Jul 19 17:39 ibdata1
-rw-r----- 1 mysql mysql 2560 Jul 19 17:39 xtrabackup_logfile
-rw-r----- 1 mysql mysql 545 Jul 19 17:39 xtrabackup_info
-rw-r----- 1 mysql mysql 113 Jul 19 17:39 xtrabackup_checkpoints
-rw-r----- 1 mysql mysql 25 Jul 19 17:39 xtrabackup_binlog_info
-rw-r----- 1 mysql mysql 418 Jul 19 17:39 backup-my.cnf
[root@DB-Server 2017-07-19_17-39-56]# more xtrabackup_checkpoints
backup_type = full-backuped
from_lsn = 0
to_lsn = 1637691
last_lsn = 1637691
compact = 0
recover_binlog_info = 0
[root@DB-Server 2017-07-19_17-39-56]# more xtrabackup_binlog_info
DB-Server-bin.000001 871
[root@DB-Server 2017-07-19_17-39-56]# more xtrabackup_info
uuid = cfb5c2d8-6cca-11e7-8113-b083fe5532e5
name =
tool_name = innobackupex
tool_command = --defaults-file=/usr/my.cnf --user=backuser --password=... /u02/mysql_backup/full
tool_version = 2.4.6
ibbackup_version = 2.4.6
server_version = 5.6.20-enterprise-commercial-advanced-log
start_time = 2017-07-19 17:39:56
end_time = 2017-07-19 17:39:58
lock_time = 0
binlog_pos = filename 'DB-Server-bin.000001', position '871'
innodb_from_lsn = 0
innodb_to_lsn = 1637691
partial = N
incremental = N
format = file
compact = N
compressed = N
encrypted = N
xtrabackup_checkpoints ： 備份類型信息（完全備份或增量備份）、LSN(日志序列號)范圍信息、備份是否壓縮
xtrabackup_binlog_info ： 二進制日志信息,MySQL當前正在使用的二進制日志文件及至備份這一刻為止二進制日志事件的位置。如果沒有開啟二進制日志，那么就不會有xtrabackup_binlog_info這個文件。
xtrabackup_info ： xtrabackup工具的版本信息、詳細命令、參數以及備份的開始、結束時間。以及備份詳細信息等。
xtrabackup_logfile ：
backup-my.cnf ： 備份命令用到的配置選項信息。
如何使用全備恢復還原呢？ 如下步驟所示：
Step 1：Prepare the Backup。
innobackupex --defaults-file=/usr/my.cnf --apply-log /u02/mysql_backup/full/2017-07-19_17-39-56/
Step 2：關閉MySQL服務，備份數據目錄或刪除數據目錄
2.1 : /etc/init.d/mysql stop
2.2 : mv /data/mysql/ /data/mysql_20170719_bak
Step 3: 恢復數據，將備份數據文件拷貝到數據目錄
innobackupex --defaults-file=/usr/my.cnf --copy-back /u02/mysql_backup/full/2017-07-19_17-39-56/
如果執行上面命令是在mysql用戶下，並且有權限創建對應目錄，那么就不需要做任何操作，如果是root賬號，那么就必須修改對應目錄的Owner，否則啟動MySQL服務會報錯。
chown -R mysql:mysql /data/mysql/*
注意，如果這里權限沒有處理好，有時候會出現一些莫名其妙的錯誤，例如，設置文件權限時，由於上面腳本處理的是/data/mysql下面的文件，沒有處理/data/mysql這個目錄的權限，啟動MySQL的時候就報這個錯誤
[root@DB-Server data]# ls -lrt
total 40
drwxr-xr-x 6 mysql mysql 4096 Jul 21 2017 mysql_20170719_bak
drwxr-x--- 8 root root 4096 Jun 25 12:09 mysql
[root@DB-Server data]# service mysql start
Starting MySQL.. ERROR! The server quit without updating PID file (/data/mysql/DB-Server.localdomain.pid).
[root@DB-Server data]# chown -R mysql:mysql /data/mysql
[root@DB-Server data]# service mysql start
Starting MySQL... SUCCESS!
Step 4: 測試數據的完整性：
[root@DB-Server ~]# service mysql start
Starting MySQL.....[ OK ]
[root@DB-Server ~]# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.6.20-enterprise-commercial-advanced-log MySQL Enterprise Server - Advanced Edition (Commercial)
Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> use MyDB;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> select * from test;
+------+
| id |
+------+
| 1000 |
| 2000 |
| 3000 |
+------+
3 rows in set (0.00 sec)
XtraBackup增量備份
在闡述Xtrabackup增量備份前，我們先來看看下面這個增量備份，你能看出其問題嗎？這個備份有啥不妥呢？ 當然在做增量備份前，都有對數據庫進行了一些測試操作。
完整備份
innobackupex --defaults-file=/usr/my.cnf --user=backuser --password=kkk123456 /u02/mysql_backup/full
增量備份1
innobackupex --defaults-file=/usr/my.cnf --user=root --password=123456 --incremental --incremental-basedir=/u02/mysql_backup/full/2017-07-24_09-38-32/ /u02/mysql_backup/incr/
增量備份2
innobackupex --defaults-file=/usr/my.cnf --user=root --password=123456 --incremental --incremental-basedir=/u02/mysql_backup/full/2017-07-24_09-32-22/ /u02/mysql_backup/incr/
其實第一次完整備份時，生成了備份目錄2017-07-24_09-38-32； 第一次增量備份時，生成了增量備份目錄2017-07-24_09-40-11，關鍵在於第二次增量備份，--incremental-basedir這個參數的值不應該是第一次完成備份的目錄，而應是增量備份1的備份目錄2017-07-24_09-40-11，如下所示，如果使用了錯誤的參數，增量備份2其實包含了增量備份1的變化部分。
[root@DB-Server 2017-07-24_09-40-11]# more xtrabackup_info
uuid = 9f916d24-7075-11e7-8f2e-b083fe5532e5
name =
tool_name = innobackupex
tool_command = --defaults-file=/usr/my.cnf --user=root --password=... --incremental --incremental-basedir=/u02/mysql_backup/full/2017-07-24_09-38-32/ /u02/mysql_backup/incr/
tool_version = 2.4.6
ibbackup_version = 2.4.6
server_version = 5.6.20-enterprise-commercial-advanced
start_time = 2017-07-24 09:40:12
end_time = 2017-07-24 09:40:14
lock_time = 0
binlog_pos =
innodb_from_lsn = 1650510
innodb_to_lsn = 1660277
partial = N
incremental = Y
format = file
compact = N
compressed = N
encrypted = N
[root@DB-Server 2017-07-24_09-40-11]# cd ../2017-07-24_09-40-25/
[root@DB-Server 2017-07-24_09-40-25]# more xtrabackup_info
uuid = a790b642-7075-11e7-8f2e-b083fe5532e5
name =
tool_name = innobackupex
tool_command = --defaults-file=/usr/my.cnf --user=root --password=... --incremental --incremental-basedir=/u02/mysql_backup/full/2017-07-24_09-38-32/ /u02/mysql_backup/incr/
tool_version = 2.4.6
ibbackup_version = 2.4.6
server_version = 5.6.20-enterprise-commercial-advanced
start_time = 2017-07-24 09:40:25
end_time = 2017-07-24 09:40:28
lock_time = 0
binlog_pos =
innodb_from_lsn = 1650510
innodb_to_lsn = 1664130
partial = N
incremental = Y
format = file
compact = N
compressed = N
encrypted = N
[root@DB-Server 2017-07-24_09-40-25]#
增量備份注意事項
1：--incremental-basedir
第一次增量備份，--incremental-basedir肯定是全備目錄，第二次增量備份，--incremental-basedir為第一次增量備份目錄，依此類推！
2：增量備份僅能應用於InnoDB或XtraDB表，對於MyISAM表而言，執行增量備份時其實進行的是完全備份。
3：應用增量備份的時候只能按照備份的順序來應用。如果應用順序錯誤，那么備份就不可用。如果無法確定順序，可以查看xtrabackup-checkpoints來確定順序。
那么我們來用案例測試一下增量備份的還原，具體步驟如下所示（這里我們使用root賬號來）
Step 1： 完整備份
mysql> use MyDB;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> create table test (id int, name varchar(12));
Query OK, 0 rows affected (0.01 sec)
mysql> insert into test values(1000, 'kerry');
Query OK, 1 row affected (0.00 sec)
mysql>
執行完整備份
innobackupex --default-files=/usr/my.cnf --user=root --password=123456 /u02/mysql_backup/full/
Step 2： 增量備份1
mysql> insert into test values(2000, 'ken');
Query OK, 1 row affected (0.00 sec)
注意 --incremental-basedir參數應該根據實際情況確定
innobackupex --defaults-file=/usr/my.cnf --user=root --password=123456 --incremental --incremental-basedir=/u02/mysql_backup/full/2017-07-24_16-15-59/ /u02/mysql_backup/incr/
Step 3：增量備份2:
mysql> create table big_table (id int);
Query OK, 0 rows affected (0.13 sec)
mysql> insert into big_table values(10000);
Query OK, 1 row affected (0.00 sec)
mysql> insert into big_table values(20000);
Query OK, 1 row affected (0.00 sec)
mysql>
注意 --incremental-basedir參數應該根據實際情況確定
innobackupex --defaults-file=/usr/my.cnf --user=root --password=123456 --incremental --incremental-basedir=/u02/mysql_backup/incr/2017-07-24_16-17-39/ /u02/mysql_backup/incr/
注意：Xtrabackup增量備份時，需要設置參數--incremental-basedir 其實這個參數不是必須的。可以用--incremental-lsn來替代。
完整備份后，檢查備份目錄下的xtrabackup_checkpoints文件，找到to_lsn，然后使用下面腳本做增量備份。
innobackupex --user=backuser --password=kkk123456 /u02/mysql_backup/full/
[root@DB-Server 2017-07-25_12-49-57]# more xtrabackup_checkpoints
backup_type = full-backuped
from_lsn = 0
to_lsn = 1733142
last_lsn = 1733142
compact = 0
recover_binlog_info = 0
innobackupex --user=backuser --password=kkk123456 --incremental --incremental-lsn=1733142 /u02/mysql_backup/incr/
然后，我們先刪除或DROP掉一些數據，模擬數據被誤刪的情況，然后還原測試驗證。 如下所示：
mysql> drop table test;
Query OK, 0 rows affected (0.00 sec)
mysql> delete from big_table where id=10000;
Query OK, 1 row affected (0.01 sec)
mysql>
Step 1： 恢復完全備份
innobackupex --defaults-file=/usr/my.cnf --apply-log --redo-only /u02/mysql_backup/full/2017-07-24_16-15-59/
注意如果后續必須應用增量備份，則必須加上--redo-only. 否則后續不能應用增量備份。這個如果對SQL Server備份還原熟悉的話，原理也是如此。
--redo-only
If you replay the committed transactions and rollback the uncommitted ones on the base backup, you will not be able
to add the incremental ones. If you do this on an incremental one, you won’t be able to add data from that moment
and the remaining increments。
Note: --redo-only should be used when merging all incrementals except the last one. That’s why the previous
line doesn’t contain the --redo-only option. Even if the --redo-only was used on the last step, backup would
still be consistent but in that case server would perform the rollback phase.
如下截圖所示，如果在恢復全備時沒有應用參數--redo-only ，后面應用增量備份時就會遇到下面錯誤。只有當最后一個增量備份時，才不需要--redo-only
Step 2：增量備份還原
innobackupex --apply-log --redo-only --incremental /u02/mysql_backup/full/2017-07-24_16-15-59/ \
--incremental-dir=/u02/mysql_backup/incr/2017-07-24_16-17-39/
注意：增量備份必須按一定順序Apply，否則后面的增量備份都無效了！
Step 3：增量備份還原
innobackupex --apply-log --incremental /u02/mysql_backup/full/2017-07-24_16-15-59/ \
--incremental-dir=/u02/mysql_backup/incr/2017-07-24_16-18-57/
Step 4： 關閉MySQL服務並移除數據目錄。
[root@DB-Server ~]# service mysql stop
Shutting down MySQL..[ OK ]
Step 5： 將備份文件拷貝回MySQL數據目錄。
innobackupex --defaults-file=/usr/my.cnf --copy-back /u02/mysql_backup/full/2017-07-24_16-15-59/
[root@DB-Server ~]# chown -R mysql:mysql /data/mysql/*
Step 6： 檢查驗證數據數據恢復情況。
[root@DB-Server mysql]# service mysql start
Starting MySQL..........[ OK ]
mysql> select * from test;
+------+-------+
| id | name |
+------+-------+
| 1000 | kerry |
| 2000 | ken |
+------+-------+
2 rows in set (0.00 sec)
mysql> select * from big_table;
+-------+
| id |
+-------+
| 10000 |
| 20000 |
+-------+
2 rows in set (0.00 sec)
XtraBackup備份高級選項
Compact Backups
1:緊湊型備份（compact backups）指在備份InnoDB tables時， 可以不備份二級索引（Secondary index)數據頁，這樣使得備份更加緊湊，從而可以減少備份的大小。缺點是備份准備過程（Prepare）需要更長的時間才能重建這些二級索引(secondary indexes)。
2：系統表空間不支持緊湊型備份（Compact backups）,所以如果要使用Compact backups，那么就必須設置變量innodb_file_per_table為ON
innobackupex --user=backuser --password=kkk123456 --compact /u02/mysql_backup/full/
如下所示，你檢查xtrabackup_checkpoints 就會發現compact為1， xtrabackup_info里面compact值為Y
注意：
發現Xtrabackup有個有意思的現象，例如下面備份腳本，參數 --compat弄錯了，執行也不報錯，只是緊湊型備份沒有生效。
Partial Backups
Percona Xtrabackup提供部分備份，這意味着你可以只備份一些特定表或數據庫，不過部分備份（Partial Backups）是有諸多限制和前提的。
1： 如果要使用部分備份（Partial Backups），前提條件是你備份的表必須在單獨的表空間中。你必須在服務器上啟動innodb_file_per_table。
2： 部分備份（Partial Backups）是不支持--stream選項，即不支持將數據通過管道傳輸給其它程序進行處理。
3： 還原部分備份跟還原完整備份也有所不同，即你不能通過簡單地將prepared的部分備份使用--copy-back選項直接復制回數據目錄，而是要通過導入表的方向來實現還原。盡管有時簡單的拷貝備份文件可以成功，但是這種方法很容易導致數據庫的不一致，因此不推薦大家這么做。
創建部分備份（Creating Partial Backups）
部分備份共有三種方式，分別是：1. 用正則表達式表示要備份的庫名及表名（參數為--include）；2. 將要備份的表名或庫名都寫在一個文本文件中（參數為--tables-file）以及 3. 將要備份表名或庫名完整的寫在命令行中（參數為：--databases）。（譯者注：不管你備份哪個庫或是哪張表，強烈推薦把mysql庫也一起備份，恢復的時候要用。）
對數據庫進行部分備份有三種方式：正則表達式(--include), 枚舉表文件(--tables-file)和列出要備份的數據庫(--databases)
方法1：使用正則表達式
innobackupex --defaults-file=/usr/my.cnf --user=backuser --password=kkk123456 --include='^MyDB[.]kkk' /u02/mysql_backup/part/
方法2：枚舉表文件(--tables-file)
# cat >back_table.txt
MyDB.test
MyDB.kkk
innobackupex --defaults-file=/usr/my.cnf --user=backuser --password=kkk123456 --tables-file=/u02/mysql_backup/back_table.txt /u02/mysql_backup/part
方法3： 通過參數--database 指定需要備份的表
–database選項可以直接指定需要備份的”表”和”庫”名,或指定一個包含所需備份表名的列表文件。
innobackupex --defaults-file=/usr/my.cnf --user=backuser --password=kkk123456 --databases="MyDB.test MyDB.kkk" /u02/mysql_backup/part
准備部分備份（Preparing Partial Backups）
innobackupex --apply-log --export /u02/mysql_backup/part/2018-06-27_16-49-59
恢復部分備份（Restoring Partial Backups）
innobackupex --apply-log --export /u02/mysql_backup/part/2018-06-27_16-49-59
此時就會生成對應表的exp文件
導入表操作：
假設由於誤操作，將表TEST的數據TRUNCATE掉了。
mysql> select * from test;
+------+-------+
| id | name |
+------+-------+
| 1000 | kerry |
| 2000 | ken |
+------+-------+
2 rows in set (0.00 sec)
mysql> truncate table test;
Query OK, 0 rows affected (0.12 sec)
mysql>
2:我們discard tablespace
mysql> alter table test discard tablespace;
Query OK, 0 rows affected (0.03 sec)
3: copy test表的ibd、cfg、exp文件
# cp /u02/mysql_backup/part/2018-06-27_16-49-59/MyDB/test.ibd /data/mysql/MyDB
# cp /u02/mysql_backup/part/2018-06-27_16-49-59/MyDB/test.cfg /data/mysql/MyDB
# cp /u02/mysql_backup/part/2018-06-27_16-49-59/MyDB/test.exp /data/mysql/MyDB
4： 導入表空間
mysql> alter table test import tablespace;
Query OK, 0 rows affected (0.03 sec)
5：驗證測試是否成功
基於tar格式備份
流備份打包
innobackupex --user=backuser --password=kkk123456 --stream=tar /tmp > /u02/mysql_backup/full/backup_20170725.tar
xbstream流備份打包壓縮
innobackupex --user=root --password=123456 --stream=tar /tmp | gzip > /u02/mysql_backup/full/backup_20170725.tar.gz
備份到遠程
中間還有很長一段內容，被我刪除了，文章寫得太長、太冗余，有點類似於技術手冊了，估計也沒有人看；另外一方面，很多細節問題還沒有仔細驗證過， 所以放在自己的筆記本中，慢慢完善！
Innobackupex部分參數介紹
查看innobackupex與xtrabackup的參數，可以使用下面命令：
#innobackupex --help
#xtrabackup
innobackupex的的部分參數介紹如下（有些不常用參數沒來及整理，后續再慢慢補充）
-v, --version
輸出xtrabackup的版本信息
-?, --help
輸出、顯示幫助信息然后退出
--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_size6個參數即可讓xtrabackup正常工作。
注意：指定要備份的mysql實例的my.cnf文件，必須為第一個選項
--apply-log
該參數是對xtrabackup的參數--prepare的封裝。 一般情況下,在備份完成后，數據尚且不能用於恢復操作，因為備份的數據中可能會包含尚未提交的事務或已經提交但尚未同步至數據文件中的事務。因此，此時數據文件仍處理不一致狀態。--apply-log的作用是通過回滾未提交的事務及同步已經提交的事務至數據文件使數據文件處於一致性狀態。
--redo-only
這個選項在prepare base full backup，往其中merge增量備份（但不包括最后一個）時候使用。This forces xtrabackup to skip the "rollback" phase and do a "redo" only
--copy-back
做數據恢復時將備份數據文件拷貝到MySQL服務器的datadir目錄;
--move-back
將所有文件從以前創建的備份目錄移動到事情數據目錄， 使用此選項必須小心， 因為它會刪除備份文件。
--galera-info
該選項創建xtrabackup_galera_info文件， 其中包含備份當時的本地節點狀態。 執行Percona-XtraDB-Cluster備份時應使用此選項。
--slave-info
該選項表示對slave進行備份的時候使用，打印出master的名字和binlog pos，同樣將這些信息以change master的命令寫入xtrabackup_slave_info文件。可以通過基於這份備份啟動一個從庫。
--incremental
建立增量備份
--no-lock
該選項表示關閉FTWRL的表鎖，只有在所有表都是Innodb表並且不關心backup的binlog pos點，如果有任何DDL語句正在執行或者非InnoDB正在更新時（包括mysql庫下的表），都不應該使用這個選項，后果是導致備份數據不一致，如果考慮備份因為獲得鎖失敗，可以考慮--safe-slave-backup立刻停止復制線程。
不允許使用flush tables with read lock表鎖。如果你的所有表示INNODB並且你不關心二進制日志備份的位置。如果有任何DDL語句被執行或任何非INNODB表上的update操作，這個選項就不能使用
--safe-slave-backup
停止從SQL進程並等待啟動備份直到slave_open_temp_tables的值為0。如果沒有打開臨時表，備份會進行，否則SQL進程將啟動並直到沒有打開的臨時表時停止。如果slave_open_temp_tables在--
safe-slave-backup-timeout秒后沒有變成0，則備份會失敗。備份結束后，從SQL進程將重新啟動。
--rsync
表示通過rsync工具優化本地傳輸，當指定這個選項，innobackupex使用rsync拷貝非Innodb文件而替換cp，當有很多DB和表的時候會快很多，不能--stream一起使用。
--force-non-empty-directories
使用此選項，就可以通過--copy-back或--move-back 將文件拷貝或移動到非空目錄。
This option, when specified, makes --copy-back or
--move-back transfer files to non-empty directories. Note
that no existing files will be overwritten. If
--copy-back or --nove-back has to copy a file from the
backup directory which already exists in the destination
directory, it will still fail with an error.
--no-timestamp
該選項可以表示要不要創建一個時間戳目錄來存儲備份，指定到自己想要的備份文件夾。指定了這個選項，備份會直接備份在BACKUP-DIR，不再創建時間戳文件夾
--no-version-check
禁止版本檢查
--no-backup-locks
--decompress
-u, --user=name
該選項表示備份賬號。
-H, --host=
該選項表示備份數據庫的地址。
-p, --password
該選項表示備份賬號的密碼。
-P, --port=#
該選項表示當前需要備份數據庫的使用的端口。
-S, --socket
此選項指定連接本地數據庫時使用的套接字，此選項接受一個字符串參數。
--incremental-history-name=name
該選項表示存儲在PERCONA_SCHEMA.xtrabackup_history基於增量備份的歷史記錄的名字。Percona Xtrabackup搜索歷史表查找最近（innodb_to_lsn）成功備份並且將to_lsn值作為增量備份啟動出事lsn.與innobackupex--incremental-history-uuid互斥。如果沒有檢測到有效的lsn，xtrabackup會返回error。
--incremental-history-uuid=name
--decrypt=name
--ftwrl-wait-query-type=name
--kill-long-query-type=name
--history[=name]
--include=name
--databases
該選項表示需要備份的數據庫,如果沒有指定該參數，表示備份全部數據庫。如果要指定多個數據庫，彼此間需要以空格隔開；如："mydb1 mydb2"，同時，在指定某數據庫時，也可以只指定其中的某張表。如："mydatabase.mytable"。該選項對innodb引擎表無效，還是會備份所有innodb表。此外，此選項也可以接受一個文件為參數，文件中每一行為一個要備份的對象。
--kill-long-queries-timeout=#
--ftwrl-wait-timeout=#
--ftwrl-wait-threshold=#
--debug-sleep-before-unlock=#
--safe-slave-backup-timeout=#
--close-files
--compact
該選項表示創建一份沒有輔助索引的緊湊的備份。
指在備份InnoDB tables時， 可以不備份二級索引（Secondary index)數據頁，這樣使得備份更加緊湊，從而可以減少備份的大小。缺點是備份准備過程（Prepare）需要更長的時間才能重建這些二級索引(secondary indexes)。
--compress[=name]
對備份數據進行行壓縮
--compress-threads=#
指定備份壓縮的線程數量。
--compress-chunk-size=#
--encrypt=name
--encrypt-key=name
--encrypt-key-file=name
--encrypt-threads=#
--encrypt-chunk-size=#
--export
--extra-lsndir=name
--incremental-basedir=name
指定一個全庫備份的目錄作為增量備份的基礎數據庫 。
與--incremental同時使用。
--incremental-dir=name
該選項表示增量備份的目錄。
--incremental-force-scan
該選項表示創建一份增量備份時，強制掃描所有增量備份中的數據頁。
--log-copy-interval=#
--incremental-lsn=name
該選項表示指定增量備份的LSN，與--incremental選項一起使用。
--parallel
--rebuild-indexes
--rebuild-threads=#
--stream
該選項表示流式備份的格式，backup完成之后以指定格式到STDOUT，目前只支持tar和xbstream。
備份文件輸出格式, tar時使用tar4ibd , 該文件可在XtarBackup binary文件中獲得.如果備份時有指定--stream=tar, 則tar4ibd文件所處目錄一定要在$PATH中(因為使用的是tar4ibd去壓縮, 在XtraBackup的binary包中可獲得該文件)。
在使用參數stream=tar備份的時候，你的xtrabackup_logfile可能會臨時放在/tmp目錄下，如果你備份的時候並發寫入較大的話xtrabackup_logfile可能會很大(5G+)，很可能會撐滿你的/tmp目錄，可以通過參數--tmpdir指定目錄來解決這個問題。
--tables-file
該選項表示指定含有表列表的文件，格式為database.table，該選項直接傳給--tables-file。
--throttle
每秒IO次數,限制backup時使用的I/O操作量，使備份對數據庫正常業務的影響最小化
-t, --tmpdir=name
--use-memory
指定備份所用內存大小。
XtraBackup問題集合
1：沒有開啟二進制日志，那么Xtrabackup有什么問題沒？
2：xtrabackup: Check 'to_lsn' of the target and 'from_lsn' of the incremental.
[root@DB-Server ~]# innobackupex --apply-log --incremental /u02/mysql_backup/full/2017-07-24_12-58-25/ --incremental-dir=/u02/mysql_backup/incr/2017-07-24_13-02-32/
170724 13:27:34 innobackupex: Starting the apply-log operation
IMPORTANT: Please check that the apply-log run completes successfully.
At the end of a successful apply-log run innobackupex
prints "completed OK!".
innobackupex version 2.4.6 based on MySQL server 5.7.13 Linux (x86_64) (revision id: 8ec05b7)
incremental backup from 1685892 is enabled.
xtrabackup: cd to /u02/mysql_backup/full/2017-07-24_12-58-25/
xtrabackup: This target seems to be already prepared with --apply-log-only.
xtrabackup: error: This incremental backup seems not to be proper for the target.
xtrabackup: Check 'to_lsn' of the target and 'from_lsn' of the incremental.
注意紅色部分，由於粗心，路徑錯誤，導致出現下面錯誤信息：
[root@DB-Server full]# innobackupex --defaults-file=/usr/my.cnf --user=root --password=123456 \
--stream=tar /tmp | gzip > u02/mysql_backup/full/backup_20170725.tar.gz
-bash: u02/mysql_backup/full/backup_20170725.tar.gz: No such file or directory
170725 16:57:35 innobackupex: Starting the backup operation
IMPORTANT: Please check that the backup run completes successfully.
At the end of a successful backup run innobackupex
prints "completed OK!".
170725 16:57:35 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup' as 'root' (using password: YES).
170725 16:57:35 version_check Connected to MySQL server
170725 16:57:35 version_check Executing a version check against the server...
170725 16:57:35 version_check Done.
170725 16:57:35 Connecting to MySQL server host: localhost, user: root, password: set, port: not set, socket: not set
Using server version 5.6.20-enterprise-commercial-advanced-log
innobackupex version 2.4.6 based on MySQL server 5.7.13 Linux (x86_64) (revision id: 8ec05b7)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /data/mysql
xtrabackup: open files limit requested 0, set to 1024
xtrabackup: using the following InnoDB configuration:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 50331648
InnoDB: Number of pools: 1
170725 16:57:35 >> log scanned up to (1737354)
xtrabackup: Generating a list of tablespaces
InnoDB: Allocated tablespace ID 4 for mysql/slave_master_info, old maximum was 0
innobackupex: Error writing file 'UNOPENED' (Errcode: 32 - Broken pipe)
archive_write_header() failed.
[01] xtrabackup: error: cannot open the destination stream for ibdata1
[01] xtrabackup: Error: xtrabackup_copy_datafile() failed.
[01] xtrabackup: Error: failed to copy datafile.
The datadir must be empty before restoring the backup. Also it’s important to note that MySQL server needs
to be shut down before restore is performed. You can’t restore to a datadir of a running mysqld instance (except when
importing a partial backup).
3：版本不支持的情況，例如 Percona-XtraBackup-2.3.4 不支持MySQL 5.7.21
# innobackupex --default-file=/usr/my.cnf --user=root --password="QwEr@123456" --app-log /tmp/fullbackup/
180613 16:36:39 innobackupex: Starting the backup operation
IMPORTANT: Please check that the backup run completes successfully.
At the end of a successful backup run innobackupex
prints "completed OK!".
180613 16:36:39 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;mysql_socket=/var/lib/mysql/mysql.sock' as 'root' (using password: YES).
180613 16:36:39 version_check Connected to MySQL server
180613 16:36:39 version_check Executing a version check against the server...
180613 16:36:39 version_check Done.
180613 16:36:39 Connecting to MySQL server host: localhost, user: root, password: set, port: 0, socket: /var/lib/mysql/mysql.sock
Error: Unsupported server version: '5.7.21'. Please report a bug at https://bugs.launchpad.net/percona-xtrabackup
后續感言：一直想全面總結XtraBackup備份，就一直在拖拖拉拉，本來2017年7月份就總結了這篇文章的大部分知識點，但是總是感覺這部分的知識點沒有總結，那部分知識點沒有測試，一直拖拖拉拉，其實哪里可能面面俱到的總結到位，能夠涵蓋大部分就可以。不完美才是技術文章的哲學形態！后續遇到了相關案例，再慢慢完善。