Backups, testing, and continuity of operations

Objective 3.4 in this course covers resilience and recovery. The previous lesson took availability, sites and power; this one takes backups, testing and continuity of operations from CompTIA's scope note — and it is the Domain 3 capstone, because a restore exercise pulls in classification, segmentation, encryption and site design at once.

Why this matters

Backups are the control that decides whether a ransomware incident is an expensive weekend or an extinction event. They are also the control most likely to be assumed rather than verified: organisations discover their backup strategy does not work at the exact moment they need it, which is the worst possible time to find out.

The exam reflects this. It asks about backup types and their restore implications, and it asks about testing — repeatedly, because an untested backup is the recurring right answer to "what went wrong here?".

The lesson

Onsite and offsite, frequency, encryption, snapshots, replication, journaling

CompTIA's backup considerations, each with what it decides:

• Onsite backups restore fastest and share every risk with production — the same fire, the same flood, the same ransomware that encrypted the primary.
• Offsite backups survive the site. They restore more slowly, and their security is a real concern: backup media in transit and at rest elsewhere is a complete copy of your data with none of your production controls.
• Frequency determines your recovery point objective — how much data you lose. Nightly backups mean up to a day of work lost. The frequency is derived from the RPO, not chosen for convenience.
• Encryption of backups is not optional. A backup is the full dataset, portable, often outside your building. Key management is the part that goes wrong: a backup encrypted with a key that is only stored in the system you are recovering from is not recoverable.
• Snapshots capture point-in-time state, usually quickly and on the same storage. They are excellent for fast rollback and they are not a backup — they usually depend on the same storage system, so its loss or encryption takes them too.
• Replication copies data continuously to another system. It gives a very low RPO and it faithfully replicates deletion and encryption, so it protects against hardware and site failure and not at all against ransomware or mistakes.
• Journaling records each change so state can be reconstructed to a chosen point, which is what allows point-in-time recovery to just before a destructive event.

The backup types by what they copy: full (everything, slowest to take, fastest to restore); incremental (everything since the last backup of any kind — fastest to take, slowest to restore, needs the full plus every incremental in order); differential (everything since the last full — middling both ways, needs only the full plus the latest differential). A scenario asking for the shortest restore time points to full or differential; a scenario constrained by backup window or storage points to incremental.

The rule worth memorising is the 3-2-1 guideline: three copies, on two different media types, one offsite. Modern practice adds one immutable or offline copy, because ransomware actively seeks and encrypts backups — and a backup the production credentials can delete is a backup the attacker can delete.

The restore that was never tested, which is the finding this lesson exists for

An unverified backup is not a control. It is a belief.

The failure modes are specific, and every one of them has ended a real organisation's recovery:

• the job reported success for months while silently skipping a database that was locked;
• the media was fine and the decryption key was stored only in the system being recovered;
• the backup software's licence had lapsed and would not restore;
• restoring the full dataset took eleven days against an RTO of one day, because nobody had ever measured the restore rate;
• the backups were complete and the attacker had been in the environment for four months, so every restore point contained their access;
• the restore worked and nobody knew the correct order to bring services back, so the application came up before the directory it authenticates against.

What to test, at intervals proportionate to the system's importance: that data restores, that it is complete and correct rather than merely present, how long the restore actually takes end-to-end, that keys are available independently, and that the recovered service functions rather than just starting.

The exam's phrasing of this is usually "what should have been done?" and the answer is a regular, documented, full restore test — not a backup verification report, which is the system marking its own homework.

Tabletop exercises, failover, simulation and parallel processing

CompTIA names four testing methods, in ascending order of realism and risk:

• Tabletop exercise — people sit around a table and talk through a scenario. No systems are touched. Cheap, safe, and it finds the decision and communication gaps: who declares an incident, who talks to the regulator, who can authorise paying for emergency hardware. It cannot tell you whether the technology works.
• Simulation — a more realistic walkthrough with some systems exercised and injects introduced during the exercise. Finds process gaps under a degree of pressure.
• Parallel processing — the recovery environment is brought up and runs alongside production, processing the same work. It proves the recovery environment functions, at real cost, without risking production.
• Failover — production is actually moved to the recovery site. The only test that proves the whole thing works, and the only one that can cause an outage of its own.

A mature programme uses all four at different cadences: tabletop quarterly, failover annually. The exam's framing: tabletop finds decision gaps cheaply; failover is the only test that proves capability, and the reason organisations avoid it is precisely the reason they need it.

Continuity of operations planning, and what it covers that DR does not

Three terms that are routinely confused and are examined as distinct.

• Disaster recovery (DR) is about technology: restoring systems, data and infrastructure after a disruptive event. Its metrics are RTO and RPO.
• Business continuity (BCP) is about the business continuing to operate, by any means, during the disruption. It covers people, premises, suppliers, communications and manual workarounds. DR is a component of BCP.
• Continuity of operations planning (COOP) is the broadest: how essential functions continue when normal arrangements are unavailable, including alternate facilities, succession of authority, and the manual processes that run when the systems are simply gone.

The distinction the exam wants: DR restores the systems; continuity keeps the business running while they are down. If a scenario describes paper processes, staff relocation, delegated authority or supplier substitution, that is continuity, not disaster recovery.

Elements a continuity plan must contain and that DR plans typically lack: a list of essential functions ranked by how long the business survives without them, succession of authority so decisions can be made when key people are unreachable, a communication plan that works when email and the corporate phone system are down, and dependency mapping including suppliers — because your continuity is limited by theirs, which connects to Domain 5's third-party risk.

RPO and RTO, and deriving them from a business statement

Four metrics, and you will be asked to derive or distinguish them.

• RPO (recovery point objective) — the maximum acceptable data loss, expressed as time. It drives backup frequency and replication. "We can afford to lose at most one hour of transactions" is an RPO of one hour, which demands backups or replication at least hourly.
• RTO (recovery time objective) — the maximum acceptable downtime. It drives site strategy and restore capability. "We must be trading again within four hours" is an RTO of four hours, which rules out a cold site.
• MTTR (mean time to repair) — how long a repair actually takes on average. A measurement of reality, against which the RTO is a target. If MTTR exceeds RTO, the objective is not being met and the gap is the finding.
• MTBF (mean time between failures) — the average interval between failures of a component. A reliability measure used for capacity and replacement planning.

The distinction to hold firmly: RPO looks backwards from the incident (how much data is gone), RTO looks forwards (how long until we are working). They are set by the business, derived from the business impact analysis in Domain 5, and they are then costed — because an RPO near zero and an RTO of minutes is achievable and expensive, and the point of stating them is to let the business decide what to buy.

One consistency check the exam likes: your backup frequency must be at least as often as your RPO, and your recovery capability must be fast enough for your RTO. A stated RPO of fifteen minutes with nightly backups is an unmet objective, no matter what the plan document says.

What to take into the exam

• Snapshots and replication are not backups: both faithfully carry deletion and encryption, and snapshots usually share the storage they protect.
• 3-2-1, plus an immutable or offline copy, because ransomware hunts backups.
• Incremental is fastest to take and slowest to restore; differential needs only the last full plus the latest differential.
• Tabletop finds decision gaps cheaply; failover is the only test that proves capability.
• DR restores systems; business continuity and COOP keep the business running while they are down.
• RPO = data loss, drives backup frequency. RTO = downtime, drives site strategy. MTTR is measured reality, MTBF is reliability.