Three Recovery Sites — Complete Comparison
| Attribute | Hot Site | Warm Site | Cold Site |
|---|---|---|---|
| Hardware on-site | Full — all hardware installed, configured, and running | Partial — some hardware; additional hardware may need to be brought in | None — empty facility; all hardware must be transported or procured |
| Data on-site | Continuously replicated in real time or near real time — current | Partial — must restore from recent backup; some lag from primary | None — all data must be brought in or restored from off-site backups |
| Software/apps on-site | Fully installed and updated to match primary | Partially configured — final configuration required | None — all software must be installed after arrival |
| Recovery Time Objective (RTO) | Shortest — hours; failover is operational quickly | Moderate — hours to a day; requires final config and data restore | Longest — days to weeks; full setup from scratch |
| Recovery Point Objective (RPO) | Minimal — data loss measured in minutes (continuous replication) | Moderate — data loss depends on backup frequency (hours) | Highest — data loss up to last backup; can be significant |
| Cost | Highest — effectively two data centers operating simultaneously | Moderate — some infrastructure maintained without full duplication | Lowest — facility lease and basic utilities only |
| Hardware purchasing | Buy two of everything — hot site mirrors every primary purchase | Buy some equipment for the site; top up as needed during recovery | Buy nothing in advance; procure or transport during disaster |
| Best for | Organizations where any downtime is extremely costly; financial, healthcare, critical infrastructure | Most organizations — practical balance of cost and recovery capability | Organizations with tight budgets and high tolerance for long outages; rarely-activated DR |
| Exam trigger phrase | "Exact replica," "flip a switch," "real-time replication," "most expensive," "fastest failover" | "Middle ground," "some hardware," "partial data," "moderate cost" | "Empty building," "bring your own hardware," "bring your own data," "cheapest," "longest recovery" |
Server Clustering vs. Load Balancing — Key Differences
| Attribute | Server Clustering | Load Balancing |
|---|---|---|
| How servers relate | Nodes know about each other — cluster software coordinates them directly | Servers are independent and unaware of each other — only the load balancer knows all servers |
| Central coordinator | No single coordinator — cluster management distributed across nodes | Central load balancer device distributes all requests |
| User's view | One logical server — users address the cluster, not individual nodes | One address (the load balancer VIP) — users address the load balancer, which routes to backends |
| Operating system | All nodes typically run the same OS for compatibility | Backend servers can run different operating systems — load balancer is OS-agnostic |
| Data sharing | Shared storage — all nodes access the same storage system for consistent data | Each server may have its own storage; data consistency managed by the application layer |
| Failure handling | Cluster software detects node failure; redistributes workload across remaining nodes | Load balancer health checks detect failed backends; removes them from pool; redistributes traffic |
| Scalability | Add nodes to the cluster in real time to increase capacity | Add servers to the load balancer pool; they begin receiving traffic immediately |
| Common use case | Database servers, file servers, applications requiring tight consistency | Web servers, API servers, stateless application tiers |
Active/Active vs. Active/Passive — HA Architecture Models
| Attribute | Active/Active | Active/Passive (Active/Standby) |
|---|---|---|
| All components operating? | Yes — all nodes handle production traffic simultaneously | No — primary handles all traffic; secondary is idle standby |
| Load distribution | Load shared across all active components | All load on primary; secondary carries zero load until failover |
| Failover speed | Immediate — remaining nodes already active and absorb load instantly | Slight delay — standby must detect failure and activate before resuming service |
| Scalability benefit | Yes — adding active nodes increases total capacity | No — standby does not contribute to capacity |
| Resource efficiency | High — all components serve production traffic | Low — standby hardware powered and ready but producing nothing |
| Complexity | Higher — all nodes must handle full load simultaneously | Lower — simpler failover logic; standby only activates on failure |
| Exam context | "Provides scalability advantages" — exam specifically notes this for active/active | Traditional HA fallback; simpler but wastes standby capacity |
Resiliency Strategy Spectrum — Threat to Control Mapping
| Failure Scope | Example Threats | Resiliency Strategy | How It Helps |
|---|---|---|---|
| Component failure | Single server crashes, disk fails, NIC fails | High availability / clustering / load balancing | Other components already active absorb the load; no downtime |
| Application tier failure | Web server process crashes, database becomes unresponsive | Load balancing with health checks | Load balancer removes failed server; healthy servers continue |
| Facility-level failure | Data center power failure, fire, physical damage to building | Hot / warm / cold recovery site | Operations fail over to the recovery site in a different location |
| Regional disaster | Hurricane, major flood, earthquake, regional power grid failure | Geographic dispersion of recovery sites | Recovery site in a different region is unaffected by the same regional event |
| Platform-specific vulnerability | Critical zero-day in Windows kernel, Linux privilege escalation | Platform diversity | Other OS platforms unaffected; organization continues serving from non-vulnerable platforms |
| Cloud provider outage / breach | AWS regional outage, Azure security incident | Multi-cloud architecture | Workloads on other cloud providers continue unaffected |
| Complete technology unavailability | All systems down, no recovery site operational yet | COOP (manual procedures) | Non-technical fallback processes keep critical functions running without any technology |
Site Resiliency — Failover and Failback Lifecycle
NORMAL OPERATIONS
Primary data center running → Recovery site continuously synchronized (data, configs)
↓
DISASTER EVENT OCCURS
Primary site becomes unavailable (facility damage, power loss, natural disaster, etc.)
↓
DISASTER DECLARED
Management formally declares disaster — triggers recovery process
↓
FAILOVER TO RECOVERY SITE
Operations transferred to recovery site — DNS redirected, network paths updated
Business processes resume from recovery site infrastructure
Duration: hours, days, weeks depending on severity
↓
PRIMARY SITE RESTORED
Primary data center rebuilt, repaired, or replaced
↓
FAILBACK TO PRIMARY
Data synchronized back to primary — operations transferred back
Must be documented just as carefully as failover
↓
NORMAL OPERATIONS RESUME
Recovery site returns to standby/sync mode
Both failover (primary → recovery) and failback (recovery → primary) must be documented and tested. The failback is often overlooked in planning and is operationally complex — data written during disaster operations at the recovery site must be synchronized back to the primary before it can resume as the authoritative source.
COOP — When Technology Is Unavailable: Manual Alternatives
| Digital Process | COOP Manual Alternative | Resources Required in Advance |
|---|---|---|
| Electronic payment processing (POS system) | Manual transaction recording on paper forms with physical customer signatures | Paper transaction forms, carbon copy sets, pens, physical signature authorization process documented |
| Automated credit card approval via payment network | Phone call to card processor's manual authorization line for voice approval | Processor phone numbers, voice authorization process, authorization code recording forms |
| Electronic receipts from POS system | Paper receipts written out manually or from pre-printed receipt books | Pre-printed receipt books, carbon copies, pens on premises |
| Digital approval workflows (purchase orders, expense approvals) | Physical paper forms routed by hand for physical signatures | Paper forms, signing authority matrix, physical routing process documented |
| Electronic communication (email, messaging) | Phone calls, fax, physical couriers for urgent documents | Contact directory printed and distributed, fax machine, courier service contacts |
| Digital identity verification (badging system) | Visual ID check by security personnel, paper visitor log | Security staff on-site, printed employee ID cards, physical visitor log books |
| Electronic inventory management | Physical inventory counts, paper count sheets | Printed count sheets, physical count process, central paper log |