アプリのデータベースをバックアップする方法（実際に復元できる状態にする）

アプリのデータベースをバックアップするには、定期的にファイルへ書き出し（Postgresの場合は標準ツールのpg_dumpを使用）、そのコピーをデータベースとは別の場所に保管し、空のデータベースへ定期的に復元して正しく動作することを確認します。危険を伴う変更を行う直前には、追加でバックアップを取ってください。GitHubリポジトリやエクスポートしたコードのバックアップには、データは含まれません。

このガイドは、データを失う心配をなくしたい小規模アプリの運営者向けです。AIで作られたアプリの多くはPostgresを使っているため、例にはPostgresを使用していますが、考え方はどのデータベースにも当てはまります。

バックアップが対象とすべきもの

アプリはデータベースだけで成り立っているわけではありません。それぞれのバックアップがどの部分を守るのかを把握しておきましょう。

再作成できないのはデータです。コードは書き直せますし、設定も入力し直せます。しかし顧客の注文は元に戻せません。

ステップ1：どれだけのデータを失えるかを決める

バックアップ計画は、次の2つの質問で決まります。

• 直近のデータをどれだけ失っても構わないか？ 1日に1回バックアップしていて、夕方にデータベースが壊れた場合、その日の変更は失われます。趣味のアプリなら問題ないかもしれませんが、注文を受け付けているアプリでは許容できない可能性があります。
• 復元の間、アプリはどれだけ停止していられるか？ 小規模なデータベースなら数分で復元できますが、大規模なデータベースではずっと時間がかかることがあります。必要になる前に、その時間を把握しておきましょう。

多くの小規模アプリでは、毎日の自動バックアップに加え、危険な変更の前に手動バックアップを取るのが妥当な出発点です。お金や健康に関わるデータを扱うアプリは、より頻繁なバックアップ、または任意の時点に復元できる（最後のバックアップ時点だけでなく、任意の瞬間に戻せる）ポイントインタイムリカバリ付きのマネージドデータベースを検討するべきです。

ステップ2：ホスティング先が既に何をしているか確認する

マネージドデータベースのプロバイダーの多くは、自動でバックアップを取得しています。次の点を確認しましょう。

• ご利用のプランでバックアップは有効になっているか？ 実行頻度はどのくらいか？
• バックアップはどのくらいの期間保持されるか？
• 任意の時点に復元できるか、それとも日次のスナップショットにしか戻せないか？
• バックアップをダウンロードできるか、それともプロバイダーのシステム内でしか復元できないか？

プロバイダーのバックアップは便利ですが、データベースと同じ「アカウント」という単一障害点を共有しています。アカウントが解約されたり、停止されたり、プロジェクトが削除されたりすると、バックアップも一緒に失われるおそれがあります。そのため、自分でもコピーを持っておくことが重要です。

ステップ3：pg_dumpでダンプを作成する

pg_dumpはPostgresのデータベースをファイルに書き出します。一貫したスナップショットを読み取るため、作業中もアプリを稼働させたままにできます。

アプリがすでに環境変数に持っている接続文字列を使った、典型的なコマンドは次のとおりです。

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

オプションの意味は次のとおりです。

• --format=customは、pg_restoreで読み込める圧縮ファイルを書き出します。後から個別のテーブルだけを復元することもできます。読める.sqlファイルにしたい場合は--format=plainを使ってください。
• --no-ownerは所有者に関するコマンドを除外します。別のデータベースへ復元するのが簡単になります。
• ファイル名の日付で、バックアップを区別できます。

pg_dumpのバージョンは、データベースのPostgresバージョン以上にしてください。古いpg_dumpでは実行を拒否されることがあります。

AIでアプリを作っていて、コマンドラインを触りたくない場合は、次のように頼むこともできます。

pg_dumpを使い、カスタム形式でアプリのデータベースのバックアップを作成してください。ファイル名には今日の日付を入れてください。接続文字列やシークレットは表示しないでください。完了したら、ファイル名とサイズを教えてください。

ステップ4：自動化する

手動でのバックアップは忘れられがちです。ご利用の環境で可能な方法で自動化しましょう。

• データベースプロバイダーの定期バックアップ（提供されている場合）
• スケジュールジョブ：サーバーやCIサービス上でpg_dumpを実行し、ファイルをストレージにアップロードする
• ホスト型のバックアップサービス：データベースに接続して取得する

どの方法を選ぶにしても、失敗したときに通知が届くようにしてください。バックアップジョブが3か月間ひっそりと失敗し続けていた、というのはよくある最悪のケースです。

ステップ5：別の場所にもコピーを保管する

一般に3-2-1ルールと呼ばれる目安があります。データのコピーを3つ持ち、2種類の異なるストレージに保存し、そのうち1つはオフサイト（別の場所）に置くというものです。小規模アプリでの実践的な方法は次のとおりです。

• ライブのデータベース
• プロバイダー自身の自動バックアップ
• 別アカウントのオブジェクトストレージバケットなど、別のストレージに保管する自分のダンプ

ほかにも次の点を守ってください。

• アクセスを制限する。 バックアップにはすべてのユーザーのデータが入っています。本番データベースと同じように扱いましょう。
• 保持ポリシーを決める。 例えば、日次バックアップは2週間、月次バックアップは1年保管する、といった具合です。古いバックアップは意図的に削除し、個人データは利用者からの要求に応じて削除しなければならない場合がある点も忘れないでください。
• バックアップをGitにコミットしない。 リポジトリ内のダンプは、いつ情報漏えいが起きてもおかしくない状態です。

ステップ6：復元をテストする

バックアップの価値は、直近に成功した復元のテストで決まります。少なくとも数か月に1回、そしてバックアップの仕組みを変更したあとには必ず行ってください。

1. 新しく空のデータベースを作成する。テストのために本番データベースへ上書き復元してはいけません。
2. 最新のバックアップをそのデータベースに復元する。

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

プレーンな.sqlファイルの場合は、代わりにpsql "$TEST_DATABASE_URL" -f backup.sqlを使います。

1. すべてのテーブルが存在すること、行数を本番データベースと比較すること、最近のレコードをいくつか確認する。
2. 可能であれば、アプリのコピーをそのデータベースに接続してログインしてみる。
3. 復元にかかった時間を記録する。それが実際の復旧時間です。

ステップ7：危険な変更の前にバックアップする

次の作業の直前には、新しいバックアップを取ってください。

• 列を削除したり名前を変えたりするデータベースマイグレーションの実行
• 大量データのインポート
• AIエージェントによるデータモデルへの大きな変更の実行
• 古いレコードの削除

AIで作ったアプリでは、機能追加の一環としてエージェントがテーブル構造を変更することがあります。チェックポイントやバージョン管理はコードを元に戻せますが、削除された行は復活させられません。大きな変更の前に30秒かけてバックアップを取るのは、低コストの保険です。

よくある間違い

• Gitやコードのエクスポートをバックアップだと思い込む。 あるのはコードであり、データではありません。
• 復元を一度もテストしない。 多くのバックアップは、必要になったときに初めて中身が空だったり、一部しかなかったり、読み込めなかったりすることがわかります。
• データベースと同じアカウントにバックアップを保管する。 1つのアカウントが乗っ取られたり解約されたりすると、両方を失います。
• アップロードされたファイルを忘れる。 データベースに保存されているのはファイルのパスだけで、画像そのものはストレージにあります。
• バックアップスクリプトにシークレットを残す。 接続文字列はスクリプトの本文ではなく、環境変数から読み込んでください。APIキーを安全に管理する方法も参照してください。

バックアップとMythex

Mythexのプロジェクトには専用のPostgresデータベースを持たせることができ、その接続情報はワークスペースと公開されたアプリに自動的に設定されます。Mythexのドキュメントにはデータベースのバックアップや復元機能についての説明はありません。そのため、自分で計画を立ててください。エージェントにダンプの作成を依頼し、ダウンロードして安全な場所に保管しましょう。特に大きな変更の前には欠かせません。プロジェクトのエクスポート（Proプラン）にはコードが含まれますが、シークレットとnode_modulesは除外されます。データベースの行は含まれません。詳しくは、ドキュメントのデータベースとデータの所有権をご覧ください。データベースそのものについては、Postgresとはを参照してください。

バックアップのチェックリスト

• 失ってもよいデータ量と、停止しても許容できる時間を決めた
• データベースホストが提供する自動バックアップの内容を確認した
• 自分のダンプが定期実行され、失敗時に通知が届く
• データベースとは別の場所に、アクセス制限をかけてコピーを保管している
• 保持ポリシーを文書化した
• データベースと同様に、アップロードされたファイルもバックアップしている
• 空のデータベースへの復元をテストし、行数を確認した
• 危険な変更の前には毎回バックアップを取る

よくある質問