What Does Your Web App Database Backup Actually Restore?

Before you pay for more database backups, ask your developer to restore a copy of your app and show you one full workflow. Can a staff member sign in, open an order, download its invoice and check whether it was paid? If the answer stops at “the database came back”, you have verified only part of the recovery.

Suppose an online store loses the afternoon's order records after a bad deployment. The payment provider may still show successful charges. The shipping system may already have booked collections. Restoring the database to the morning can give you a working app that disagrees with both. A buyer needs to know who will put those records back in agreement, and how long that will take.

How much can you afford to lose?

Start with two limits. The recovery point objective, or RPO, is the acceptable amount of recent data loss measured in time. The recovery time objective, or RTO, is how long you can tolerate the service being unavailable or degraded. They are targets. The age of the newest usable restore point and the time taken in a drill are measurements you compare with those targets.

For example, imagine a bookings app has a 30-minute data-loss target and a two-hour recovery target. A daily snapshot at 02:00 cannot by itself meet the first target when damage happens at 15:00. A restore point at 14:50 is recent enough for an incident at 15:00. It still fails the second target if the team needs three hours to reconnect the app, verify bookings and reopen it safely. Neither target is a vendor promise.

Use a different target if the consequences are different. A product catalogue that changes weekly and an admissions system collecting documents and fees should not inherit the same settings because they use the same database host. Confirm whether another system records the writes independently and what the team can reconstruct without guessing.

What can daily backups and point-in-time recovery restore?

Daily backups give you specific recovery points. Point-in-time recovery, or PITR, lets you choose a time inside the available recovery window rather than choosing only between daily copies. In PostgreSQL, continuous archiving and recovery can use a base backup and replay the intervening write-ahead log up to a chosen point. A logical export such as a PostgreSQL dump is useful for portability but does not provide that replay history.

For a quiet corruption, the oldest usable point can matter more than the newest. If a bad import changed invoice balances last Tuesday and you notice on Monday, a restore window that starts on Thursday cannot get you back to the moment before the import. Write down both the oldest and latest available points from your own dashboard. Check how the newest point moves during ordinary operation instead of treating the timestamp selector as a guarantee that every recent write is recoverable.

Hosting setup	What to verify before relying on it
Supabase database backups	Check whether your project has daily backups or PITR and what restore procedure applies. Supabase explicitly excludes files stored through its Storage API from database backups.
Neon history window	Check the project's configured history window and whether it covers the timestamp you need. Branch history is useful for a restore inside the project; plan separately for loss of the project itself.
Amazon RDS point-in-time restore	Check the instance's latest restorable time. For a DB instance, this restore creates a new instance without changing the source. Include reconnecting clients and verifying performance in your drill.

There is no need to change host just because a feature has a different name. Ask what your configuration did in the last test. A screenshot of the backup plan is useful supporting evidence; a dated record showing recovered rows and reopened workflows is stronger.

What will a database restore leave behind?

Uploaded files. An invoice row can point at an object that was deleted from storage. Putting the row back does not recreate the PDF. Verify how the objects themselves are backed up or versioned, how far back those versions go, and whether the recovered app can retrieve the correct copy. Repeat the check with a missing or replaced file, not just one that still exists in the current bucket.

Anything outside the database. A mail queue, search index, deployment secret or scheduled task may belong to a different system. Some can be rebuilt from the database. Others need their own recovery copy or documented configuration. Your handover should identify the owner and the recovery step for each dependency. It should not contain passwords or production tokens in a shared document.

Work done by other services. A payment system, courier or CRM may have processed an operation that your restored database no longer remembers. Keep the external references you need for reconciliation. Before you reopen the app, find payments with no restored order, shipments for cancelled orders and queued messages that could be delivered twice. Use a record of the original action to decide what to repair; do not re-run all jobs from the restored date.

Loss of the project or account. Ask which recovery copies you could still reach if you lost access to the production project. Supabase says project deletion removes associated backups. AWS distinguishes retained automated backups from a final snapshot when deleting an RDS instance. Neon's backup guide describes options alongside branch history, including exports. Check where an independent copy lives, who can read it and whether its retention meets the need. Encrypt recovery copies and restrict access to them; a copy of production data needs the same care as production.

What should a restore drill prove before launch?

Ask for a drill during acceptance of a custom web application. Start with a known scenario, such as a bad import at 14:15 or a missing invoice attachment. Write down the desired recovery point with the timezone. Give one person authority to call the restore, and have another verify what the recovered app actually does. The person running it should be able to find the steps even when the developer who set it up is away.

1. Prepare a separate target. Use the provider's documented route to restore into an isolated environment, or an export into a separate test database where appropriate. Do not rehearse by restoring over live data. Use synthetic or suitably protected data and keep the test environment private.
2. Prevent side effects. Use test credentials; disable production email, payments, webhooks and scheduled jobs before starting the restored application. Prove the job cannot charge a customer or send an old reminder. Confirm you can still view the relevant records without calling a live provider.
3. Check records and permissions. Compare a known order, a recent successful payment reference and a released invoice with the expected state at the chosen time. Open the actual invoice file. Verify that a staff user sees only the records they are allowed to see. If you changed CRM systems, the CRM migration checklist gives examples of relationships and ownership that are easy to miss.
4. Time the workflow, not just the database command. Record when the database was reachable, when staff could finish the critical tasks, and what delayed recovery in between. Check whether performance is acceptable under representative use. Compare the result with the business target; do not assume the same time applies to an incident with more data or less staff.
5. Write the decision down. Keep a short record of the tested date, the restore point, the latest verified business record, the person who can approve reopening and any missing step. Repeat the drill after a significant change to the database, storage or integration setup, and at a cadence that suits the risk.

For a small order system, the evidence might fit on one page: a timestamp for the restored database, the three order references checked, proof that an attached invoice opened, and an unresolved step for reconciling the courier. That unresolved step is precisely what you want to find in a drill. Assign it to a person and test it next time.

When should you avoid a more expensive backup plan?

Do not buy a longer retention window simply because it is available. Buy enough time to notice and investigate the kinds of corruption that could matter to you. If the drill shows the recovery point is already good enough but the app takes too long to rebuild, put the next budget into deployment documentation, access and verification. A finer recovery point will not fix a two-hour wait for the only person with the right permissions.

Do not assume every incident needs a full rewind. A full restore to before the error also leaves out legitimate writes made afterwards. If only one import went wrong, a recovered copy may let you identify affected records before deciding how to repair production. Get agreement on how to handle new orders or edits during the incident, and reconcile them before moving traffic to a restored system.

If the app mostly displays information owned by another service, protect the original data and prove you can rebuild the app from it. If you use a hosted CRM you cannot restore yourself, start with the provider's recovery and export options instead of buying database features you will never use.

If you are reviewing a build or a hosting handover, tell us which workflow has to come back first. That is a better starting point for a recovery plan than a list of backup products.