Exercise 3: Why a Direct Live Backup Risks Corruption, and How the Snapshot Workflow Avoids It — Possible Solution
====================================================================

Why a direct backup risks corruption:

Per the chapter, "backing up a live, actively-written database file
directly risks capturing an inconsistent, mid-write state -- a backup
that looks complete but is actually corrupted, because different
parts of the file were captured at different moments while writes
kept happening in between." A backup tool like tar reads a file's
contents sequentially, from beginning to end, and this read process
itself takes real, non-zero time for any file of meaningful size. If
the database keeps writing to that same file WHILE the backup tool is
still in the middle of reading it, the backup ends up containing a mix
of "old" data (the parts already read before a write happened) and
"new" data (the parts read after), even though the live database's own
internal logic never intended for those two states to coexist in a
single consistent snapshot. The resulting backup file can look
complete -- the right total size, no read errors -- while actually
representing a state the database was never really in at any single
point in time, which can make it unusable or actively misleading when
restored later.

How the LVM snapshot workflow avoids this:

Per the chapter's own workflow, the LVM snapshot is taken first,
"near-instantaneously, freezing the origin volume's exact state at
that moment from the snapshot's own point of view -- while the
original keeps being written to completely normally, with essentially
no downtime." From the instant the snapshot is created, the backup
tool reads not from the live, still-changing origin volume, but from
the snapshot -- a distinct volume whose own content is fixed at
exactly the moment the snapshot was taken, per the chapter's own COW
mechanism (old block contents are preserved in the snapshot before
being overwritten on the origin). Because the snapshot's own view
never changes for as long as it exists, tar can take however long it
needs to read through it completely, with a fully consistent, single-
point-in-time view throughout -- regardless of how much the live
database continues to change on the original volume during that same
window.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the actual mechanism of the corruption risk (a
sequential read racing against ongoing writes, producing a
never-really-existed mixed state) and then explains, using the
chapter's own workflow, exactly what property of the snapshot (a
frozen, unchanging point-in-time view) eliminates that race.