What Is Backup and Recovery?

Backup is the control that determines how bad your worst day becomes, and it is the one most likely to be assumed working rather than known working. The distinction that matters is not whether backups run — they almost always do — but whether anyone has restored from them recently.

Ransomware changed the requirements fundamentally. Attackers now target backups deliberately and specifically, because an organisation that can restore does not pay.

What ransomware changed

Traditional backup design assumed the threat was hardware failure, accidental deletion or a site becoming unavailable. Against a credentialed attacker who has been in the environment for weeks, those designs fail in specific ways: backup servers are domain-joined and reachable, backup credentials are stored in the environment being backed up, and snapshots can be deleted through the same management interface the attacker now controls.

The answer is immutability — backups that cannot be altered or deleted for a defined retention period, by anyone, including an administrator with valid credentials. Combined with an offline or logically separated copy, that is what makes recovery survivable.

Recovery objectives drive the design

Two numbers define the requirement. Recovery point objective is how much data you can afford to lose, which sets backup frequency. Recovery time objective is how long you can afford to be down, which sets the recovery architecture.

Both should be set per system by the people who own the business process, not by IT in the abstract. A four-hour objective for a clinical system and a one-week objective for an archive are both reasonable, and pretending everything needs the former makes the plan unaffordable and therefore untested.

Restore testing is the whole control

A backup job reporting success proves the job ran. It does not prove the data is complete, that the media is readable, that the restore procedure works, that anyone knows how to execute it, or that the restored system functions.

Testing means restoring to a usable state and verifying the result — at least annually for anything important, and at a scale that reflects reality. A single-file restore proves very little about recovering an entire database under pressure.

Retention and the data you should not still have

Backup retention is where deleted data quietly persists. A record removed from production under a retention schedule or an erasure request remains in every backup taken while it existed, and those backups may be held for years.

This is a recognised tension rather than a solved problem. The generally accepted position is that backups are put beyond use — documented as containing the data, not restored without re-applying the deletion, and allowed to expire on the normal cycle. See the right to be forgotten.

What matters is that the position is deliberate and written down. An organisation that has never considered it will be asked during an erasure request or an audit, and improvising the answer is a poor moment to discover the retention period is seven years.

Where to start

Restore your most important system from backup into an isolated environment and time it. Whatever that exercise reveals will be more useful than another year of successful backup reports.

See immutable backups and backup testing. GuardsArm supports incident response and recovery planning.