MySQL備份與還原詳細過程示例

MySQL備份與還原詳細過程示例

1、MySQL備份類型

1.熱備份、溫備份、冷備份 （根據服務器狀態）

熱備份：讀、寫不受影響；

溫備份：僅能夠執行讀操做；

冷備份：離線備份；讀、寫操做均停止；

2.物理備份與邏輯備份 （從對象來分）

物理備份：複製數據文件；

邏輯備份：將數據導出至文本文件中；

 

3.徹底備份、增量備份、差別備份 （從數據收集來分）

徹底備份：備份所有數據；

增量備份：僅備份上次徹底備份或增量備份之後變化的數據；

差別備份：僅備份上次徹底備份以來變化的數據；

4.邏輯備份的優勢：

在備份速度上兩種備份要取決於不一樣的存儲引擎

物理備份的還原速度很是快。可是物理備份的最小力度只能作到表

邏輯備份保存的結構一般都是純ASCII的，因此咱們可使用文本處理工具來處理

邏輯備份有很是強的兼容性，而物理備份則對版本要求很是高

邏輯備份也對保持數據的安全性有保證

 

5.邏輯備份的缺點：

邏輯備份要對RDBMS產生額外的壓力，而裸備份無壓力

邏輯備份的結果可能要比源文件更大。因此不少人都對備份的內容進行壓縮

邏輯備份可能會丟失浮點數的精度信息

注:差別備份要比增量備份佔用的空間大，但恢復時比較方便！但咱們通常都用增量備份！

2、MySQL備份都備份什麼

通常備份如下幾個部分：

1.數據文件

2.日誌文件（好比事務日誌，二進制日誌）

3.存儲過程，存儲函數，觸發器

4.配置文件（十分重要，各個配置文件都要備份）

5.用於實現數據庫備份的腳本，數據庫自身清理的Croutab等……

3、MySQL經常使用的備份工具

1.Mysql自帶的備份工具

(1)mysqldump 邏輯備份工具，支持全部引擎，MyISAM引擎是溫備，InnoDB引擎是熱備，備份速度中速，還原速度很是很是慢，可是在實現還原的時候，具備很大的操做餘地。具備很好的彈性。

mysqlhotcopy 物理備份工具，但只支持MyISAM引擎，基本上屬於冷備的範疇，物理備份，速度比較快。

2.文件系統備份工具

(1)cp冷備份，支持全部引擎，複製命令，只能實現冷備，物理備份。使用歸檔工具，cp命令，對其進行備份的，備份速度快，還原速度幾乎最快，可是靈活度很低，能夠跨系統，可是跨平臺能力不好。

(2)lvm 幾乎是熱備份，支持全部引擎，基於快照(LVM，ZFS)的物理備份，速度很是快，幾乎是熱備。隻影響數據幾秒鐘而已。可是建立快照的過程自己就影響到了數據庫在線的使用，因此備份速度比較快，恢復速度比較快，沒有什麼彈性空間，並且LVM的限制：不能對多個邏輯卷同一時間進行備份，因此數據文件和事務日誌等各類文件必須放在同一個LVM上。而ZFS則很是好的能夠在多邏輯卷之間備份。

3.其它工具

(1)ibbackup 商業工具 MyISAM是溫備份，InnoDB是熱備份 ，備份和還原速度都很快，這個軟件它的每服務器受權版本是5000美圓。

(2)xtrabackup 開源工具 MyISAM是溫備份，InnoDB是熱備份 ，是ibbackup商業工具的替代工具。

4、MySQL備份策略

1.直接拷貝數據庫文件（文件系統備份工具 cp）（適合小型數據庫，是最可靠的）

當你使用直接備份方法時，必須保證表不在被使用。若是服務器在你正在拷貝一個表時改變它，拷貝就失去意義。保證你的拷貝完整性的最好方法是關閉服務器，拷貝文件，而後重啓服務器。若是你不想關閉服務器，要在執行表檢查的同時鎖定服務器。若是服務器在運行，相同的制約也適用於拷貝文件，並且你應該使用相同的鎖定協議讓服務器「安靜下來」。當你完成了備份時，須要重啓服務器(若是關閉了它)或釋放加在表上的鎖定(若是你讓服務器運行)。要用直接拷貝文件把一個數據庫從一臺機器拷貝到另外一臺機器上，只是將文件拷貝到另外一臺服務器主機的適當數據目錄下便可。要確保文件是MyIASM格式或兩臺機器有相同的硬件結構，不然你的數據庫在另外一臺主機上有奇怪的內容。你也應該保證在另外一臺機器上的服務器在你正在安裝數據庫表時不訪問它們。

2.mysqldump備份數據庫（徹底備份+增長備份，速度相對較慢，適合中小型數據庫）（MyISAM是溫備份，InnoDB是熱備份）

mysqldump 是採用SQL級別的備份機制，它將數據表導成 SQL 腳本文件，在不一樣的 MySQL 版本之間升級時相對比較合適，這也是最經常使用的備份方法。mysqldump 比直接拷貝要慢些。對於中等級別業務量的系統來講，備份策略能夠這麼定：第一次徹底備份，天天一次增量備份，每週再作一次徹底備份，如此一直重複。而對於重要的且繁忙的系統來講，則可能須要天天一次全量備份，每小時一次增量備份，甚至更頻繁。爲了避免影響線上業務，實如今線備份，而且能增量備份，最好的辦法就是採用主從複製機制(replication)，在 slave 機器上作備份。

3.lvs快照從物理角度實現幾乎熱備的徹底備份，配合二進制日誌備份實現增量備份，速度快適合比較煩忙的數據庫

前提：

數據文件要在邏輯捲上；

此邏輯卷所在卷組必須有足夠空間使用快照卷；

數據文件和事務日誌要在同一個邏輯捲上；

示例步驟：

1).打開會話，施加讀鎖，鎖定全部表；

mysql> FLUSH TABLES WITH READ LOCK;

mysql> FLUSH LOGS;

2).經過另外一個終端，保存二進制日誌文件及相關位置信息；

mysql -uroot -p -e 'SHOW MASTER STATUS\G' > /path/to/master.info

3).建立快照卷

lvcreate -L # -s -p r -n LV_NAME /path/to/source_lv

4).釋放鎖

mysql> UNLOCK TABLES;

5).掛載快照卷，備份

mount

cp

(6).刪除快照卷；

或者用現成的集成命令工具mylvmbackup(能夠集成上面的命令集合，自動完成備份)

mylvmbackup --user=dba --password=xxx  --mycnf=/etc/my.cnf   --vgname=testvg  --lvname=testlv --backuptype=tar --lvsize=100M --backupdir=/var/lib/backup

4.xtrabackup 備份數據庫，實現徹底熱備份與增量熱備份（MyISAM是溫備份，InnoDB是熱備份），因爲有的數據在設計之初，數據目錄沒有存放在LVM上，因此不能用LVM做備份，則用xtrabackup代替來備份數據庫

說明：Xtrabackup是一個對InnoDB作數據備份的工具，支持在線熱備份(備份時不影響數據讀寫)，是商業備份工具InnoDB Hotbackup或ibbackup的一個很好的替代品。

Xtrabackup有兩個主要的工具：xtrabackup、innobackupex:

xtrabackup 只能備份InnoDB和XtraDB兩種數據表，而不能備份MyISAM數據表。

innobackupex 是參考了InnoDB Hotbackup的innoback腳本修改而來的.innobackupex是一個perl腳本封裝，封裝了xtrabackup。主要是爲了方便的同時備份InnoDB和MyISAM引擎的表，但在處理myisam時須要加一個讀鎖。而且加入了一些使用的選項。如slave-info能夠記錄備份恢復後做爲slave須要的一些信息，根據這些信息，能夠很方便的利用備份來重作slave。

特色：備份過程快速、可靠;備份過程不會打斷正在執行的事務；可以基於壓縮等功能節約磁盤空間和流量；自動實現備份檢驗；還原速度快。

5.主從複製（replication）實現數據庫實時備份（集羣中經常使用）

6.總結

單機備份是徹底備份（全部數據庫文件）+增量備份（備份二進制日誌）相結合！

集羣中備份是徹底備份（全部數據庫文件）+增量備份（備份二進制日誌）+主從複製（replication）相結合的方法！

數據會完整備份到/root/mybackup/xtrabackup/中目錄名字爲當前的日期，xtrabackup會備份全部的InnoDB表，MyISAM表只是複製表結構文件、以及MyISAM、MERGE、CSV和ARCHIVE表的相關文件，同時還會備份觸發器和數據庫配置信息相關的文件。除了保存數據外還生成了一些xtrabackup須要的數據文件，詳解以下：

xtrabackup_checkpoints 備份類型（如徹底或增量）、備份狀態（如是否已經爲prepared狀態）和LSN(日誌序列號)範圍信息；每一個InnoDB頁(一般爲16k大小)都會包含一個日誌序列號，即LSN。LSN是整個數據庫系統的系統版本號，每一個頁面相關的LSN可以代表此頁面最近是如何發生改變的。

xtrabackup_binlog_info mysql服務器當前正在使用的二進制日誌文件及至備份這一刻爲止二進制日誌事件的位置。

xtrabackup_binary 備份中用到的xtrabackup的可執行文件。

backup-my.cnf 備份命令用到的配置選項信息。

xtrabackup_logfile 記錄標準輸出信息xtrabackup_logfile

注:若是在增量備份後數據庫出現故障，咱們須要經過完整備份+到如今爲止的全部增量備份+最後一次增量備份到如今的二進制日誌來恢復。

示例:

安裝percona-xtrabackup

解決依賴關係:yum -y install perl perl-devel libaio libaio-devel perl-Time-HiRes perl-DBD-MySQL rsync perl-Digest-MD5 libev

下載percona-xtrabackup:wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.6/binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.6-1.el7.x86_64.rpm

安裝percona-xtrabackup:rpm -ivh percona-xtrabackup-24-2.4.6-1.el7.x86_64.rpm

能夠建立一個最小權限的用戶進行備份

mysql> CREATE USER ’bkpuser’@’localhost’ IDENTIFIED BY ’111111’;
mysql> REVOKE ALL PRIVILEGES, GRANT OPTION FROM ’bkpuser’;
mysql> GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO ’bkpuser’@’localhost’;
mysql> FLUSH PRIVILEGES;

單獨備份：

#innobackupex --user=root --password=111111 --host=192.168.2.5 --defaults-file=/etc/my.cnf --databases=test /root/mybackup

備份並打包壓縮：

#innobackupex --user=root --password=111111 --host=192.168.2.5 --defaults-file=/etc/my.cnf --databases=test --stream=tar /root/mybackup/ | gzip > /root/mybackup/testdb.tar.gz

帶時間戳：

innobackupex --user=root --password=111111 --host=192.168.2.5 --defaults-file=/etc/my.cnf --databases=test --stream=tar /root/mybackup/ | gzip > /root/mybackup/`date +%F`_testdb.tar.gz

備份信息輸出重定向到文件：

innobackupex --user=root --password=111111 --host=192.168.2.5 --defaults-file=/etc/my.cnf --databases=test --stream=tar /root/mybackup/ 2>/root/mybackup/test.log | gzip 1>/root/mybackup/test.tar.gz

說明：

--stream #指定流的格式，目前只支持tar

--database=test #單獨對test數據庫作備份 ，如果不添加此參數那就那就是對全庫作

2>/root/mybackup/test.log #輸出信息寫入日誌中

1>/root/mybackup/test.tar.gz #打包壓縮存儲到該文件中

解壓 tar -izxvf 要加-i參數，官方解釋 innobackupex : You must use -i (--ignore-zeros) option for extraction of the tar stream.

在備份完成後，數據尚且不能用於恢復操做，由於備份的數據中可能會包含還沒有提交的事務或已經提交但還沒有同步至數據文件中的事務。

此時數據文件仍處理不一致狀態。「準備」的主要做用正是經過回滾未提交的事務及同步已經提交的事務至數據文件也使得數據文件處於一致性狀態。

 5、xtrabackup工具有份與恢復實戰

 1.xtrabackup工具數據庫徹底備份與恢復

 (1)查看當前測試數據庫test，表tb02,準備備份目錄爲/root/mybackup

 mysql> USE test;
 Database changed
 mysql> SHOW TABLES;
 +----------------+
 | Tables_in_test |
 +----------------+
 | tb02           |
 +----------------+
 1 row in set (0.00 sec)
 mysql> SELECT * FROM tb02;
+---+---+
| a | b |
+---+---+
| 1 | 2 |
+---+---+
1 row in set (0.00 sec)

 (2)對test庫進行全備份

# innobackupex --user=root --password=111111 --host=192.168.2.5 --default-file=/etc/my.cnf --include=test /root/mybackup/
170227 11:11:01 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!".
......(此處省略內容)
170227 11:11:06 Backup created in directory '/root/mybackup/2017-02-27_11-11-01/'
170227 11:11:06 [00] Writing backup-my.cnf
170227 11:11:06 [00]        ...done
170227 11:11:06 [00] Writing xtrabackup_info
170227 11:11:06 [00]        ...done
xtrabackup: Transaction log of lsn (30571253363) to (30571253372) was copied.
170227 11:11:07 completed OK!   #test庫備份成功

(3)模擬數據被破壞(test數據庫被刪)

mysql> drop database test;
Query OK, 1 row affected (0.01 sec)

# ls /mydata/data/  #存放數據目錄下已經沒有test目錄了
auto.cnf      ibdata1      ibtmp1           node03.err            sys
ddl_log.log     ib_logfile0  mysql            node03.pid          
ib_buffer_pool  ib_logfile1  mysqld_safe.pid  performance_schema

(4)從test全備中恢復test數據庫

注:使用innobackupex的--apply-log和--export選項

先暫停mysql服務:systemctl stop  mysqld.service

# innobackupex --user=root --password=111111 --host=192.168.2.5 --default-file=/etc/my.cnf --apply-log --export  /root/mybackup/2017-02-27_11-11-01/
170227 11:14:43 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!".
......(此處省略內容)
InnoDB: 32 non-redo rollback segment(s) are active.
InnoDB: 5.7.13 started; log sequence number 30571253781
xtrabackup: starting shutdown with innodb_fast_shutdown = 0
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 30571253800
170227 11:14:48 completed OK!

拷貝備份文件拷貝回數據目錄/mydata/data

#cp -rf /root/mybackup/2017-02-27_11-11-01/* /mydata/data/
# ls /mydata/data/  #存放數據目錄下test目錄已經恢復
auto.cnf      ibdata1      ibtmp1           node03.err            sys
ddl_log.log     ib_logfile0  mysql            node03.pid          test
ib_buffer_pool  ib_logfile1  mysqld_safe.pid  performance_schema

    受權目錄權限

# chown -R mysql:mysql /mydata/data/

    啓動mysql服務

#systemctl start  mysql.service

檢查還原後的數據庫以及表是否正常

mysql> SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| test               |
+--------------------+
5 rows in set (0.00 sec)
mysql> USE test;
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 tb02;
+---+---+
| a | b |
+---+---+
| 1 | 2 |
+---+---+
1 row in set (0.00 sec)

 2.示例1是對單個庫的全備份以及還原，實際生產環境中存在全部庫的備份還原。

 (1)全部庫備份(innobackupex後不帶--include或--databases參數即表示全備全部庫)

# innobackupex --user=root --password=111111 --host=192.168.2.5  /root/mybackup/
170227 11:52:46 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!".

Unrecognized character \x01; marked by <-- HERE after <-- HERE near column 1 at - line 1374.
170227 11:52:46 Connecting to MySQL server host: 192.168.2.5, user: root, password: set, port: not set, socket: not set
Using server version 5.7.17
innobackupex version 2.4.6 based on MySQL server 5.7.13 Linux (x86_64) (revision id: 54967d1)
xtrabackup: uses posix_fadvise().
......(此處省略內容)
170227 11:52:51 Executing UNLOCK TABLES
170227 11:52:51 All tables unlocked
170227 11:52:51 [00] Copying ib_buffer_pool to /root/mybackup/2017-02-27_11-52-46/ib_buffer_pool
170227 11:52:51 [00]        ...done
170227 11:52:51 Backup created in directory '/root/mybackup/2017-02-27_11-52-46/'
170227 11:52:51 [00] Writing backup-my.cnf
170227 11:52:51 [00]        ...done
170227 11:52:51 [00] Writing xtrabackup_info
170227 11:52:51 [00]        ...done
xtrabackup: Transaction log of lsn (30571256358) to (30571256367) was copied.
170227 11:52:51 completed OK!

 (2)模擬數據被破壞(/mydata/data/目錄下數據庫文件被刪除)

# rm -rf /mydata/data/*  數據所有刪除

 (3)從全備中恢復數據

提交未提交的數據,使用--apply-log 參數

 # innobackupex --user=root --password=111111 --host=192.168.2.5 --apply-log  /root/mybackup/2017-02-27_11-52-46/
170227 14:03:31 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: 54967d1)
xtrabackup: cd to /root/mybackup/2017-02-27_11-52-46/
xtrabackup: This target seems to be not prepared yet.
InnoDB: Number of pools: 1
xtrabackup: xtrabackup_logfile detected: size=8388608, start_lsn=(30571256358)
......
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 30571256872
170227 14:03:36 completed OK!

拷貝全備文件至/mydata/data/，並修改文件屬主和屬組，啓動mysql服務

# cp -rf /root/mybackup/2017-02-27_11-52-46/* /mydata/data/
# chown -R mysql:mysql /mydata/data/
# systemctl start mysqld.service

 3.實際生產環境中，經常使用的備份策略，如上面提到的每週一個全備份，天天一個增量備份等，下面示例模擬該場景。

(1)mysql開啓二進制日誌記錄，在/etc/my.cnf配置新增以下參數:

server-id =1

log-bin=mysql-bin  (#強烈建議生產環境中二進制日誌保存位置應該在不一樣磁盤單獨保存)

binlog-format=row

# systemctl restart mysqld.service  #須要重啓mysql服務

(2)進行全備份。

# innobackupex --user=root --password=111111 --host=192.168.2.5 --default-file=/etc/my.cnf /root/mybackup/
......(省略此內容)
170227 15:36:02 Executing UNLOCK TABLES
170227 15:36:02 All tables unlocked
170227 15:36:02 [00] Copying ib_buffer_pool to /root/mybackup/2017-02-27_15-35-57/ib_buffer_pool
170227 15:36:02 [00]        ...done
170227 15:36:02 Backup created in directory '/root/mybackup/2017-02-27_15-35-57/'
MySQL binlog position: filename 'mysql-bin.000002', position '154'
170227 15:36:02 [00] Writing backup-my.cnf
170227 15:36:02 [00]        ...done
170227 15:36:02 [00] Writing xtrabackup_info
170227 15:36:02 [00]        ...done
xtrabackup: Transaction log of lsn (30571256975) to (30571256984) was copied.
170227 15:36:02 completed OK!  #備份完成
# cat /root/mybackup/2017-02-27_15-35-57/xtrabackup_checkpoints 
backup_type = full-backuped
from_lsn = 0
to_lsn = 30571256975
last_lsn = 30571256984
compact = 0
recover_binlog_info = 0

(3)第1次增量備份(增量存放位置/root/backupnew)

增量備份以前，在test數據庫tb02表插入一行數據

mysql> insert into tb02 values (3,4);
Query OK, 1 row affected (0.04 sec)

#innobackupex --user=root --password=111111 --host=192.168.2.5  --incremental  /root/backupnew/ --incremental-basedir=/root/mybackup/2017-02-27_15-35-57/
......(此處內容省略)
170227 16:03:39 [00] Copying ib_buffer_pool to /root/backupnew/2017-02-27_16-03-35/ib_buffer_pool
170227 16:03:39 [00]        ...done
170227 16:03:39 Backup created in directory '/root/backupnew/2017-02-27_16-03-35/'
MySQL binlog position: filename 'mysql-bin.000002', position '414'
170227 16:03:39 [00] Writing backup-my.cnf
170227 16:03:39 [00]        ...done
170227 16:03:39 [00] Writing xtrabackup_info
170227 16:03:39 [00]        ...done
xtrabackup: Transaction log of lsn (30571257380) to (30571257389) was copied.
170227 16:03:39 completed OK!

說明：

--incremental #增量備份存放位置

--incremental-basedir  #第1次增量備份指向全備份文件位置(如是第n次增量備份，該位置應該指向上一次備份文件位置)

# cat /root/backupnew/2017-02-27_16-03-35/xtrabackup_checkpoints 
backup_type = incremental
from_lsn = 30571256975   #這是全備時的"to_lsn"值
to_lsn = 30571257380
last_lsn = 30571257389
compact = 0
recover_binlog_info = 0

(4)第2次增量備份

再插入一行數據

mysql> insert into tb02 values (5,6);
Query OK, 1 row affected (0.04 sec)

# innobackupex --user=root --password=111111 --host=192.168.2.5  --incremental  /root/backupnew/ --incremental-basedir=/root/backupnew/2017-02-27_16-03-35/
說明:--incremental-basedir指向第1次增量備份
......(此處內容省略)
170227 16:11:29 Executing UNLOCK TABLES
170227 16:11:29 All tables unlocked
170227 16:11:29 [00] Copying ib_buffer_pool to /root/backupnew/2017-02-27_16-11-24/ib_buffer_pool
170227 16:11:29 [00]        ...done
170227 16:11:29 Backup created in directory '/root/backupnew/2017-02-27_16-11-24/'
MySQL binlog position: filename 'mysql-bin.000002', position '674'
170227 16:11:29 [00] Writing backup-my.cnf
170227 16:11:29 [00]        ...done
170227 16:11:29 [00] Writing xtrabackup_info
170227 16:11:29 [00]        ...done
xtrabackup: Transaction log of lsn (30571257724) to (30571257733) was copied.
170227 16:11:29 completed OK!
# cat /root/backupnew/2017-02-27_16-11-24/xtrabackup_checkpoints 
backup_type = incremental
from_lsn = 30571257380 #第1次增量備份的"to_lsn"值
to_lsn = 30571257724
last_lsn = 30571257733
compact = 0
recover_binlog_info = 0

備份完以後，再作一次數據插入，方便下面恢復到某個時間點測試

mysql> insert into tb02 values (7,8);
Query OK, 1 row affected (0.04 sec)

因爲上面log-bin二進制日誌跟數據保存與數據庫數據文件在同一目錄，如該目錄被損壞就不能恢復到某個時間點了，因此這裏拷貝二進制日誌至/tmp/下

#cp -a /mydata/data/mysql-bin.* /tmp/

(5)模擬數據損壞，如在最後一次插入數據後，存放數據庫文件目錄被惡意刪除了

# systemctl stop mysqld.service
# rm -rf /mydata/data/*   #刪除數據目錄文件

(6)合併全部備份數據文件

# innobackupex --apply-log --redo-only /root/mybackup/2017-02-27_15-35-57/   #準備合併全備份
170227 16:35:55 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!".
......(此處省略內容)
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 30571256993
InnoDB: Number of pools: 1
170227 16:35:56 completed OK!
# innobackupex --apply-log --redo-only /root/mybackup/2017-02-27_15-35-57/ --incremental-dir=/root/backupnew/2017-02-27_16-03-35/ #準備合併第一增量備份的文件
IMPORTANT: Please check that the apply-log run completes successfully.
           At the end of a successful apply-log run innobackupex
           prints "completed OK!".
......(此處省略內容)
170227 16:38:47 [01]        ...done
170227 16:38:47 [01] Copying /root/backupnew/2017-02-27_16-03-35/performance_schema/session_status.frm to ./performance_schema/session_status.frm
170227 16:38:47 [01]        ...done
170227 16:38:47 [00] Copying /root/backupnew/2017-02-27_16-03-35//xtrabackup_binlog_info to ./xtrabackup_binlog_info
170227 16:38:47 [00]        ...done
170227 16:38:47 [00] Copying /root/backupnew/2017-02-27_16-03-35//xtrabackup_info to ./xtrabackup_info
170227 16:38:47 [00]        ...done
170227 16:38:47 completed OK!
# innobackupex --apply-log --redo-only /root/mybackup/2017-02-27_15-35-57/ --incremental-dir=/root/backupnew/2017-02-27_16-11-24/ #準備合併第二增量備份的文件
IMPORTANT: Please check that the apply-log run completes successfully.
           At the end of a successful apply-log run innobackupex
           prints "completed OK!".
......(此處省略內容)
170227 16:40:16 [01] Copying /root/backupnew/2017-02-27_16-11-24/performance_schema/global_status.frm to ./performance_schema/global_status.frm
170227 16:40:16 [01]        ...done
170227 16:40:16 [01] Copying /root/backupnew/2017-02-27_16-11-24/performance_schema/session_status.frm to ./performance_schema/session_status.frm
170227 16:40:16 [01]        ...done
170227 16:40:16 [00] Copying /root/backupnew/2017-02-27_16-11-24//xtrabackup_binlog_info to ./xtrabackup_binlog_info
170227 16:40:16 [00]        ...done
170227 16:40:16 [00] Copying /root/backupnew/2017-02-27_16-11-24//xtrabackup_info to ./xtrabackup_info
170227 16:40:16 [00]        ...done
170227 16:40:16 completed OK!
# cat /root/mybackup/2017-02-27_15-35-57/xtrabackup_checkpoints 
backup_type = log-applied
from_lsn = 0
to_lsn = 30571257724  #這時已經合併到第二次增量備份是的「to_lsn」值
last_lsn = 30571257733
compact = 0
recover_binlog_info = 0

拷貝合併後的文件至/mydata/data/，並修改文件屬主和屬組，啓動mysql服務

# cp -rf /root/mybackup/2017-02-27_15-35-57/* /mydata/data/
# chown -R mysql:mysql /mydata/data/
# systemctl start mysqld.service

檢查數據

mysql> select * from tb02;
+---+---+
| a | b |
+---+---+
| 1 | 2 |
| 3 | 4 |
| 5 | 6 |
+---+---+
3 rows in set (0.00 sec)

注意：這時沒法恢復到第二次增量備份後的操做，也就是插入的新數據這裏沒有，二進制日誌就起到了關鍵的做用了。

查看第2次增量後的二進制日誌文件及position信息：

# cat /root/backupnew/2017-02-27_16-11-24/xtrabackup_binlog_info 
mysql-bin.000002674

用mysqlbinlog工具導出最後一次增量備份後的sql操做

#/usr/local/mysql/bin/mysqlbinlog --start-position=674 /tmp/mysql-bin.000002 > /tmp/t.sql

在test數據庫，導入t.sql

mysql> source /tmp/t.sql

從新檢查數據:

mysql> select * from tb02;
+---+---+
| a | b |
+---+---+
| 1 | 2 |
| 3 | 4 |
| 5 | 6 |
| 7 | 8 |
+---+---+
4 rows in set (0.00 sec)

總結:

一、xtrabackup進行數據恢復時須要把各個增量的數據備份與全備份的數據進行合併，對每次增量備份的合併只能將已提交的事務進行重放(redo)，對合備份的數據恢復也只能作redo操做，把各個增量都合併完成後再把沒有提交的事務進行回滾(undo)操做，合併完增量備份後，全備份的「xtrabackup_checkpoints」文件中的「last_lsn」應該是最後一次增量備份時的值，這些合併作redo的過程就是恢復數據前的準備工做（prepare）。

而真正在作數據恢復，建議先把全備和增量備份的文件都copy一份爲副本，避免操做失誤致使備份文件的損壞。

二、經過apply-log同步到徹底備份文件中，若是但願利用增量日誌還原到固定某次增量備份的數據，則不能使用apply-log操做，若是但願利用增量日誌還原到固定哪次增量備份的數據，則將最初的徹底備份的數據、和指望還原到某個增量備份前的增量備份的數據，拷貝一份到別的地方，而後依次對拷貝出來的徹底備份作apply-log，對每次增量備份作apply-log，而後用造成的apply-log後造成的徹底備份的數據，進行恢復.

三、實際恢復測試中，innobackupex使用--copy-back參數時，會報錯如下:

# innobackupex --defaults-file=/etc/my.cnf --copy-back /root/mybackup/2017-02-27_11-52-46/

170227 14:53:27 innobackupex: Starting the copy-back operation

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

          At the end of a successful copy-back run innobackupex

          prints "completed OK!".

innobackupex version 2.4.6 based on MySQL server 5.7.13 Linux (x86_64) (revision id: 54967d1)

Original data directory /mydata/data is not empty!

有google、百度說是xtrabackup的BUG，建議採用--apply-log後，進行拷貝文件，再修改文件的屬主和屬組也是能夠的。

參考連接:http://zhaochj.blog.51cto.com/368705/1633254