A failed server, a corrupted database and an inaccessible data centre need different responses. High availability covers defined component failures. Backup provides an earlier data state. Disaster recovery organises service restoration. What matters is which work must continue and when your applications need to be usable again.
high availability
Continue operations through defined failures
Backup
Restore data from a backup
Disaster Recovery
Restart services in an agreed sequence
Two targets. Two different questions.
How much data can you afford to lose?
From the last usable data state to the failureWhen must the application be usable again?
From failure to a working applicationIllustrative values, not a recommendation or service commitment. Both targets must be agreed with the business. The diagram is not to scale.
Which failure do you need to handle?
| Situation | Possible response | Key prerequisite |
|---|---|---|
| A host fails | Restart VMs on the remaining hosts | HA is correctly configured, data is accessible and sufficient spare capacity is available. |
| A database is corrupted | Restore a suitable backup | The data state and application consistency have been checked. |
| The storage system fails | Independent redundancy or recovery | A second controller alone does not protect against every system-wide failure. |
| A site is unavailable | Start prepared recovery operations | Capacity, access, networking and core services are ready. |
| Administrative access is compromised | Contain the incident and restore in a controlled manner | Backups and emergency access are protected. Cleanup and approval are coordinated with the security-incident team. |
Set downtime and data-loss targets separately
For example, order processing must be available again within four hours, with no more than 30 minutes of data lost. Four hours is the recovery time objective (RTO); 30 minutes is the recovery point objective (RPO). These figures are illustrative, not recommendations for your environment. Agree targets with the business and check whether your technology meets them. Include core services, application startup and functional checks in the elapsed time. Replication can propagate corrupted data, so it does not replace backup.
Account for recovery dependencies
A running VM is not yet a recovered application. Identity services, DNS, networking, databases and external connections must become available in the right order. A site outage may require a different response from a security incident.
- Separate backups sufficiently from the failure and attack scenarios.
- Keep the capacity, access and keys needed for recovery available.
- Define responsibility and approval even if normal communication channels fail.
Judge tests by the actual outcome
Do not just check whether a backup can be read. Ask the business team to test a relevant function in the restored application. Record elapsed time, the data state used, deviations and outstanding actions. One successful test demonstrates only the scenario tested, not overall disaster readiness.
Questions to resolve
- Record the application and its business and technical owners.
- List required core services, interfaces and recovery access.
- Agree recovery time and tolerable data loss.
- Document the date, scenario, measured duration and data state of the most recent test.
- Have the business team check functionality and assign outstanding actions.
MCE Bank
At MCE Bank, off-site backups and regularly documented recovery tests complement the redundant infrastructure. The case study describes the architecture and ongoing operations.
View the project