按照數據庫大小備份，有四種類型，分別應用於不同場合，下面簡要介紹一下：
這是大多數人常用的方式，它可以備份整個數據庫，包含用戶表、系統表、索引、視圖和存儲過程等所有數據庫對象。但它需要花費更多的時間和空間，所以，一般推薦一周做一次完全備份。
事務日志是一個單獨的文件，它記錄數據庫的改變，備份的時候只需要復制自上次備份以來對數據庫所做的改變，所以只需要很少的時間。為了使數據庫具有魯棒性，推薦每小時甚至更頻繁的備份事務日志。
也叫增量備份。它是只備份數據庫一部分的另一種方法，它不使用事務日志，相反，它使用整個數據庫的一種新映象。它比最初的完全備份小，因為它只包含自上次完全備份以來所改變的數據庫。它的優點是存儲和恢復速度快。推薦每天做一次差異備份。
數據庫可以由硬盤上的許多文件構成。如果這個數據庫非常大，並且一個晚上也不能將它備份完，那麼可以使用文件備份每晚備份數據庫的一部分。由於一般情況下數據庫不會大到必須使用多個文件存儲，所以這種備份不是很常用。
按照數據庫的狀態可分為三種：
1.冷備份，此時數據庫處於關閉狀態，能夠較好的保證數據庫的完整性。
2.熱備份，數據庫正處於運行狀態，這種方法依賴於數據庫的[1] 日志文件進行備份。
3.邏輯備份，使用軟件從數據庫中提取數據並將結果寫到一個文件上。
mysql按照備份恢復方式分為邏輯備份和物理備份。邏輯備份是備份sql語句，在恢復的時候執行備份的sql語句實現數據庫數據的重現，物理備份就是備份數據文件了，比較形象點就是cp下數據文件，但真正備份的時候自然不是的cp這麼簡單。
這2種備份各有優劣，一般來說，物理備份恢復速度比較快，占用空間比較大，邏輯備份速度比較慢，占用空間比較小。
Mysqldump是mysql自帶的備份工具，目錄在bin目錄下面：/usr/local/mysql/bin/mysqldump，支持基於innodb的熱備份。但是由於是邏輯備份，所以速度不是很快，適合備份數據比較小的場景。Mysqldump完全備份+二進制日志可以實現基於時間點的恢復。
對myisam存儲引擎的表，只能使用溫備份，這個時候要防止數據的寫入，所以先加上讀鎖。這個時候也可以進入數據庫手動加讀鎖，不過這樣比較麻煩，可以在mysqldump工具中直接有一個加鎖的選擇，就是 --lock-all-tables ，例如mysqldump --databases test --lock-all-tables --flush-logs > /tmp/backup_test_`date+%F-%H-%M`.sql。
如果是備份單張表，直接在庫名字test後面加上表名字即可。
對於innodb存儲引擎表，可以熱備，不必對數據庫進行加鎖的操作，加一個選項可以進行熱備份，--single-transaction，例如：mysqldump --databases test --single-transaction --flush-logs--master-data=2> /tmp/backup_test_`date +%F-%H-%M`.sql。
PS：注意點，恢復的時候記得關閉二進制日志：
mysql> set sql_log_bin=0;
因為這是基於邏輯備份方式，所以執行sql會插入數據，會記錄到二進制日志裡面去，因為這事恢復，所以插入的二進制日志基本沒有啥意思，可以關閉掉，縮短恢復時間。
在物理備份中，有基於文件系統的物理備份（LVM的快照），也可以直接用tar之類的命令對整個數據庫目錄進行打包備份，但是這些只能進行泠備份，不同的存儲引擎備份的也不一樣，myisam自動備份到表級別，而innodb不開啟獨立表空間的話只能備份整個數據庫。
下面就介紹下使用LVM的快照功能進行備份為了安全，首先在數據庫上施加讀鎖
mysql>FLUSH TABLES WITH READ LOCK;
刷新一下二進制日志，便於做時間點恢復
mysql>FLUSH LOGS;
然後創建快照卷
lvcreate –L 1G –s –n data-snap –p –r/dev/myvg/mydata
最後進入數據庫釋放讀鎖
UNLOCK TABLES;
掛載快照卷進行備份
mount –r /dev/myvg/data-snap /mnt/snap
然後對/mnt/snap下的文件進行打包備份
還原的時候，關閉mysqld，然後備份二進制日志後將原來備份的文件還原進去，然後通過二進制日志還原到出錯的時間點（通過二進制還原時間點的時候不要忘了暫時關閉二進制日志）
在2010年到2012年之間，mysql數據庫部署在亞馬遜的雲環境中，他們提供了LVM快照，蠻方便快捷的，使用lvm快照，在亞馬遜的萬兆網絡下，恢復起來也迅速無比。
0，准備從庫第一次數據備份，臨時鎖所有表，開啟窗口1
mysql> flush tables with read lock; Query OK, 0 rows affected (0.00 sec) mysql> show master status; +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB |Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000003 | 194554 | | | +------------------+----------+--------------+------------------+ 1 row in set (0.00 sec)
PS：這個窗口不能exit，要一直保持知道tar完包為止。
--重新開一個shell窗口，去數據文件目錄tar包
開啟窗口2
切換到窗口1，執行解鎖命令
mysql>
copy tar包到另外一個mysql庫服務器上面，覆蓋data目錄，然後重啟mysql數據庫服務。
支持innodb的物理熱備份，支持完全備份，增量備份，而且速度非常快，支持innodb存儲引起的數據在不同數據庫之間遷移，支持復制模式下的從機備份恢復備份恢復
，為了讓xtrabackup支持更多的功能擴展，可以設立獨立表空間，打開 innodb_file_per_table功能，啟用之後可以支持單獨的表備份。
參考文章地址：http://www.Bkjia.com/database/201405/297844.html
支持在線熱備與恢復
大數據量的時候，備份恢復都比較快快
xtrabackup可以實現完全備份，增量備份，以及部分備份。
xtrabackup備份原理
xtraBackup基於InnoDB的crash-recovery功能。它會復制innodb的data file，由於不鎖表，復制出來的數據是不一致的，在恢復的時候使用crash-recovery，使得數據恢復一致。
InnoDB維護了一個redo log，又稱為transaction log，事務日志，它包含了innodb數據的所有改動情況。當InnoDB啟動的時候，它會先去檢查data file和transaction log，並且會做二步操作：
xtraBackup在備份的時候， 一頁一頁地復制innodb的數據，而且不鎖定表，與此同時，XtraBackup還有另外一個線程監視著transactions log，一旦log發生變化，就把變化過的log pages復制走。為什麼要急著復制走呢？因為transactions log文件大小有限，寫滿之後，就會從頭再開始寫，所以新數據可能會覆蓋到舊的數據。
在prepare過程中，XtraBackup使用復制到的transactionslog對備份出來的innodb data file進行crash recovery。
