資料庫與附件還原演練：網站備份驗證完整清單

文章目錄

• 1. 盤點要還原的資料與相依項
• 資料庫之外還有哪些相依項目
• 用備份範圍表釐清涵蓋與未涵蓋項目
• 2. 檢查備份可讀與時間一致
• 先確認備份檔案能否正常解壓與讀取
• 比對資料庫備份與附件備份的時間戳
• 3. 在隔離環境執行還原
• 建立與正式站隔離的測試環境
• 依序還原資料庫、附件與設定檔
• 4. 驗證資料與附件完整性
• 資料庫層級的完整性檢查
• 附件檔案的抽樣與全量比對
• 5. 記錄實測時間和未涵蓋範圍
• 用還原驗收紀錄表留下實測數據
• 誠實標註本次演練沒有涵蓋的範圍

資料庫還原演練是確認網站備份真正可用的實際測試，做法是在隔離環境中把備份檔案完整還原出來，比對資料與附件是否與還原前一致，而不是單純確認備份檔案存在。多數企業網站有排程備份機制，但真正做過還原測試的比例並不高——備份跟還原是兩件事，備份只是把資料複製出來，還原才是驗證這份複製品能不能在意外發生時真的救命。

台中一家經營多年的機械零件商曾經跟我們聊到，他們的網站主機商每天都寄備份完成通知信，老闆一直以為那就是「安全網」，直到有一次測試環境真的需要還原資料庫，才發現附件檔案根本沒有包含在備份範圍裡，產品型錄的 PDF 全部消失。這類狀況不是個案，而是備份策略裡常見的結構性漏洞。

本文重點摘要

• 資料庫還原演練是唯一能驗證備份真正可用的方法，單純確認檔案存在並不足夠
• 還原測試必須涵蓋資料庫、附件、相依設定三個層面，缺一不可
• 隔離環境執行還原能避免二次傷害正式站，是還原演練的基本原則
• 還原後的資料比對與附件完整性檢查，決定這份備份是否真的堪用
• 記錄實測還原時間與未涵蓋範圍，才能建立可信的災難復原依據

盤點要還原的資料與相依項

還原演練第一步不是打開備份檔案，而是先列出網站到底有哪些資料需要還原，以及這些資料彼此之間有什麼相依關係。多數人只想到資料庫，忽略了附件檔案、網站設定檔、第三方外掛資料，甚至是金流與物流串接的 API 金鑰設定。這些項目如果沒有一併納入還原範圍，就算資料庫救回來了，網站可能還是無法正常運作。

資料庫之外還有哪些相依項目

一個典型的 WordPress 或客製化電商網站，資料庫通常只佔還原範圍的一部分。常見的相依項目包括：使用者上傳的圖片與檔案（通常存在獨立的檔案系統或物件儲存服務）、網站設定檔（例如資料庫連線資訊、API 金鑰）、SSL 憑證與網域設定、第三方服務的 webhook 設定。這些項目分散在不同位置，備份機制如果只設定資料庫自動備份，其餘項目很容易被遺漏。

用備份範圍表釐清涵蓋與未涵蓋項目

建議在演練前先建立一張備份範圍表，逐項列出資料類型、儲存位置、備份頻率、負責單位。這張表不需要複雜的工具，一份試算表就能完成，重點是誠實標註「目前沒有備份」的項目，而不是假設全部都有涵蓋。

檢查備份可讀與時間一致

備份檔案存在，不代表它能被正常開啟或還原。這是許多企業最容易誤判的環節：主機商的備份通知信只顯示「備份完成」，但沒有人真的打開過那個壓縮檔，確認裡面的資料是否完整、是否損毀。

先確認備份檔案能否正常解壓與讀取

檢查的第一步很單純，就是把備份檔案下載下來，嘗試解壓縮，確認檔案沒有損毀。資料庫備份常見格式是 SQL dump 檔，可以用文字編輯器開啟前幾行，確認內容是否為完整的 SQL 語法而非亂碼或空白檔案。附件備份通常是壓縮檔，解壓縮後要確認檔案數量與原始檔案系統大致相符。

比對資料庫備份與附件備份的時間戳

這是最容易被忽略、卻影響還原結果最大的一個檢查點。如果資料庫備份是週一凌晨產生，附件備份是週三凌晨產生，兩者還原回去之後，資料庫裡記錄的訂單可能對應不到附件裡的出貨單檔案，或者商品圖片編號跟資料庫裡的商品資料對不上。時間戳不一致的備份組合還原出來的網站，表面上能跑，但資料邏輯是錯亂的。

還原演練前，務必確認資料庫備份與附件備份的時間戳落在同一個備份週期內，兩者時間差距過大，還原出來的資料很可能互相對不上。

備份能開啟只是及格，時間戳一致才是備份真正可用的門檻。

在隔離環境執行還原

還原測試絕對不能直接在正式站上操作。這句話聽起來像常識，但實務上確實有企業因為「想省一道工序」而直接在正式站嘗試還原，結果造成服務中斷，甚至資料被覆蓋得更混亂。

建立與正式站隔離的測試環境

隔離環境可以是另一台虛擬主機、本機的本地開發環境，或是雲端服務商提供的測試子網域。重點是這個環境跟正式站完全獨立，不會因為還原操作而影響到真正在運作的網站與使用者。對於使用共用主機的中小企業，許多主機商方案本身就提供「測試環境」或「Staging 環境」功能，可以善用這個機制進行演練，而不需要額外租用主機資源。

依序還原資料庫、附件與設定檔

還原順序建議是：先還原資料庫，再還原附件檔案，最後套用設定檔。這個順序能確保每一步出錯時，比較容易定位問題來源。資料庫還原通常透過 phpMyAdmin、Adminer 等工具匯入 SQL 檔，或是用指令列工具直接匯入；附件還原則是把壓縮檔解開後放回對應的檔案目錄；設定檔還原要特別注意資料庫連線資訊、網域名稱等參數，在測試環境中需要對應調整，不能直接套用正式站的設定去連線正式資料庫。

假設一家經營教育訓練課程的公司，每年固定在週年慶前進行一次還原演練，流程是先在內部測試伺服器建立一個跟正式站架構相同的環境，再把最近一次的完整備份還原進去，確認課程報名資料、上傳的講義附件都能正常對應。這種定期演練不保證零風險，但至少能提前發現備份流程中的缺口，而不是等到真正出事才第一次嘗試還原。

驗證資料與附件完整性

還原完成只是流程的一半，接下來要做的是逐項比對，確認還原出來的資料跟原始資料一致，而不是看網站能打開就當作成功。

資料庫層級的完整性檢查

常見的檢查項目包括：資料表數量是否與原始資料庫一致、關鍵資料表的記錄筆數是否吻合（例如訂單表、會員表、商品表）、資料編碼是否正確（中文字是否出現亂碼）、資料表之間的關聯是否正常（例如訂單對應到的商品 ID 是否存在）。這些檢查可以用簡單的 SQL 查詢語句完成，例如比對筆數的 COUNT(*) 查詢，不需要複雜的工具。

附件檔案的抽樣與全量比對

附件檔案的驗證方式分兩種：抽樣檢查與全量比對。抽樣檢查是隨機挑選幾筆資料庫裡記錄的附件路徑，確認對應的檔案是否存在且能正常開啟；全量比對則是比較還原前後的檔案總數與檔案總大小，確認沒有遺漏。對附件數量龐大的網站（例如累積多年的商品圖片），全量比對比較耗時，但抽樣檢查不足以發現系統性的遺漏問題，建議兩者搭配使用。

還原後務必核對資料表筆數與附件檔案總數，只檢查首頁能不能打開，無法反映資料是否真的完整還原。

網站打得開不代表資料完整，筆數比對才是驗證還原成功的硬指標。

記錄實測時間和未涵蓋範圍

還原演練做完之後，最容易被省略但其實最重要的一步，是把這次演練的結果寫成紀錄。沒有紀錄的演練，下一次還是得從頭摸索，也無法對外（例如對客戶或主管）說明真實的復原能力。

用還原驗收紀錄表留下實測數據

驗收紀錄應該包含：演練日期、備份檔案的產生時間、還原開始與結束時間（藉此算出實際花費的還原時間，也就是技術上常說的 RTO，Recovery Time Objective，復原時間目標）、資料完整性比對結果、發現的問題與處理方式。這份紀錄不需要制式格式，一份 Google 表單或試算表都可以，重點是確實填寫，而且要用「實測的數字」，不能用猜測的時間去填。

誠實標註本次演練沒有涵蓋的範圍

這點常被忽略，卻是避免誤判風險的關鍵。例如這次演練只測試了資料庫和圖片附件，沒有測試金流串接設定的還原，或是沒有測試在正式站流量高峰期間還原所需的額外時間，這些「未涵蓋範圍」都應該明確寫在紀錄裡，而不是讓人誤以為「演練成功」就等於「任何情境都能安全復原」。

我們在協助企業規劃網站維運顧問服務時，通常會建議把還原演練排進年度或季度的維運行事曆，而不是當成一次性的專案。資料量會隨著網站經營時間增加而成長，還原所需的時間也會跟著變化，去年測試出來的還原時間，不代表今年還適用。

需要協助規劃網站備份與還原演練流程？

如果貴公司的網站還沒有做過完整的還原演練，或是不確定目前的備份範圍是否足夠，歡迎與我們聯繫，討論適合貴公司網站架構的備份策略與系統維護顧問服務。