# The backup exists. Can the application use it?

A restore is complete when a verified business workflow works again. Recovering files alone does not restore identity, configuration or external dependencies.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Start with the service people need

Imagine restoring a job-management database successfully, then discovering that attached photos use an unavailable encryption key and the login callback still points at the failed environment. The database restore worked. The service remains unusable.

Define recovery around a concrete task, such as an authorised employee opening a job, reading its attachments and recording an update. That task reveals which components must return together.

List the data stores, object storage, secrets, identity configuration and integration state involved. Some may have different backup schedules or recovery mechanisms. A single backup-success dashboard does not establish a consistent recovery point across them.

## Choose the failure the drill represents

Accidental deletion, database corruption and loss of an entire environment require different recovery paths. State the scenario before selecting a backup.

For corruption discovered late, the newest backup may already contain the bad state. The drill needs a way to identify a clean recovery point and understand the work created after it.

For an environment loss, test access to backups and keys without relying on that environment. A recovery procedure that requires the failed system to authenticate or decrypt is incomplete.

### Restore data into a working service

The drill connects a selected recovery point to an isolated application, then verifies a business workflow before accepting the result.

1. **Recovery point**: Select usable data for the stated failure
2. **Dependencies**: Provide keys, identity, configuration and storage
3. **Isolated application**: Start a compatible release with controlled integrations
4. **Business verification**: Read, change and reconcile a known record

## Keep the restored copy isolated

A drill can restore real data and runnable jobs. Prevent it from sending customer emails, charging accounts or consuming production queues unless a specific controlled test requires that action.

Isolation must include outbound effects, not only an obscure hostname. Restored configuration can still contain live integration destinations.

Protect access to the copied data and record its cleanup plan. A temporary test environment can expose the same sensitive information as production.

## Measure the whole recovery interval

Record time to obtain authority, provision resources, restore data, configure the application and verify the workflow. The storage restore duration is one component of the total.

Also establish the actual recovered data boundary. A configured backup frequency is not proof of how much recent work survives. Use known records or transaction evidence to identify what the restored service contains.

## Turn the result into a maintained procedure

Save the runbook version, recovery point, application version, timings and unresolved gaps. Assign owners to fixes such as missing keys or incompatible configuration.

Repeat after meaningful changes to the service and its dependencies. The useful outcome is evidence that today's application can recover through the documented path, rather than confidence inherited from a successful drill performed before the system changed.

## Sources

- [AWS Backup: restore testing](https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing.html)
- [PostgreSQL: continuous archiving and recovery](https://www.postgresql.org/docs/17/continuous-archiving.html)