Amazon DynamoDBのバックアップとポイントインタイムリカバリ

Amazon DynamoDBのデータ保護では、オンデマンドバックアップと**ポイントインタイムリカバリ（PITR）**を使い分けます。オンデマンドバックアップは任意のタイミングで明示的に保存する方式です。PITRは継続的なバックアップを保持し、設定された期間内の時点を指定して復元する方式です。

どちらも、誤った更新や削除からデータを回復するための機能です。復元操作は元のテーブルを巻き戻すのではなく、新しいテーブルを作成します。復元後にアプリケーションの参照先を切り替えるか、復元データを検証してから必要なデータを移すかは、運用手順として別に決めておきます。

オンデマンドバックアップ

オンデマンドバックアップは、必要なタイミングでテーブルのバックアップを作成する方法です。デプロイやデータ移行の前、定期的な保全ポイントなど、保存したいタイミングを運用側で決められます。バックアップ作成中もテーブルの読み書きは継続でき、バックアップ処理によってテーブルのパフォーマンスが低下することはありません。

作成したバックアップは、明示的に削除するまで保持されます。元のテーブルを削除してもバックアップは独立して残るため、テーブル自体の誤削除に備えられます。保持する期間を自動化したい場合は、バックアップの削除を含む運用やAWS Backupによるポリシー管理を組み合わせます。

オンデマンドバックアップから復元する場合、保存時点のデータを使って別のテーブルを作成します。復元にはデータ量やインデックスなどに応じた時間がかかるため、「数秒で完了する」とは見積もらず、必要な復旧時間を実環境に近い条件で確認します。

ポイントインタイムリカバリ（PITR）

PITRは、テーブルへの変更を継続的に保護し、指定した過去の時点の状態へ復元する機能です。最大で過去35日間が復元可能なウィンドウになります。固定時点のバックアップだけを選ぶオンデマンド方式と異なり、保持期間の中から復旧先の時刻を指定できます。

復元時点は秒単位の粒度で指定できます。ただし、現在進行中のデータを瞬時に復元できるわけではありません。最新の復元可能時点は通常、現在時刻のおよそ5分前です。たとえば、注文管理テーブルで誤った一括更新が行われた場合、誤更新が始まる直前の時点を選び、その時点のデータを別テーブルへ復元する設計ができます。

PITRを無効化すると、それまでの継続バックアップの復元ウィンドウは失われます。後から再び有効にしても、無効化前の期間を利用できる状態に戻るわけではなく、新しい保護期間が始まります。PITRを一時停止してコストを抑えたあと、直ちに無効化前の時点へ復元できるとは考えないようにします。

2つの方式の比較

観点	オンデマンドバックアップ	ポイントインタイムリカバリ
バックアップの作成	必要なタイミングで明示的に作成	有効化中は継続的にバックアップ
復元先	新しいテーブル	新しいテーブル
復元する時点	バックアップを作成した時点	復元ウィンドウ内の指定時点
保持	明示的に削除するまで保持	最大35日間の復元ウィンドウ
元テーブルの削除	バックアップは元テーブルから独立して残る	PITRの有効状態や復元ウィンドウを確認して対応する
適した目的	特定の節目を長く保持する、作業前の復旧点を作る	直前の誤操作など、任意の時点への復旧に備える

両者は代替関係とは限りません。過去35日を超えて保存したい節目にはオンデマンドバックアップを使い、継続的な復旧点が必要なテーブルではPITRを有効にするなど、保持期間と復旧要件に応じて併用できます。

復元時に作成されるテーブル

バックアップやPITRからの復元では、復元データを持つ新しいテーブルが作られます。既存テーブルを直接上書きしたり、指定時点に巻き戻したりする機能ではありません。そのため、復元後にはテーブル名、アプリケーションの接続先、読み書きの開始タイミングを慎重に扱います。復旧用テーブルの内容を確認する時間を確保し、誤ったデータを再び本番へ流さないようにします。

復元操作では、復元先テーブルの設定を指定できる項目があります。必要に応じて、課金モード、テーブルの読み書きキャパシティ、グローバルセカンダリインデックス（GSI）の容量、暗号化などを復元時に構成します。利用できる設定やインデックスの扱いは復元方法と現在のサービス仕様を確認し、元の設定が必ずすべて引き継がれるとは考えないでください。

復元後は、復元時に指定しなかった運用設定を確認して再適用します。たとえば、次の設定は復元後に改めて構成するものとして復旧手順に含めます。

設定	復元後の確認
オートスケーリング	テーブルやGSIのApplication Auto Scaling設定、最小・最大容量、目標使用率を再構成する
IAMポリシー	アプリケーションや運用者が復元テーブルへアクセスできる権限を確認する
CloudWatchアラーム	復元テーブルを監視対象にするアラームや通知先を設定する
タグ	コスト配分や運用管理に必要なタグを付け直す
DynamoDB Streams	変更イベントを使う場合はストリームを有効にし、イベントソースマッピングなどの接続先も確認する
TTL	有効化する属性名と期限切れアイテムの削除動作を再設定する

これらの設定がないままアプリケーションを再開すると、権限不足、監視の欠落、変更イベント処理の停止、期限切れデータの残存などにつながります。復元後の確認項目を手順書に含め、データの復旧と運用機能の復旧を別々に確認します。

復旧手段の選択

バックアップ方式は、どの程度前の状態まで戻せる必要があるか、どれくらいの期間を保持するかで判断します。

要件	検討する方法
デプロイや一括データ変更の前に特定時点を保存したい	オンデマンドバックアップを作成
35日以内の任意の時点へ戻したい	PITRを有効化し、必要な時刻を指定して復元
35日を超える期間、特定の状態を保存したい	オンデマンドバックアップの保持を設計
テーブル全体を削除してしまった場合に備えたい	テーブルと独立して残るオンデマンドバックアップを保持するか、削除時点のPITRの状態を確認
復元後すぐに本番運用へ戻したい	新しいテーブルへの復元時間、接続先の切り替え、権限・監視・Streams・TTLの再設定を含めて復旧を演習

バックアップが存在することだけで、要求された復旧時間が満たされるとは限りません。バックアップ作成、復元完了、設定の再適用、アプリケーション切り替えまでを通した復旧時間を確認します。また、レプリカ間でデータを複製するグローバルテーブルはリージョン間可用性の機能であり、誤った更新も複製され得るため、過去時点への復旧を担うバックアップやPITRとは役割が異なります。

バックアップと復元には、保存量、復元データ量、リージョンや機能の利用条件などに応じた料金が発生します。固定額を前提にせず、Amazon DynamoDBの料金ページで構成に応じた課金要素を確認します。

試験で押さえるポイント

• 任意の時点で明示的に作成し、明示的に削除するまで保持する方式はオンデマンドバックアップ。
• オンデマンドバックアップは元テーブルを削除しても残り、バックアップ作成はテーブルの読み書き性能に影響しない。
• PITRは継続バックアップを使い、最大35日間の復元ウィンドウから時点を選ぶ。復元指定は秒単位だが、最新の復元可能時点は通常、現在のおよそ5分前。
• PITRを無効にすると復元ウィンドウが失われ、再有効化後は新しい保護期間が始まる。
• オンデマンドバックアップもPITRも、復元結果は新しいテーブルになる。既存テーブルの上書きやその場での巻き戻しではない。
• 復元にはデータ量などに応じた時間がかかるため、数秒で完了すると保証しない。必要な復旧時間は実際の構成で確認する。
• 課金モード、テーブルやGSIのキャパシティ、暗号化など復元時に指定できる設定と、復元後に再設定するオートスケーリング、IAM、CloudWatch、タグ、Streams、TTLを区別する。

AWS公式ドキュメント

• Amazon DynamoDBのバックアップと復元
• オンデマンドバックアップと復元
• ポイントインタイムリカバリ（PITR）
• Amazon DynamoDBの料金

関連トピック

• Amazon DynamoDBの基本とデータモデル
• Amazon DynamoDBのキャパシティモードと読み書き性能
• Amazon DynamoDBグローバルテーブル