バックアップとリストア：RPO・RTOの基本とSupabaseで設定すべき最低限

「バックアップが必要だとわかっていたのに、やっていなかった」——これはスタートアップのエンジニアから最もよく聞く後悔の一つだ。バックアップは「問題が起きなければ永遠に不要」だが、「問題が起きたときに初めて設定しておけばよかったと気づく」ものだ。

本番環境でDBが壊れた、誰かが間違ってデータを削除した、そういうとき「どこまで戻れるか」と「何時間で復旧できるか」を事前に決めていた組織と、そうでない組織では対応コストがまったく違う。

RPOとRTOを具体的なシナリオで理解する

難しい言葉が並ぶが、シンプルな話だ。

シナリオ： 昨夜9時に、データベースのデータが壊れた。誰かがmigrationを誤って実行し、重要なテーブルのデータが消えた。エンジニアが気づいたのは翌朝9時だ。

RPO（Recovery Point Objective）：どの時点のデータまで戻ることを許容するか。

• RPOが8時間なら：昨夜1時のバックアップまで戻る = 8時間分のデータを失う
• RPOが30分なら：昨夜8時30分のバックアップまで戻る = 30分分のデータを失う
• RPOが0なら：データ損失ゼロ = リアルタイムレプリケーションが必要（コストが高い）

RTO（Recovery Time Objective）：障害を検知してから復旧完了までに何時間かけていいか。

• RTOが4時間なら：午後1時までに復旧できればいい
• RTOが1時間なら：午前10時までに復旧できればいい
• RTOが0なら：ダウンタイムなし = アクティブ・アクティブ構成が必要（コストが非常に高い）

MVPのスタートアップであれば、RPO 24時間（日次バックアップ）、RTO 4時間（半日以内に復旧）という設定が現実的な最低ラインだ。

なぜvibe codingのMVPはバックアップを設定しないのか

理由は単純だ。「今は誰も使っていないから」「後でやる」「Supabaseが自動でやってくれているはず」という思い込みだ。

特に最後の思い込みは注意が必要だ。SupabaseのフリープランではPI(ポイントインタイム)リカバリは使えない。日次バックアップも自動で有効になっているわけではなく、Proプランでないと使えないケースがある。「クラウドを使っているから大丈夫」は間違いだ。

実際にあったケースでは、フリープランのSupabaseプロジェクトをそのまま本番公開し、3ヶ月後に開発メンバーがSQLを誤操作してユーザーデータが消えた。バックアップはなく、復旧不能だった。そのとき初めて「バックアップの設定をしておけばよかった」と気づいた。

SupabaseのバックアップをDashboardで確認する方法

フリープランの場合

Supabaseダッシュボードで Database > Backups を開く。フリープランでは自動バックアップは利用できない。手動でCSV/JSONエクスポートするか、Pro以上へのアップグレードが必要だ。

フリープランで最低限できることは：

# Supabase CLIを使った手動ダンプ（定期実行を設定する）
supabase db dump --db-url postgresql://... > backup_$(date +%Y%m%d).sql

これをGitHub ActionsやCronで週1回実行してS3やGCSに保存するだけでも、ゼロよりはるかにましだ。

ProプランのPoint-in-time Recovery（PITR）

Supabase Proプラン（$25/月〜）では、PITRが使える。PITRとは「特定の時刻のDBの状態に戻せる」機能だ。

有効化手順：

1. Supabaseダッシュボードにログイン
2. 対象プロジェクトを選択
3. Database > Backups を開く
4. 「Point-in-time recovery」のスイッチをオンにする
5. 保持期間を設定する（7日、14日、30日から選択）

PITRを有効にすると、例えば「昨夜8時32分の状態に戻す」という粒度でリストアできる。これによりRPOが数分単位まで下がる。

バックアップの確認と手動リストア

Database > Backups 画面では：

• 最新のバックアップ時刻
• 過去のバックアップ一覧
• 各バックアップのリストアボタン

が確認できる。「バックアップはある」だけではなく、リストアボタンを一度押してみて動作を確認しておくことが重要だ（後述）。

Supabase以外のバックアップ：必要か？

スタートアップのMVPであれば、Supabaseのバックアップだけで十分なケースがほとんどだ。ただし、以下の場合は追加バックアップを検討する。

追加バックアップを検討すべきケース：

• ユーザーの決済情報・個人情報・医療情報など、復旧不能なデータを扱う場合
• 法規制でデータ保持期間が決まっている業種（医療、金融など）
• データベース以外のファイル（ユーザーがアップロードした画像等）がある場合

追加バックアップの選択肢：

画像などのファイルはSupabase StorageのバックアップがProプランで自動化されるが、Cloudinaryなど別サービスを使っている場合は個別に確認が必要だ。

リストアのテストをやっている人は少ない

「バックアップはある」という組織でも、実際にリストアのテストをやったことがある組織は非常に少ない。バックアップがあっても、いざというときにリストアできなければ意味がない。

簡単なリストアテスト手順：

1. Supabaseのバックアップ画面を開く
2. 最新のバックアップを確認する
3. ステージング環境（または新規プロジェクト）にリストアを実行する
4. データが正しく復元されているか確認する
5. アプリケーションが正常に動作するか確認する

このテストを四半期に1回行うだけで、「バックアップはあるのにリストアできなかった」という事態を防げる。特に新しい機能追加でテーブル構造を変えたあとは、既存のバックアップからのリストアが正しく動くかを確認するべきだ。

スタートアップMVPの現実的な最低ライン

理想と現実のギャップを埋めるために、最低限これだけやっておく、という基準を示す。

最低限：

• Supabase Proプランへの移行（日次バックアップ + PITR有効化）
• バックアップの保持期間：7日間
• リストア手順のドキュメント化（箇条書き3行でもいい）
• 週1回の手動CSVエクスポートをGitHub Actionsで自動化

ユーザーデータが重要なサービス（ECサイト、課金あり等）なら追加で：

• PITR有効化（Supabase Proで設定）
• バックアップの保持期間：30日間
• 四半期に1回のリストアテスト

バックアップは「設定したら終わり」ではない。定期的に「最新のバックアップが正常に取得されているか」「リストアは機能するか」を確認する運用がセットになって初めて機能する仕組みだ。

データを失うのは一瞬だ。バックアップがない状態で本番公開するのは、安全網なしで綱渡りをするのと変わらない。最低限の設定を今すぐやることをすすめる。