Cloud & Infrastructure
Updated
A successful backup job is only one component of recovery. A mission-critical workload also depends on identity, network paths, compute, configuration, keys, applications, vendor access, communications, and a tested order of restoration. Backup and disaster recovery architecture connects those components to the business process that must resume.
This guide focuses on the architecture and operating evidence an operations manager should require. It does not treat backup and disaster recovery as interchangeable, and it does not assume that purchasing a second tool creates a recoverable service.
Translate business impact into design inputs
Begin with the work people must perform, not a list of servers. For each critical workflow, identify the minimum service level needed during disruption, the maximum tolerable loss of recent data, the acceptable interruption, and the order in which dependencies must return. Technical teams often express the last two as a recovery point objective and recovery time objective, but leadership must approve what those targets mean for actual operations.
Do not turn an objective into a promise until the full path has been designed, funded, and exercised. A target that covers a database but ignores authentication, DNS, connectivity, application licensing, or a third-party interface is incomplete.
Map the complete recovery chain
| Architecture layer | Questions to resolve | Evidence operations should see |
|---|---|---|
| Business workflow | Which service must resume, at what minimum capacity, and in what order? | Approved impact analysis and restoration priorities |
| Data and configuration | Which files, databases, SaaS records, application settings, code, and keys are required? | Protected-data inventory and retention design |
| Identity and privilege | How will responders authenticate and gain controlled administrative access during an outage? | Emergency-access procedure and access review |
| Infrastructure | Where will compute, storage, network, DNS, and security services run during recovery? | Recovery topology, capacity assumptions, and build instructions |
| Applications and vendors | Which licenses, installers, support contacts, integrations, and vendor actions are required? | Dependency register, contracts, and escalation paths |
| Operations | Who declares an incident, restores each layer, validates data, and authorizes return to normal? | Runbook, responsibility matrix, and exercise records |
Separate availability, backup, and disaster recovery
Availability features can keep a service running through some component failures. Backups preserve recoverable versions of data or systems. Disaster recovery coordinates people and technology to restore an acceptable business service after a larger disruption. Each addresses different failure modes.
Replication can improve availability or recovery speed, but it can also copy corruption, deletion, or malicious change. A sound design therefore includes recoverable copies with protection appropriate to the threat model. CISA recommends offline, encrypted backups of critical data and regular tests of their availability and integrity in a disaster recovery scenario. Cloud designs should also account for customer responsibilities, deletion protection, versioning, and privileged access to backup systems.
Design for isolation and control-plane failure
Ask what happens if the production administrator account, primary directory, network, cloud tenant, or backup console is unavailable or compromised. Recovery copies should not depend entirely on the same identities and control plane as production. The exact design varies by platform, but the architecture review should address:
- separate and tightly controlled administrative paths for recovery systems;
- protected credentials, encryption keys, configuration exports, and infrastructure definitions;
- retention or immutability settings aligned to the incident scenarios being considered;
- an offline or otherwise isolated source of runbooks, contacts, licenses, and network diagrams;
- monitoring for failed jobs, unexpected deletion, policy change, and loss of protected coverage; and
- a documented method to establish a clean recovery environment rather than restoring into a still-compromised one.
Use scenario coverage, not a product inventory
Review the architecture against materially different incidents. A single-file deletion, failed update, ransomware event, lost facility, identity compromise, cloud-region disruption, and prolonged vendor outage do not use the same response path.
| Scenario | Capability to demonstrate | Validation question |
|---|---|---|
| Accidental change | Granular restore with known version history | Can the owner verify the restored record without overwriting valid newer work? |
| Ransomware or destructive access | Isolated, trusted copies and clean-room recovery | Can recovery proceed without relying on compromised production privilege? |
| Infrastructure loss | Alternate capacity, connectivity, configuration, and data | Can the complete priority workflow operate in the recovery location? |
| Identity outage | Controlled emergency access and identity restoration sequence | Can responders authenticate without creating an uncontrolled bypass? |
| Provider interruption | Vendor escalation, continuity procedure, and exit data | Which functions remain possible while the provider is unavailable? |
Test at four levels
- Copy verification: monitor job completion, coverage, retention, and integrity signals. A green job alone is not a business recovery test.
- Component restore: recover representative files, systems, databases, and configurations into a safe location and validate them.
- Workflow exercise: restore the dependencies needed for a real business transaction, including identity, application access, integration, and user validation.
- Coordinated incident exercise: rehearse decision authority, communications, vendor escalation, security investigation, recovery sequencing, and return to normal operation.
Keep the date, scenario, scope, participants, actual sequence, observed recovery points and times, validation results, exceptions, and assigned corrective work. Do not report that a plan is "tested" without stating what was actually exercised.
Make architecture ownership visible
The business owner approves service priorities and disruption tolerance. IT owns or coordinates the technical design and evidence. Security determines when recovery can safely begin after a suspected compromise. Vendors must have explicit responsibilities and escalation paths. Leadership accepts residual risk and funds gaps. One person may fill several roles in a small organization, but the decisions still need names and alternates.
Review the dependency map and protected-data scope after material system, identity, network, vendor, or retention changes. Review unresolved exercise findings until they close. A recovery architecture is a maintained operating system, not a diagram produced once for an audit.
Related recovery guides
- Clarify the roles of backup and disaster recovery.
- Build a cloud incident posture report for leadership.
- Exercise ransomware decisions with a practical tabletop playbook.
Primary sources
- NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems
- CISA #StopRansomware Guide
- CISA Cross-Sector Cybersecurity Performance Goals
- Microsoft Azure Well-Architected Framework: reliability
- HHS Healthcare and Public Health Cybersecurity Performance Goals
Suggested next step
Talk with Cloud Core MSP if you need to turn recovery objectives into a dependency map, protected-copy design, and exercise program for critical workloads.