MySQL備份與還原詳細過程示例
一、MySQL備份類型
1.熱備份、溫備份、冷備份 （根據服務器狀態）
熱備份：讀、寫不受影響；
溫備份：僅可以執行讀操作；
冷備份：離線備份；讀、寫操作均中止；
2.物理備份與邏輯備份 （從對象來分）
物理備份：複製數據文件；
邏輯備份：將數據導出至文本文件中；
3.完全備份、增量備份、差異備份 （從數據收集來分）
完全備份：備份全部數據；
增量備份：僅備份上次完全備份或增量備份以後變化的數據；
差異備份：僅備份上次完全備份以來變化的數據；
4.邏輯備份的優點：
在備份速度上兩種備份要取決於不同的存儲引擎
物理備份的還原速度非常快。但是物理備份的最小力度只能做到表
邏輯備份保存的結構通常都是純ASCII的，所以我們可以使用文本處理工具來處理
邏輯備份有非常強的兼容性，而物理備份則對版本要求非常高
邏輯備份也對保持數據的安全性有保證
5.邏輯備份的缺點：
邏輯備份要對RDBMS產生額外的壓力，而裸備份無壓力
邏輯備份的結果可能要比源文件更大。所以很多人都對備份的內容進行壓縮
邏輯備份可能會丟失浮點數的精度信息
注:差異備份要比增量備份佔用的空間大，但恢復時比較方便！但我們一般都用增量備份！
二、MySQL備份都備份什麼
一般備份以下幾個部分：
1.數據文件
2.日誌文件（比如事務日誌，二進制日誌）
3.存儲過程，存儲函數，觸發器
4.配置文件（十分重要，各個配置文件都要備份）
5.用於實現數據庫備份的腳本，數據庫自身清理的Croutab等……
三、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商業工具的替代工具。
四、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.
在備份完成後，數據尚且不能用於恢復操作，因爲備份的數據中可能會包含尚未提交的事務或已經提交但尚未同步至數據文件中的事務。
此時數據文件仍處理不一致狀態。“準備”的主要作用正是通過回滾未提交的事務及同步已經提交的事務至數據文件也使得數據文件處於一致性狀態。
五、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)
總結:
1、xtrabackup進行數據恢復時需要把各個增量的數據備份與全備份的數據進行合併，對每次增量備份的合併只能將已提交的事務進行重放(redo)，對合備份的數據恢復也只能做redo操作，把各個增量都合併完成後再把沒有提交的事務進行回滾(undo)操作，合併完增量備份後，全備份的“xtrabackup_checkpoints”文件中的“last_lsn”應該是最後一次增量備份時的值，這些合併做redo的過程就是恢復數據前的準備工作（prepare）。
而真正在做數據恢復，建議先把全備和增量備份的文件都copy一份爲副本，避免操作失誤導致備份文件的損壞。
2、通過apply-log同步到完全備份文件中，如果希望利用增量日誌還原到固定某次增量備份的數據，則不能使用apply-log操作，如果希望利用增量日誌還原到固定哪次增量備份的數據，則將最初的完全備份的數據、和期望還原到某個增量備份前的增量備份的數據，拷貝一份到別的地方，然後依次對拷貝出來的完全備份做apply-log，對每次增量備份做apply-log，然後用形成的apply-log後形成的完全備份的數據，進行恢復.
3、實際恢復測試中，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