DRI IT Disaster Recovery and Resilience 1 — Questions and Answers
Question 1: What is the difference between a 'warm site' and a 'hot site' in IT disaster recovery?
- A warm site uses older equipment; a hot site uses current-generation hardware
- A hot site is fully equipped and operational, ready for immediate failover; a warm site has equipment that must be configured and loaded before use (Correct answer)
- A warm site is located domestically; a hot site is located internationally
- A hot site is maintained by a vendor; a warm site is maintained internally
Correct answer: A hot site is fully equipped and operational, ready for immediate failover; a warm site has equipment that must be configured and loaded before use
A hot site is a fully equipped, live alternate facility that can be activated within minutes to hours with minimal configuration. A warm site has hardware and connectivity in place but requires configuration, software installation, and data loading before becoming operational—typically taking hours to days.
Recovery site options exist on a spectrum of readiness and cost. A cold site is essentially an empty facility with power and connectivity—organizations must procure and configure all equipment before it can be used (days to weeks to activate). A warm site has hardware, connectivity, and basic infrastructure in place but requires software installation, configuration, and recent data loading—typically 24-48 hours to activate. A hot site is fully configured and operational with current data replication, enabling activation within minutes to hours. Mobile recovery units, cloud-based recovery, and reciprocal agreements are additional alternatives. Site selection is driven by the BIA-derived RTO: applications with RTO of 4 hours or less typically require hot site or cloud-based recovery; those with 24-72 hour RTOs may be served by warm sites; less critical functions may tolerate cold site recovery timelines. Cost scales with readiness—hot sites are significantly more expensive than warm or cold options.
Question 2: Which IT resilience concept involves maintaining duplicate systems that operate simultaneously so that failure of one component has no impact on service availability?
- High availability (HA) architecture (Correct answer)
- Backup and restore procedures
- Redundant network pathways only
- Regular software patching and updates
Correct answer: High availability (HA) architecture
High availability (HA) architecture uses redundant, simultaneously operating components so that failure of any single element is automatically absorbed by other components without service interruption—eliminating single points of failure.
High availability architecture is fundamentally different from disaster recovery: HA prevents outages through redundancy and automatic failover, while DR recovers from outages after they occur. HA systems use techniques such as clustering (multiple servers sharing workload with automatic failover), load balancing (distributing traffic across multiple servers), redundant power supplies and network interfaces, geographic redundancy (active-active configurations across data centers), and automated health monitoring with automatic rerouting. HA targets are expressed as 'nines of availability'—99.9% availability allows about 8.7 hours of downtime per year; 99.999% (five nines) allows only about 5 minutes. For systems with RTOs of zero (no downtime acceptable), HA architecture is the only appropriate solution because even the fastest DR process involves some recovery time. HA investments are justified when the cost of downtime exceeds the cost of redundancy.
Question 3: What is 'replication lag' and why is it significant for IT disaster recovery?
- The delay between a server failure and the activation of backup systems
- The time gap between when data is written to the primary system and when it appears in the replica (Correct answer)
- The time required to physically transport backup tapes to an offsite location
- The processing delay caused by running backup jobs during business hours
Correct answer: The time gap between when data is written to the primary system and when it appears in the replica
Replication lag is the time delay between data being written to the primary system and appearing in the replication target. It directly determines the potential data loss (RPO exposure) if the primary system fails during the lag period.
Data replication is a core technique for achieving low RPOs in IT disaster recovery. In synchronous replication, data is confirmed written to both primary and replica before the write is acknowledged to the application—replication lag is near zero, providing RPO near zero at the cost of performance overhead and distance limitations. In asynchronous replication, data is written to primary first and replicated afterward—providing better performance and supporting longer distances but creating replication lag that can range from seconds to minutes. If the primary system fails while replication lag exists, all transactions that occurred during the lag period are not present in the replica and may be permanently lost. This lost data represents the actual RPO achieved, which must be within the BIA-defined RPO tolerance. DR planners must measure and monitor replication lag continuously to ensure the actual RPO achieved meets requirements, and must factor expected lag into failover procedures.
Question 4: Which of the following BEST describes the concept of 'Defense in Depth' in IT resilience?
- Using the most expensive security technology available for all systems
- Employing multiple layers of security and resilience controls so that failure of one layer does not compromise the entire system (Correct answer)
- Focusing all resilience investment on the perimeter network to prevent intrusions
- Maintaining a single, comprehensive system that addresses all resilience needs
Correct answer: Employing multiple layers of security and resilience controls so that failure of one layer does not compromise the entire system
Defense in Depth applies multiple layers of controls so that a single failure cannot compromise the entire system—each layer provides protection that compensates for weaknesses in adjacent layers.
Defense in Depth originated as a military concept—using successive defensive lines so that breaching the first line does not mean instant defeat—and applies directly to IT resilience. In a layered architecture, each control compensates for the potential failure of adjacent controls: physical security prevents unauthorized physical access; network segmentation limits lateral movement if perimeter defenses fail; endpoint protection addresses threats that bypass network controls; application-level controls catch what endpoint protection misses; data encryption protects data even if all other controls are bypassed. For resilience specifically, layered approaches might include redundant power (utility → generator → UPS), redundant connectivity (primary ISP → secondary ISP → cellular backup), redundant systems (primary server → replica → manual process), and redundant data protection (online backup → nearline backup → offsite tape). The key principle is that no single control failure leads to unacceptable consequences.
Question 5: During IT disaster recovery, what is the significance of the 'failback' process?
- Failing back refers to the process of returning operations from the recovery environment to the restored primary environment after the incident is resolved (Correct answer)
- Failback is the term for failing over to a backup site when the primary site fails
- Failback describes the process of restoring deleted files from backup
- Failback is a testing technique for validating recovery procedures
Correct answer: Failing back refers to the process of returning operations from the recovery environment to the restored primary environment after the incident is resolved
Failback is the process of transitioning operations back from the recovery (alternate) environment to the restored primary environment after the primary has been repaired and validated—completing the full recovery cycle.
Most DR planning focuses on failover—moving operations from the failed primary to the recovery environment. However, failback—returning to the primary environment once it has been restored—is equally complex and often more disruptive than the original failover. During failback, the organization must: restore data synchronization between recovery and primary environments (capturing all transactions that occurred during the recovery period), validate the restored primary environment thoroughly, plan the transition window to minimize operational impact, reverse all the network and DNS changes made during failover, and deactivate the recovery environment in a controlled manner. Failback failures can cause data loss or service disruption if not carefully planned. DR test plans should specifically include failback procedures, and organizations should practice full failover-failback cycles to validate their ability to complete the entire recovery lifecycle, not just the initial failover step.
Question 6: What is meant by 'Recovery Point Actual (RPA)' versus 'Recovery Point Objective (RPO)'?
- RPA is the regulatory requirement; RPO is the internal goal
- RPO is the target data loss tolerance; RPA is the actual data loss achieved during a specific recovery event (Correct answer)
- RPA applies to real-time systems; RPO applies to batch-processing systems
- These terms are interchangeable in modern DR practice
Correct answer: RPO is the target data loss tolerance; RPA is the actual data loss achieved during a specific recovery event
RPO is the target—the maximum data loss the business can tolerate. RPA is the actual data loss that occurred during a specific recovery event. Comparing RPA to RPO measures whether the DR solution actually met its objectives.
The RPO/RPA distinction is analogous to RTO/RTA (Recovery Time Actual) and reveals the critical difference between planned and actual performance. An organization might set an RPO of 1 hour for a critical database (meaning no more than 1 hour of transactions can be permanently lost). During an actual recovery or DR test, the RPA measures what data was actually available in the recovery environment—if replication lag was 45 minutes at the time of failure, the RPA would be 45 minutes of data loss. If the RPA is within the RPO, the solution is meeting its objective. If the RPA exceeds the RPO (e.g., 3 hours of data was lost when only 1 hour was acceptable), the DR solution requires remediation. Tracking RPA through DR tests is essential for demonstrating that the technical solution actually meets business requirements and for identifying when investments must be upgraded to maintain required recovery objectives.
DRI IT Disaster Recovery and Resilience 1
What is the difference between a 'warm site' and a 'hot site' in IT disaster recovery?