公司最新備份還原得到嗎？香港批發商的實用驗收表

先由出貨安排訂出底線

批發公司每天接單、執貨、安排送貨，備份是否有用，要看系統還原後同事能否繼續處理這些工作。昨晚顯示「備份成功」，並不能證明訂單及送貨附件都找得回。可請維護夥伴把最新可用備份還原至隔離測試副本，再由熟悉訂單的同事核對。這次驗收要作出的決定很具體：現有安排能否繼續採用，還是要先撥款修正，再做一次示範。

先問負責人兩件事：停工多久便會影響當天出貨？最近多久的新增或修改資料若遺失，公司仍有辦法補回？前者是復原時間目標（RTO），後者是復原點目標（RPO）。例如，公司可能暫定最多停工四小時、最多遺失一小時內的變動；這只是說明訂法的假設，並非通用標準或客戶成果。若訂單沒有其他可核對紀錄，即使只少了半小時資料，也可能不能接受。

AWS 的定期復原測試指引要求核實資料是否完整、正確及可存取，並按業務的復原時間及資料流失目標評估。只把環境還原、卻沒有實際讀取資料，是指引列出的常見問題。以下驗收表是按批發業務需要設計的編輯示例，不代表某項雲端服務已包含這些能力。

把演練範圍寫進維護工作

維護預算有限，可先選訂單系統、相關資料庫及出貨所需的附件儲存空間。報價應列明準備、測試環境、業務核對、證據整理及清理工作。只取回一份檔案，適合驗證文件能否救回，卻不能證明訂單系統可運作；連所有辦公系統一起演練，涵蓋較廣，但準備工夫也較多。採用較小範圍時，必須寫下未測項目，不能把一次訂單測試當成全公司已具備復原能力。

開始前，夥伴要列出所選備份、涵蓋的資料時間點、應用程式版本及所需配套。隔離副本應限制登入，並停用客戶電郵、正式付款、速遞預約及與正式系統同步的連線，避免測試單真的發出去。若還原真實業務備份，須事先安排獲授權的存取及必要的證據保留。虛構資料可用來說明驗收方法，但若只示範一份特製的測試備份，仍未證明公司最新備份可用。無法確認隔離便應暫停。

逐項填寫還原驗收表

核對基準須與備份的資料時間點一致。正式系統之後仍會接單，拿現在的總數與昨晚備份比較，差異未必是還原失敗。先限定日期範圍和訂單狀態，再核對筆數、數量及金額；兩份內容不同的資料，也可以有相同筆數。抽查應包括普通訂單、修改過的訂單、取消單及有多份附件的訂單。請同事以日常工作權限在應用程式內開啟，不能只由管理員在資料庫內看到紀錄便算合格。

識別碼及時間存於內部紀錄；表內不要放密碼或不必要的客戶資料。

量度停工時間時，應包括取回存取權、準備環境、等候支援、還原及業務核對。若演練前已準備好部分項目，要列明哪些時間未計算，另行評估所需等候。判斷資料流失則要核實最近已提交的交易及前後紀錄，不能單憑最大的訂單編號推斷中間沒有缺漏。相反，若該段時間根本沒有新交易，最後一張訂單較舊，也不等於真的遺失了資料。

還原夠快，仍可能不合格

假設測試資料在指定時間點有 120 張訂單，抽查其中三張，應共有六份附件。還原後 120 張訂單都在，但一份附件打不開，附件項目便不通過，不能因畫面正常載入而略過。再假設模擬事故發生於香港時間 10:00，最後核實可還原的交易是 08:30，而已知其後確有提交交易卻未能找回，示例的資料流失時段便是 90 分鐘，超出先前假設的一小時上限。即使三小時便完成復原、符合四小時停工上限，也不能抵銷其餘失敗。這些數字全屬虛構測試示例。

先按不合格項目找修正方向。附件遺漏，要查是否根本未納入備份，再重測；資料流失時段太長，可能要調整備份安排或復原方式，由夥伴在實際系統證明可行；耗時過長，也可能是帳戶由誰掌握或支援未能及時到位。先取得針對問題的工作範圍及估價。若暫時接受限制，應寫清楚風險及替代處理方法，不能把負責人願意承擔風險，記成測試已通過。

把下一次驗收也安排好

演練頻率應配合出錯後果及維護預算，例如可先討論每季一次，而非把季度當成所有公司的硬性要求。備份設定、附件存放位置或應用程式版本有重大改動後，也應重測。保存驗收表、必要紀錄、限制及修正狀態，讓下次有一致基準可比。完成檢視後，按事先約定的資料處理安排刪除隔離副本。抽樣通過所支持的是當次範圍與條件，並非往後每次復原的保證。

下次與維護夥伴開會前，先指定一位業務驗收同事，由負責人寫下可承受的停工及資料流失上限，再把這份驗收範圍交給對方，要求提供示範日期及分項估價，包括測試環境與清理費用。若連復原帳戶由誰掌握也不清楚，可先用下方保安指南整理責任；需要向夥伴書面交代工作時，需求書工具可協助列出這次小型演練的範圍、排除項目及驗收條件。