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.

What was lost, and what wasn't (Chapters 3 and 8)

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.

Verifying before trusting it (Chapter 5)

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.

A snag, diagnosed correctly (Chapter 7)

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.

Communicating the real timeline (Chapters 6 and 9)

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.

The finding (Chapters 2 and 5)

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.

Confirming it wasn't a total surprise (Chapter 4)

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.

The payoff

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.

Confirming the gap (Chapter 1)

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.

Setting the record straight (Chapter 6)

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 hardest conversation (Chapter 9)

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 aboveSource 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

What this course deliberately doesn't cover
  • 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

Exercise 1

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 solution
Exercise 2

Explain 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 solution
Exercise 3

Explain 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 solution

Chapter 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