gcloud sql clone point-in-time で本番DB復元の記録

やったこと

本番の Cloud SQL（PostgreSQL）を、任意の時点に復元できるか確認する訓練として、実際にクローンを作ってみました。

gcloud sql instances clone <元インスタンス> <クローン名> \
  --point-in-time=<10分前のUTC時刻>

結果だけ先に書くと、Cloud Audit Logs 上でクローン作成の開始から完了まで約10分でした（実測では08:27:02開始→08:36:51完了、UTC）。確認が終わったらすぐに削除したので、稼働していたのは実質30分程度、費用は数十円でした。

なぜ本番で試す必要があったか

このインスタンスは availability_type = "ZONAL" で動いています。

module "cloud_sql" {
  # ...
  availability_type = "ZONAL"
  tier               = "db-custom-1-3840"
  deletion_protection = true
  # ...
}

HA（高可用性）構成ではなく、コストを優先して ZONAL にしている分、障害時の可用性はバックアップと point-in-time recovery（PITR）で補うという設計です。補う側の手段が「手順としては存在するが、実際に動くか確認していない」状態だと、設計そのものが机上の話になります。訓練として実行し、記録を残しました。

復元先はプライベートIPのみ

クローンは元のインスタンスと同じ、プライベートIPのみのネットワーク設定（VPC Peering 経由の Private Services Access）で作られます。つまり、手元の端末から直接 psql で繋いで中身を見る、ということはできません。

中身を確認するには、次のどちらかが必要です。

• VPC 内で動く Cloud Run Job や VM から接続する
• 確認したいテーブルだけを export して取り出す

今回は後者で、gcloud sql export sql --table=<対象テーブル> を東京リージョンの一時バケット（公開防止つき）へ出し、対象テーブルの8行分を目視で確認しました。確認が終わったら一時バケットを削除し、インスタンス側は削除保護を外してクローンを削除しています。「復元できた」で終わらせず、復元したデータに実際にアクセスできる経路まで含めて初めて訓練が成立するという点は、やってみるまで実感が薄い部分でした。

PITR の制約

今回のインスタンス（10GB規模）では、PITR の保持期間は7日でした。保持期間を過ぎた時点はもう復元できません。「必要になったら使えばいい」ものではなく、保持期間内に一度動かして確認しておかないと、いざ必要になったときに手順が合っているかを試す機会そのものが失われます。

今回確かめたのは1テーブルの中身までで、全テーブルの整合性は未確認のまま残っています。

次にやること

この訓練記録を踏まえて、次は監査ログの整合性を検証する Job をクローン側に向けて実行する手順を整備する予定です。そこまでやって初めて、全テーブルの整合まで確かめたことになります。復元はできても、復元したデータが検証に使える状態かどうかはまだ別の確認になるためです。