A backup is only part of a recovery plan

A notification saying that a backup completed is reassuring. It does not, by itself, show that the application can be restored or that staff can resume their work.

Ask for a recovery exercise before the system becomes something the business cannot comfortably operate without.

Define recovery in business terms

Start with the task that must return: viewing current orders, dispatching goods, or accessing a booking schedule. Identify who will confirm that the recovered system is usable.

AWS's backup recovery guidance recommends periodic restoration tests that verify data integrity and recovery objectives. It distinguishes the recovery time objective, or RTO, from the recovery point objective, or RPO: the intended time to recover and the acceptable point to which data can be recovered, respectively.

Discuss these as business requirements with your technical team. How long can the task be unavailable? How much recent work could the business tolerate having to reconstruct? The answers should reflect the service, not an arbitrary promise copied from another project.

Decide what the exercise includes

Ask for an inventory of the elements needed to run the application: data, uploaded files, configuration, access, and external dependencies. Establish which are backed up and which have another recovery method.

Choose a suitable isolated environment with the appropriate protection for the restored data. The exercise should not overwrite the live service or send real customer notifications.

Agree which external effects must be disabled or simulated. For an illustrative ordering application, a restored record should not accidentally trigger another payment, shipment, or confirmation message.

Verify a business task, not just a running database

Have a responsible operator inspect representative records and perform an agreed safe task in the restored environment.

Useful questions include:

• Can the expected users access the recovered application?
• Are important records and their associated files available?
• Do relationships between records still make sense?
• Is the most recent recoverable point consistent with the agreed objective?
• Can the team identify work that would need reconciliation?

Record the actual procedure and observations. A database that starts successfully is one part of the result, not the whole acceptance condition.

Measure the whole exercise

Capture the time spent obtaining access, locating the recovery material, restoring it, configuring the application, and verifying the business task. Separate the tool's processing time from the team's total effort.

If the process relies on an individual remembering an undocumented step, add that step to the runbook and test the revised instructions. Include the information a substitute operator would need, while keeping secrets in an appropriate access system rather than in a public document.

Report failures and limitations plainly. An exercise that exposes a missing dependency is useful when it leads to an assigned correction.

Plan reconciliation and repeat testing

In a real recovery, other systems may have continued processing. Ask how the team would compare the recovered records with those external systems before resuming automated work.

Decide who can authorize return to service and who communicates with staff. Include any temporary operating process in the plan.

Schedule future exercises within the maintenance arrangement, and repeat relevant checks after material changes. The exercise should demonstrate that you can recover the work. Record what you restored and how you verified it.