Exercise 3: Why the NAS Fire Example Connects to Chapter 1's Central Claim — Possible Solution
====================================================================

CHAPTER 1's ORIGINAL CLAIM
------------------------------
Per Chapter 1, "a backup job reporting 'success' confirms exactly one
thing: data was copied somewhere. It confirms nothing about whether
that copy is complete, uncorrupted, or genuinely restorable into a
working state."

WHAT ACTUALLY WENT WRONG IN THE NAS EXAMPLE
------------------------------
Per this chapter, "backups have run successfully every night for
years" - the copy operation itself was never the problem. The data was
genuinely, completely, correctly copied, night after night, exactly as
intended. The failure had nothing to do with the backup job's own
execution.

WHY THIS IS A DIFFERENT KIND OF FAILURE THAN CHAPTER 1 DESCRIBED, BUT
THE SAME UNDERLYING LESSON
------------------------------
Chapter 1's own examples were about a copy being incomplete or
corrupted despite a success status - a failure of the data itself.
This chapter's example is about the copy being perfectly correct, but
stored somewhere that couldn't survive the actual disaster - a failure
of location, not of the copy operation. Different specific cause, but
the same underlying pattern: a "success" status describes only the
copy step, and says nothing about whether the overall backup strategy
will actually work when needed.

WHY THIS IS DESCRIBED AS "CONNECTING DIRECTLY" RATHER THAN AS A
SEPARATE ISSUE
------------------------------
Both examples share the exact same structural gap: a green checkmark
that keeps appearing, night after night or job after job, while a
completely separate condition (data integrity in Chapter 1's case,
physical location in this chapter's case) determines whether the
backup would have actually helped. Neither gap would ever show up in
the job's own status log - both are invisible until an actual recovery
is attempted.

WHY THIS MATTERS FOR THE COURSE AS A WHOLE
------------------------------
It shows that "a success status doesn't prove recoverability" isn't a
single narrow warning about corrupted files - it's a general principle
with multiple independent ways to go wrong, of which data corruption
(Chapter 1) and unsafe storage location (this chapter) are two
separate examples.

WHY THIS WORKS AS AN ANSWER
------------------------------
It restates Chapter 1's original claim, explains that the NAS example
represents a different specific failure (location, not data
integrity) than Chapter 1 described, and explains why both still count
as the same underlying pattern - a success status that says nothing
about the specific way recovery could actually fail.