擁有 RAID、叢集或鏡像 ≠ 擁有可靠備份。許多 DBA 發現備份失效時，往往已造成無法挽回的資料遺失。本文梳理備份流程中十大常見盲點，並給出分層防禦建議，助你建立「睡得著覺」的備份體系。
硬體冗余只能防禦實體磁碟故障，無法防範 人為誤刪、邏輯錯誤、惡意破壞 或 軟體 Bug 導致資料損毀。必須有獨立備份副本支援時間點復原 (Point-in-Time Recovery)。
完整備份耗時久、佔空間大，頻率低。策略：完整備份 + 交易記錄備份 (如每日完整 + 每 15 分鐘記錄備份)，支援任意時間點復原。差異備份因累積變更量大，適合低頻變更資料庫。
伺服器火災、雷擊、控制器損壞會導致備份同步消失。必須異地備份：網路傳輸至異地伺服器、雲端儲存 (Azure Blob/S3) 或磁帶離場。
手動複製極不可靠。建議：在維護計畫或 SQL Agent 作業中，緊接備份步驟加入 xp_cmdshell、PowerShell 或 SSIS 任務自動推送至異地，並記錄傳輸狀態。
備份檔存在 ≠ 可還原。定期演練：在測試環境還原完整+記錄鏈，驗證 RESTORE VERIFYONLY、DBCC CHECKDB、資料筆數核對。記錄備份斷鏈 (LSN 不連續) 會導致無法復原至最新點。
若每 10 分鐘一筆記錄備份，災難復原需逐筆套用數百個檔案。對策：編寫自動化還原腳本 (PowerShell/dbatools) 批次套用；或採用 記錄配送 (Log Shipping) / AlwaysOn 可用性群組 維護暖備資料庫，故障切換秒級完成。
多資料庫伺服器易忽略清理。自動化清理策略：維護計畫加入「清除維護任務」，保留 N 天完整備份 + 對應記錄備份；監控磁碟剩餘空間 < 20% 發送警報。
BACKUP DATABASE 預設不執行 CHECKSUM，損壞頁會被安靜備份。啟用：BACKUP DATABASE ... WITH CHECKSUM；並排程 DBCC CHECKDB (建議每週離峰時段)，在檢查通過前 禁止刪除舊備份。
若 DBCC 發現損壞，舊備份可能是最後乾淨副本。流程：DBCC CHECKDB 成功 → 刪除過期備份 → 記錄清理日誌。若 DBCC 失敗 → 保留所有備份 → 立即通報 → 人工介入。
維護計畫只能本機操作。完整體系 = 維護計畫 (本機備份+DBCC) + 自動化傳輸腳本 + 異地驗證還原演練 + 監控告警儀表板。
