Dennis Academy

Simple explanation

Prevention will eventually fail — resilience and recovery are what happen next. This lesson covers designing systems that survive failure, and the backup/testing practices that make recovery actually possible when needed.

Technical explanation

High availability — architecture designed so a single failure doesn't cause an outage (redundant components, no single point of failure).
Site considerations: hot site (fully operational duplicate, ready to take over almost immediately — expensive), cold site (basic infrastructure only, requires significant setup time — cheap), warm site (partially configured, a middle ground), geographic dispersion (sites far enough apart that one regional disaster doesn't take out both).
Platform diversity — not relying on a single vendor/technology stack everywhere, so one vendor's flaw doesn't compromise everything.
Multi-cloud systems — spreading workloads across more than one cloud provider for resilience (and to avoid vendor lock-in).
Continuity of operations — the broader plan for keeping the business functioning during disruption, not just IT systems.
Capacity planning — ensuring enough resources exist to handle both normal load and failover scenarios.
Testing: tabletop exercises (discussion-based walkthrough, no systems actually touched), failover testing (actually triggering a failover to confirm it works), simulation (more realistic than tabletop, less disruptive than a full failover test), parallel processing testing (running the backup system alongside production to validate it without cutting over).
Backups: onsite vs. offsite, frequency, encryption (backups are a copy of your sensitive data — they need the same protection), snapshots (point-in-time captures, often fast but tied to the original system), recovery (the actual restore process, which should be tested, not just assumed to work), replication (continuously copying data to another location), journaling (recording changes so you can replay/recover to any point in time).
Backup types: full (everything, every time — simple restore, slow backup), incremental (only what changed since the last backup of any type — fast backup, slower restore since you need the full plus every increment), differential (everything changed since the last FULL backup — a middle ground), plus storage media/location considerations: tape, disk, NAS, SAN, cloud, image-based, online vs. offline, and distance considerations for offsite storage.
Power: generators (sustained backup power) and UPS (Uninterruptible Power Supply — short-term power to bridge a gap or allow graceful shutdown).

Synonyms / related terms

| Term | Means | |---|---| | DR site | Disaster Recovery site (hot/warm/cold) | | UPS | Uninterruptible Power Supply | | Snapshot | Point-in-time backup, often storage-system-native |

Concept Check

"A company wants the fastest possible backup window but is willing to accept a slower, more complex restore process if disaster strikes. Which backup type fits?" Incremental — it backs up only what changed since the last backup of any kind, making the backup itself fast, but restoring requires reassembling the full backup plus every incremental since, making restore slower and more complex than a differential approach.

Interview-style Q&A

Q: Why test backups instead of just trusting that the backup job completed successfully? A: "A backup job reporting 'success' only confirms data was written somewhere — it says nothing about whether that data can actually be restored and is usable. I've seen backups that 'succeeded' for months turn out to be corrupted or incomplete the one time they were actually needed. Testing recovery, not just backup completion, is the only way to know it actually works."

Memory trick