A backup is useful only if your organization can restore the right data and make the application work again. A disaster recovery strategy adds the people, infrastructure, dependencies and decisions needed to resume service after an outage, cyberattack or serious error.
The right approach depends on the business impact of disruption—not on choosing the most elaborate architecture. Start with critical applications, set measurable recovery targets and test whether the complete service can meet them.
Set recovery targets around business impact
Identify the applications that support essential transactions and the consequences of losing them. Include dependencies such as identity services, databases, payment providers, integrations and document storage. Agree on priorities with both business and technical owners.
For each application, define two objectives:
- Recovery time objective (RTO): the maximum acceptable time from interruption to service restoration.
- Recovery point objective (RPO): the maximum acceptable amount of data loss expressed as time.
For example, an application with a four-hour RTO and a one-hour RPO aims to resume service within four hours while losing no more than one hour of changes. These are targets, not guarantees: backup frequency alone does not prove the RPO will be met. The AWS guidance on business continuity explains how business impact informs both objectives.
Protect what is needed to rebuild
Inventory more than the production database. Recovery may also require uploaded files, application code, infrastructure definitions, configuration, certificates, encryption keys and records of external dependencies. Keep sensitive recovery materials protected, and ensure authorized responders can access them even if the primary identity system is unavailable.
Choose backup frequency and retention to cover both short-term mistakes and problems discovered later. Replication supports availability, but it can also propagate unwanted changes; retain recoverable historical copies separately. The CISA #StopRansomware Guide recommends offline, encrypted backups and regular tests of their availability and integrity.
Limit who can change or delete backups, separate backup administration from everyday production access where feasible, and monitor failed jobs. Immutable storage can add protection against changes during a defined retention period, but it does not replace an offline copy, secure key management or a restore test.
Check cloud and software-as-a-service responsibilities
Do not assume a provider’s availability measures give you the historical recovery points or restore scope your business needs. Review each service’s retention, export and restore capabilities, access requirements, geographic location and contractual responsibilities. For example, Microsoft distinguishes Microsoft 365 disaster recovery copies from historical backups; other products have their own terms and capabilities.
Choose a recovery architecture you can operate
The AWS Well-Architected Framework describes several patterns. Their trade-offs also help frame decisions outside AWS:
- Backup and restore: rebuild infrastructure and restore data when needed. This is generally simpler and less expensive to maintain, but recovery may take longer.
- Pilot light: keep core recovery components and replicated data ready, then start or deploy remaining resources during recovery.
- Warm standby: run a reduced-capacity copy of the service that can be scaled up. It can shorten recovery time but requires more continuously operating resources.
- Active/active: serve traffic from multiple environments. This can improve availability but adds cost and complexity, including data consistency and failover design.
None of these patterns guarantees a particular RTO or RPO. Compare the total cost of infrastructure, storage, transfers, licensing, operational support and testing with the impact of downtime. Consider the failure scenario too: a second environment in the same region may not protect against a region-wide disruption.
Test the service, not just the backup job
Document a runbook with incident contacts, decision authority, recovery steps and a communication plan. In a safe test environment, restore a representative application and its dependencies, verify data integrity, sign in, and complete a meaningful business transaction. Measure elapsed time from the simulated interruption to usable service, and compare the restored data’s recovery point with the RPO.
Run exercises regularly and after significant architecture changes. Include scenarios such as a corrupted database, inaccessible identity provider or compromised administrator account. Record gaps, assign owners and deadlines, then retest. Before returning production traffic after a security incident, assess whether the environment and restored data are trustworthy; coordinate recovery with the incident response team.
What to agree with a delivery partner
A useful engagement should produce a prioritized application inventory, agreed RTOs and RPOs, an architecture decision, a recovery runbook and evidence from a restore exercise. Agree who owns backups, credentials, monitoring, incident decisions, test execution and ongoing updates. Ask how the partner will hand over documentation and how access can be retained if the engagement ends.
For international organizations, also review data location, supplier dependencies and applicable contractual or regulatory requirements with the appropriate advisers. Altweeb’s software development and technology consulting services provide a relevant context for discussing application dependencies, delivery choices and coordination with an organization’s existing infrastructure and security providers. The scope and responsibilities should be agreed for each engagement.
Conclusion
Start with one critical application: define acceptable downtime and data loss, protect everything required to rebuild it, and run a measured recovery exercise. Use the results to improve the plan before extending it to the rest of the portfolio.
To explore this further, see Technology and digital growth, brought into one clear view..
Add your perspective