1. 每個人都知道需要備份，但並不是每個人都能意識到需要的是可恢復的備份

1.1. 如果你沒有提前做好備份規劃，也許以後會發現已經錯失了一些最佳的選擇

1.2. 在伺服器已經配置好以後，才想起應該使用LVM，以便獲取文件系統的快照——但這時已經太遲了

1.3. 如果你沒有計劃做定期的恢復演練，當真的需要恢復時，就會發現並沒有那麼順利

2. 不要掉進副本就是備份的陷阱

2.1. 副本對生成備份而言是一個干涉較少的源，但它不是備份本身

2.2. 確保備份可以通過DROP TABLE測試

2.2.1. “遭受黑客攻擊”的測試

2.2.2. 能通過數據中心失敗的測試

2.2.3. 如果是基於備庫生成備份，需要通過從源重建備份，並從那時起強制執行super_read_only來確保你的所有副本是一致的

3. 裸文件備份

3.1. 物理備份

3.2. 文件系統中的文件副本

4. 邏輯備份

4.1. 重建數據所需的SQL語句

5. 推薦的備份方式

5.1. Percona XtraBackup進行裸文件備份

5.2. mydumper進行邏輯備份

5.3. 無侵入地實現二進位的原始數據備份

5.3.1. 備份可以通過啟動mysqld實例檢查所有的表來進行驗證

5.3.2. 建議備份二進位日誌

5.3.2.1. 儘可能久地保留多份備份的數據和二進位文件

5.3.2.2. 即使最近的備份無法使用，還可以使用較老的備份來執行恢復或者創建新的副本

6. 整體備份和恢復策略要點

6.1. 安全

6.1.1. 訪問備份的入口

6.1.2. 恢複數據的許可權

6.1.3. 文件是否需要加密

6.2. 備份存儲在哪裡

6.2.1. 離源數據多遠

6.2.1.1. 在一塊不同的磁碟上

6.2.1.2. 一臺不同的伺服器上

6.2.1.3. 離線存儲

6.2.2. 如何將數據從源頭移動到目的地

6.3. 保留策略、審計、法律要求，以及相關的條款

6.4. 存儲解決方案和介質，壓縮，以及增量備份

6.5. 存儲的格式

6.6. 對備份的監控和報告

6.7. 存儲層內置備份功能

6.7.1. 其他專用設備

7. 熱備份

7.1. 不需要任何的服務停機時間

8. 還原

8.1. 從備份文件中獲取數據，可以將這些文件載入到MySQL里，也可以將這些文件放置到MySQL期望的路徑中

9. 恢復

9.1. 當某些異常發生後對一個系統或其部分的拯救

9.2. 從備份中還原數據

9.3. 使伺服器完全恢復功能的所有必要步驟

9.4. 存儲引擎的崩潰恢復要求數據和日誌文件一致

9.4.1. 要確保數據文件中只包含已經提交的事務所做的修改，恢復操作會將日誌中還沒有應用到數據文件的事務重新執行

10. 備份的理由

10.1. 災難恢復

10.1.1. 硬體故障

10.1.2. 一個不經意的Bug導致數據損壞

10.1.3. 伺服器及其數據由於某些原因不可獲取或無法使用

10.1.4. 某人偶然連錯伺服器執行了一個ALTER TABLE操作

10.1.5. 機房大樓被燒毀

10.1.6. 惡意的黑客攻擊

10.2. 人們改變想法

10.2.1. 經常會在刪除某些數據後又想恢復這些數據

10.3. 審計

10.3.1. 需要知道數據或Schema在過去的某個時間點是什麼樣的

10.4. 測試

10.4.1. 最簡單的基於實際數據來測試的方法是，定期用最新的生產環境數據更新測試伺服器

10.4.2. 只要把備份文件還原到測試伺服器上即可

11. 備份誤區

11.1. 複製就是備份

11.1.1. 複製不是備份

11.1.2. 使用RAID陣列也不是備份

11.1.3. 不是備份，也不是備份的替代品

11.2. 快照就是備份

11.2.1. 無論是LVM、ZFS還是SAN快照，都不是真正的備份

11.2.1.1. 不包含數據的完整副本

11.2.2. 快照是寫時複製

11.2.2.1. 只包含數據的實時副本與快照發生時的數據之間的差異

11.2.3. 如果備份是用於某些特殊用戶的，那麼快照可能是一個非常好的方法

12. 定義恢復需求

12.1. 備份在先

12.1.1. 只有已經做了備份才可能恢復，因此在構建系統時，註意力自然會集中在備份上

12.2. 備份由腳本和任務自動完成

12.3. 備份是日常任務，但恢復常常發生在危急情形下

12.4. 安全的需要

12.4.1. 做異地備份，可能需要對備份數據進行加密，或採取其他措施來進行保護

12.5. 需要培養幾個人並有計劃地讓他們互為備份，這樣就無須由一個不合格的人來恢複數據

12.6. 恢復點目標（PRO）

12.7. 恢復時間目標（RTO）

13. 備份方案

13.1. 備份僅是數據的一個副本，但是受限於應用程式的要求、MySQL的存儲引擎架構，以及系統配置等因素，複製一份數據變得很困難

13.2. 對數據丟失的承受力越強，備份越簡單

13.2.1. 一個“寬鬆”的基於故障時間點的恢復需求意味著需要重建數據，直到“足夠接近”問題發生的時刻

13.2.2. 一個“硬性”的需求意味著不能容忍丟失任何一個已提交的事務，即使某些可怕的事情發生（例如，伺服器著火了）

13.2.2.1. 將二進位日誌保存在一個獨立的SAN捲

13.2.2.2. 使用DRBD磁碟複製

13.3. 在生產實踐中，對於大資料庫來說，裸文件備份是必需的：邏輯備份太慢並受到資源限制，從邏輯備份中恢復需要很長時間

13.3.1. 基於快照的備份，例如Percona   XtraBackup和MySQL  EnterpriseBackup，是最好的選擇

13.3.2. 對於較小的資料庫，邏輯備份可以很好地勝任

13.4. 保留多個備份集

13.5. 定期從邏輯備份（或者裸文件備份）中抽取數據進行恢複測試

13.6. 保存二進位日誌用於基於故障時間點的恢復

13.6.1. 將expire_logs_days參數的值設置得足夠大，至少確保可以從最近兩次裸文件備份中做基於時間點的恢復

13.6.2. 保持源運行且不應用任何二進位日誌的情況下創建一個副本

13.6.3. 使備份二進位日誌獨立於過期設置，二進位日誌需要保存在備份中足夠長的時間，以便能從最近的邏輯備份中進行恢復

13.6.4. 重放二進位日誌來恢復到想要的時間點

13.7. 完全不藉助備份工具本身來監控備份和備份的過程

13.7.1. 需要額外驗證備份是否正常

13.8. 通過演練整個恢復過程來測試備份和恢復

13.8.1. 測算恢復所需要的資源（CPU、磁碟空間、實際時間，以及網路帶寬等）

13.9. 考慮安全性