Exercise 3: Why Ticket 3 Is a Genuinely Different Case From Chapter 4's Ticket — Possible Solution ==================================================================== WHAT CHAPTER 4's TICKET ACTUALLY WAS ------------------------------ In Chapter 4, a real backup job existed and was supposed to be protecting the folder in question - it had simply silently stopped running three weeks earlier, with failure alerts going to a decommissioned inbox. There was a genuine safeguard in place that failed, and a real, if outdated, backup still existed to partially restore from. WHAT TICKET 3 ACTUALLY IS ------------------------------ Per this capstone, "nothing was ever backed up here in the first place ... this location was simply never in scope." There was no backup job protecting this file at any point - not one that failed silently, not one that degraded, but a location that was never included in the backup policy at all. There is no chain to check, no job log to read, and no partial recovery available, because there was never anything to check or recover from. WHY THIS IS A DIFFERENT KIND OF PROBLEM, NOT JUST A WORSE VERSION OF THE SAME ONE ------------------------------ Chapter 4's ticket is a story about a safeguard that existed and failed - the kind of failure this whole course spends most of its chapters teaching how to detect, verify against, and prevent (job-log checks, test restores, alert monitoring). Ticket 3 is a story about a safeguard that was never designed to exist in that location at all - a scoping and expectations problem, not a verification or monitoring failure. No amount of checking logs or testing restores could ever have caught this, because there was no backup process covering this location to check in the first place. WHY BOTH STILL END WITH DATA LOSS, BUT FOR ENTIRELY DIFFERENT REASONS ------------------------------ The user's practical outcome in both cases is similar - some data is gone. But the appropriate response differs sharply: Chapter 4's ticket rightly triggers escalating a process failure that needs fixing (the alerting gap), while Ticket 3 rightly triggers a conversation about backup policy scope and user expectations (Chapter 6's own assumed-vs-actual RPO gap) - there's no broken process to fix here, only a scope that was never what the user assumed it to be. WHY THIS WORKS AS AN ANSWER ------------------------------ It contrasts what actually existed and failed in Chapter 4's ticket against what never existed at all in Ticket 3, explains why this makes them different categories of problem rather than different severities of the same one, and explains why the appropriate follow-up response differs accordingly.