Why "backup completed" doesn't mean you can recover

A backup job that completes successfully tells you one thing: data was written somewhere. It does not tell you whether that data can be read back, whether the restore finishes within a time your organisation can tolerate, or whether the same failure that took down production also compromised the backup.

Three separate, testable claims get collapsed into one green checkmark:

• The copy exists. This is what a completed job actually verifies.
• The copy restores. This requires an actual restore attempt — file integrity checks on the backup file are not the same test.
• The copy survives what took down production. If your backup is reachable and deletable from the same administrative credentials that were compromised, ransomware that gets domain admin gets your backup too.

The fix for the first two is a scheduled restore test with the measured recovery time reported in writing — not assumed from a job log. The fix for the third is immutability: object storage with Object Lock in compliance mode, where a backup object cannot be deleted or modified before its retention expires, by anyone, including an administrator.

None of this is exotic. It's the difference between checking that a fire extinguisher is present and actually testing that it discharges.