Exercise 3: Two Years of "Successful" Backups Isn't a Verified Plan — Possible Solution
====================================================================

WHY THIS DOESN'T GUARANTEE A WORKING DISASTER-RECOVERY PLAN: a
backup job reporting "success" only confirms that the job RAN without
throwing an error — it says nothing about whether the resulting file
actually contains complete, valid, restorable data. Silent corruption,
an incomplete dump caused by a connection dropping partway through, a
schema change that broke the restore process months ago without
anyone noticing, or a permissions issue that quietly excluded some
tables can all produce a backup file that looks fine, logs as
"successful," and is completely useless the moment someone actually
tries to restore from it.

Two years of green checkmarks in a job log is not evidence the
underlying data is recoverable — it's only evidence that a process ran
to completion, which is a much weaker claim. The company genuinely
does not know whether their backups work; they've simply never had a
reason to find out.

WHAT SHOULD CHANGE: scheduled, regular test restores — actually
restoring a real backup into an isolated test environment and
verifying the resulting data matches what's expected — need to become
a standing, recurring part of the backup process, not a one-time
setup step. Per this chapter's tip box, the worst possible time to
discover a backup doesn't actually work is during a real incident, when
there's no time left to fix it — regular test restores are what turns
"we assume our backups work" into "we know our backups work," verified
on an ongoing basis rather than left as an untested assumption.