1. はじめに
Amazon Aurora の復旧機能を調査する機会があり、ポイントインタイムリカバリ（PITR） に関して勘違いしていたポイントをまとめました。
2. 継続的バックアップとポイントインタイムリカバリ（PITR）
2.1. 継続的バックアップとは？
継続的バックアップとは、DBインスタンスへの書き込みと並行して、トランザクションログをリアルタイムでストレージ（Amazon S3）に保存し続ける仕組みのことです。
2.2. ポイントインタイムリカバリとは？
ポイントインタイムリカバリ（PITR）とは、継続的なバックアップデータを利用し、過去35日前から現在より5分前までの任意の時点を指定してデータを復元できる機能のことです。
3. 勘違いしていたポイント
PITR について勘違いしていたポイントは、「現在のクラスターが過去の状態にロールバックされる」とイメージしていましたが、実際には異なります。
3.1. 既存クラスターで復旧されない
PITRを実行すると、指定した時点のデータの新しいDBクラスター」が作成されます。
元のクラスター: そのまま残ります（調査や比較に使用可能）。 新しいクラスター: 指定した時刻の状態で新規作成されます。
※ 新しいクラスターが作成されるためエンドポイントが変更されます。
3.2. なぜ「新しいクラスター」なのか？
これには以下のメリットがあります。
安全性の確保: 復元操作に失敗しても、現在の本番環境（既存クラスター）に影響を与えません。
3.3. 注意すべき点
PITRは、RPO（Recovery Point Objective）の達成には非常に有効なバックアップ方法ですが、PITR はクラスターを別途新規で作成した上で復元するため、復元にはある程度の時間がかかることが想定されます。復旧にかかる時間は事前にテストしておき、RPO,RTOが達成できることを確認すべきです。
REL09-BP04 データの定期的な復旧を行ってバックアップの完全性とプロセスを確認する
4. PITR を有効化する設定
PITR を有効化するためには、BackupRetentionPeriod(バックアップ保持期間) を１以上で設定する必要があります。
こちらを設定すると自動バックアップ（スナップショット）が有効になるのと同時に継続的バックアップも有効になります。
4.1. RDS設定用CloudFormationのサンプル
TestDB:
Type: "AWS::RDS::DBInstance"
Properties:
DBInstanceIdentifier: test-db
Engine: postgres
EngineVersion: 17.6
DBInstanceClass: db.t3.micro
AllocatedStorage: 30
StorageType: gp2
DBName: eksworkdb
MasterUsername: user
MasterUserPassword: password
DBSubnetGroupName: !Ref EksWorkDBSubnetGroup
PubliclyAccessible: false
MultiAZ: false
PreferredBackupWindow: 18:00-18:30
PreferredMaintenanceWindow: sat:19:00-sat:19:30
AutoMinorVersionUpgrade: false
DBParameterGroupName: !Ref EksWorkDBParameterGroup
VPCSecurityGroups:
- !Ref RdsSecurityGroup
CopyTagsToSnapshot: true
# この設定が必要（１以上に設定することで有効化する）
BackupRetentionPeriod: 7
DeletionProtection: false
5. PITRの実施
5.1. データ登録
eksworkdb=> \dt
List of relations
Schema | Name | Type | Owner
--------+-------+-------+------------
public | users | table | eksdbadmin
(1 row)
eksworkdb=> select * from users;
user_id | username | email | status | created_at
---------+----------+--------------------+--------+----------------------------
1 | tanaka | tanaka@example.com | active | 2026-01-07 14:16:21.683738
2 | suzuki | suzuki@example.com | active | 2026-01-07 14:16:21.683738
3 | sato | sato@example.com | active | 2026-01-07 14:16:21.683738
5.2. データ削除
eksworkdb=> TRUNCATE TABLE users RESTART IDENTITY;
TRUNCATE TABLE
eksworkdb=> select * from users;
user_id | username | email | status | created_at
---------+----------+-------+--------+------------
(0 rows)
5.3 復元
AWSマネジメントコンソール＞RDS＞アクション＞特定時点への復元を押下する。
復元時点を指定する。
DBインスタンス識別子を入力する。
特定時点への復元ボタンを押下する。
復元完了したこと確認する。
5.4 復元の確認
eksworkdb=> \dt
List of relations
Schema | Name | Type | Owner
--------+-------+-------+------------
public | users | table | eksdbadmin
(1 row)
eksworkdb=> select * from users;
user_id | username | email | status | created_at
---------+----------+--------------------+--------+----------------------------
1 | tanaka | tanaka@example.com | active | 2026-01-07 14:16:21.683738
2 | suzuki | suzuki@example.com | active | 2026-01-07 14:16:21.683738
3 | sato | sato@example.com | active | 2026-01-07 14:16:21.683738
(3 rows)
eksworkdb=>
6. 復元時に気をつけること
PITRは非常に強力な機能ですが、実際の障害復旧（リカバリ）においては、単にボタンを押すだけでは終わりません。
6.1. エンドポイントの変更と切り替え作業
PITRを実行すると、新しいDBクラスターとして作成されるため、接続先のエンドポイント（DNS名）が変わります。
接続情報の更新: アプリケーションが参照している環境変数や設定ファイル（AWS Lambdaの環境変数や、Parameter Store）を新しいエンドポイントに書き換える必要があります。
影響範囲: 接続先を切り替えるまで、アプリケーションは古い（データが消えた状態の）DBを参照し、続けてしまう点に注意してください。
7. まとめ
Amazon Aurora の PITR（ポイントインタイムリカバリ）を調査して分かった重要なポイントは、以下の通りです。
- 既存のクラスターを過去の状態に戻すのではなく、別個の新しいクラスターとして復元される。
- 新規作成されるため、復元後はアプリケーション側の接続先設定（DNS名など）の更新が必須。
- データの復元自体には時間がかかるため、RTO（目標復旧時間）を達成できるか事前にテストしておくことが重要。
「いざという時に過去に戻せる」という安心感は大きいですが、いざその時が来た際に**「接続先が変わることを忘れていた！」**となると復旧が遅れてしまいます。
PITRの仕組みを正しく理解し、復旧手順（ドキュメントの整備や切り替えの自動化）までを含めて準備しておくことが、真に「止まらないシステム」への第一歩だと感じました。