前一篇處理「物件與檔案資料：一致性比複製更難」，這篇進一步討論「模型與 Cache 要備份嗎？重建策略的取捨」。共同的量測條件是前後比較的基礎。

今天要回答的問題

比較完整備份模型檔與從來源重建的 RTO、成本與可靠性，定義 artifact provenance。

工程邊界

AI 平台的 Storage 同時承擔「大、頻繁、可重建與不可重建」資料

模型權重與下載 cache 通常很大但可重新取得；資料庫、使用者文件與設定可能相對小，卻不可隨意重建；Log 與 temporary artifacts 則會持續增長。三者若混在同一個 filesystem，很容易因為「可丟的資料」把「不能丟的服務」一起塞滿。

因此容量治理至少要有資料分類、保留期限、high-water mark、清理政策與 I/O 觀測。模型載入慢時，也要先確認是不是 storage throughput／random I/O，而不是直覺去怪 GPU。

一個可以直接重現的起點

備份一定要用「還原」驗收

只看到備份檔存在，不能證明災難時真的能救回來。本文的驗收標準是：在隔離環境中完成 restore，確認 schema、資料、權限與應用程式都能重新工作，並記錄實際 RTO。若有多個資料來源，還要說明各資料來源的時間一致性與可接受 RPO。

# PostgreSQL 邏輯備份示意，參數請依自己的環境調整
pg_dump -Fc -d "$DATABASE_URL" -f backup.dump

# 還原必須在測試環境實際演練
pg_restore --clean --if-exists -d "$RESTORE_DATABASE_URL" backup.dump

為可重建模型保存來源資訊

先把「刪除可重建的 model cache，再由固定來源重建」需要固定的輸入、版本與環境集中在同一份小型測試計畫；函式名稱代表實際工具。

plan = {
    "change": '刪除可重建的 model cache，再由固定來源重建',
    "fixed": ("input", "version", "environment"),
    "metrics": ('重建時間', '下載量', 'hash', '服務恢復時間'),
}
for round_no in range(1, 4):
    sample = run_once(plan)  # 接上實際壓測或維運工具
    save_sample(round_no, sample)

驗證與落地方式

驗證可從「刪除可重建的 model cache，再由固定來源重建」開始。先列出資料、設定、憑證、模型與服務之間的復原依賴，再決定哪些內容必須備份、哪些可以由固定來源重建。測試不能停在檔案存在或指令成功，必須在隔離環境完成還原，並由應用程式層確認資料可讀、權限正確且核心流程可用。

這篇優先比較：重建時間、下載量、hash、服務恢復時間。總恢復時間應拆成環境準備、資料傳輸、還原、驗證與重新開放流量等階段，才能找出真正瓶頸。若服務很快啟動但資料落後、物件遺失或權限錯誤，仍不能算復原完成。

常見誤判

• 把「有備份檔」等同「可以還原」，沒有定期驗證格式、版本與相依服務。
• 用估算值填寫 RPO／RTO，卻沒有從真實演練量出最後資料點與恢復時間。
• 所有資料一律複製，沒有區分不可取代資料與可重建 cache，導致成本與還原時間同時增加。

上線前檢查

Runbook 應明確標出復原順序、必要權限、secret 來源、驗證方式與停止條件。每次演練結束後，要確認暫存資源已清理，並把實際阻塞點回寫到流程。若某一步只能靠特定人員記憶完成，代表復原能力仍有單點風險。

如何閱讀結果

先看資料正確性，再看服務是否啟動，最後才評估速度。RTO 很短但資料不一致沒有實際意義；資料完整但復原時間超過業務容忍範圍，也表示策略需要調整。應把每段耗時與人工介入次數列出，找出最值得自動化或預先準備的環節。

單次演練通過不代表長期有效。資料量、版本與依賴會持續變化，因此需要固定週期重跑，並在重大架構或權限變更後追加驗證。

結果判讀

判讀不只看最大或最漂亮的數字。這一天真正要回答的是：決定哪些資料備份、哪些只保存 manifest。

如果核心指標改善，但錯誤率、尾端延遲、資源成本或恢復能力變差，這代表取捨，而不是無條件進步。相反地，沒有改善也不是無效結果；至少能排除一條看似合理、實際上不值得增加複雜度的路。

今天的結論

今天的工程判斷是：決定哪些資料備份、哪些只保存 manifest。無論結果支持或否定原本假設，都必須保留完整條件，才能和下一天的實驗串在一起。

下一篇將處理：RPO／RTO 不是名詞：轉化為可測量目標。

參考資料

• Google SRE Book
• Prometheus Documentation
• vLLM Documentation
• PostgreSQL Backup and Restore