How to use SimpleBackups: first database backup and first test restore

What you need before the first SimpleBackups backup

To use SimpleBackups you create one backup job, let it run, then restore the file somewhere safe to prove it works. These steps follow the official SimpleBackups documentation as read on 3 October 2026. This site has not run them hands-on. You need:

• A SimpleBackups account. The free Basic plan allows one backup job, databases up to 1 GB and a daily schedule. A larger database needs Lite ($49 per month, up to 5 GB) or Plus ($99, up to 250 GB).
• A database user with read access. For PostgreSQL the docs ask for CONNECT on the database and SELECT on all tables and sequences in each schema.
• A storage destination: your own bucket, or the SimpleStorage quota included in the plan.
• A network path. For a managed database behind a firewall, allow the SimpleBackups IP addresses shown when you toggle the firewall option.

Create the first database backup

For a managed database such as Amazon RDS, Supabase or DigitalOcean, the docs describe the serverless route:

1. Open Create Backup. Under Server, select Serverless backup worker and click Enable if it is not yet on.
2. Under Database, choose the engine and enter host, port, user, password and database name.
3. Choose the storage destination.
4. Set the schedule and the retention count. Daily with retention 7 keeps a week of copies.
5. Optionally paste an RSA public key to encrypt the backup. This cannot be changed after the first run.
6. Name the backup and click Create Backup.
7. Trigger a run by hand, then open the Logs tab and confirm the file size looks right for your database.

If the database runs on a server you control, connect that server first. SimpleBackups gives you a one-line command to run over SSH, or an agent to install when SSH is not an option. Then pick the server under Own Server in the same form. The dump runs on your machine and uploads straight to your storage. Choosing a backup route explains the trade-off.

Run the first test restore into a scratch database

SimpleBackups does not restore databases for you. Its docs give this procedure for PostgreSQL:

1. Open the backup, go to the Logs tab and click the info icon next to the run you want.
2. Generate a signed download link and copy it.
3. On a test machine, download the file and decompress it. If you encrypted the backup, decrypt it first with your private key.
4. Create an empty database: createdb restore_test
5. Optionally list what the archive contains: pg_restore --list postgresql-backup.pgsql
6. Restore a custom-format dump: pg_restore --single-transaction --no-owner -d restore_test postgresql-backup.pgsql
7. A plain-text dump (a .sql file) is loaded with psql instead of pg_restore.

The PostgreSQL manual says --single-transaction wraps the restore so it either completes fully or changes nothing, and --no-owner skips commands that set object ownership, which lets any user run the restore. SimpleBackups uses custom format when its quick export option is selected, and plain text otherwise. PostgreSQL dump formats explains the difference.

A worked example with real settings

A team has a 3 GB PostgreSQL database on a managed host and is on Lite. It creates one serverless backup with two schedules: Daily (03:00 UTC) with retention 14, and Monthly (the 1st at 01:30 UTC) with retention 12. The destination is the team's own bucket. Failure alerts go to Slack, which Lite allows. After the first run, an engineer downloads the file to a staging server, runs the commands above into restore_test, counts rows in the three largest tables, and writes down how long the restore took. That time is the team's real recovery time for this database. The acceptance checks list what else to verify.

The mistake to avoid: restoring over the live database

The SimpleBackups restore page warns that a restore replaces the data in the target database. The safe habit is to restore into a new, empty database on a separate machine, as in the steps above, and only then decide whether to switch over. Restoring to an isolated target covers how to set one up.

Two smaller traps come from the docs. New backups alert on failure only, so a quiet inbox is the expected state and you should still look at the Logs tab. And a backup that exceeds a plan limit is locked and does not run until you change it or upgrade.