DynamoDB のバックアップと Point-in-Time Recovery 完全ガイド

DynamoDBはデータを2つの方法で保護します。オンデマンドバックアップは、あなたが 取得して無期限に保持するフルスナップショットです。ポイントインタイムリカバリ （PITR）は継続的・自動的なバックアップで、ローリングウィンドウ内の任意の秒に テーブルをリストアできます。どちらも_新しい_テーブルにリストアします — これらは 復旧ツールであって、元に戻すボタンではありません。

監査ログにとって、これは譲れません。それは不変のコンプライアンス記録です。 イベントを書き換える悪いマイグレーションや、うっかりの一括削除は、ミスの直前の 瞬間まで復旧可能でなければなりません。

DynamoDBのバックアップとポイントインタイムリカバリはどう動くか？

DynamoDBは2種類のバックアップを提供します。ポイントインタイムリカバリ（PITR）は 継続的な自動バックアップを取り、設定可能な1〜35日のウィンドウ内の任意の秒に リストアできます。オンデマンドバックアップは無期限に保持される手動のフル スナップショットです。どちらも元のテーブルの上ではなく新しいテーブルにリストア するので、その場での取り消しではなく復旧ツールです。

• PITR = 継続的バックアップ、任意の秒にリストア — 設定可能な1〜35日の ウィンドウ内で（以前は固定の35日でした）。
• オンデマンドバックアップ = 手動のフルスナップショット — PITRのウィンドウとは 独立して、望むだけ長く保持します。
• リストアは新しいテーブルを作成します。 新しい名前にリストアしてから切り替え ます — 元のテーブルはそのままです。
• PITRはテーブルサイズで課金され、リストアポイントの数では課金されません — DynamoDB料金計算機で見積もりましょう。

問題：その場で取り消せないミス

DynamoDBにはロールバックできるトランザクションログも、書き込みの「取り消し」も ありません。マイグレーションスクリプトがすべてのイベントのactionフィールドを 書き換えたり、誰かが意図より広い削除を実行したりすると、テーブルは単に間違った 状態になります。バックアップがなければ、データは失われます。

監査ログ — その価値すべてが信頼できる記録であること — にとって、「先週火曜の イベントを取り戻せない」はただの不便ではなくコンプライアンスの失敗です。

バックアップとPITRの仕組み

ポイントインタイムリカバリは、いったん有効にすると継続的な自動バックアップを 取ります。AWSドキュメントに よれば、PITRはテーブルデータのフルマネージドな継続的バックアップを、秒単位の リストア粒度で提供します。ウィンドウはRecoveryPeriodInDaysで1〜35日に設定 でき、その中の任意の秒にリストアできます — リアルタイムから約5分遅れ （LatestRestorableDateTime）まで — 別のリージョンへのリストアも含みます。

重要な境界が1つ：リカバリ期間を短くすると、最も早いリストアポイントが即座に 減り、PITRを無効にしてから再度有効にすると、リストア可能な開始時刻がリセット されます — それまでの継続的な履歴を失います。

PITRはマネージドなS3へのエクスポートの前提条件でも あります。エクスポートは同じ継続的バックアップから読み取るため、PITRがオフだと ExportTableToPointInTimeは PointInTimeRecoveryUnavailableExceptionで失敗します。

オンデマンドバックアップは別物です。明示的に作成して無期限に保持する手動の フルテーブルスナップショットで、マイグレーション前のチェックポイントや、35日の PITRウィンドウを超える長期のコンプライアンスアーカイブに便利です。リクエストは 即座に処理されてバックアップは数分以内にリストア可能になり、テーブルのスループットは 一切消費せず、保持できる数にも上限はありません。ドキュメントに書かれた正直な注意点が 1つあります。オンデマンドバックアップはアイテム間の因果一貫性を保証しません — 更新間のズレは"usually much less than a second"とされていますが、書き込みが集中する 最中に取ったバックアップは、単一の凍結された瞬間ではありません。

リストアでは戻ってこないもの

リストアが作り直すのはテーブルのデータとそのインデックスであって、運用まわりの 配線ではありません。 AWSのドキュメントによれば、 リストアしたテーブルでは次の設定を手動で再構成する必要があります。Auto Scalingポリシー、 IAMポリシー、CloudWatchのメトリクスとアラーム、タグ、ストリーム設定、TTL、削除保護、 そしてPITRそのものです。バックアップからリストアしてPITRの再有効化を忘れること — それこそが次のインシデントを復旧不能にする道筋です。

リストア時に意図的に変更できる設定もあります — 課金モード、プロビジョンドキャパシティ、 暗号化キー — また、セカンダリインデックスの一部またはすべてを除外することもでき、 後で作り直せるならリストアはその分だけ速く安くなります。リストアは別のリージョンを 対象にすることもでき、そして既存のテーブルを上書きすることは決してありません。

AWS Backupによるスケジュールバックアップ

DynamoDB自身のオンデマンドバックアップにスケジューラーはありません。保持期間付きの 定期バックアップが必要なら、DynamoDBはAWS Backupとネイティブに統合されています (AWSのドキュメント)。 バックアッププランが提供するのは、ライフサイクルルール（コールドストレージへの階層化を 含む）付きのスケジュールバックアップ、DR向けのアカウント間・リージョン間の自動コピー、 バックアップボールト経由の独立したKMSキー、そして誰にも黙って削除できないWORM コンプライアンス体制のためのVault Lockです。運用上の落とし穴が2つあります。 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は復旧ウィンドウであって、 長期保存ではありません。

これで監査ログの運用ループが閉じます。整合性のためのトランザクション、反応のための ストリーム、期限切れのためのTTL、コストのための適切なキャパシティーモード、 リージョンの回復力のためのグローバルテーブル、そしてデータ復旧のためのPITR。 それらがどう組み合わさるかは、 運用とコストの概観で見直してください。

DynoTableをダウンロードして、リストアしたテーブルにつなぎ、信頼する 前に復旧を検証しましょう。