The database has been restored, the application starts and its health check passes. Is the incident over? Consider a repair centre. Staff can see service tickets again, but some equipment already returned to customers is still listed as under repair. Documents sent out during the missing period are absent. Continuing without reconciliation risks making decisions against the wrong history.
Disaster recovery should return the company to agreed operations with data it understands. Database startup is only one milestone. The rest is easily left out when infrastructure availability is the sole measure of success.
Two objectives that need business owners
RTO is the target limit between service disruption and restoration of the agreed service. Detection, the recovery decision, environment preparation, restoring data and required checks all consume that time. Starting the stopwatch only when an engineer launches a script produces a flattering number while ignoring the time the business has already lost.
RPO describes the tolerated time gap between the incident and the recovery point the organisation needs to be able to reach. It expresses how much recent history may be lost or reconstructed separately. A backup schedule does not demonstrate compliance: the newest copy may be inaccessible, damaged or already contain corrupted records.
Apply these objectives to a particular workflow. Historical repair archives and handing equipment back to customers may have different requirements. Calling everything critical obscures recovery priorities and turns secondary dependencies into mandatory blockers.
Google Cloud's DR planning guide connects recovery objectives with strategy. It does not establish a universal acceptable outage: that decision remains with the business.
A failed server and damaged data need different responses
A healthy replica may help when a machine fails. If the application wrote incorrect records, the replica may have copied them. Switching machines then restores access to the same bad state.
Logical corruption calls for a known-good point, suitable backups and, where supported, the logs needed for point-in-time recovery. The newest possible point is not automatically the correct one. Establish when the damage began first.
Valid work may have happened alongside the bad writes. Rewinding the whole database also removes that work. The repair centre must identify repairs completed, equipment collected and documents sent after the selected recovery point. Reconciliation with external systems and original records belongs in the plan, rather than becoming an unexplained backlog for support.
What belongs in a recoverable set?
A database archive alone may be insufficient. The company also needs files, a compatible application version, configuration, encryption-key availability and an authorised way to gain access. A surviving encrypted backup is not usable data if its key was lost with the original environment.
Backup protection should be separated from ordinary application privileges. A compromised production identity should not automatically be able to delete every recovery point. Access separation, protected retention and storage controls need to match the platform and the threat being addressed.
Restoring into an isolated environment is useful, provided its external effects are controlled. A restored worker must not resend real documents, trigger payments or deliver old jobs to partners. Starting a copy successfully can create a fresh incident if the test is allowed to act on the outside world.
Restore useful work in a deliberate order
Read-only repair history might return before new changes are permitted. Receiving enquiries might resume while equipment handover remains unavailable. That limited mode should be explicit and agreed beforehand. Employees must not mistake a temporary interface for a fully recovered service.
Validate relationships, permissions, documents and representative operations after restoration. Matching row counts is not enough. Ticket totals can agree while customer links or attachments are missing.
Queues require reconciliation too. A message may survive even though its external action already completed and the local completion marker was lost. Before restarting consumers at full speed, establish how duplicates will be identified and which effects need verification with the recipient.
A procedure someone else can execute
Name the person authorised to start recovery, a substitute and a communication path for when normal tools are unavailable. Instructions and approved emergency access must not exist only inside the system being restored. Urgency does not remove the need to control privileges and record actions.
During a drill, have someone other than the author follow the procedure. This exposes unwritten steps: locating a compatible release, replacing a certificate or finding the person qualified to validate the result. Capturing those gaps matters more than declaring success after the author quietly rescued the exercise.
Azure's DR planning guidance treats ownership, communication and sequencing as part of recovery. For a small product, a short executable procedure may be enough; a large document is not the objective.
The evidence a drill should leave
Record when work was disrupted, when recovery was authorised, when data became available and when the workflow owner verified the agreed operations. Record the recovered point, discrepancies and manual reconstruction separately.
If the time target was met only because the team secretly pre-provisioned resources absent from the plan, qualify the result. If service returned but redundancy did not, restoring protection is still outstanding work. The next failure would otherwise arrive with no reserve left.
Start acceptance with one important workflow and carry it through. An employee should complete real work safely and account for operations caught in the gap, not merely recognise the interface. Only then is it useful to compare backup restoration, standby environments and multiple active sites. AWS Well-Architected describes those recovery strategies.