幾乎每個維運過伺服器的人，都聽過或經歷過同一個故事：一條寫錯的指令、一次沒看清目錄的刪除、一個覆蓋了正式資料庫的遷移指令碼，幾秒鐘就抹掉了幾年的資料。真正區分「虛驚一場」和「滅頂之災」的，從來不是運氣，而是有沒有一份可用的備份。

先分清快照和備份

很多人以為開了快照就萬事大吉，其實兩者作用不同：

  • 快照（Snapshot）：整機某一時刻的映像，還原快、適合系統升級或大改動前的「後悔藥」。但通常和執行個體存放在同一基礎設施上，粒度粗，不適合找回單一檔案。
  • 備份（Backup）：資料檔案級別的副本，可以存到別處，支援保留多個歷史版本，適合因應誤刪、資料損毀和勒索軟體。

結論：兩者都要，且不能互相取代。

3-2-1 原則依然是最實用的框架

  • 3 份資料：正式資料 + 兩份備份。
  • 2 種媒介或位置：不要把備份和來源資料放在同一台機器、同一顆磁碟上。
  • 1 份異地：至少一份放在不同的服務商或不同地區，避免單點故障或帳號問題導致全軍覆沒。

具體怎麼落地

  • 資料庫單獨邏輯備份：直接複製資料目錄常常拿到不一致的狀態。用 mysqldump、pg_dump 等工具做邏輯匯出，並壓縮存檔。
  • 用增量備份工具：restic、borg 等支援去重、增量和加密，長期保留多個版本的空間開銷遠低於每天完整複製。
  • 排程任務自動執行：用 cron 或 systemd timer 每日自動跑，人工手動備份必然會忘。
  • 加密後再上傳異地：備份裡往往包含使用者資料和憑證，傳到物件儲存前務必加密。
  • 設定保留策略：例如日備保留 7 天、週備保留 4 週、月備保留 6 個月，避免儲存無限膨脹。
  • 監控備份是否成功：靜默失敗的排程任務比沒有備份更危險——你以為有，實際沒有。給失敗加上告警。

最關鍵的一步：定期演練還原

這是絕大多數人跳過、卻最不該跳過的環節。沒有驗證過還原流程的備份，不能算備份。每季花半小時，在一台臨時執行個體上把最近的備份完整還原一次，確認資料完整、服務能起來、你還記得操作步驟。真正出事的那天，你要的是一份演練過的流程，而不是一堆沒人打開過的壓縮檔。

SharkCloud 支援執行個體快照與彈性的資源配置，你可以隨時開一台臨時執行個體做還原演練，用很小的代價換來「出事時真的救得回來」的確定性。