DynamoDB 備份與時間點復原

DynamoDB 以兩種方式保護你的資料。隨需備份是你自行建立並無限期保留的完整快照。時間點復原（PITR）則是持續、自動的備份，讓你能將表格復原到一個滾動視窗內的任意秒。兩者都會復原到一張新的表格 — 它們是復原工具，而非「復原上一步」的按鈕。

對於稽核記錄而言，這是無可妥協的。它是一份不可變更的合規紀錄；一次改寫事件的失敗遷移，或是一次意外的大量刪除，都必須能復原到犯錯之前的那一刻。

DynamoDB 備份與時間點復原如何運作？

DynamoDB 提供兩種備份類型。時間點復原（PITR）會進行持續的自動備份，讓你能將表格復原到可設定的 1 至 35 天視窗內的任意秒。隨需備份則是手動建立的完整快照，可無限期保留。兩者都會復原到一張新表格，絕不覆寫原本的表格，因此它們是復原工具，而非就地的「復原上一步」。

• PITR＝持續備份、可復原到任意秒，視窗可設定為 1 到 35 天（過去曾固定為 35 天）。
• 隨需備份＝手動的完整快照，可隨你想保留多久就保留多久，獨立於 PITR 的視窗之外。
• 復原會建立一張新表格。 你復原到一個新名稱，再切換過去 — 原本的表格不受影響。
• PITR 依表格大小計價，而非依復原點的數量 — 可用 DynamoDB 定價計算機 來估算。

問題：一個無法就地復原的錯誤

DynamoDB 沒有可供回滾的交易記錄，寫入也沒有「復原上一步」。如果一段遷移指令碼改寫了每個事件的 action 欄位，或是有人執行了範圍超出預期的刪除，表格就只是處於錯誤的狀態。沒有備份的話，資料就此消失。

對於一份稽核記錄 — 它的全部價值就在於是一份可信賴的紀錄 — 「我們拿不回上週二的事件」是一次合規失敗，而不只是不便而已。

備份與 PITR 如何運作

時間點復原一旦啟用，就會進行持續的自動備份。根據 AWS 文件， PITR「提供完全託管、自動且持續的表格資料備份，最多可保留 35 天的復原點，並達到每秒粒度」。視窗可透過 RecoveryPeriodInDays 設定為 1 到 35 天，你可以復原到視窗內的任意秒 — 甚至復原到不同的區域。

有一個重要的邊界情況：縮短復原期間會立即縮短最早的復原點，而停用後再重新啟用 PITR 會重設可復原的起始時間 — 你會失去先前的持續歷史。

隨需備份則是另一回事：手動、完整表格的快照，由你明確建立並無限期保留，適合作為遷移前的檢查點，或是超出 35 天 PITR 視窗的長期合規封存。

兩者都會復原到一張新表格，而非覆寫既有的表格：

一個實作範例：從失敗的遷移中復原

一段原本要新增 expiresAt 屬性的遷移，反而把每個事件的 action 覆寫成空字串。PITR 已開啟且視窗為 35 天，於是你復原到遷移執行之前的那一秒：

在你驗證復原結果的同時，受損的表格仍維持不動 — 你比對復原後的事件與線上的事件，確認 action 值已恢復，再將應用程式指向新表格。復原本身不會破壞任何東西。

如果損失的是少數幾個項目而非整張表格的損毀，你也可以改為檢視線上資料與復原的副本，只把受影響的列複製過去 — 請見複製 DynamoDB 表格。

在 DynoTable 中實作

一次復原的好壞，全看你對它的驗證。在復原到 audit-log-restored 之後，你需要實際查看復原回來的事件，確認它們與犯錯之前應有的樣子相符。

DynoTable 連接復原後的表格就跟連接其他表格一樣，所以你可以查詢受影響租戶的事件、確認 action 值正確，並在切換之前與線上表格比對 — 讓復原從一場信心的賭注變成一次經過驗證的復原。

你也可以匯出復原回來的事件，作為一份離線的合規紀錄 — 請見將 DynamoDB 匯出為 CSV。

陷阱與後續步驟

• 在你需要之前就先啟用 PITR。 它只保護自開啟那一刻起的資料 — 沒有回溯復原這回事。為任何你承擔不起資料遺失的表格開啟它。
• 停用 PITR 會重設視窗。 把它關掉再開啟會抹除持續歷史；可復原的起始時間會從重新啟用時重新開始。
• 復原既不是即時的，也不是免費的。 一次復原會佈建一整張新表格，所需時間與大小成正比；請為這段期間與額外的表格預留成本。
• 35 天不是封存。 若需保留超過 PITR 視窗的時間，請進行隨需備份或匯出至 S3 — PITR 是一個復原視窗，而非長期儲存。

這就為稽核記錄的維運迴圈畫下句點：交易確保一致性、Streams 用於反應、TTL 用於到期、適當的容量模式控制成本、global table 帶來區域韌性，而 PITR 用於資料復原。回頭看維運與成本概觀，了解它們如何環環相扣。

下載 DynoTable 來連接一張復原後的表格，並在你信任它之前先驗證你的復原結果。