はじめに
現在、未経験からWeb系エンジニアへの転職を目指して学習しており、
個人開発アプリを Render 上で本番公開しています。
その中で、バックアップの重要性を実感したので整理してみました。
Render で PostgreSQL を使って本番アプリを運用していると、次のような場面に遭遇します。
- 本番 PostgreSQL のデータを修正する必要がある
- migration を当てるのが不安
- 失敗したとき、どう戻せばいいかわからない
そこで、Render のDB管理画面を見ると、
- Point-in-Time Recovery
- Export（Logical Backup）
という 2 種類のバックアップ手段があり、「結局どれを使えばいいの？」となりがちです。
私自身、最初は
「そもそもバックアップって必要？」
「Renderでどうやったらバックアップできるんだろう？」
からはじまりました。
この記事では、
- Renderが提供するPostgreSQLのバックアップ方法
- それぞれの 違い
- 管理画面での具体的な操作手順
を整理します。
本記事では Free / Paid 両方のバックアップ機能を扱いますが、
Point-in-Time Recovery（PITR）は有料の Render Postgres で提供されています。
想定読者
- Render で PostgreSQLを使ったWebアプリを本番運用している人
- 「PostgreSQLのバックアップ方法がよくわからない」人
- migration やデータ修正を本番でやるのが怖い人
- バックアップ手順を忘れた未来の自分
結論
Render PostgreSQL のバックアップ方法は2種類あり、それぞれ用途が異なります。
| 用途 | 使う機能 |
|---|---|
| 作業前の保険 | Logical Backup（Export） |
| 本番事故の復旧 | Point-in-Time Recovery |
- Export は「この時点のスナップショットをファイルとして残す」
- PITR は「過去の任意時点へ復旧できる」
という違いです。
どちらか一方で十分ではありません。
Render PostgreSQLのバックアップ2種類について
下記画像が実際のRenderバックアップページです。
2種類のバックアップについて詳しく確認していきます。
1. Point-in-Time Recovery（PITR）
「時間を巻き戻す」ための復旧手段です。
Render は内部的にバックアップとログ（WAL）を保持していて、過去一定期間内の「ある時点の状態」を再現できます。
特徴（自分の理解）
- 任意の日時を指定して復元できる（保持期間内）
- 復旧時は、新しい PostgreSQL インスタンス（別DB）として作られる
“元DBをその場で巻き戻す” じゃないので、復旧操作そのものが 本番を直撃しにくい
元DBを残しておけるので、比較したり、必要なデータだけ救出する判断もできる
- アプリ側の接続先（DATABASE_URL 等）を切り替えるまでは本番影響が出にくい
注意点（ここは仕様として押さえたい）
- PITR は有料の Render Postgres に提供されている
-
保持期間は workspace plan により異なる
- Hobby: 3 days
- Professional 以上: 7 days :
👉 つまり PITR は「事故対応・災害復旧」寄りの機能というイメージです。
※PITR は「いま動いているDBをその場で巻き戻す」機能ではなく、
復元した別DBを作成し、あとから接続先を切り替える仕組み。
2. Logical Backup（Export / pg_dump）
「データをファイルとして保存する」バックアップです。
Render の管理画面から Export を実行すると、バックアップファイルが生成されます。
仕様としてのポイント
- Export は
.dir.tar.gz形式（directory-based format） - Render は Logical backup を 作成後 7日間保持
- 生成したファイルは 手元にダウンロードして長期保存できる
- ローカルや別の PostgreSQL に復元できる
※Free プランでは自動バックアップや PITR は利用できませんが、手動の Export（Logical Backup）は実行可能です。
👉 Logical Backup は「作業前バックアップ・持ち出し用」という使い方がしっくりきますね。
両者の違いを比較
両者の違いを表に整理しました。
| 観点 | PITR | Logical Backup（Export） |
|---|---|---|
| 思想 | 時間を戻す | スナップショットをファイル化 |
| 粒度 | 細かい（任意時点） | 作成時点のみ |
| 保存場所 | Render内部 | ファイル（ダウンロード可） |
| 復元先 | 新しいPostgreSQLインスタンス | 任意（ローカル/別DB） |
| 主用途 | 本番事故復旧 | 作業前の保険・持ち出し |
【操作手順】
そもそも、最初Renderの管理画面からどうやってバックアップページに移動できるかがわからないかたもいるのではないでしょうか？(過去の自分がそうでした)
なので、バックアップページに移動する手順からお伝えします。
1.Projectsを開く
まずは、バックアップとりたいアプリの「Project」を選択します。
2. サービスの「データベース名」を選択
自分がDB作成するときに決めた名前が表示されていると思うので、そこをクリックします。
3. 「Recovery」を選択
画面左側の「Recovery」を選択すると、バックアップページへ移動できます。
【操作手順】Logical Backup（Export）の取り方
つづいて、Logical Backup（Export）の操作手順です。
手順概要
- Export を作成する
- バックアップファイルをダウンロード
1. Export を作成する
- Create export をクリックします。
- エクスポートが完了するまで待つ
- 同時に複数のExportは実行できないので注意。
2. バックアップファイルをダウンロード
Create exportクリック後、しばらく待つとファイルが作成されるので、作成されたファイル名をクリックします。
-
.dir.tar.gzファイルが生成される - 作成日時付きのファイル名になる
- 必要であればローカルに保存
👉 本番 PostgreSQL を書き換える前に必ず実行するのがよいかと思います。
【操作手順】Point-in-Time Recovery の流れ
つづいて、Point-in-Time Recovery の操作手順です。
手順概要
- Restore database を開く
- 復元内容を指定する
- Start Recovery をクリック
1. Restore database を開く
Restore dataseをクリックすると、下記のような画面が表示されます。
⚠️ この時点ではまだ何も起きません。(不安になりますよね)
2. 復元内容を指定する
実行する場合は下記内容を指定します。
指定する内容：
- 新しい PostgreSQL の名前
- 復元したい日時（保持期間内）
- 既存設定をコピーするかどうか
3. Start Recovery を押すと起きること
Start Recoveryをクリックすると、
- 新しい PostgreSQL インスタンスが作成される
- 元の本番 DB は一切変更されない
- アプリはまだ元の DB を使い続ける
👉 アプリの接続先（DATABASE_URL など）を切り替えたタイミングで、実際の影響が出ます。
まとめ
最初、Rendedrでバックアップってそもそもどうやるの？からスタートしました。
そうすると、バックアップにも2つ種類があり、自分のアプリのDBを守るためのものなのでしっかりと確認しておくべきだと感じました。
バックアップは「取っただけ」で安心しがちですが、
- どのケースで PITR を使うか
- どのタイミングで Export を取るか
- 復元手順を把握しているか
まで整理しておくと、本番作業に対する心理的なハードルがかなり下がると感じました。
自分と同じように「怖い...」「よくわからない...」と思っている人の参考になればうれしいです。
参考（公式ドキュメント）
-
PostgreSQL Backups
Render が提供する PostgreSQL バックアップ機能の公式説明ページ
https://render.com/docs/postgresql-backups -
Point-in-Time Recovery 解説
PITR の仕組み（WAL・復元の考え方）を解説しているページ
https://render.com/blog/point-in-time-recovery -
PITR保持期間について
保持日数に関する記載（Hobby / Professional）
https://render.com/docs/postgresql-refresh -
Logical Export形式について
現在の export 形式が directory-based format であることの公式告知
https://render.com/changelog/render-postgres-logical-exports-now-use-a-directory-based-format