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