這個系列第4篇聊過「有備份不等於救得回來」，今天把這個主題收尾：怎麼確定救得回來？答案只有一個——實際演練過。

備份圈有句老話：「備份沒有失敗過的，都是還原的時候才失敗。」聽起來像玩笑，但每個做過災難復原的人都笑不出來。

為什麼備份看起來成功，還原卻失敗

備份軟體回報「Job Completed Successfully」，只代表「資料有被複製出去」，不代表那份資料還原回來能用。實務上翻車的原因五花八門：

• 備份到的資料本身就有問題：資料庫沒有做一致性備份，還原回來檔案在，但資料庫起不來。
• 漏備了關鍵東西：AP 伺服器備了，但設定檔放在另一台沒人記得的機器上；或是憑證、金鑰沒備到，系統還原了卻無法提供服務。
• 還原順序沒人知道：AD 要先起來、DNS 要通、資料庫要在 AP 之前……真的出事那天，這些相依關係如果只存在某位資深同仁的腦袋裡，而他剛好在休假，就精彩了。
• 還原時間遠超想像：老闆以為半天能恢復，實際上光把 50TB 從備份設備倒回來就要兩天——這就是之前講的 RTO 沒有被驗證過。
• 備份資料早就悄悄壞了：媒體損壞、備份鏈斷裂，平常沒人發現，要用的時候才知道。

以上每一項，都只有「真的還原一次」才會被發現。

還原演練可以分幾個層級

不是每次演練都要全公司大陣仗，可以由小到大分層做：

Level 1：檔案級抽驗（每月）
隨機挑幾個備份，還原幾個檔案出來開開看。成本最低，至少確認備份資料讀得出來。

Level 2：單機還原（每季)
挑一台伺服器或 VM，完整還原到隔離的測試網段，開機、登入、確認服務起得來。很多備份軟體有自動化驗證功能（例如開機後自動檢查服務狀態），可以把這件事變成例行程序。

Level 3：應用系統級演練（每半年）
把一整套系統（AP + DB + 相關服務）在測試環境還原起來，實際操作業務功能，順便計時——這個時間就是你「實測的 RTO」，拿去跟當初承諾管理層的數字對照，通常會很有戲劇效果。

Level 4：全災難演練（每年）
模擬機房全毀或勒索軟體全面爆發的情境，依照災難復原計畫（DRP）文件、由文件上寫的順序把核心系統救回來。重點是「照文件做」，不能靠某個人的記憶——因為演練的目的之一，就是驗證文件本身寫得對不對。

演練完最重要的一件事：留下紀錄

每次演練要記錄：還原了什麼、花多少時間、遇到什麼問題、文件哪裡要改。演練發現問題不是壞事，演練的目的就是在平常把問題找出來，而不是在災難那天才認識它們。

另外，金融、醫療等受監理的產業，主管機關本來就會要求定期災難復原演練並留存紀錄，這些報告在稽核時都是必交項目——所以與其被動應付稽核，不如把它做成真的有用的例行工作。

系列小結

到這篇為止，這個 Backup 系列把基礎觀念走完一輪了：

從「什麼是備份」、備份/複本/災難復原的差異、有備份不等於救得回來、RPO/RTO、3-2-1 原則、備份視窗與增量備份，到快照、Dedupe、Air Gap，最後用還原演練收尾。

串起來其實就是一句話：備份不是一個產品，是一套要被驗證的流程。 買了設備、排了排程只是起點，定期確認「救得回來、救得夠快」才是這件事的本體。

之後有機會再開進階篇，聊聊備份加密、雲端備份、以及 Cyber Recovery 隔離區的實際運作。我們下次見。