SQL Server 資料庫備份策略：避開 7 大常見陷阱，打造可靠的災難恢復防線

引言：備份不等於可恢復

許多 DBA 以為「排程跑完、檔案存在」就高枕無憂。實際上，唯有經過還原演練的備份，才算真正的備份。以下整理 7 大盲點與對策。

陷阱 1：誤信 RAID 可替代備份

迷思：RAID 1/5/10 可容忍磁碟故障，資料不會丟。
真相：RAID 無法防範邏輯錯誤（如 `DELETE` 無 `WHERE`、`TRUNCATE TABLE`、惡意竄改、勒索軟體加密）。
對策：備份是針對「邏輯錯誤」的最後防線，RAID 僅是「硬體故障」的第一道防線，兩者互補不互斥。

陷阱 2：僅做完整備份，無法達到 RPO

迷思：每天一備，簡單好管理。
真相：完整備份耗時久、檔案大，無法頻繁執行 → RPO（復原點目標）動輒 24 小時。
對策：採用 完整備份 + 交易記錄備份（如每日完整 + 每 15-60 分鐘記錄備份）。差異備份適用於「資料變動量小」的資料庫，否則體積逼近完整備份，失去優勢。

陷阱 3：備份只存本機，單一故障點

迷思：備份在 D 槽，資料庫在 C 槽，已分開。
真相：主機板燒毀、機房火災、勒索軟體橫向移動加密全磁碟 → 備份同步消失。
對策：3-2-1 原則：3 份拷貝、2 種媒體（磁碟+帶庫/雲端）、1 份異地。至少將備份檔即時傳送至另一台實體主機或雲端儲存（Azure Blob / AWS S3）。

陷阱 4：備份傳送腳本手工維護，易遺漏

對策：將「備份 → 壓縮 → 加密 → 傳送 → 驗證」封裝為 SQL Server Agent 作業 或 PowerShell / Azure Data Factory 排程，失敗自動告警（Email/Teams/Slack）。

陷阱 5：從未驗證備份鏈完整性

風險：記錄備份中斷（磁碟滿、網路斷、Agent 停止）導致 LSN 斷鏈，還原時卡在中間無法繼續。
對策：

• 定期執行 RESTORE VERIFYONLY 搭配 CHECKSUM。
• 建立「還原演練」自動化流程：每週還原至測試環境，跑一遍 DBCC CHECKDB。
• 監控 msdb.dbo.backupset 確認 LSN 連續、無遺漏。

陷阱 6：大量記錄備份導致還原耗時過長（RTO 超標）

情境：每 10 分鐘一記錄備份，災難發生時需還原 100+ 個 `.trn` 檔。
對策：

• 使用 還原腳本產生器（PowerShell/dbatools）自動串接 `RESTORE LOG ... WITH NORECOVERY`。
• 考慮 差異備份 縮短記錄鏈長度（每 6 小時一差異）。
• 企業版可啟用 備份壓縮、加密、條帶化 加速 I/O。

陷阱 7：舊備份檔堆積佔滿磁碟，導致新備份失敗

對策：在維護計畫中加入清理任務（依保留天數/備份集數刪除），並設定磁碟剩餘空間告警（< 15% 發送通知）。

總結：最小可行性備份架構

記住：未經測試的備份，只是佔用磁碟空間的廢檔。