A dashboard says your database was backed up last night. That is reassuring. It does not yet tell you whether you could recover the working product if the app, its files, or the account running it became unavailable.
The question to ask is practical: has someone restored the system into a separate environment and shown that its important customer journeys still work?
A database is only part of the product
Imagine a hypothetical client portal with signed-in users, uploaded contracts, and project records. The database backup contains the project records and references to the contracts. If the uploaded files are missing, those references point to documents you can no longer open.
This is a real category of limitation, not a criticism of backups. For example, Supabase's backup documentation states that database backups do not include objects stored through its Storage API. The right recovery plan depends on what your provider actually includes.
List the pieces your app relies on: database, uploaded files, source code, deployment configuration, domain management, scheduled jobs, authentication, and third-party services. Sensitive credentials need controlled recovery arrangements, not a spreadsheet passed around the team.
Decide how much loss and downtime you can tolerate
“We need backups” is not a complete requirement. Ask how much recent work the business could afford to lose and how long customers could reasonably wait for recovery.
For a hypothetical tool used once a week, yesterday's records might be sufficient. For a product recording paid orders all day, losing today's activity may be unacceptable. These decisions determine whether the backup frequency and recovery approach match the business.
Also check who can access backups when the primary account is unavailable, how long they are retained, and what happens if the project itself is deleted. A backup controlled through the same compromised account may not provide the separation you expect.
Practice recovery without affecting customers
Have an engineer restore a backup into an isolated environment. Disable outgoing email, payment actions, and scheduled integrations there so a rehearsal cannot contact customers or repeat business operations.
The recovery check should demonstrate more than a successful database import:
- The correct application version can read the restored data.
- A test user can sign in and open the expected records.
- Uploaded files are present and access restrictions still work.
- Background work can resume without replaying completed actions blindly.
- The team knows what recent changes are missing and how to reconcile them.
Record the time taken, missing dependencies, and manual steps. Give another authorized person enough instructions to repeat the process.
Restoring old data changes the present
A recovery can bring back old payment states, deleted memberships, or work that was already completed in another service. You need a reconciliation plan, not an assumption that every system will travel back to the same moment.
Similarly, reverting application code does not automatically reverse database changes. Compatibility and the consequences of losing newer records need assessment before a live restore.
Five prompts to use with your AI coding assistant
Before you begin: Use the same project conversation for all five prompts. Inspect first, approve the plan yourself, and never test against live customer data or secrets.
These prompts assume your assistant can inspect the relevant project. Ask it to say clearly if it cannot. Use the prompts one at a time, reviewing each response before moving to the next step.
1. Map
Inventory all components required to restore the service: databases, uploads, code, configuration, scheduled jobs, external dependencies, and securely managed keys. Identify current backup coverage.
2. Audit
Review backup schedules, retention, restore permissions, compatibility, and any existing recovery tests. Separate backed-up components from components proven restorable.
3. Plan
Propose a documented recovery sequence and isolated test environment. Ask me to specify acceptable downtime and data loss; do not invent these business requirements.
4. Challenge
Walk through failure scenarios, missing credentials, incompatible database versions, and external integrations. Design a synthetic-data recovery drill that cannot affect live customers.
5. Implement
After approval, configure or test only authorized recovery components in isolation. Record restored components, measured time, data checks, and unresolved risks; do not touch production recovery points.
If your only evidence is a green backup indicator, request a recovery rehearsal. DitchNow can help founders establish production reliability and a usable technical handover. Book a call to discuss the parts of your app you could not afford to lose.
About DitchNow
DitchNow is based in Haarlem, Netherlands, and helps founders and teams fix and extend software and put AI to work. Meet DitchNow.