網站備份還原實務：檔案、資料庫與復原演練應怎樣安排

網站備份還原演習紀錄：檔案有了，訂單卻回不來

假設一間香港商戶每晚收到「備份成功」通知，某天網站故障後在測試環境還原，首頁可以打開，當日下午的訂單和上載相片卻找不到。這是虛構演習，不是 Black Media 客戶個案。網站備份還原要回答的不是有沒有檔案，而是按某個已知時間點能恢復哪些功能和資料，哪些仍須人工處理。

第一份演習紀錄不必寫成只有工程師看得明的長篇命令。商戶先列三個問題：網站中斷後哪種操作必須最先回復？可以接受遺失多少時間內的新資料？有多少時間和人手可用於核對？技術人員再把答案對應到檔案、資料庫、設定、外部接駁和備份安排。這樣才知道「成功」應怎樣驗收。

這篇處理備份內容、一致性、保管與還原測試；一般帳戶和程式檢查可見網站保安檢查指南。若只想比較寄存方案有沒有提供備份欄位，可先參考網頁寄存規格比較，再沿本文把「有備份」拆成真能操作的復原方案。

演習前先定要恢復的業務功能

把復原目標寫成可檢查的動作

討論恢復時間時，不妨先問誰要在系統恢復後做第一件事。編輯人員能否登入並讀取舊文章？顧客能否看到商品、把商品放入購物車並完成一張測試訂單？客服能否在後台找到該單並辨別付款狀態？每一個動作都要有負責確認的人、測試資料，以及可接受的最晚資料時間點。若前台恢復了，後台仍無法找回交易紀錄，網站對商戶而言並未恢復。業務部門與技術人員宜一起決定先救哪部分，否則很容易只看見首頁開得動，就宣佈事故結束。

復原目標也會隨工作時段改變。假設某個網店在上線活動期間持續有新訂單，若只用活動前的資料庫，後續訂單可能需要另外核對；同一備份在閒置時間可能足夠，在繁忙時卻差很遠。商戶毋須在政策中填一個漂亮的分鐘數，應先說明可接受多少資料缺口，以及誰有權決定停機、停止收單或轉用人工登記。

由一宗工作倒推必要資料

假設公司網站只接受表格查詢，復原時要核對舊表格內容、最新提交的時間、通知收件地址，以及新提交能否入庫。若是網店，還要查訂單、付款確認、商品及存貨狀態，不能只檢查產品頁。不同網站的關鍵流程不同，應由日常使用的人說明，再交維護者寫成演習情境。

每個情境寫明預期結果，例如「指定的測試訂單與商品照片可從還原環境查到，未被測試的付款服務不會誤發通知」。不宜只寫「網站正常」，因為瀏覽器看見畫面，未必代表登入、資料庫查詢和寄件排程已恢復。確認者應實際做一次工作，並留下可核對的結果摘要。

分清可接受的資料損失與停頓

常用的兩個問題是：最遠要回到多久以前的資料，以及業務可容許多久無法操作。這相當於復原時間點與復原時間目標，但毋須先背縮寫才可討論。若網店每天都有新訂單，只留每週一次備份，商戶就要知道可能無法找回其間資料。若復原需要重新安裝程式、找回憑證及核對訂單，花的時間亦不能只算載入資料庫。

這些是由公司決定可承受程度的目標，不是供應商看見一行字便自動保證的結果。要問現有服務能否提供相應版本、能否取回，以及演習完成花了多久。演習結果若達不到公司需要，應調整安排或目標，不能把它留在文件上，卻沒有任何措施支持。

清點備份：檔案、資料庫與設定各有角色

備份內容不只程式碼

自建 CMS 可能包含網站程式、上載相片、下載文件、資料庫與環境設定。若只保存 Git 倉庫中的程式碼，產品資料及客人查詢未必在內；只匯出資料庫，又可能沒有圖片或必要設定。請維護者列出網站實際依賴項目、資料位置與產生備份的方法，由業務人員核對是否遺漏正被使用的內容。

如果網站會寄電郵，需區分通知內容是否存於網站資料庫，還是只在外部郵箱。網站備份一般不能被假定包含全部郵件歷史。支付、物流與帳戶服務的資料亦可能分別由外部提供者管理；演習表應列出哪些可以由網站自身重建、哪些要向服務方核對，避免一個「全站備份」的說法掩蓋依賴。

記錄設定而不公開憑證

網站要重新運行，可能還需要 PHP 相容環境、資料庫連接方式、排程、網域設定及第三方接駁參數。備份規劃要列出需要哪些設定及由誰保管，卻不應在多人可讀文件直接貼上密碼或支付金鑰。演習時由獲授權者從適當保管位置提供必要資料，並於事後檢查是否留下不應公開的副本。

若系統使用特殊元件或特定程式版本，記錄安裝來源與相容條件。還原目標環境與原本不同時，資料能匯入未必等於網站可正常運作。維護文件應讓另一位合資格人員知道需要甚麼，而非只能依賴某位開發者的記憶。版本更新後，亦應更新復原所需步驟。

資料庫備份：要核對一致時間點

正在寫入的網站不能只靠複製檔案

網店可能一邊接單一邊更新存貨，直接在不合適的狀態下複製資料檔案，可能得不到可用的還原版本。MySQL 官方文件提供不同備份與復原方法；實際選擇要考慮資料庫引擎、版本及寫入情況，由維護人員訂定正確操作。商戶要問的是「哪個時間點的訂單與商品資料可以一起還原」。

若使用邏輯匯出或資料庫快照，亦要知道操作期間能否繼續寫入，以及匯出檔是否包含所需的結構與資料。不同表格可能存在關聯，不能只看某個匯出檔大小或檔名就確認一致。演習可用已批准的虛構測試訂單，核對訂單內容與相關商品在還原後能互相對上。

比對資料時間與操作記錄

商戶應記錄備份起始與完成時間、最後可查到的測試資料，以及正式系統當時仍可能有甚麼新工作。如果某段期間的訂單只能從支付服務紀錄與客戶電郵人工補回，這是需要另作程序的缺口，不應在復原報告中寫成全部恢復。核對者要知道哪些資料由哪個來源確認。

資料庫系統的版本相容與字元集亦需由技術人員測試，尤其舊系統包含繁體中文內容及自訂欄位時。匯入後首頁能打開，不代表每個中文字、搜尋結果與訂單明細都正確。可抽查含中文、英文與特殊符號的非敏感樣本，確認資料沒有截斷或錯碼，再安排業務核對重要欄位。

保存位置：能取到備份，也要保護備份

同一個失效原因會否同時拿走正式站與副本

討論異地備份時，真正要問的是：如果原本的帳戶被鎖、儲存裝置故障，或者維護操作誤刪資料，副本是否仍能取得。把檔案複製到同一部主機的另一個資料夾，有助應付個別檔案誤改，卻未必能應付整部主機無法使用。獨立權限、不同儲存位置、取回程序及憑證保管方式，需要連同實際災難情境一起審視；也要決定誰可以刪除過期備份，避免一般網站帳戶同時控制所有副本。

備份本身可能包含顧客聯絡資料和訂單詳情，測試人員不宜隨意把完整副本帶到個人電腦。演習應指定可用的隔離環境，列明誰有權下載、解密、清除測試資料，及如何確認測試環境不會發出真實通知。若無法在不暴露真實資料的情況下驗證，可選用受控的最小資料樣本，但要明白樣本未必涵蓋大資料表的實際復原時間。

避免所有副本依賴同一個故障範圍

如果網站與唯一備份存放於同一部伺服器，主機損壞、帳戶遭入侵或誤刪時，兩者可能一起受影響。應向服務提供者查核副本實際保存位置、存取方式及保留安排，再按業務需要考慮其他獨立儲存位置。Black Media 自述擁有自己的數據中心，但具體客戶備份安排仍要以實際服務內容確認，不能從公司規模推論每個網站都有異地副本。

「異地」也需要說明相對甚麼風險，例如與原主機不同設備、不同權限或不同設施。多個備份檔若都由同一組被盜的管理憑證控制，獨立性可能不足。討論時可同時問管理權限、刪除保護及從何處取得副本，不只問備份數目。

備份內可能有客戶資料

訂單、聯絡表格與帳戶資訊都可能進入備份，存取及分享需要有限制。應指定誰可取得、誰批准恢復、檔案經甚麼方式傳遞，以及過期副本如何處理。請避免把整份資料庫寄到一般多人群組作測試；需要演習時，可在受控環境以必要的測試資料驗證，真實資料的處理另按公司適用要求安排。

備份檔是否經加密及金鑰由誰保管，也要隨保護要求討論。若加密金鑰只有一名離職員工知道，副本即使仍在，也可能取不到。相反，把金鑰放在同一個人人可讀的位置，亦無助保護資料。保管方案要能讓授權人員在緊急時取得，但不讓日常不相關帳戶任意下載。

版本與保留期：不是愈多愈安全

不同事故需要不同時間點

如果某項錯誤設定在數日前才被發現，而每天的備份都已包含錯誤，只留最近一份可能無法找到可用版本。版本安排要依資料更新頻率、能接受的資料缺口與成本決定，不宜直接套用他人天數。可在演習紀錄中加入「何時首次發現異常」與「哪個版本沒有受影響」，看看既有保留方案能否提供選擇。

同時，長期保留大量舊備份也會增加資料保管責任。若業務只需較短的還原窗口，便應按公司需要制訂保存與清理規則；若需要較長期間，亦要確認儲存空間、權限與資料安全。無人覆核的自動保留政策，可能在最需要的時候找不到版本，或累積不必要的敏感資料。

備份通知不是品質驗證

收到排程成功通知，至少要核對備份是否真的完成、檔案大小是否合理、能否讀取與還原。若磁碟滿了、憑證失效或外部儲存被停用，排程可能產生錯誤或不完整副本。設計檢查流程時，區分自動監察與定期人工演習，不能把看過一次綠色圖示當成長期保證。

建立簡短例行紀錄：最近成功備份時間、版本可用數目、上次還原演習結果，以及仍待處理的問題。這份紀錄不必公開技術憑證，但要讓公司知道是否已有負責人跟進失敗。若通知寄往無人閱讀的舊郵箱，應先更改接收與升級安排，再談備份工具是否先進。

正式演習：在隔離環境重建一個可用網站

把資料復原與對外切換拆開測試

還原到隔離環境時，先記下原站使用的程式版本、資料庫版本、檔案權限與必要設定，再逐項確認復原環境是否相容。測試用域名或內部入口須限制存取，並關閉會對外發信、收款或觸發物流通知的功能。確認資料可讀與功能可用之後，另開一次桌面演練：假如要讓顧客重新連到網站，哪位同事更新設定、哪位同事檢查安全連線、哪位同事確認舊連結仍可到達？不應在未經授權的測試中真的改動正式域名的指向。

每步最好留下「執行人、開始時間、結束時間、結果、阻塞原因」；如果重建需要一封藏在前員工郵箱的密碼重設電郵，便算找到具體缺口。若資料庫匯入完成但應用程式報錯，先找版本、連線、編碼與權限的差異，再判定是副本損壞或環境不一致。演習重點在於讓下一位同事可按紀錄重做，而不是某個熟悉系統的人臨時救起一次。

約定範圍、資源與中止條件

演習前選定要還原的版本、測試環境、授權參與者及預計核對的業務功能。若測試會接觸真實資料，先安排合適權限和保護；可用虛構資料的部分則優先使用虛構資料。演習不應隨意將舊備份覆蓋正式網站，除非是已批准的實際事故處理，並有清楚的回退安排。

有些接駁不適合在測試環境真的寄信或向支付服務發出正式請求，技術人員應先關閉或替換相關出口。商戶核對的是資料與功能能否安全重現，不需讓虛構測試單觸發真實出貨或收款。對依賴正式環境才能驗證的部分，要清楚寫明限制與之後的核對方法。

按次序記錄實際操作與耗時

演習記錄可從取得備份開始，沿建立環境、匯入資料、接回設定、測試訪客功能到業務簽收逐步記錄。哪些步驟需供應商權限、哪些要等資料人員確認，也要寫下時間。這能顯示真正瓶頸：也許檔案很快取得，卻花了大部分時間尋找舊憑證或釐清哪一個版本才對。

不要把某一次在測試環境成功的耗時直接當成任何事故時都能達到的承諾。正式事件可能涉及網絡、帳戶、資料完整性及外部服務問題，條件不同。演習數字是用來改進程序，報告應保留前提；商戶可以據此決定要補人手、文件或不同的儲存安排。

讓實際使用者驗收，不只工程師

技術人員可檢查網站回應、資料庫與日誌；客服核對查詢，內容同事核對檔案，財務核對訂單。每位驗收者用一個已定的虛構情境操作，確認結果。若原定功能只可由管理員帳戶完成，普通同事卻無法操作，應記錄權限缺口，不宜把技術測試通過當成業務可用。

演習失敗後，先修過程中暴露的缺口

找不到檔案、解不到密和內容不一致是三種問題

找不到副本，要追備份產生、保存和通知；拿到加密檔卻不能解密，要查授權與金鑰交接；資料可匯入卻訂單與商品對不上，則需查一致性與備份時間點。將失敗類型分清，才能交給正確人員，亦能避免所有異常都以「多買儲存空間」作回答。

若因版本或元件不相容而失敗，先記錄當前程式與資料庫環境，不要未經測試直接修改正式站。可由維護者評估更新文件、備份格式或還原環境，重新安排演習。每次修正後再跑原本失敗的關鍵步驟，才知道問題是否真正解決。

保留風險與限制的正確描述

若現階段只能恢復文章與圖片，未能證明最新訂單完整，應向商戶明確說明；不能因首頁打得開便宣稱網站全面恢復。可以暫時安排訂單人工核對或限制部分功能，但須指定負責人及結束條件。演習報告讓管理層有依據安排資源，也讓技術方知道下一輪要改善甚麼。

• 把異常列為可重現的現象，而非只寫「失敗」。
• 指定負責人、修正方法與覆核日期。
• 保留原本備份，不因整理報告而抹去需要查的證據。

事故真的來到：還原前先保護新產生的資料

事故期間的新資料，要另列核對清單

假設網站在資料庫故障前仍接到數張訂單，而最後一次可用備份早於這些交易；直接還原可能讓網頁看似正常，後台卻失去客人已收到的訂單確認。先暫停會再寫入資料的入口，保存現有系統能取出的紀錄與付款端可核對的交易資訊，並由授權人決定逐筆補回、聯絡客人或採取其他安排。不能把付款電郵當成完整訂單備份，也不能猜測被刪的客戶資料。

恢復之後，要從顧客視角檢查真正的終點：嘗試登入測試帳戶、查看商品資訊、提交不會造成實際付款的測試流程，並核對後台狀態與外寄通知。若涉及敏感資料或安全事件，復原與調查的次序需由負責人按情況定；先保留必要證據，再恢復服務，避免修復過程掩蓋問題根源。最後記下哪些資料無法完全補回，讓客服能有一致的答覆。

舊版本回來，現有訂單可能消失

當正式網站仍部分可用，直接還原舊資料庫可能覆蓋事故前後已收到的查詢與訂單。應由技術負責人與業務代表確認停止寫入時點、需要保存的新增資料及適當切換方式，再執行已批准方案。若部分付款服務仍在收款，須與財務核對不能在資料庫還原後遺漏已完成的交易。

這不是要求老闆自己合併兩份資料。老闆要確認哪類工作影響最大、誰可授權暫停交易，以及如何通知相關同事。技術人員則處理資料一致性與實作。真正事故可能有入侵風險，必要時還要先保存證據和隔離問題，不能只用一份較早備份覆蓋可疑痕跡便當作完結。

先恢復哪些入口，由業務優先次序決定

如果客服急需查看舊訂單，可考慮在安全受控的環境恢復只供查閱的資料；如果正式網站必須先重新接受查詢，則需確認新的資料如何保存。兩種需要可能要分階段安排，不能假設全部功能同一刻恢復。預先做過的演習與責任表，可讓商戶在壓力下仍知道應先聯絡誰。

需要新寄存或伺服器環境時，應核對相容設定及備份取回方式；需要修正網站程式或資料流程時，則由熟悉應用的人負責驗證。網上商店尤須把付款、存貨與訂單狀態交給相關同事分別簽收。基礎設備恢復只是其中一步，是否可重新營業由完整流程測試決定。

把演習變成持續工作，而不是一次展示

網站功能、內容與人員都會變。新接了支付服務、增加檔案上傳或更換資料庫版本後，原本的備份方案可能缺少新項目。可在每次重要變更後核對備份範圍，定期安排有代表性的還原演習，並更新聯絡人。具體頻率按網站變動與可承受的資料損失訂定，不假設所有公司需同一週期。

完成一次演習後，整理一頁讓老闆看得明的結論：可恢復到哪個版本、需要多久、有哪些未驗證資料，以及下次要先補甚麼。技術細節留在受控文件，管理決定則寫在摘要中。若公司正在考慮升級主機或重新製作系統，這份紀錄也可指出真正要改善的資料流，而不是只以備份功能名稱作採購理由。

1. 選一項網站最重要的業務操作，寫明可接受的資料缺口。
2. 核對檔案、資料庫、設定及外部服務分別由誰備份。
3. 在受控環境演練，記錄失敗、實際耗時與業務簽收結果。
4. 針對未通過事項修正，再用同一情境覆核。

若想由現有備份開始安排演習，可帶上資料類型、現有寄存安排及最怕遺失的工作，與 Black Media 討論網站備份還原的範圍。先約定甚麼才算真正復原，再安排能重複執行的測試，才知道副本是否對得上公司的日常運作。