Backup and restore

There is nothing to turn on. Every project with a database is backed up about once a minute while it is in use, and once more right before it pauses.

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 is how large the database is when you restore that backup; object is how much that backup itself stores.

Full backups and commit logs

The first backup of a database is a full backup. Every backup after it is a commit log: it carries, in order, every commit made since the previous backup and links to it. While the database is in use a backup is taken about once a minute, and one more is taken right before the project pauses, is redeployed, or shuts down. A new full backup is taken when the logs since the last one add up to the size of the database.

Because a backup carries the commits between it and the previous one in order, every one of those commits is a restore point — not only the moment the backup was taken. The commits column shows the range each backup carries.

You do not manage this. runlot pg restore accepts a backup, a commit, or a time, and the service pours the full backup plus the logs up to the point you chose. Because a log needs the ones before it, retention keeps every backup a retained backup depends on — the list can hold a few more entries than the retention window says.

Backups taken right before a restore or a delete (pre-restore, pre-delete) are always full, so they stand on their own.

Retention

Backups are taken often and each carries only what changed, so a restore can land on any point within the retention window.

The most recent backup is never deleted, regardless of age or count. Even a project that has been idle for a long time keeps its last backup.

When the data has not changed

If nothing has changed since the previous backup, no new backup is created. A record of the backup check is still kept. This keeps unused projects from storing many copies of identical data.

Even a project that was stopped automatically because it had no requests is started briefly at backup time, backed up, and stopped again. Being stopped never means skipping a backup.

Encryption and storage location

Each backup is encrypted with a per-project key. That key is in turn encrypted with a master key, and the encrypted backup data is stored in object storage in another region.

Restoring

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

Before a restore begins, a backup of the current data is taken first. So even if you restore the wrong backup, you can get back to the state you were in before the restore.

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

To restore, you must type the project name exactly. We do not accept a simple yes/no confirmation for an action that is hard to undo. This command requires the admin role.

Even with latest, the CLI lists the backups first and shows you the one it will actually restore, so that what you saw on screen and what gets restored cannot diverge.

Right after a restore

A restore stops the project and starts it again from the backup you chose. For up to 3 seconds after it starts, database requests may get a 57P03 error. See the reactivation window for details.

Which points in time you can restore to

Any commit inside the retention window: seven days on the free plan, thirty on Pro. A backup is an ordered log of commits, so txn:<commit> lands on that exact commit even when it is in the middle of a backup. A time lands on the last commit at or before it, at the resolution of one backup — about a minute while the database is in use.

What is not offered is the minute or so after the newest backup: commits made since the last backup was shipped are on the project's node only, and are lost if that node fails before the next backup. While the project is paused there is no such window — the last backup was taken as it paused.

Diagnostic exports are not backups

runlot pg export

The file this command produces is not managed as a backup and cannot be used to restore. Use it to share your current state with a support request.