Point-in-time recovery

Every paid Postgres database can be restored to any minute of the last 7 days. The restore goes into a new database, so the one your app is using is never changed.

3 min read

What it covers

Backups give you a recovery point every hour. If someone runs a bad DELETE at 14:37, the newest backup may be from 14:00, and 37 minutes of orders or sign-ups would be gone.

Point-in-time recovery closes that gap. Naijacloud keeps a continuous record of every change to your database, so you can ask for it as it was at 14:36.

Paid Postgres databases: any minute of the last 7 days. The newest minute you can pick is about two minutes ago.
Free size: not included. Move the database to a paid size and it is set up within the hour.
Caches (Redis and Valkey) are not covered.

The record is stored encrypted (AES-256), like your backups.

Setup

There is nothing to switch on. Paid Postgres databases are set up for it automatically. Setting it up restarts the database once, which takes a few seconds. Your app reconnects as it would after any restart.

You can restore to any minute after setup finished. A database set up today cannot go back to yesterday.

Restoring to a minute

Open the database's Settings tab and find Point-in-time recovery, under Backups.
Pick the time, in UTC. The field only allows the minutes you can restore to.
Optionally, name the new database. By default it is called after the original and the time you picked.
Choose Restore to this time and confirm.

Only workspace owners and admins can restore.

The restore runs in the background, and its progress is shown under the form. How long it takes depends on the database's size and how much changed since its last daily copy. When it finishes, Open the new database takes you to it.

Times are in UTC. Lagos is UTC+1, so 15:36 in Lagos is 14:36 UTC.

The new database

The restore creates a new database next to the original:

the same size and region,
the same database name, user and password, so your app's queries and credentials work unchanged,
its own connection string, because it is a different server.

The original keeps running and is not changed. That lets you look at the restored copy first and copy back only the rows you lost, or switch your app over to it completely.

To switch over, change your app's DATABASE_URL to the new database's connection string and redeploy. Delete the old database once you no longer need it.

The new database is billed like any database of its size, from the moment it is created until you delete it. Delete it when you are done.

The new database is set up for point-in-time recovery too, so it can be restored to a minute in the same way.

Related: Backups & restore, Connecting.