You have multiple generations of backups. The newest one restores fine.
Ransomware was detected today. But you don't actually know when the
intrusion started.
The natural instinct: restore the latest backup. But "restorable" and
"safe to adopt as your recovery point" are not the same claim.
This is one chapter from a self-study book I've been writing on Backup /
Recovery / Archive design. Here's the short version.
Latest ≠ Correct
A backup taken after compromise may already contain:
- encrypted data
- corrupted state
- some other form of unsafe state
This doesn't mean "newer is dangerous." It means newness alone doesn't
prove correctness.
False signals of "clean"
The chapter lists reasons people wrongly declare a backup safe — none of
which, alone, proves it:
- it restored successfully
- it was protected as immutable
- the hash matched
- antivirus scan passed
- it predates the detection time
Each is a useful signal. None is proof on its own.
Two checkpoints, not one
NIST's guidance on cyber recovery separates verification into two stages:
checking the recovery asset before you use it, and checking the restored
system before you put it back into production. One check is not enough.
The discipline that matters most
"Don't turn 'unknown' into 'safe.'"
When the intrusion start time is uncertain — which it often is — that
uncertainty doesn't disappear just because you'd like to move forward.
The chapter treats "we don't know" as an honest state, not a failure to
be papered over.
Full chapter: https://osiix.com/en/library/backup-recovery-archive-fundamentals/chapter-11.html
Book index: https://osiix.com/en/library/backup-recovery-archive-fundamentals/
