資料庫備份九大實戰場景與應對策略：從 RAID 誤區到異地備份自動化

場景一：有 RAID 還需要備份嗎？

需要。 RAID 僅防禦**磁碟物理故障**，無法應對：

• 人為誤刪/誤更新（邏輯錯誤）
• 病毒/勒索軟體加密
• 資料庫內部邏輯損壞
• 多磁碟同時故障超出 RAID 容錯等級

**結論：** RAID ≠ 備份，備份是針對邏輯錯誤的最後防線。磁碟鏡像同理。

場景二：備份策略選型——全備 + 日誌備份是王道

• 僅全備份：恢復點目標（RPO）= 上次全備時間，**資料遺失風險大**；全備耗時長，頻率受限。
• 全備 + 差異備份：微軟差異備份記錄「上次全備以來變化」，頻繁變更下差異備份迅速膨脹接近全備大小，**失去優勢**。
• 全備 + 日誌備份（每 15-60 分鐘）： RPO 可控至分鐘級，備份檔小、速度快，**適合 90%+ 生產環境**。

場景三：本地備份不夠——必須異地備份

本機磁碟損壞/伺服器整機故障 → 本地備份同歸於盡。**必須將備份檔傳送至另一物理硬體**（廉價備份伺服器/NAS/雲端儲存）。磁帶機非必選，網路傳輸更靈活。

場景四：備份傳輸自動化——納入 T-SQL/PLSQL 作業

不要依賴人工複製或獨立排程。**在備份作業步驟中直接嵌入傳輸邏輯**（PowerShell、scp、rsync、AZCopy、rclone），確保「備份完成即異地到達」，消除時間窗口風險。

場景五：備份可用性驗證——定期恢復演練

備份檔到達異地 ≠ 可用。必須定期（月/季）在測試環境**實際恢復驗證**：

• 全備 + 日誌鏈完整性（無斷檔）
• 恢復至最新時間點成功
• 關鍵表資料筆數、檢核和校驗
• 應用層功能冒煙測試

場景六：高頻日誌備份恢復自動化——腳本化還原

日誌備份每 10 分鐘一次 → 故障時需還原數百個日誌檔。**手工還原不現實**，必須編寫/使用自動化還原腳本（RMAN `RESTORE DATABASE; RECOVER DATABASE;`、SQL Server `RESTORE LOG ... WITH NORECOVERY` 迴圈）。

場景七：多資料庫環境備份保留自動化——策略引擎

數十/上百資料庫 + 磁碟空間有限 → **集中式保留策略引擎**：

• 按資料庫重要性分級（核心/重要/一般）
• 定義保留天數/代數（如核心 30 天/10 代、一般 7 天/3 代）
• 自動清理過期備份，**長假前預執行**防止滿盤
• 記錄清理日誌供稽核

場景八：備份不檢查資料頁完整性——必須 DBCC/DBV 先行

• 資料頁損壞 → 備份仍成功、不報錯 → 損壞頁進入備份鏈。
• 若稍後發現損壞，早期乾淨備份可能已被保留策略刪除 → **無乾淨備份可用**。
• 鐵律： **DBCC CHECKDB / DBVERIFY 通過前，嚴禁刪除舊備份**。
• 維護計劃順序：DBCC → 全備 → 日誌備份 → 傳輸 → 保留清理。

場景九：維護計劃僅限本機——需自建異地傳輸

SQL Server 維護計劃 / Oracle Enterprise Manager 排程**不支援跨機器傳輸**。**必須自行開發/整合異地傳輸模組**（Agent Job 步驟、Shell 腳本、Ansible Playbook、雲廠商 CLI）。

總結：備份系統成熟度模型

**目標：** 將組織推向 L3/L4，讓備份真正成為「可靠的最後防線」。