Business Continuity & Disaster Recovery Planning

BCP vs DRP: Two Related, Distinct Plans

• Business Continuity Plan (BCP) — how the organization keeps operating (which functions, on what alternate process, staffed by whom) during a disruption, broader than IT alone
• Disaster Recovery Plan (DRP) — how IT systems and data specifically get restored after a disruption

A BCP might say "customer support continues via a manual paper process during an outage"; the DRP is the technical plan for actually bringing the customer support system back online.

RTO and RPO: The Two Numbers That Define Your Recovery Strategy

• RTO (Recovery Time Objective) — the maximum acceptable time to restore a system after a disruption
• RPO (Recovery Point Objective) — the maximum acceptable amount of data loss, measured in time (i.e., "how old can our most recent usable backup be?")

Worked example: if backups run nightly at 2 AM and a system fails at 1 PM, the RPO determines whether losing that day's 11 hours of data is acceptable — if the required RPO is 1 hour, nightly backups don't meet it, and more frequent backups or replication are needed.

Hot, Warm, and Cold Sites

Choosing a site type is a direct tradeoff against RTO — an organization with a 1-hour RTO requirement cannot rely on a cold site.

The 3-2-1 Backup Rule

• 3 copies of data (the original plus two backups)
• 2 different storage media types (e.g. disk and cloud, not two drives from the same vendor/batch)
• 1 copy stored offsite (protects against a site-wide disaster like fire or flood destroying all local copies at once)

Each part of the rule closes a different single-point-of-failure: media-type diversity protects against a format-specific corruption bug; the offsite copy protects against physical site loss.

Tabletop Exercises: Testing the Plan Without Breaking Anything

A tabletop exercise walks stakeholders through a simulated disaster scenario verbally/on paper ("the primary data center just lost power — what do we do, in what order, who's responsible?") without actually executing failover. It's the cheapest, lowest-risk way to find gaps in a plan — outdated contact lists, unclear ownership, an implicit assumption that turns out to be wrong — before a real disaster proves them the hard way.

Common Pitfalls

• Writing a DRP once and never updating it as infrastructure changes, so it describes a system that no longer exists
• Setting an RPO that the actual backup schedule can't support, discovering the gap only during a real incident
• Assuming a backup exists and is restorable without ever testing an actual restore
• Skipping tabletop exercises because "the plan is documented," when documentation and rehearsed execution are very different things