DynamoDB 備份與時間點還原（PITR）完整指南

DynamoDB 以兩種方式保護你的資料。隨需備份是你自己 擷取並可無限期保留的完整快照。時間點還原（PITR）是持續、 自動的備份，讓你把表格還原到一個滾動視窗內的任何一秒。兩者都還原到一個_新_表格——它們是復原工具，不是一顆復原按鈕。

對稽核日誌而言這是不可妥協的。它是一份不可變的合規紀錄；一次 改寫事件的糟糕遷移，或一次意外的大量刪除，都必須能 還原到犯錯前的那一刻。

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

DynamoDB 提供兩種備份類型。時間點還原（PITR）擷取持續的自動備份，讓你還原到一個可設定的 1 到 35 天視窗內的任何一秒。隨需備份是無限期保留的手動完整快照。兩者都還原到一個新表格，絕不覆蓋原始表格，所以它們是復原工具，而不是就地的復原。

• PITR = 持續備份，還原到任何一秒，在一個可設定的 1 到 35 天視窗內（它以前是固定的 35 天）。
• 隨需備份 = 手動的完整快照，愛保留多久就多久， 獨立於 PITR 的視窗。
• 還原會建立一個新表格。 你還原到一個新名字，然後切換—— 原始表格不受影響。
• PITR 依表格大小計價，而非依還原點的數量——用 DynamoDB 定價計算機 估算它。

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

DynamoDB 沒有可供你回滾的交易日誌，也沒有對一次寫入的「復原」。如果一次 遷移指令稿改寫了每個事件的 action 欄位，或有人執行了一次 比預期更廣的刪除，表格就只是處於錯誤的狀態。沒有 備份，資料就沒了。

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

備份與 PITR 如何運作

時間點還原一旦啟用，就會擷取持續的自動備份。依 AWS 文件， PITR 為你提供完全受管、具每秒還原粒度的表格資料持續 備份。這個視窗可透過 RecoveryPeriodInDays 設定為 1 到 35 天，而你可以還原到其中的任何一秒——直到大約落後於實際時間五分鐘 （LatestRestorableDateTime）——也包括還原到一個不同的 region。

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

PITR 也把關受管的匯出到 S3：該匯出讀取的是 同一份持續備份，因此在 PITR 關閉時，ExportTableToPointInTime 會以 PointInTimeRecoveryUnavailableException 失敗。

隨需備份是分開的：手動、整表的快照，你明確地 建立並無限期保留，適合作為遷移前的檢查點，或 一份超出 35 天 PITR 視窗的長期合規封存。請求會被立即處理， 備份在幾分鐘內就可供還原，不會消耗表格的任何輸送量，而且你 保留幾份都沒有上限。文件裡有一個誠實的但書：隨需備份並不保證 跨項目的因果一致性——各次更新之間的偏差「usually much less than a second」，但一份在寫入尖峰中途取得的備份，並不是一個單一的 凍結瞬間。

還原不會帶回來的東西

一次還原重建的是表格的資料與它的索引——而不是它的維運接線。根據 AWS 文件， 你必須在還原後的表格上手動重新設定：自動調整規模政策、 IAM 政策、CloudWatch 指標與警報、標籤、串流設定、TTL、 刪除保護，以及 PITR 本身。從備份還原卻忘了重新啟用 PITR， 正是下一次事故變成無法復原的原因。

在還原時，你可以刻意變更某些設定——計費模式、佈建容量、 加密金鑰——而且你可以排除部分或全部次要索引，只要你之後有辦法 重建它們，這會讓還原更快也更便宜。還原也可以指向不同的區域， 而且一次還原永遠不會覆蓋既有的表格。

用 AWS Backup 做排程備份

DynamoDB 自己的隨需備份沒有排程器。若要有保留期的週期性備份， DynamoDB 與 AWS Backup 有原生整合 （AWS 文件）： 備份計畫給你帶生命週期規則的排程備份（包含冷儲存分層）、 為災難復原自動進行的跨帳戶與跨區域複製、透過備份保存庫使用的一把 獨立 KMS 金鑰，以及提供 WORM 合規態勢、誰都無法悄悄刪除的 Vault Lock。 兩個維運上的陷阱：AWS Backup 必須逐帳戶、逐區域明確選擇加入， 而它建立的備份（類型 AWS_BACKUP）無法從 DynamoDB 主控台刪除—— 請改在 AWS Backup 中管理它們。

兩者都還原到一個新表格，而非覆蓋既有的：

一個實作範例：從一次糟糕的遷移中復原

一次原本要新增一個 expiresAt 屬性的遷移，反而以一個空字串 覆寫了每個事件上的 action。PITR 開著、視窗為 35 天，所以你還原 到遷移執行_之前_的那一秒：

被破壞的表格在你驗證還原時保持不動——你把 還原後的事件與即時的事件比對、確認 action 值回來了，然後 重新指向應用程式。復原本身沒有摧毀任何東西。

如果損失的是少數幾個項目而非整表的損壞，你可以 改為檢視即時資料與還原後的副本，只把受影響的資料列複製 過去——參見 複製一個 DynamoDB 表格。

在 DynoTable 中操作

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

DynoTable 會像連上任何其他表格一樣連上還原後的表格，所以你可以查詢 受影響租戶的事件、確認 action 值是正確的，並在切換之前與 即時表格比對——把一次還原從一次信仰之躍變成一次已驗證的復原。

你也可以匯出那些復原的事件，作為一份離線的合規紀錄——參見 把 DynamoDB 匯出到 CSV。

陷阱與後續步驟

• 在你需要它_之前_就啟用 PITR。 它只從開啟的那一刻起保護—— 沒有追溯性的復原。為任何你損失不起其資料的表格開啟它。
• 停用 PITR 會重設視窗。 把它切掉再切回來會抹掉那份 持續歷史；可還原的起始時間會從重新啟用時重新開始。
• 還原既不即時也不免費。 一次還原會佈建一整個新表格，並 花費與大小成正比的時間；為那段時長與那個額外的表格編列預算。
• 35 天不是封存。 若要超出 PITR 視窗的保留，就擷取隨需 備份或匯出到 S3——PITR 是一個復原視窗，不是長期儲存。

那就闔上了稽核日誌的操作環路：交易保一致性、Streams 供反應、TTL 供過期、對的容量模式保成本、global tables 供 region 韌性，而 PITR 供資料復原。回顧 操作與成本總覽，看看它們如何拼在一起。

下載 DynoTable，連上一個還原後的表格，在你信任你的 復原之前先驗證它。