本文へ移動
runlot

バックアップとリストア

データベースは使用中、約 1 分に 1 回コミットログとして自動的にバックアップされ、暗号化されたコピーが別のリージョンに保管されます。1 つのコマンドで任意のバックアップ、任意のコミット、任意の時刻に復元できます。

特に有効化する必要はありません。データベースを持つすべてのプロジェクトは、使用中は約 1 分に 1 回、そして停止する直前にもう 1 回バックアップされます。

runlot pg generations
  epoch  seq  createdAt             type   size     object   kind       final
* 3      17   2026-09-05T14:00:00Z  delta  41.2 MiB 96.0 KiB scheduled  -
  3      16   2026-09-05T13:00:00Z  delta  41.2 MiB 1.3 MiB  scheduled  -
  3      15   2026-09-05T12:00:00Z  full   40.9 MiB 173 MiB  scheduled  -
  …

size はそのバックアップから復元したときのデータベースの大きさ、object はそのバックアップ自体が保存する容量です。

フルバックアップとコミットログ

データベースの最初のバックアップはフルバックアップです。それ以降のバックアップはすべてコミットログで、直前のバックアップ以降に行われたすべてのコミットを順番に保持し、そのバックアップにリンクします。データベースの使用中は約 1 分に 1 回バックアップが取得され、プロジェクトが停止・再デプロイ・終了する直前にもう 1 回取得されます。前回のフルバックアップ以降のログの合計がデータベースのサイズに達すると、新しいフルバックアップが取得されます。

バックアップは直前のバックアップとの間のコミットを順番に保持するため、バックアップが取得された瞬間だけでなく、そのコミットの 1 つ 1 つが復元ポイントです。commits 列に各バックアップが保持する範囲が表示されます。

これを管理する必要はありません。runlot pg restore はバックアップ、コミット、時刻のいずれかを受け取り、サービスがフルバックアップと選択した地点までのログを順に流し込みます。ログはそれ以前のログを必要とするため、保持ポリシーは保持されるバックアップが依存するバックアップをすべて残します — 一覧は保持期間より数件多くなることがあります。

復元や削除の直前に取得されるバックアップ(pre-restore、pre-delete)は常にフルバックアップなので、単体で成り立ちます。

保持期間

プラン保持されるバックアップ保持期間
無料—7 日
プロ—30 日

バックアップは頻繁に取得され、それぞれ変更分のみを含むため、保持ウィンドウ内の任意の時点に復元できます。

最新のバックアップは、経過時間や数に関係なく削除されません。 長期間アイドル状態のプロジェクトでも、最後のバックアップは保持されます。

データが変更されていない場合

前回のバックアップから変更がない場合、新しいバックアップは作成されません。それでもバックアップ確認の記録は残ります。これにより、使われていないプロジェクトが同一データの複製を大量に保存することを防ぎます。

リクエストがなかったために自動的に停止されたプロジェクトであっても、バックアップの時刻には一時的に起動し、バックアップを取ってから再び停止されます。停止中であってもバックアップがスキップされることはありません。

暗号化と保管場所

各バックアップはプロジェクトごとの鍵で暗号化されます。その鍵はさらにマスターキーで暗号化され、暗号化されたバックアップデータは別のリージョンのオブジェクトストレージに保管されます。

リストア

runlot pg restore 3/15                    # the end of backup 3/15
runlot pg restore latest                  # the end of the newest backup
runlot pg restore txn:8812                # exactly commit 8812, wherever it is in the list
runlot pg restore 2026-09-12T05:32:07Z    # the last commit at or before that time

リストアを開始する前に、まず現在のデータのバックアップが取得されます。そのため、誤ったバックアップをリストアしてしまっても、リストア前の状態に戻すことができます。

The current data is backed up first, then restored from backup 3/15. Anything written after that point is lost.
Type the project name to continue: my-app

リストアするには、プロジェクト名を正確に入力する必要があります。元に戻すのが難しい操作について、単純な yes/no の確認は受け付けません。このコマンドには admin ロールが必要です。

latest を指定した場合でも、CLI はまずバックアップの一覧を表示し、実際にリストアする対象を示します。そのため、画面で確認した内容とリストアされる内容が食い違うことはありません。

リストア直後について

リストアを実行すると、プロジェクトが停止し、選択したバックアップから再度起動します。起動後最大 3 秒間は、データベースへのリクエストが 57P03 エラーになることがあります。詳細は再アクティベーションウィンドウを参照してください。

リストアできる時点について

保持期間内の任意のコミットです。無料プランは 7 日、Pro は 30 日です。バックアップはコミットの順序付きログなので、txn:<commit> はバックアップの途中にあるコミットでも正確にそのコミットに着地します。時刻を指定すると、その時刻以前の最後のコミットに着地します。分解能はバックアップ 1 回分 — データベースの使用中は約 1 分 — です。

提供されないのは、最新のバックアップ以降の 1 分ほどです。最後のバックアップが送られた後のコミットはプロジェクトのノードにしかなく、次のバックアップの前にそのノードが故障すると失われます。プロジェクトの停止中にはそのような窓はありません — 停止時に最後のバックアップが取得されているためです。

診断エクスポートはバックアップではありません

runlot pg export

このコマンドが生成するファイルはバックアップとして管理されず、リストアには使用できません。サポートへの問い合わせで現在の状態を共有する際に使用してください。

このページの目次