# 快照與備份：選擇你需要承受的故障 | SwissOctet 深入解析 https://swissoctet.com/zh-tw/insights/snapshots-backups-consistency/ SwissOctet / 深入解析 / 儲存與復原 儲存與復原 實務應用 · 4 分鐘閱讀 快照與備份：選擇你需要承受的故障 比較復原點、故障邊界與應用程式一致性，而不是假設快照與獨立備份提供相同的保護。 由 SwissOctet 編輯部撰寫 儲存指南 複製連結 本頁內容 01 先描述副本，再為它命名 02 比較你預期能承受的故障 03 檢查應用程式一致性 04 把保留期視為復原時間窗 05 區分成功的工作與已驗證的資料 06 測試一次小型且完整的復原 07 把選用備份視為特定服務來閱讀 您的實用檢查清單 來源與延伸閱讀 返回資料庫 直接答案 快照是某個時間點的代表，其保護程度取決於實作方式。備份策略則加入刻意的保留、存取隔離與經過測試的復原。有些快照就是備份；有些則依賴原始儲存。請詢問在刪除、遭入侵或主要環境遺失時，什麼還能留存。 01 先描述副本，再為它命名 「快照」這個詞告訴你某個時間點已被代表，但沒有告訴你可復原的資料存放在哪裡，或誰能刪除它。原始儲存上的檔案系統快照與供應商管理的區塊快照，可能有不同的故障邊界。請從實作方式著手，而不是把標籤當成通用的保證。 AWS 將 EBS 快照記載為其磁碟區的增量時間點備份。那是特定的實作方式，不能證明每個快照選項的行為都相同。對任何服務，都要詢問復原是否依賴原始磁碟區、副本是否離開主要故障域，以及來源被移除時會發生什麼事。 02 比較你預期能承受的故障 更新後的快速回復與帳號遺失後的復原，是不同的问题。本機快照對前者可能很方便，但對後者提供的隔離很少。獨立副本可以增加保護，但前提是其儲存、存取與刪除路徑，與你準備應對的事件有足夠的隔離。 寫下故障與所需結果。這個說明性比較是決策輔助，不是 SwissOctet 的功能清單。它鼓勵針對副本與控制提出問題，而不是主張某種技術永遠較優。實際結果取決於配置與營運方記載的復原流程。 情境 對快照的提問 對備份的提問 應用程式更新出錯 我能回到預期的時間點嗎？ 可用的復原需要多久？ 主要磁碟遺失 副本依賴那顆磁碟嗎？ 我能復原到全新的儲存嗎？ 管理帳號遭入侵 這個帳號能刪除每一份副本嗎？ 刪除權限是否已隔離？ 數週後才發現錯誤 那個時間點還保留著嗎？ 保留期是否涵蓋發現延遲？ 03 檢查應用程式一致性 磁碟可以在應用程式仍在變更檔案時擷取它們。視軟體與快照流程而定，結果可能代表當機一致狀態，而非協調過的應用程式狀態。不要假設檔案可讀就表示資料庫與其相關上傳內容彼此一致。請使用應用程式或資料庫記載的備份方法。 PostgreSQL 的連續歸檔設計說明了差異：復原需要合適的基礎備份，以及一連串連續的所需預寫日誌檔案。在資料庫執行時隨手複製的目錄，不是等效的程序。如果應用程式也把檔案存放在資料庫之外，請規劃這兩個資料集如何一起復原。 04 把保留期視為復原時間窗 保留期應考量錯誤可能多久未被察覺。十天的時間窗，對一個月後才發現的意外刪除沒有幫助。無限期保留每一份副本會造成不同的問題：成本、敏感資料暴露增加，以及不明確的刪除政策。請依具體的營運與資料處理需求來選擇保留期。 為復原點標上有用的背景資訊，例如應用程式版本與已完成工作的時間，但不要嵌入機密。保留足夠的歷史，以區分良好狀態與損壞狀態。在修剪之前，確認所選系統如何處理共用或增量資料；刪除一個已標記的時間點，未必等於刪除一個單純的獨立檔案。 05 區分成功的工作與已驗證的資料 備份工具回報成功，只表示其流程依其規則完成。它不會自動證明所有重要應用程式資料都已選取、每個儲存的位元組都完好無損，或新伺服器能使用該結果。這些是不同的檢查。請把儲存庫健康狀態、選取範圍檢視與具代表性的復原納入營運計畫。 Restic 記載了其預設儲存庫檢查與實際讀取已儲存 pack 資料的驗證之間的差異。完整讀取資料的檢查可能耗費更多時間與頻寬。這個例子讓規劃重點變得具體：決定驗證實際讀取什麼，並為這項工作編列預算。請使用工具文件，而不是假設每個名為 check 的指令都有相同的涵蓋範圍。 06 測試一次小型且完整的復原 想像一個出版系統，包含資料庫、上傳的圖片與配置。把三者都復原到私人的測試環境，然後開啟一篇文章並驗證其附件。在演練期間，請停用排程郵件、付款與發佈整合。只測試一個隨機文字檔，會錯過讓應用程式有用的那些關聯。 測量所需時間，並記錄缺少哪些憑證、套件版本或外部相依性。檢視復原檔案的權限，而不只是其內容。復原演練經常會發現資料確實存在，但使用它所需的指示或存取權，從未與營運計畫一起保存下來。 07 把選用備份視為特定服務來閱讀 設定 SwissOctet 時，請查看該系列確切的備份選項與保留期。詢問它涵蓋哪些磁碟區與應用程式資料、復原是否為自助式，以及主要配置變更時會發生什麼事。單憑選項標籤，無法確立獨立副本、不可變儲存庫或資料庫一致的復原點。 在工作負載適合的地方使用快照，並針對它們未涵蓋的故障維持更廣泛的備份策略。為重要資料記錄一條獨立的復原路徑，保護能抹除副本的憑證，並測試該程序。最強的選擇是能承受你所定義情境的那一個，而不是名稱最令人安心的那一個。 付諸行動 您的實用檢查清單。 ✓ 找出可復原資料所在的位置。 ✓ 列出副本必須承受的故障。 ✓ 使用應用程式支援的一致性方法。 ✓ 依發現時間窗選擇保留期。 ✓ 分別保護刪除權限。 ✓ 在隔離環境中復原完整的應用程式。 下載檢查清單 常見問題 重要細節。 快照永遠不是備份嗎？ + 有些快照實作就是備份。有用的區別在於其儲存相依性、保留期、存取模型與經過測試的復原，而不只是標籤。 成功的完整性檢查能證明應用程式可運作嗎？ + 它只能證明該檢查涵蓋的範圍。請分別測試應用程式復原、配置、權限與資料關聯。 我應該把備份放在同一台伺服器上嗎？ + 同伺服器副本或許能應付有限的錯誤，但會共同承擔重要故障。重要資料需要一條位於你打算承受之故障邊界之外的復原路徑。 主要參考資料 前往來源。 這些參考資料支持本指南中的技術概念。在變更生產系統之前，請遵循最新文件。 Amazon EBS：快照 docs.aws.amazon.com PostgreSQL：連續歸檔與時間點復原 www.postgresql.org Restic：使用儲存庫與完整性檢查 restic.readthedocs.io 由 SwissOctet 提供的編輯指引。範例僅供說明。服務規格、可用選項與合約條件必須另行驗證。 連結知識 相關基礎架構。 Vault Storage 瑞士 Pulse NVMe 瑞士 Metal Zenith 瑞士 保持脈絡 您的下一份實地筆記。 探索所有指南 實地筆記 / 01 + 儲存與復原 基礎 NVMe 何時對您的應用程式產生影響 區分容量、延遲與輸送量，讓更快的儲存標籤能回答真實的應用程式問題。 4 分鐘閱讀 閱讀指南 實地筆記 / 02 + 儲存與復原 進階 測量 NVMe 效能時不要誤導自己 在從磁碟測試得出應用程式結論之前，先定義 I/O 模式、控制快取效應，並檢查延遲分布。 6 分鐘閱讀 閱讀指南 實地筆記 / 03 + 儲存與復原 基礎 物件、檔案或區塊儲存：選擇應用程式所需的介面 在將容量需求轉化為應用程式架構之前，先區分儲存介面、存取語意與營運責任。 4 分鐘閱讀 閱讀指南