Backup
In resilience and incident recovery, a backup is a separate copy of data and configuration held so that a known-good state can be restored after loss, corruption or ransomware. What makes a copy useful is not that it exists but that it is isolated from the thing that broke and that somebody has restored from it.
What it is
A backup is a duplicate of data and configuration kept somewhere separate, so it can be restored if it is lost, corrupted or encrypted by ransomware. It is the line of defence that holds up the availability of information when the others have failed.
It covers risks with nothing in common: an attack, a hardware failure, a natural disaster, human error. And it is not measured by whether it exists, but by how fast you are operating again with it, which is a property of how it is stored and whether anyone has ever restored it.
How it works
A backup regime is described by three numbers and one rule. The recovery point objective is how much data you accept losing, which sets how often copies are taken. The recovery time objective is how long you accept being down, which sets how the copies are stored and how restore is performed. Retention is how far back you can go, which decides whether you can escape corruption that was not noticed for weeks.
The rule is the familiar 3-2-1 arrangement: three copies of the data, on two different kinds of media, with one held off site. Against ransomware a fourth property has been added in practice, which is that at least one copy is offline or immutable, meaning the storage itself refuses deletion or modification until a retention period expires. That is the property that survives an attacker who holds domain administrator rights, and it is what an immutable backup is for.
What goes wrong
Modern ransomware operators go for the backups first, and they do it with the credentials they already stole rather than with malware. What we see on tests is a backup server joined to the same directory as everything else, administered by an account in a widely held group, and holding a catalogue that can delete its own retention policy. The copies are then encrypted or deleted before anything on production is touched, which is why an isolated identity plane for backup infrastructure matters more than the storage technology.
The other failure is quieter. Backups that run, are monitored, and have never been restored. Untested backups are not backups. A restore rehearsal is where you discover that the encryption keys are in the vault you did not back up, that the recovery documentation is on the file share that is down, or that the restore takes eleven days at the available throughput.
Where this shows up in an audit
On an internal engagement we look at reachability and identity: who can authenticate to the backup system, whether that path is shared with normal administration, and whether the immutability is enforced by the storage or merely configured in software an attacker with credentials could reconfigure. We do not delete anything to prove it. The finding states the path we could have taken and where the isolation should have stopped it, alongside the date of the last documented restore test, which is the number that predicts how incident response will go.