1. 線上備份

2. 離線備份

2.1. 關閉MySQL做備份是最簡單、最安全的

2.2. 所有獲取一致性副本的方法中最好的

2.3. 損壞或不一致的風險最小

2.4. 根本不用關心InnoDB緩衝池中的臟頁或其他緩存

2.5. 不需要擔心數據在嘗試備份的過程中被修改

2.5.1. 伺服器不對應用提供訪問

3. 備份時間

3.1. 將備份複製到目的地需要多久

4. 備份負載

4.1. 在將備份複製到目的地時對伺服器性能的影響有多大

4.2. 在備份伺服器上壓縮而不是在MySQL伺服器上

4.3. Percona XtraBackup和MySQL Enterprise Backup這樣的工具都有限流選項，可在使用p v時加--rate-limit選項來限製備份腳本的吞吐量

5. 犧牲其一以增強另外一個

6. 恢復時間

6.1. 把備份鏡像從存儲位置複製到MySQL伺服器、重放二進位日誌等，需要多久

7. 邏輯備份

7.1. 導出

7.2. 以一種MySQL能夠解析的格式來包含數據

7.2.1. SQL語句

7.2.2. 以某個符號分隔的文本

7.3. 優點

7.3.1. 邏輯備份備份的文件是可以用編輯器或像grep和sed之類的命令查看和操作的普通文件

7.3.2. 恢復非常簡單

7.3.3. 可以通過網路來備份和恢復，也就是說，可以在與MySQL主機不同的另外一臺機器上操作

7.3.4. 可以在類似雲資料庫這樣不能訪問底層文件系統的系統中使用

7.3.5. 靈活

7.3.6. 與存儲引擎無關

7.3.6.1. 消除了底層數據存儲引擎的差異

7.3.7. 有助於避免數據損壞

7.3.7.1. 如果MySQL在記憶體中的數據還沒有損壞，當不能得到一個正常的裸文件備份時，或許可以得到一個可以信賴的邏輯備份

7.4. 缺點

7.4.1. 必須由資料庫伺服器完成生成邏輯備份的工作，因此要占用更多的CPU周期

7.4.1.1. 某些場景下比資料庫文件本身更大

7.4.2. 無法保證導出後再還原出來的一定是同樣的數據

7.4.2.1. 浮點表示的問題、軟體Bug等都會導致問題

7.4.3. 從邏輯備份中還原需要MySQL載入和解釋語句，將它們轉化為存儲格式，並重建索引，所有這一切會很慢

7.4.3.1. MySQL中導出數據和通過SQL語句將其載入回去的龐大開銷

7.4.3.2. 如果使用邏輯備份，測試恢復需要的時間將非常重要

7.4.3.3. 邏輯備份最可怕的地方就是不確定的還原時間

8. 裸文件備份

8.1. 原始文件是指存放於硬碟上的文件

8.2. 直接複製原始文件

8.3. 優點

8.3.1. 基於文件的物理備份，它只需將需要的文件複製到其他地方即可完成備份，不需要其他額外的工作來生成原始文件

8.3.2. 非常容易跨平臺、操作系統和MySQL版本工作

8.3.3. 從裸文件備份中恢復會更快

8.3.3.1. MySQL伺服器不需要執行任何SQL語句或構建索引

8.3.3.2. 如果有很大的InnoDB表，無法完全緩存到記憶體中，則裸文件備份的恢復要快得多

8.3.3.2.1. 至少要快一個數量級

8.4. 缺點

8.4.1. InnoDB的原始文件通常比相應的邏輯備份要大得多

8.4.1.1. 表空間往往包含很多未使用的空間

8.4.2. 不總是可以跨平臺、操作系統及MySQL版本的

8.4.2.1. 文件名大小寫敏感和浮點格式是可能會遇到麻煩的

8.4.2.2. 對於需要長期保留或者是用於滿足法律合規要求的備份，儘量不要完全依賴裸文件備份

8.4.2.3. 每隔一段時間需要做一次邏輯備份

8.4.3. 除非經過測試，不要假定備份（特別是裸文件備份）是正常的

8.4.3.1. CHECK TABLES

8.4.3.2. 不建議僅對文件運行innochecksum

9. 混合使用

9.1. 使用裸文件備份

9.2. 用得到的數據啟動MySQL伺服器實例並運行mysqlcheck

9.3. 周期性地使用mysqldump執行邏輯備份

9.4. 優點是不會使生產伺服器在導出時有過度負擔

9.5. 如果能夠方便地利用文件系統的快照，也可以生成一個快照，將該快照複製到另外一臺伺服器上並釋放，然後測試原始文件，再執行邏輯備份

10. 備份什麼

10.1. 恢復的需求決定需要備份什麼

10.2. 最簡單的策略是只備份數據和表定義，但這是一個最低的要求

10.3. 非顯著數據

10.3.1. 二進位日誌和InnoDB事務日誌

10.3.2. 在理想情況下，應該把整個數據目錄和MySQL一起備份起來

10.4. 代碼

10.4.1. 現代的MySQL伺服器可以存儲許多代碼，例如，觸發器和存儲過程

10.4.2. 實際是存放在mysql資料庫中的

10.5. 伺服器配置

10.5.1. 對於伺服器配置來說，備份中對生產伺服器至關重要的任何外部配置，都十分重要

10.6. 選定的操作系統文件

10.6.1. 在UNIX伺服器上，這可能包括cron任務、用戶和組的配置、管理腳本，以及sudo規則

11. 部分備份

11.1. 一般不包含完整的數據集

11.1.1. 因為某些數據沒有改變

11.1.2. 對減少伺服器開銷、備份時間及備份空間而言都很適合

11.2. Percona XtraBackup和MySQL Enterprise Backup，仍然會掃描伺服器上的所有數據塊，因而並不會節約太多的開銷

11.2.1. 確實會減少一定量的備份時間和大量用於壓縮的CPU時間

11.2.2. 會減少磁碟空間的使用

11.3. 差異備份

11.3.1. 自上次全備份後所有改變的部分而做的備份

11.4. 增量備份

11.4.1. 對自任意類型的上次備份後的所有修改做的備份

11.4.2. 缺點

11.4.2.1. 會增加恢復的複雜性

11.4.2.2. 額外的風險

11.4.2.3. 更長的恢復時間

12. 建議

12.1. 使用Percona XtraBackup和MySQL Enterprise Backup中的增量備份特性

12.2. 備份二進位日誌

12.2.1. 在每次備份後使用FLUSH LOGS來開始記錄一個新的二進位日誌，這樣就只需要備份新的二進位日誌

12.3. 如果有一些“引用”表，例如，包含不同語種、各個月的名稱列表，或者州或區域的簡寫等，可以考慮將它們單獨放在一個資料庫中，這樣就不需要每次都備份這些表

12.3.1. 一個更好的選擇可能是把這些數據放到程式代碼中，而不是保存在資料庫中

12.4. 某些數據根本不需要備份

12.4.1. 相對於從全備份中可能獲得的快速恢復時間，避免備份可以節約更多時間開銷

12.4.2. 臨時數據也不用備份

12.5. 備份所有的數據，然後發送到一個有去重特性的地方

12.6. 如果可以做全備份，考慮到簡便性，建議儘量做全備份

12.6.1. 建議至少一周一次

13. 複製

13.1. 從副本中備份最大的好處是可以不幹擾源庫，避免在源庫上增加額外的負載

13.1.1. 這是一個建立副本伺服器的好理由，即使不需要用它做負載均衡或提供高可用性

13.2. 用GTID是非常明智的

13.2.1. 避免了必須保存有關複製過程的所有信息

13.3. 故意將一個副本延遲複製一段時間對於某些災難場景非常有用

13.4. 源庫與副本數據不匹配是很常見的，並且MySQL沒有方法檢測這個問題

13.4.1. 唯一方法是使用Percona Toolkit中的pt-table-checksum之類的工具

13.4.2. 防止這種情況的最好方法是使用super_read_only來確保只有複製可以寫入副本

13.5. 複製不是備份