MySQL 備份、還原與災難復原完整指南

資料庫管理最重要的工作之一，不只是建立 Database，也不是寫 SQL，而是 資料不見的時候，能不能救回來？

這件事情很多人並不會在意，直到你碰上了。

很多人知道要備份 MySQL，但真正的資料庫管理不能只問「有沒有 Backup？」而是還要關注：如果今天資料庫真的壞了，我可以恢復到什麼時間點？需要多久？

這就牽涉到：

• Backup（備份）
• Restore（還原）
• Recovery（復原）
• Full Backup（完整備份）
• Incremental Backup（增量備份）
• Binary Log
• Point-in-Time Recovery
• Disaster Recovery
• RPO
• RTO

Backup 不等於 Recovery

假設每天凌晨 2:00 完成一次 Backup，今天下午 16:00 資料庫發生問題。

02:00 ───────────────── 16:00
 Backup                  故障

如果只能 Restore 凌晨 2:00 的 Backup，代表中間 14 小時的資料可能遺失。

有 Backup，不代表具備完整的 Recovery 能力。

真正需要設計的是：Backup + Recovery Strategy。

Full Backup 完整備份

Full Backup 是某一個時間點完整保存資料。

優點是 Restore 邏輯簡單；缺點則是資料越大，Backup 越久、所需儲存空間越大，而且 Recovery Point 可能距離故障時間很遠。

因此大型正式環境通常不能只依靠每天一次 Full Backup。

mysqldump

學習 MySQL Backup 最常接觸到的工具之一是 mysqldump。

mysqldump -u root -p shop > shop.sql

可以將資料庫輸出成 SQL Format。

還原時：

mysql -u root -p shop < shop.sql

其優點是：

• 操作簡單
• SQL 格式容易理解
• 適合教學
• 適合較小型資料庫
• 可以選擇 Database 或 Table

但是資料量很大時，Logical Backup 的 Backup 與 Restore 時間就必須特別評估。

Logical Backup 與 Physical Backup

Logical Backup

保存 CREATE TABLE、INSERT 與資料內容等邏輯資訊，mysqldump 就是典型方法。

優點是可讀性高、彈性高、容易選擇個別 Table；但大型資料庫 Restore 可能比較花時間。

Physical Backup

直接處理 Database Physical Files。對大型資料庫而言，可能具有更好的 Backup / Restore 效率。

選擇何種方式必須考慮：

• Database Size
• Backup Window
• Restore Time
• Storage
• Availability
• MySQL 架構

Binary Log 是什麼？

如果只有凌晨 2:00 的 Full Backup，而事故發生在 16:00，如何找回中間 14 小時的變更？

其中一個非常重要的工具就是 Binary Log（Binlog）。

Binary Log 可以記錄會造成資料改變的事件，也可以用於 Replication。

Full Backup
     +
Binary Log
     ↓
Point-in-Time Recovery

Point-in-Time Recovery

Point-in-Time Recovery，簡稱 PITR，可以理解成：不只是還原某個 Backup，而是把資料庫重新推進到指定的時間點。

02:00 Full Backup
 │
 ├─ 02:01 Binlog
 ├─ 05:30 Binlog
 ├─ 10:00 Binlog
 ├─ 14:20 Binlog
 └─ 15:59 Binlog

16:00 發生事故

可以先 Restore 02:00 的 Full Backup，再重新套用 Binary Log，將資料恢復到接近事故發生之前的狀態。

PITR 也可以處理人為誤刪

資料庫災難不一定是硬碟損壞，更多時候可能是：

DELETE FROM customers;

甚至：

DROP TABLE orders;

假設錯誤操作發生在 2026-09-03 14:32:10，理想的 Recovery 目標可能是恢復到 14:32:09，也就是錯誤發生的前一刻。

RPO 是什麼？

RPO 是 Recovery Point Objective。

簡單講就是：最多可以接受遺失多少資料？

如果 RPO = 24 小時，代表公司可以接受最多損失一天資料；如果 RPO = 5 分鐘，Backup 與 Recovery Strategy 就必須讓資料恢復到非常接近故障前的狀態。

RTO 是什麼？

RTO 是 Recovery Time Objective。

它回答另一個問題：資料庫壞掉後，最多可以停機多久？

RTO = 8 小時，和 RTO = 10 分鐘，需要的架構完全不同。

因此 Backup Strategy 不是「每天幾點備份」，而是必須同時考慮 RPO + RTO。

Backup 不應該放在同一台 Server

MySQL Database
C:\mysql\data

Backup
C:\mysql\backup

看起來有 Backup，但如果整台 Disk 故障，Database 與 Backup 可能一起消失。

所以正式環境至少應該考慮：

• 不同 Disk
• 不同 Server
• Off-site Backup
• Object Storage
• Cloud Storage
• 不同地理位置

Backup 也需要安全管理

Backup 裡面通常包含使用者資料、Email、訂單、公司資料、個人資料與商業機密。

因此 Backup 本身也是高度敏感資料，應考慮：

• Encryption
• Access Control
• Retention Policy
• Backup Log
• Backup Integrity
• Secure Deletion

最重要的是 Restore Test

很多公司每天顯示「Backup Successful」就認為資料很安全，但真正重要的是：這份 Backup 到底能不能 Restore？

Backup
↓
Restore 到測試環境
↓
驗證 Schema
↓
驗證資料
↓
驗證 Application

所以 Backup Strategy 中一定要包含 Restore Test。

建議的 Backup Strategy

Production MySQL
      │
      ├── Full Backup
      │
      ├── Binary Log
      │
      ├── Off-site Copy
      │
      └── Restore Test
              │
              ↓
        Disaster Recovery

真正成熟的資料庫管理，不是「我有備份」，而是可以明確回答：

• 備份在哪裡？
• 多久備份一次？
• 保留多久？
• 誰可以讀？
• 能否還原？
• 多久可以還原？
• 最多損失多少資料？
• 能否恢復到指定時間？

備份的目的從來不是產生 Backup File，真正的目的只有一個：發生事故之後，可以把資料救回來。

延伸學習

• mysqldump 完整教學
• MySQL Workbench Backup 與 Restore
• Logical Backup 與 Physical Backup
• Binary Log 是什麼？
• mysqlbinlog 教學
• Point-in-Time Recovery 實作
• Full Backup 與 Incremental Backup
• RPO 與 RTO
• MySQL Disaster Recovery
• Backup Encryption
• 如何測試 Backup 是否真的可以 Restore