Capstone — Three Data-Loss Tickets, Start to Finish
Backup & Disaster Recovery Basics
Chapter 10 · Capstone — Three Data-Loss Tickets, Start to Finish
Nine chapters built the toolkit — backup types, the 3-2-1 rule, verifying jobs actually ran, proving a restore genuinely works, RTO/RPO, diagnosing failures, backup security, and honest communication. This capstone runs three fresh tickets through that toolkit end to end, matching the three-scenario shape most of this subject's own courses use.
Ticket 1: A Ransomware Attack, Survived by One Copy
Overnight, ransomware compromises administrative credentials, encrypts production servers, and deletes every backup its access reaches.
Every connected and network-accessible backup is gone, exactly the pattern Chapter 3 warned about. One copy survives: an immutable offsite backup, protected by a retention lock the compromised admin credentials couldn't override — Chapter 8's own defense working exactly as intended.
Rather than assuming the surviving copy is automatically good, the team applies the same discipline Chapter 5 built for routine testing — actually restoring it to a real, isolated environment and confirming the result is genuinely usable, not just present.
The restore stalls with an unrecognized-format error. Rather than concluding the surviving backup is also bad, the team recognizes this specific signal from Chapter 7's own catalog — the backup software has been upgraded since this copy was created — and completes the restore using a compatible tool version.
Leadership is given the organization's own pre-agreed RTO, not an optimistic guess, along with a direct acknowledgment that the connected backups were lost and why the offsite copy alone made recovery possible at all.
Ticket 2: A Problem Found Before It Became a Disaster
A routine, scheduled test restore — the discipline Chapter 5 built specifically for this — turns up a real problem, with no actual emergency driving it.
Restoring a mid-week point in the incremental chain fails partway through. Per Chapter 2's own weakest-link warning, one corrupted incremental has broken every day after it in the chain — found only because the test restore was actually attempted, not assumed to be fine.
Checking the job's own logs per Chapter 4 reveals a warning had actually been logged the night the corruption occurred — present in the record the whole time, simply never reviewed until this test restore prompted someone to look.
Because this was caught during a scheduled test rather than during a real emergency, there's time to fix the underlying job and rerun a clean backup — exactly the outcome Chapter 5's own testing cadence exists to make possible.
Ticket 3: A Genuinely Honest "No"
A user requests recovery of a file that turns out to have lived only on a personal laptop, in a location the organization's backup policy never covered.
Unlike Chapter 4's own ticket — where a real backup existed but had silently failed — this is a different case entirely: nothing was ever backed up here in the first place. There's no chain to check and no job log to read, because this location was simply never in scope.
The gap is a clear illustration of the difference between an assumed and an actual RPO — the user believed "everything is backed up," a belief the organization's own actual policy never supported for personal devices.
The user is told plainly and directly that this specific file cannot be recovered — no vague language about "exploring options" that were never real, per Chapter 9's own reasoning about why a direct answer is more respectful than a delayed one.
Chapter Attribution
| Technique used above | Source chapter |
|---|---|
| "Backup exists" ≠ "recoverable" as the core distinguishing question (Ticket 3) | Chapter 1 |
| The weakest-link incremental chain failure (Ticket 2) | Chapter 2 |
| Ransomware targeting accessible backups specifically (Ticket 1) | Chapter 3 |
| Reading job logs to confirm a warning had already been recorded (Ticket 2) | Chapter 4 |
| Verifying a surviving backup actually restores before trusting it (Ticket 1); routine test-restore discipline catching a real problem early (Ticket 2) | Chapter 5 |
| A pre-agreed real RTO for leadership (Ticket 1); the assumed-vs-actual RPO gap (Ticket 3) | Chapter 6 |
| Diagnosing a format-incompatibility restore failure correctly (Ticket 1) | Chapter 7 |
| An immutable, retention-locked offsite copy surviving compromised credentials (Ticket 1) | Chapter 8 |
| Honest leadership communication (Ticket 1); a direct, respectful "no" (Ticket 3) | Chapter 9 |
Honest Scope Note
- No specific backup-vendor product tutorials — tools differ widely, this course teaches transferable verification discipline instead
- No legal or regulatory data-retention requirements — jurisdiction- and industry-specific, out of scope here
- No disaster-recovery-site or failover infrastructure design — a genuinely separate discipline from backup and restore itself
- No budget or cost analysis for backup infrastructure — a business decision, not a support-verification one
- No substitute for an organization's own actual disaster-recovery runbook — this course builds the judgment to use one well, not the runbook itself
Hands-On Exercises
Explain why the surviving immutable backup in Ticket 1 was still verified via a test restore before being trusted, rather than being used immediately just because it had survived the attack.
📄 View solutionExplain what specifically made Ticket 2 a genuine success story rather than just another failure, given that a real corrupted backup was involved either way.
📄 View solutionExplain why Ticket 3 is described as a "different case entirely" from Chapter 4's own ticket, even though both end with the user losing some of their data.
📄 View solutionChapter 10 Quick Reference — Course Complete
- Ticket 1: a ransomware attack survived only through an immutable offsite copy, verified rather than trusted blindly, restored despite a format snag, communicated honestly
- Ticket 2: a scheduled test restore catching a broken incremental chain before it ever became a real emergency
- Ticket 3: a genuinely honest "no" for data that was never actually in the backup's scope at all
- The recurring theme across all ten chapters: "we have backups" and "we can recover" are two different claims, and only testing proves the second one
- This closes Backup & Disaster Recovery Basics, 10/10 chapters — the eighth complete course under the Technical Support subject