XtraBackup是現今為止唯一一款為InnoDB 和XtraDB提供熱備的開源工具，這個工具有以下的有點：
（1）備份快速高效而且可靠
（2）備份過程可以做到事物處理不間斷
（3）節省磁盤空間和網絡帶寬
（4）自動備份驗證
（5）恢復速度快而高效
XtraBackup適用於所有版本的Percona Server, MySQL, 和MariaDB.而且提供了流式備份，增量備份，全備份，壓縮備份的功能。對於InnoDB, XtraDB, 和HailDB，XtraBackup可以實現完全無阻塞的備份。而且它對MyISAM, Merge, 和Archive等存儲引擎也有很好的支持，但是在備份的末尾部分要短暫的寫入時間造成不可用狀態。當然官方也有一個要掏錢的工具MySQL Enterprise backup，不過大家都很少用的，功能相比XtraBackup不多，但是還是收費的，我們不排斥收費，我們只是力挺開源。
我們可以簡單先看一下XtraBackup能做到那些：
（1）InnoDB 無阻塞備份，如果不是INNODB的數據表的話還是回lock table。
（2）可以為mysql提供增量備份
（3）使用流式備份將mysql備份傳送到另外一台server
（4）在線在mysql數據庫之間移動數據表
（5）很輕松六步創建一個復制的slave，這個我寫過
http://www.cnblogs.com/shengdimaya/p/5798794.html
（6）對數據庫服務器沒有太大負載
（7）XtraBackup 提供多種加密備份。
percona的XtraBackup 在備份的過程中是回跳過二級索引的備份，直到備份一個完整的數據庫備份以后，再去重新創建二級索引，而且XtraBackup在備份中是可以導出單個表的，而且導出的表還可以在導入到percona庫里（版本號大於5.1或者mysql官方大於5.6），而且在備份的時候會產生一個備份鎖，是個輕量級的替代鎖（替代FLUSH TABLES WITH READ LOCK）。
我們上面已經看到了XtraBackup功能的強大之處，下面看一下XtraBackup到底是怎么運行的：
其實XtraBackup也是基於INNODB的 crash-recovery功能來實現的，他是對於數據文件的直接拷貝，為了保證數據內部的一致性，就需要使用到了crash-recovery來確保恢復的數據庫是一致性的，而且是可用的。mysql本身是有一個自己自身的事務日志文件，也就是redo log，也就是說當INNODB啟動的時候會做兩步操作，事務日志中已經提交的事物會重做，之前沒有提交的事物但是已經對數據文件做了修改的就會回滾，借此來保證數據的一致性。大部分關系型數據庫都是這個原理。XtraBackup 也是基於LSN( log sequence number)來工作的，每次啟動備份，都會記錄LSN，然后開始拷貝文件，拷貝文件是要花費一部分時間的，所以說這期間一般情況都會有數據交互，所以說所有文件也可能記錄的並不是一個時間點的數據，這個時候XtraBackup 就會啟動一個后台進程來觀測mysql的事務日志，而且把事務日志中的改變記錄下來。我們知道事物日志是回重用的（redo log）,所以說這個監控事務日志的后台進程從啟動那一刻起就會不停的運作，直到備份結束。這個后台監控進程會記錄所有的事務日志的改變，這些是保證數據一致性所必須的。
前面有提到，XtraBackup 在備份的時候會用一個備份鎖（ Backup locks ）來取代FLUSH TABLES WITH READ LOCK，這是一個輕量級的替代鎖（percona server 5.6+），XtraBackup 也會利用這個特性自動備份非INNODB表數據，可以防止阻塞DML語句的操作，當 backup locks 被支持的時候，xtrabackup 就會先拷貝INNODB的數據表，運行LOCK TABLES FOR BACKUP來拷貝MYASIM表和 .frm 文件，當拷貝結束后，在開始拷貝 .frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSM, .CSV, .par, 和.opt等文件。當然需要注意的是，備份的第一步是先完成INNODB的備份（文件和日志），LOCK TABLES FOR BACKUP只是針對非INNODB表來說的。
以上執行完畢以后，XtraBackup 會執行LOCK BINLOG FOR BACKUP來鎖定日志文件用以記錄在日志中的位置，或者是Exec_Master_Log_Pos 或者Exec_Gtid_Set的值，這些記錄值是和SHOW MASTER/SLAVE STATUS中report的是一致的。然后停止拷貝事務日志，記錄位置信息，結束以后unlock日志和表。
在恢復的准備階段，XtraBackup 會執行crash-recovery執行備份的日志，然后將數據庫啟動到可用的狀態。最終備份的INNODB和MYASIM表都會數據一致，INNODB表數據一致是到備份結束的時間點，而不是備份開始的時間點，因為日志是要應用到這個時間點的。這個時間點是和FLUSH TABLES WITH READ LOCK是一致的。
下面看一下怎么去Restoring 一個 backup：
我們可以使用--copy-back 或者 --move-backup參數來還原一個數據庫。在還原的時候，xtrabackup 會首先去讀取配置文件里面的一些參數（ datadir, innodb_data_home_dir, innodb_data_file_path, innodb_log_group_home_dir）已確定這些目錄是否存在。
如果存在的話就回去執行拷貝，首先被拷貝的是MYASIM表，索引還有一些其他存儲引擎的文件，接下來才會拷貝INNODB表和索引，然后是事務日志文件，在復制的時候是要保留源文件的所有屬性，所以說這些目錄的所有者最好是給mysql用戶。但是我們要特別注意--move-back這個參數，它是會移動備份文件，而不僅僅是恢復那么簡單。這樣的話原來的備份就沒有了，是一個很危險的操作，唯一的適用場景就是磁盤空間不足了，只能通過移動的方式來恢復，SO這個參數還是少用為妙。