由於mysql存在多種數據庫備份方式，而且各有利弊，對於我們初學者來說，選擇合適的備份方式確實有些困難。個人覺得，首先要基於公司的需求，考慮能夠容忍丟失多少數據、花多少人力時間成本等，這是我們制定備份方案的依據，同時制定出來的方案要可執行，要執行，不能把方案當作紙上談兵。下面我把我們實際的備份方案整理出來供大家參考交流。
作為數據安全的一個重要內容——數據備份的重要性卻往往被人們所忽視。只要發生數據傳輸、數據存儲和數據交換，就有可能產生數據故障。這時，如果沒有采取數據備份和數據恢復手段與措施，就會導致數據的丟失，有時造成的損失是無法彌補與估量的。結合我們公司線上業務的實際情況，來說說我們的備份方案，當前主要采取全備+binlog備份方式。其中全備分為邏輯備份+物理備份，同時主從復制也作為一種備份的方式存在，從而最大程度降低數據故障帶來的風險。
一 數據備份部分
1 邏輯備份
- 應用場景
邏輯備份，我們主要用在當數據量較小時，數據庫出現數據故障，對於恢復時間要求不高；搭建主從環境，搭建測試環境及備用庫等方面。
- 備份時間及地點
每日凌晨3:10在從庫上備份，備份文件存放在從庫上的/data/backup/fullbackup，當然如果有充足的機器，更安全的方式是備份到遠程服務器。
- 備份方式
采用mysqldump進行全庫備份，通過定時任務，定時執行shell備份腳本。這里就不提供了。
2 物理備份
- 應用場景
主要應對要求恢復時間較高；數據量比較大；
- 備份時間及地點
每周一凌晨3:10在主庫上備份。備份文件存放遠程服務器目錄下
- 備份方式
采用percona的社區工具innobackupex，該工具可以在線熱備，不影響線上的業務。
以上兩種方式的備份只能恢復某段時間的數據，對於按照時間點的恢復是無能為力的，那怎么辦呢？binlog日志，是的，我們采取的是實時同步binlog日志到遠程服務器上，這樣理論上是可以恢復到任意時間點的。
3 binlog備份
- 應用場景
對於一些由於錯誤操作等造成數據丟失錯誤的，需要按照時間點進行還原的情況下。
- 備份時間及地點
備份服務器實時將主庫上binlog同步到遠程服務器上。
- 備份方式
mysqlbinlog工具進行日志拉取，shell腳本如下：
mysqlbinlog --read-from-remote-server --host=1.1.1.1 --port=3306 --user="backup" --password="backup" --raw --stop-never mysql-bin.000840 --result-file=/data/backup/binlog/
經過以上三種結合的備份方式，基本上可以滿足在數據異常丟失情況下，恢復到正常狀態。
4 主從復制
- 應用場景
主要應用於讀寫分離，故障轉移的情況下
- 備份時間及地點
幾乎可以認為是同步進行數據的復制
- 備份方式
采用mysql提供的復制技術
對於主從復制，如果用於備庫的話，最好是讓sql_thread執行慢一段時間，可以是1天。這個結合實際情況，自己選擇。
二 數據恢復與測試部分
備份文件有了之后還需要對其定期的進行恢復測試，不然可能是白忙一場。因為很多情況下，有些備份文件可能已經損壞。當我們遇到數據丟失故障時，在緊急關頭，竟然發現備份的文件無法恢復或者數據一致性和完整性沒有達到要求，如果我們定期的對備份文件進行恢復測試，這種悲劇可能就不會發生。
1 恢復時間及地點
每周進行一次恢復測試，主要在測試機上進行
2 恢復方式
模擬某個時間點主機數據全部丟失，要求恢復到丟失時間點的所有數據，先進行全備恢復，然后根據binlog恢復到最近時間點。
作為一名DBA，千萬不要忽視數據備份和恢復測試的重要性。要知道，有時，備份可能拯救我們的命！！！切記切記。