A green backup notification answers a narrow question: did a backup job report success? The buying question is different: can the people responsible restore the right information and make the application usable again?
Before accepting “backups included” in a maintenance proposal, ask for a recovery requirements sheet and a restore-drill report. The first defines what the business needs. The second records what actually happened under stated conditions. Neither is a guarantee that recovery will always work.
Use the checklist below to agree recovery targets, inventory what must be restored, plan an isolated drill and decide what evidence would justify reopening the application.
1. Define recovery targets: RPO, RTO and a usable workflow
NIST's contingency-planning guide provides background on determining contingency requirements and priorities.[1] For a small application, start with the work that must resume: finding an order, checking a booking or opening a customer's attachment. “The server is running” is not the same acceptance condition.
Use two separate planning targets:
- Recovery point objective (RPO): how far back in time the recovered data may be. Translate it into the amount of work the business would need to reconstruct.
- Recovery time objective (RTO): how long the agreed recovery process may take. Define when its clock starts and what business checks must pass before it stops.
These are negotiated targets, not measured performance or guarantees. Record detection and escalation time separately if they sit outside the chosen RTO clock; otherwise an apparently fast restore can hide a long interruption.
Ask the provider which backup method can support the targets, what it excludes and what evidence is still missing. A backup schedule alone does not prove the latest usable recovery point. A failed job, unreadable copy or later-discovered corruption can change the answer.
2. Inventory backup coverage beyond the database
Build a coverage list with a location, recovery method and owner for each item:
- Business records and their relationships.
- Uploaded documents and images, including the connection between file objects and database records.
- Application code, deployment configuration and required runtime versions.
- Database roles, permissions and required extensions.
- Access to encryption keys and a secure process for recovering or replacing secrets.
- External dependencies, such as identity, payment or messaging services, and a plan for unavailable services.
Do not paste credentials into the worksheet. Record the approved access procedure and responsible role instead.
PostgreSQL provides a useful database-specific warning: pg_dump covers a single database, not cluster-wide roles or tablespaces. The documentation also explains that required owners and grantees must already exist to recreate original ownership and permissions correctly.[3] A database export is therefore not, by itself, evidence that the whole application can be recovered.
For files stored separately, ask how the team will establish a compatible data-and-file recovery point. A record pointing to a missing attachment is not a complete business result. This is a requirement to design and test, not a claim that every backup product provides coordinated recovery.
3. Check who can damage or delete recovery copies
Could the same compromised application account delete live data and its recovery copies? Who can shorten retention, change the destination or disable the job? How would a responder obtain an intact copy if the normal administrator account were unavailable?
CISA's StopRansomware Guide recommends offline, encrypted backups of critical data and regular checks of backup availability and integrity in a disaster-recovery scenario.[2] Treat that as planning guidance, not certification of your application or provider.
Ask for documented separation between everyday application access and backup administration, a recoverable copy outside the failure scenario being tested, and a checked route to the necessary decryption material. Have the technical owner explain the limits of any offline, isolated or immutable-copy design. None of those labels alone proves that a restore will succeed.
Retention is also a business decision. Older copies may help when corruption is discovered late, but they retain information that may no longer be needed. Agree retention periods, access restrictions, expiry and a procedure for handling previously deleted records after a restore. Obtain appropriate privacy or legal advice where obligations are uncertain; “keep everything forever” is not a recovery policy.
4. Run an isolated restore drill, not a second production system
Ask the technical owner to restore into an approved isolated environment. Define its access and data-handling rules first. Use synthetic data where appropriate; if real backup data is necessary, authorize and protect that use explicitly.
Before starting the restored application, disable or isolate outbound email, payment actions, scheduled jobs, webhooks and other integrations. A drill should not contact customers, charge a payment method or overwrite live records. Do not assume a copied production configuration is safe.
Record:
- Backup identity, creation time and timezone.
- Application and database versions, restore tools and settings.
- Environment differences and the responsible operator.
- Start and finish timestamps for retrieval, restore, dependency repair and application checks.
- Errors, unresolved steps and any unmet recovery target.
PostgreSQL's SQL-dump documentation illustrates why error handling belongs in this report: by default, psql continues after an SQL error, and a restore can leave a partially restored database.[3] Ask the developer to select and verify failure behavior appropriate to the actual restore method. This article provides no production restore command and reports no executed database test.
5. Verify business integrity and permissions before reopening
A restore report needs more than “login worked.” Agree a small acceptance set:
- Open a known record and its related attachment.
- Compare an agreed sample or reconciliation total against a trusted reference at the selected recovery point.
- Exercise one representative workflow without triggering external effects.
- Confirm that an ordinary user cannot see another user's restricted records, where that boundary applies.
- Check that expected owners and administrators have the intended access, without granting broad privileges merely to make the drill pass.
- Record missing, duplicated, corrupted or unexpectedly accessible information.
Adapt these proposed checks with the developer and business owner. Passing a sample does not establish that every record is intact or that the application is secure. For a related planning aid, see the web application permissions checklist; the restore drill still needs its own access checks.
Example: the booking tool loads, but recovery fails
Imagine a small booking application whose database is restored successfully, but its confirmation attachments are absent and its ordinary staff role cannot open the booking list. The service starts, yet the business acceptance checks fail.
The useful result is a record of the missing file coverage and role-recreation step, with a named owner and a new test after correction—not a polished “success” label. The business owner also needs to know which bookings fall after the chosen recovery point and how they would be reconciled from an approved independent record.
This is a fictional planning example, not a CodeDrawn Digital client story, executed restore or promised outcome. No recovery duration or loss tolerance is implied.
Copy this recovery requirements worksheet
For each critical workflow, complete the following before accepting a recovery plan:
| Decision | Requirement to agree | Evidence to request |
|---|---|---|
| Business outcome | What must a user be able to do again? | Named acceptance checks and business sign-off owner |
| Data loss | Agreed RPO and how missing work is reconciled | Latest usable recovery point, timezone and known gap |
| Interruption | Agreed RTO, clock boundaries and escalation | Timestamped drill stages and unmet target explanation |
| Coverage | Records, files, roles, configuration and dependencies | Inventory, exclusions and recovery instructions |
| Access separation | Who may read, change or delete copies? | Reviewed access configuration and emergency-access procedure |
| Retention and privacy | Copy lifetime and post-restore deletion handling | Retention settings and approved reconciliation procedure |
| Isolation | What stops the drill affecting real services? | Environment controls, integration isolation and cleanup record |
| Integrity and permissions | What would make the restored result unacceptable? | Check results, errors and unresolved exceptions |
| Ownership | Who declares an incident, restores and authorizes reopening? | Primary and backup role, communication route and next update |
| Next drill | What changes require a retest, and when is it due? | Assigned corrective actions and the next agreed drill date |
Keep a failed drill useful. Name the owner of each correction, say what remains unproved and communicate the limitation through the agreed incident route. Do not silently reopen the application because infrastructure checks passed. The person authorized to resume business operations should see the data gap and outstanding risks.
Bring recovery requirements into the project brief
If you are commissioning a web application or planning maintenance, include the critical workflow, acceptable disruption, data-loss concern and current evidence gaps in the brief. Avoid sending backup files, secrets or customer records in an initial inquiry.
Explore CodeDrawn Digital's website and application services, or use the project brief helper to prepare a starting brief and request an email draft. The helper does not submit an inquiry or confirm app opening, sending or receipt. Recovery scope, responsibilities and targets still need explicit agreement; this article offers no backup guarantee or service-level commitment.
Sources
[1] https:
[2] https:
[3] https: