完成「模型與 Cache 要備份嗎?重建策略的取捨」後,下一個問題是「RPO/RTO 不是名詞:轉化為可測量目標」能否重跑、否定並留下失敗原因。這就是今天的範圍。
針對 DB、設定、模型服務分別設定 RPO/RTO,並把目標對映到備份頻率與復原步驟。
AI 平台需要先分資料:database、object/file data、configuration、secrets、model artifacts、container image 與 cache。不是所有東西都要備份;能可靠重建的資料,保存「來源與版本」往往比複製數 TB cache 更合理。
RPO 定義可以接受遺失多少資料,RTO 定義可以接受多久恢復。兩者最後都要靠 restore drill 驗證。只有 backup successful 的紀錄,沒有從空環境恢復的演練,不能證明災難復原成立。
只看到備份檔存在,不能證明災難時真的能救回來。本文的驗收標準是:在隔離環境中完成 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
先把「用一次隔離還原演練計算資料點與服務恢復時間」需要固定的輸入、版本與環境集中在同一份小型測試計畫;函式名稱代表實際工具。
plan = {
"change": '用一次隔離還原演練計算資料點與服務恢復時間',
"fixed": ("input", "version", "environment"),
"metrics": ('最後可用資料時間', 'RPO', 'RTO', '驗證結果'),
}
for round_no in range(1, 4):
sample = run_once(plan) # 接上實際壓測或維運工具
save_sample(round_no, sample)
驗證可從「用一次隔離還原演練計算資料點與服務恢復時間」開始。先列出資料、設定、憑證、模型與服務之間的復原依賴,再決定哪些內容必須備份、哪些可以由固定來源重建。測試不能停在檔案存在或指令成功,必須在隔離環境完成還原,並由應用程式層確認資料可讀、權限正確且核心流程可用。
這篇優先比較:最後可用資料時間、RPO、RTO、驗證結果。總恢復時間應拆成環境準備、資料傳輸、還原、驗證與重新開放流量等階段,才能找出真正瓶頸。若服務很快啟動但資料落後、物件遺失或權限錯誤,仍不能算復原完成。
Runbook 應明確標出復原順序、必要權限、secret 來源、驗證方式與停止條件。每次演練結束後,要確認暫存資源已清理,並把實際阻塞點回寫到流程。若某一步只能靠特定人員記憶完成,代表復原能力仍有單點風險。
先看資料正確性,再看服務是否啟動,最後才評估速度。RTO 很短但資料不一致沒有實際意義;資料完整但復原時間超過業務容忍範圍,也表示策略需要調整。應把每段耗時與人工介入次數列出,找出最值得自動化或預先準備的環節。
單次演練通過不代表長期有效。資料量、版本與依賴會持續變化,因此需要固定週期重跑,並在重大架構或權限變更後追加驗證。
判讀不只看最大或最漂亮的數字。這一天真正要回答的是:把 RPO/RTO 轉成實際測量而非口號。
如果核心指標改善,但錯誤率、尾端延遲、資源成本或恢復能力變差,這代表取捨,而不是無條件進步。相反地,沒有改善也不是無效結果;至少能排除一條看似合理、實際上不值得增加複雜度的路。
今天的工程判斷是:把 RPO/RTO 轉成實際測量而非口號。無論結果支持或否定原本假設,都必須保留完整條件,才能和下一天的實驗串在一起。
下一篇將處理:災難復原演練:從空機到重新提供 AI 服務。