Disaster Recovery & Business Continuity

Disaster Recovery & Business Continuity // Cloud+ Field Notes
CompTIA Cloud+ · Objective 3.3 & Availability · Disaster Recovery

12
Disaster Recovery & Business Continuity

Backups protect data. Availability protects access. Disaster recovery is what happens when both get tested for real — this field guide covers backup strategy, replication, resource availability, and the RTO/RPO math that drives site selection.

8 Parts 44 Exam Keywords 4 Interactive Tools Read time ~18 min
dr-status.log

$ dr-status --check rto rpo replication

# cross-referencing backup jobs, AZ health, failover targets

✓ 3-2-1 rule satisfied · ✓ RPO 1h met · ✓ hot site synced

$

01

Backup Types

Every backup strategy is a trade between how long the backup job takes and how long the restore takes. The four core types make that trade differently.

Full
Incremental
Differential

Beyond the big three

  • Synthetic full — assembled from the last full plus subsequent incrementals, not pulled from live data
  • Snapshot — read-only, point-in-time; common for VMs, Active Directory, Exchange (e.g. AWS EBS Snapshots)
  • Archive — not a backup at all; optimized for cheap long-term retention, not protection (AWS Glacier, Azure Archive Storage, GCP Nearline/Coldline/Archive)
STaaS vs. BUaaS — storage as a service is generic remote storage; backup as a service is purpose-built for backup jobs — slower disks, higher capacity, much cheaper. Don't treat day-to-day cloud storage as a backup repository once volume grows.
02

Backup Objects & Locations

What you back up — and where you put it — depends on how often it changes and how fast you'd need it back.

ObjectProtectsTypical frequency
System-stateCore OS configurationOn major config/version change
Application-levelApp configs, executables, customizationsBefore version migration
FilesystemUser dataEvery 24 hours (typical)
Database dumpDB contents via SQL statementsMultiple times a day for busy DBs
Configuration fileAnsible/Chef/Puppet/DSC filesAny time edited

The 3-2-1 rule

3 copies of data, on 2 different media types, with 1 copy offsite. With cloud storage, a common modern variant keeps a single onsite copy and replicates two cloud copies across different regions.

Offsite trade-off — more secure against site-wide disaster, but slower to retrieve for routine restores like an accidentally deleted file. Cloud storage counts as offsite — but restore still needs an internet connection.
03

Backup Targets & Schedules

Tape, disk, and cloud each solve a different part of the cost-versus-speed-versus-control equation.

TargetStrengthTrade-off
TapeCost-to-capacity, long-term archiveSlow to access
DiskFast backup and restoreNot ideal for long-term archive
Cloud / object storageLow upfront cost, scalable, globally accessibleInternet connection becomes a speed variable

Schedule guidelines

  • User data — frequent enough to recover file versions (often daily)
  • Configuration files — any time a change is made
  • System-state — on major version or config changes
  • Database data — multiple times a day for busy databases; database settings themselves rarely change
04

Data Retention & Replication

Retention governs how long data must — and can — be kept. Replication keeps copies current across servers and sites.

Retention best practices

  • Maintain compliance with industry regulation and legal requirement minimums and maximums
  • Track data sovereignty considerations for where retained data lives
  • Classify data first — classification drives retention rules
  • Automate deletion and purging to stay compliant and control storage cost
Asynchronous
Synchronous
05

Encryption & Recovery Testing

Encrypted backups protect confidentiality. Regular restore testing is what proves recoverability actually works.

Encryption scopeProtects against
In transitInterception while moving across LAN, WAN, or to the CSP
At restExposure of data sitting on storage media, private or public cloud

Testing levels

  • Individual file restore — simulates accidental user deletion
  • System recovery — simulates a server failure
  • Disaster recovery — simulates a widespread outage
Integrity via hashing — run a checksum before upload and again after. Matching hashes confirm the backup wasn't altered or corrupted in transit; a mismatch means something changed.
06

Recovery Types & Options

The right restore type depends on whether you're recovering for real or just testing that recovery works.

Restore typeWhen to use it
In-place / overwriteReal incident — roll back to a known point, overwriting current data
Side-by-side / parallelCompare backed-up files against current production without overwriting
Alternate locationTesting — restore to a separate system (often a VM) while production stays live
Granular fileRecover individual modified or deleted files
Snapshot restoralRecover a VM to a specific point in time; also used to migrate data across AWS accounts/regions
Security note — the restore destination needs the same security posture as the source — it will hold a full copy of the backed-up data the moment the job completes.
07

Resource Availability

Backups protect data that's already gone. Availability architecture tries to keep things from going down at all.

Regions & availability zones

Each cloud region contains multiple availability zones — data centers with isolated power and networking, connected by fast links, but far enough apart to avoid sharing a single point of failure.

Availability techniques

  • Cloud bursting — overflow to public cloud only when on-prem/private capacity is exceeded
  • Edge computing — move compute near the data source (e.g. IoT sensors) instead of shipping data to a central site
  • NIC teaming — combines NICs into one virtual NIC for failover and link aggregation
  • Load balancing — distributes connections across servers; round-robin, most-recently-used, or weighted scheduling
Monitoring toolType
Prometheus / GrafanaOpen-source
AWS CloudWatch / Azure Monitor / GCP MonitoringCSP-native
Hybrid vs. multi-cloud — hybrid mixes private + public cloud; multi-cloud mixes two or more public providers. Multi-cloud avoids vendor lock-in but adds real complexity to replication and failover.
08

Disaster Recovery & Sites

RTO and RPO are the two numbers that actually decide which site tier you can afford — drag the sliders to see how they trade off.

Recovery Time Objective (RTO)4 hours
Recovery Point Objective (RPO)1 hour

DR site tiers

Site typeCostData handlingEquipment present
HotHighImmediate replicationAll
WarmMediumData migratedSome
ColdLowerData migratedNone
CloudVariableVariableNone
recovery metric — click to define
Geographic spread — a DR site far enough from the primary survives regional disasters, but distance adds legal complications across borders, longer replication time, and the question of who staffs it.

Exam Keyword Flashcards

Tap a card to flip it.

Quick Self-Check

Four questions pulled straight from the module.

Score: 0 / 0
Module 12 · Disaster Recovery and Business Continuity CompTIA Cloud+ Objective 3.3