Disaster recovery and business continuity

In short

Business continuity planning (BCP) is the management discipline that keeps an organisation's critical business functions running, or restores them quickly, when a disruption hits; disaster recovery (DR) is the IT subset that restores systems, data and infrastructure. The two are measured by targets — RTO (how fast), RPO (how much data loss) and MTD (the absolute deadline) — derived from a business impact analysis. In India this is not optional for regulated sectors: RBI, SEBI and IRDAI mandate documented, tested continuity and recovery arrangements, and the Digital Personal Data Protection Act, 2023 makes safeguarding and breach notification a statutory duty from 13 May 2027 (until then IT Act s.43A and the SPDI Rules 2011 govern). It is examined in AICTE-model IT operations, cloud computing and information security papers, in UGC-CBCS cyber security courses, and asked in placement rounds at TCS, Infosys, Wipro, HCLTech, Cognizant, Accenture, Capgemini and every bank/NBFC IT team.

Explained

Definitions and how the pieces fit

• Disaster: any event that stops normal IT service beyond the ability of routine incident handling — flood, fire, power failure, ransomware, fibre cut, cloud-region outage, mass human error.
• Business continuity management (BCM): the whole lifecycle — policy, BIA, strategy, plans, testing, review — governed by ISO 22301:2019 (the current edition of the BCMS standard; adopted in India as IS/ISO 22301).
• Business continuity plan (BCP): business-side procedures — alternate premises, manual workarounds, staff call trees, supplier switching.
• Disaster recovery plan (DRP): IT-side procedures — restore order, failover steps, data recovery, network re-routing. ISO/IEC 27031 covers ICT readiness for business continuity; ISO/IEC 24762 covered DR service provision.
• Crisis management plan: who declares a disaster, who speaks to regulators, media and customers.
• Hierarchy to remember: BCM is the programme; BCP and DRP are plans inside it; incident response handles the security event; DR restores the platform.
• Resilience is designing so disruption does not happen (redundancy, HA clustering); recovery is acting after it does. Both are needed — HA protects against component failure, DR against site/data loss.

Business impact analysis and risk assessment

1. Inventory processes and the IT services behind them — map process → application → server/database → dependency (DNS, AD, payment gateway, SMS gateway).
2. Quantify impact over time — financial loss, regulatory penalty, reputational damage, safety, at 1 h, 4 h, 1 day, 1 week.
3. Set MTD/MTPD (maximum tolerable downtime / period of disruption) for each process — the point beyond which the business cannot recover.
4. Derive RTO (must be less than MTD, leaving margin for business resumption) and RPO from data-change tolerance.
5. Classify criticality: Tier 0/mission-critical (payments, core banking) → Tier 3 (internal reporting).
6. Risk assessment (separate exercise): identify threats, likelihood and impact; risk = likelihood × impact; treat by avoid / reduce / transfer (insurance) / accept.
7. Dependency and single-point-of-failure analysis — upstream vendors, a single ISP, one DBA who holds the keys, one AD forest.

Recovery objectives and metrics

• RTO (Recovery Time Objective): maximum acceptable time to restore a service after disruption.
• RPO (Recovery Point Objective): maximum acceptable data loss, expressed as time — equals the backup/replication interval in the worst case.
• MTD/MTPD: RTO + time to resume business work; RTO must always be strictly less than MTD.
• WRT (Work Recovery Time): after the system is up, time to validate data, re-key lost transactions and resume normal work. MTD = RTO + WRT.
• MTBF / MTTR: mean time between failures and mean time to repair — reliability inputs; availability = MTBF/(MTBF+MTTR).
• RTA / RPA (actual): what a drill actually achieved — the gap against RTO/RPO is the audit finding.
• Lower RTO/RPO costs more, non-linearly: RPO of 24 h is nightly tape; RPO near zero needs synchronous replication and dark fibre.

Backup strategies and data protection

• Full backup: everything each time — simplest restore, largest storage and window.
• Incremental: only blocks/files changed since the last backup of any type — small window, restore needs the full plus every later increment.
• Differential: changes since the last full — larger than incremental, restore needs only full + latest differential.
• Synthetic full / forever-incremental: server merges increments into a new full without touching production (Veeam, Commvault, NetBackup).
• Snapshots: point-in-time copy at storage/VM level; fast, but same array — not a backup by itself.
• Continuous data protection (CDP): journals every write; RPO of seconds.
• 3-2-1 rule: 3 copies, on 2 different media, 1 off-site. Modern form 3-2-1-1-0: one copy immutable/air-gapped (WORM, object lock, tape out of the library) and 0 verified errors — the ransomware-era addition, because malware deletes reachable backups.
• Grandfather-father-son (GFS) retention: daily, weekly, monthly, yearly copies.
• Replication types: *synchronous* (write acknowledged only after both sites commit → RPO = 0, distance-limited to roughly 50–100 km by latency) and *asynchronous* (RPO = seconds to minutes, any distance).
• Backup verification: restore tests, checksums, media rotation; an untested backup is an assumption, not a control.

Recovery site strategies

• Hot site: fully equipped, data current, staffed or automatable — RTO minutes to a few hours; highest cost.
• Warm site: hardware and network ready, data restored from recent backup/async replication — RTO hours to a day.
• Cold site: space, power, cooling only — RTO days to weeks; cheapest.
• Mirrored/active-active site: both sites serve live traffic; near-zero RTO and RPO; highest cost and complexity.
• Mobile site: containerised DC on a truck — used after floods/earthquakes.
• Reciprocal agreement: two firms host each other — cheap, legally weak, capacity rarely verified.
• Cloud DR / DRaaS: pilot light (minimal core always on), warm standby (scaled-down live copy), multi-site active-active; pay for the standby only until failover. AWS/Azure/GCP Indian regions (Mumbai, Hyderabad, Delhi NCR, Pune, Chennai) make in-country DR pairs feasible, which matters for data-residency conditions.
• Site separation: DR site must be on a different seismic zone (IS 1893 zones), flood plain, power grid and telecom path — RBI expects "different seismic zone" for banks' DR data centres.
• Failover and failback: failover switches production to DR (DNS/GSLB change, storage promotion, IP re-advertisement); failback returns to primary after re-syncing — the step most often untested.

Plan lifecycle, testing and governance

1. Policy and scope — board/management approval, named BCM owner.
2. BIA and risk assessment → recovery objectives.
3. Strategy selection — site, backup, replication, vendor contracts with SLAs and penalties.
4. Plan documentation — call trees, escalation matrix, RACI, restore runbooks, vendor contacts, declaration authority, alternate work locations. Keep a printed/offline copy; the plan must not live only on the system that fails.
5. Testing, in increasing rigour: *checklist/desk review* → *walk-through/tabletop* (discussion of a scenario) → *simulation* → *parallel test* (DR runs alongside production, no cut-over) → *full-interruption test* (production actually moved — the only real proof, and the riskiest).
6. Review and improvement — after every drill, incident and major change; at least annually, and after any significant change in architecture, regulation or vendors.
7. Training and awareness — people, not documents, execute recovery.
8. Indian regulatory and legal framework (verify current versions before quoting in an audit):
   • RBI — Cyber Security Framework for banks (2016 circular) and the Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices, 2023 (effective 1 April 2024) require a board-approved BCP/DR policy, a DR site in a different seismic zone, DR drills at least half-yearly for critical systems, and defined RTO/RPO.
   • SEBI — Cybersecurity and Cyber Resilience Framework (CSCRF, 2024) for regulated entities; stock exchanges and depositories have long-standing BCP-DR norms with RTO of 45 minutes and RPO of 15 minutes for critical systems (confirm the current circular — these numbers have been revised over time).
   • IRDAI — information and cyber security guidelines require BCP/DR with periodic testing.
   • CERT-In Directions, 28 April 2022 — report specified cyber incidents within 6 hours of noticing, maintain ICT logs for 180 days in India.
   • Digital Personal Data Protection Act, 2023 — duty to protect personal data with reasonable security safeguards and to notify the Data Protection Board and affected data principals of a breach; Rules notified in 2025 with phased implementation, so check the stage in force.
   • IT Act, 2000 — section 43A/72A exposure for failure of reasonable security practices; ISO/IEC 27001:2022 control on ICT readiness for business continuity.
   • Telecom and insurance of records, plus NDMA/Disaster Management Act, 2005 for the national disaster framework; IS 1893 (Part 1):2016 for seismic zoning of the site.

Advantages, limitations and comparisons

• Advantages: survives outages with bounded loss; satisfies regulators and customer audits; often lowers insurance cost; the BIA itself exposes undocumented dependencies.
• Limitations: real money for capacity that idles; plans decay as architecture changes; full-interruption tests themselves risk an outage; cloud DR can hide a shared dependency (same region, same IAM, same account compromised by ransomware).
• DR vs HA: HA is automatic, local, component-level (clusters, RAID, dual PSU); DR is site-level, often manual to declare, protects against correlated loss. RAID and snapshots are not backups; replication copies corruption and ransomware encryption too — hence immutable copies.
• Backup vs archive: backup is for recovery with short retention; archive is for long-term retention and retrieval.

Key points

• BCP - keeps the business running; DRP - restores IT; BCM is the governing programme.
• BIA - identifies critical processes, impact over time, and sets MTD, RTO and RPO.
• RTO - maximum acceptable time to restore a service; RPO - maximum tolerable data loss in time.
• MTD = RTO + WRT - RTO must always be less than MTD, with margin.
• Availability = MTBF/(MTBF+MTTR); five nines ≈ 5.26 minutes downtime a year.
• 3-2-1-1-0 - 3 copies, 2 media, 1 off-site, 1 immutable/air-gapped, 0 restore errors.
• Incremental - small backups, long restore chain; differential - bigger backups, shorter restore.
• Synchronous replication - RPO = 0 but distance-limited; asynchronous - any distance, small data loss.
• Hot / warm / cold site - RTO of hours → day → days, with cost falling in the same order.
• Cloud DR tiers - backup-and-restore, pilot light, warm standby, active-active (multi-site).
• Failback - the return to primary; the most commonly untested phase of DR.
• Test ladder - checklist → tabletop → simulation → parallel → full interruption.
• Replication is not backup - it faithfully copies corruption, deletion and ransomware encryption.
• RBI IT Governance Master Direction, 2023 - board-approved BCP/DR, DR in a different seismic zone, periodic drills.
• CERT-In 2022 directions - incident reporting within 6 hours; 180-day log retention in India.
• DPDP Act, 2023 - reasonable security safeguards and breach notification duties for personal data.
• ISO 22301:2019 - BCMS requirements; ISO/IEC 27031 - ICT readiness for business continuity.
• Declaration authority - a named person must have written power to declare a disaster and invoke the DRP.

Formulas and examples

Example 1 — Availability and downtime. A server has MTBF 4,000 h and MTTR 5 h.

• A = 4,000/(4,000 + 5) = 4,000/4,005 = 0.998752 → 99.875%.
• Annual downtime = (1 − 0.998752) × 525,600 min = 0.0012484 × 525,600 ≈ 656 minutes ≈ 10.9 hours/year.
• Halving MTTR to 2.5 h: A = 4,000/4,002.5 = 0.999375 → downtime ≈ 328 minutes. Faster repair buys as much as more reliable hardware.

Example 2 — RPO, RTO and cost of downtime. A bank's internet-banking platform earns ₹25 lakh revenue per hour. Nightly backup at 01:00; failure at 16:00; restore takes 6 h.

• Data loss = 16:00 − 01:00 = 15 h of transactions → RPO achieved = 15 h; if the policy RPO is 15 min, the design fails by a factor of 60.
• Downtime cost = 6 h × ₹25,00,000 = ₹1.5 crore for one event.
• Moving to asynchronous replication (RPO 5 min) plus a warm site (RTO 1 h) cuts the loss to 1 × ₹25,00,000 = ₹25 lakh — a saving of ₹1.25 crore per event, which justifies an annual DR spend well above that if the event occurs even once a year.

Example 3 — ALE and DR justification. A data centre worth ₹8 crore faces a flood that would destroy 40% of its value, expected once in 20 years.

• EF = 0.40 → SLE = 8,00,00,000 × 0.40 = ₹3.2 crore.
• ARO = 1/20 = 0.05 → ALE = 3,20,00,000 × 0.05 = ₹16 lakh per year.
• A DR site reducing EF to 0.05 gives SLE = ₹40 lakh, ALE = ₹2 lakh/year. Benefit = 16 − 2 = ₹14 lakh/year, so spending up to about ₹14 lakh a year on that control is justified on this risk alone.

Example 4 — Backup window and storage. A 2 TB file server changes 3% daily. Full backup throughput 200 GB/h; retention = 1 full + 6 incrementals (GFS weekly cycle).

• Daily change = 0.03 × 2,048 GB ≈ 61.4 GB.
• Full backup time = 2,048/200 ≈ 10.2 h — too long for an 8-hour night window, so a weekend full + nightly incrementals is required.
• Incremental time ≈ 61.4/200 ≈ 0.31 h ≈ 18 minutes.
• Cycle storage ≈ 2,048 + (6 × 61.4) ≈ 2,416 GB ≈ 2.36 TB per cycle; 4 cycles retained ≈ 9.4 TB before deduplication.
• Worst-case restore after a Saturday failure = full + 6 increments = 2,416/200 ≈ 12.1 h, which must be checked against the RTO.

Example 5 — MTD arithmetic. A hospital's billing system has MTD 8 h. Restoring the VM and database takes 3 h; re-keying manual bills raised during the outage takes 4 h.

• MTD = RTO + WRT → 8 = RTO + 4 → permissible RTO = 4 h; achieved RTO is 3 h, so there is 1 h of margin. If restore slips to 5 h, MTD is breached even though the "system is up".

Where it is used

• Banking, NBFC and payments: core banking and UPI switches run active-active or hot DR with near-zero RTO under RBI directions; half-yearly DR drills are audited, and NPCI/payment operators maintain their own continuity requirements.
• Capital markets: exchanges, depositories and brokers (NSE, BSE, CDSL, NSDL) operate DR sites and run mandated drills under SEBI's framework; a trading halt is a reportable event.
• IT services and GCCs: TCS, Infosys, Wipro, HCLTech, Cognizant, Capgemini and Accenture sell and operate BCP/DR for clients and must prove their own — ISO 22301 and ISO/IEC 27001 certification is a standard RFP condition.
• Cloud and data-centre providers: AWS, Azure, Google Cloud, Jio, Airtel Nxtra, CtrlS, Yotta, Sify sell DRaaS, backup-as-a-service and multi-region architectures in Indian regions for data-residency reasons.
• Government and public services: NIC/MeghRaj cloud hosts state applications with DR pairing (for example Delhi–Hyderabad–Bhubaneswar NDC sites); Aadhaar, GSTN, IRCTC and railway systems run geo-redundant platforms.
• Job roles: BCP/DR analyst, backup administrator, SRE/platform engineer, infrastructure architect, IT risk and compliance analyst, internal auditor (ISO 22301 lead implementer/auditor, CBCP, CISA certifications are commonly asked for).

Interview questions

• Q: What is the difference between RTO and RPO? A: RTO is how long the service may stay down before restoration; RPO is how much data, measured in time, the business can afford to lose. RTO drives recovery infrastructure, RPO drives backup and replication frequency.
• Q: Is high availability the same as disaster recovery? A: No. HA is automatic protection against component or node failure within a site; DR restores service after the loss of a site, a dataset or a large region, and usually involves a declaration and a deliberate failover.
• Q: Why is replication not a backup? A: Replication copies every write, including corruption, accidental deletion and ransomware encryption, to the secondary almost immediately; a backup keeps independent historical, ideally immutable, point-in-time copies.
• Q: What is the 3-2-1-1-0 rule? A: Keep 3 copies of data on 2 different media with 1 copy off-site, 1 copy immutable or air-gapped, and 0 errors in verified restore tests.
• Q: When would you choose asynchronous over synchronous replication? A: When the DR site is far away or links are latency-bound — synchronous replication makes every production write wait for the remote commit, which is impractical beyond roughly 50–100 km; async accepts seconds of RPO for distance and performance.
• Q: What does a business impact analysis produce? A: A list of critical processes with their dependencies, the impact of downtime over time, and the agreed MTD, RTO and RPO for each — the inputs to every DR design decision.
• Q: How do you test a DR plan without risking production? A: Work up the ladder — checklist review, tabletop walk-through, simulation, then a parallel test where DR runs alongside production without cut-over; a full-interruption test is scheduled only when the parallel test is clean.
• Q: What is failback and why does it fail so often? A: Failback is returning production to the primary site after recovery; it fails because the primary's data is stale, re-synchronisation is not rehearsed, and plans usually stop at failover.
• Q: What does Indian regulation require of a bank's DR site? A: Under RBI's IT Governance Master Direction (2023), a board-approved BCP/DR policy, defined RTO and RPO, a DR site in a different seismic zone from the primary, and periodic — at least half-yearly for critical systems — DR drills with documented results.
• Q: How soon must a cyber incident be reported in India? A: Under CERT-In's April 2022 directions, specified incidents must be reported within 6 hours of noticing them, and ICT logs must be retained for 180 days within India; sectoral regulators and the DPDP Act add their own notification duties.
• Q: A service must achieve 99.99% availability. What does that allow you? A: About 52.6 minutes of downtime per year, or roughly 4.4 minutes a month — including planned maintenance, which forces redundancy and rolling upgrades rather than maintenance windows.
• Q: What is a pilot-light DR architecture? A: A cloud pattern where only core elements (database replica, AMIs/images, network, IAM) run continuously at the DR region; compute is scaled up on failover — cheaper than a warm standby, with an RTO of tens of minutes.
• Q: Who declares a disaster? A: A named authority in the plan — typically the crisis management team head or CIO — with written delegation and alternates, because an ambiguous declaration authority is the single biggest cause of delay.

Common mistakes

• Swapping RTO and RPO in exams, or quoting RPO in gigabytes instead of time.
• Treating RAID, snapshots or replication as backups, and keeping the only backup copy on a network share the ransomware can reach.
• Never testing a restore — reporting "backup successful" from the job log rather than from a verified recovery.
• Writing a plan that lives only on the primary site's file server or an online wiki, with no offline copy and no printed contact tree.
• Ignoring WRT, so a plan that meets its RTO still breaches MTD once data validation and re-keying are counted.
• Planning for technology only — forgetting people (succession, alternate staff, travel), premises, suppliers and upstream dependencies like DNS, AD or a single ISP.
• Siting the DR centre on the same grid, flood plain, seismic zone or fibre route as the primary, or in the same cloud region, and calling it geo-redundant.
• Quoting old regulatory numbers without checking: RBI, SEBI and DPDP requirements have been revised, and specific RTO/RPO mandates change by circular.

Related topics

Virtualisation: VMware and Hyper-V · Cloud computing service and deployment models · Information security management and ISO/IEC 27001 · RAID, storage area networks and data centre design · Network design, load balancing and DNS failover · IT service management and ITIL incident/problem management