本番導入前のDynamoDBテーブルで、将来の誤更新に備え、継続的に保護された直近7日間の指定時点へ戻せるようにしたい。毎週の手動バックアップでは更新間の履歴が不足する。
障害後は復元可能範囲を確認し、誤更新直前のデータを新しいテーブルへ復元する。復元後のアプリ接続先と運用設定の再準備は許容する。
最も適切な設定はどれか。
PITRを事故前に有効化し、設定した保持期間と実際の復元可能範囲を確認して新しいテーブルへ復元する。
詳細解説
有効化前の履歴は後から作れない。将来の誤更新に備えて先に保護する必要がある。
オンデマンドバックアップは取得時点の復元用であり、取得間の連続した時点復元を提供しない。
PITRは新しいテーブルを作る。元のテーブルへの上書き復元ではなく、検証と接続先切替を準備する。
継続バックアップの復元可能範囲内で指定時点へ戻せる。実際のEarliestRestorableDateTimeとLatestRestorableDateTimeを確認する。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
公式資料でPointInTimeRecoveryStatus、RecoveryPeriodInDays、復元可能時刻、新テーブルの再設定を確認する。
参考にした公式資料
確認できる内容
有効化前へ戻せない理由、最新時刻の遅れ、接続先とPITR等の再設定を説明できる。
理解のポイント
- point-in-time recovery
- 継続的バックアップ
- DynamoDB
確認時の注意
- 確認環境: AWS公式SOA-C03試験ガイドとAWS公式ドキュメントの確認
- AWS公式SOA-C03試験ガイドと各サービスの公式ドキュメントを確認する。
基礎のおさらい
保持日数と実際の履歴を区別する
RecoveryPeriodInDaysは1〜35日で設定する。7日保持を設定しても有効化直後に7日前へ戻れるわけではない。復元可能範囲はEarliestRestorableDateTime〜LatestRestorableDateTimeで、最新時刻は通常約5分前となる。ContinuousBackupsStatusがENABLEDでも、PointInTimeRecoveryStatusの有効化確認が別に必要である。
新テーブルを復元してから利用を再開する
PITRは新しいテーブルを作り、復元中も元のテーブルは利用できる。復元所要時間はデータ量やインデックス等で変わり、固定の完了時間は保証されない。復元データを検証し、アプリの接続先とIAM、Auto Scaling、TTL、Streams、アラーム、PITR等を再準備して切り替える。