Cram Sheet · Domain 3.4
Resilience and recovery — CompTIA Security+ SY0-701
Both make a service survive a single device failure, and both get lumped together because of that. The difference is what the group of devices is.
| Concept | What it is | Key detail |
|---|---|---|
| Clustering | Two or more servers act as one logical server | Usually same OS; users see a single device |
| Load balancing | Traffic is spread across multiple independent servers | Servers can differ (even different OSes); balancer adds/removes servers as needed |
| Site type | Hardware | Data/software | Recovery time |
|---|---|---|---|
| Hot site | Fully stocked, constantly updated, ready and waiting (exact replica) | Continuously replicated | Minutes (“flip a switch”) |
| Warm site | Rack space, no data | You bring software and data | Days |
| Cold site | Empty building | You bring everything, including people | Weeks to months |
| Term | What it means |
|---|---|
| Geographic dispersion | Recovery site is physically far from the primary site, so one regional disaster (hurricane, flood) can't take out both |
| Virtual site (hot/warm/cold) | Same three tiers, built in the cloud instead of a physical building. Virtual hot = fully replicated and instantly accessible; virtual cold = resources sit dormant until activated |
| Mobile site | Portable unit (trailer, tent) that can be configured as hot, warm, or cold; used for rapid, flexible deployment |
Platform diversity: deliberately running different operating systems, vendors, and technologies so a vulnerability or flaw specific to one platform can't take down the whole organization at once. Windows-specific vulnerabilities generally don't touch Linux or macOS, and vice versa.
Multi-cloud systems: the same principle applied to cloud providers. Spreading workloads across AWS, Azure, and Google Cloud means one provider's outage or breach doesn't take everything down with it.
The plan for keeping the business running when technology fails, not just the technology itself. If systems go down, COOP defines the manual fallback: paper receipts, phone-based transaction approvals, manual processes. These procedures must be documented and tested before a real disruption happens, not improvised during one.
All four validate a recovery plan without waiting for a real disaster. They differ in what they actually exercise.
| Method | Anchor | What happens |
|---|---|---|
| Tabletop exercise | Talk it through | Key players discuss a simulated disaster around a table; no systems are touched |
| Failover test | Actually switch over | Redundant infrastructure (routers, firewalls, switches) takes over from a failed unit, often automatically |
| Simulation | Fake the attack | A real-feeling event is run against real users, e.g. a phishing campaign, to test filters and user response |
| Parallel processing | Split the load | A process runs across multiple CPUs/systems at once; a faulty processor is removed while the rest keep working |
Matching supply to demand so you have neither outages (too little) nor wasted spend (too much). CompTIA groups it into three areas:
| Area | Focus |
|---|---|
| People | Staffing for services that need human intervention, e.g. call centers; balancing understaffing (slow response) against overstaffing (wasted cost) |
| Technology | Choosing systems that can scale, e.g. distributing web load, clustering/splitting databases, using on-demand cloud services |
| Infrastructure | The underlying framework: CPU, network, storage. Physical devices take longer to deploy; cloud-based devices deploy faster for unexpected capacity needs |
| Type | Captures | Backup speed | Restore speed |
|---|---|---|---|
| Full backup | Everything, every time | Slowest | Fastest (one set) |
| Incremental backup | Changes since the last backup (full or incremental) | Faster than full, slower than differential | Slowest (restore full, then every incremental in order) |
| Differential backup | Changes since the last full backup | Faster than incremental | Faster than incremental (restore full, then the one latest differential) |
| Consideration | Detail |
|---|---|
| Onsite backups | No internet link needed, immediately available, generally cheaper |
| Offsite backups | Transferred over internet/WAN, survives a disaster at the primary site, restorable from anywhere. Most organizations run both. |
| Frequency | Systems with high change rates need more frequent backups; organizations often keep layered daily/weekly/monthly sets |
| Encryption | Backup media, especially offsite or cloud, holds a full history of sensitive data in one place. Encrypting it means a stolen or intercepted backup is unreadable without the recovery key |
| Technique | Anchor | How it works |
|---|---|---|
| Snapshot | Point-in-time copy | Captures an entire system's state at one moment; common on VMs and cloud. Later snapshots capture only the changes since the last one, so you can revert to any saved point. |
| Replication | Near real-time mirror | Data is continuously synchronized to another location, so a current copy always exists elsewhere |
| Journaling | Write-ahead log | Before data is written to storage, a journal entry records the intended change. If power fails mid-write, the journal is used to recover cleanly instead of restoring an entire backup |
| Solution | Duration | Detail |
|---|---|---|
| UPS (uninterruptible power supply) | Short-term | Covers blackouts, brownouts, and surges immediately. Types: offline/standby, line-interactive, online/double-conversion. |
| Generator | Long-term | Requires fuel storage, can power an entire building, but takes a few minutes to spin up, during which the UPS bridges the gap. |
Domain 3.4 · Resilience and recovery · Sources: Professor Messer SY0-701 Course Notes, CompTIA Security+ Study Guide v1, CompTIA Security+ Study Guide 9th Edition (Gibson)