Backups and recovery Explained and Compared

How do you recover an accidentally changed booking?

Find the last version that was right and inspect it in a separate copy. You can recover the value you need while keeping bookings people made after the mistake.

What should you check when a booking disappears?

Look up the exact booking before restoring anything. An incorrect status can hide it from the normal list. Check when it changed and whether you need an older value, the whole record or its attachment.

A backup keeps a copy or history you can go back to. A restore loads what was saved into a destination. A daily snapshot gives you the state at one saved time. Point-in-time recovery uses retained changes to return to a selected time inside a window.

Write down when the record was last correct and the time zone. Check whether the backup was taken after the record existed and before the mistake. An earlier backup can be too old to help.

Why restore to a separate place first?

Inspect the older copy before replacing anything. An in-place restore can remove good changes made after the mistake, including records for other customers.

For practice, use a backup made with fictional data or one approved for test use after sensitive data is removed. Confirm the destination uses only test data, test sign-in and test file storage. Check the jobs, email and other actions it can run. Disable outgoing actions or point them only to verified test destinations before restoring or opening the copy. If you cannot confirm those boundaries, use the paper exercise.

A separate project can still start copied jobs. Supabase’s physical restore to a new project can run copied database jobs as soon as it completes. It does not offer a pause before they start. If you cannot rule out those effects, stay on paper or use a logical restore path that lets you inspect and remove those actions before they can run. For a real recovery using customer data, limit access to authorized people and verify that copied records and outgoing connections are contained before restoring.

Compare tools

Scroll the table sideways to read every column.

Compare what you can recover from each backup
Tool	What point can you recover?How far back the service can recover data and which copies it keeps.	Where does the restore go?What the operation replaces and where you can inspect it separately.	What else needs recovery?Whether files or sign-in records come back with the database.	What changes the cost or limit?What the plan, host or retained data can add to the bill.
Supabase	Daily backups cover 7 days on Pro, 14 on Team and up to 30 on Enterprise. Point-in-time recovery is a paid add-on.	A restore in place replaces the database. A paid project with physical backups can restore to a new project.	A new-project restore copies sign-in records. Copy original files, storage settings and sign-in settings separately.	Free projects need their own exports. The add-on price depends on the window. A new project adds hosting costs.
Neon	Up to 6 hours on Free with a 1 GB history cap, 7 days on Launch and 30 on Scale. Check the set window.	Create a branch from an earlier point to inspect it. An in-place restore rewinds every database on the selected root branch.	The rewind includes Managed Better Auth records when used. Object Storage and Functions are outside the rewind.	Paid plans meter retained change history by GB-month separately from ordinary database storage.
PostgreSQL	A dump saves one database at a point in time. Point-in-time recovery needs a base backup and continuous archived changes.	Load a dump into an empty test database. For point-in-time recovery, use a separate installation and its matching files.	A dump can include account tables stored in that database. Recover external sign-in, uploaded files and installation-wide roles and tablespaces separately.	Your host or team sets the backup schedule and retention. Budget for storing backups and running a restore.
Convex	Manual snapshots are kept for 7 days. Professional offers daily and weekly backups. Check which scheduled copies are available.	A same-team dashboard restore can replace data in a standard test deployment. Dedicated destinations cannot take restores from other deployments. Ask Convex support to restore a dedicated physical backup.	Include files when taking a backup. Restore adds missing files and keeps existing ones. Keep code and sign-in settings separately.	Free/Starter keeps up to two backups per deployment. Creating and storing backups can use billable bandwidth and storage.
SimpleBackups	Recover from a retained PostgreSQL dump. Storage Sync restore uses the latest successful replica.	Restore a downloaded dump to a disposable database. Use an empty path to inspect a file replica.	Plan for uploads, external sign-in and any encryption key separately.	Check configured jobs, frequency, database size, storage and transfer.
SnapShooter	Choose a native disk image or a saved file/database backup job. The schedule and retention decide which copies remain.	Use an isolated snapshot restore with no live service access or visitor traffic from first boot. Restore database files to a disposable database.	A disk image covers that disk. Separate databases, upload buckets and app connections need their own plan.	Check backup resources, schedule and included storage, plus provider snapshot or object storage charges.
Databasus	Use a retained dump or a supported PostgreSQL 17+ physical backup with retained change logs for recovery between copies.	Restore to an isolated compatible database. A verification agent can use a temporary database for its checks.	Plan separately for uploaded files, app connections and the Databasus settings and key.	Apache-2.0 software. Supply a host, storage, verification capacity and maintenance.
Portabase	Choose a completed scheduled or manual copy for a supported source. A PostgreSQL dump represents the selected database at backup time.	The selected target can be overwritten. Use a fresh compatible database to inspect the copy.	Check roles and access separately from a single database dump. Files have their own supported restore modes.	Apache-2.0 software. Budget for running the dashboard and agent, retained copies and storage transfer.
pgBackRest	Use a valid backup set plus the continuous archived PostgreSQL change log for a time target.	Restore database files into a separate empty target for a rehearsal. The operation can replace or remove destination files.	Check out-of-directory configuration, uploads and external sign-in separately.	MIT software. Retained backup sets and logs, repository storage, network and test restore capacity drive cost.
Barman	Use a base backup completed before the target and archived changes through that time. A recovery window differs from keeping a fixed backup count.	Recover to a separate directory or server. Check where separate data folders will go and how the target gets archived logs.	Keep copies and checks for external uploads and sign-in. Verify permissions on the recovered copy.	GPL software. Budget for a backup host, backup and log retention, and space for the test restore.

Can you recover one fictional booking and keep the newer ones?

Use paper. At 10:00, booking J-17 is confirmed and has a sample receipt. At 10:20, someone accidentally marks it canceled. At 10:25, J-18 is booked correctly. Your task is to recover the right status without losing J-18.

Pick the recovery point
Draw two possible copies saved at 10:15 and 10:30 in the same time zone. The 10:15 copy has J-17 in the correct state. The 10:30 copy already includes the mistake.
Draw the two destinations
Keep the current saved records for canceled J-17 and confirmed J-18. On another page, draw what the 10:15 restore would show. J-18 should be absent in that copy because it was made later.
Check the attachment and access
Mark whether the 10:15 copy includes the original sample receipt or just its name. On paper, check that J-17’s fictional owner could open it and a second test account could not.
Choose what to bring back
Mark only the verified status from the older copy for review. Keep J-18 and check whether J-17 has changed again before applying anything in a real recovery. Write down what the current list should show afterward.

What should you write down after a practice restore?

Record which copy worked, what it left out and how long it took to make the booking usable again. Someone else should be able to repeat the recovery with those notes.

What to keep in a recovery note
Decision	Write down
Which copy to use	When the copy was saved, its time zone and where to find it. Keep a separately stored export if you need recovery after losing access to the service.
Which parts had to be rebuilt	Name anything you restored separately, such as the original file, storage permissions or sign-in settings. Record the exact test account checks that passed.
When the app was ready	Write down the time from starting the restore to finishing the record, file and access checks. The recovery window measures how far back you can go. This measures how long your team took.