Exercise 2: Improving a Nightly Full Re-Copy with send/receive — Possible Solution
====================================================================

Explanation:

Re-copying the entire 2TB dataset every night, when only a small
fraction of the data actually changes day to day, means the vast
majority of every night's transfer is spent re-sending data that is
already identical on the remote host from the previous night -- pure
wasted time and bandwidth, proportional to the full 2TB regardless of
how little actually changed.

Per the chapter's own worked example, ZFS's incremental send solves
exactly this: "zfs send -i tank/data@daily-2026-07-13
tank/data@daily-2026-07-14 | ssh backup-host zfs receive backup/data"
sends only the blocks that changed between yesterday's snapshot and
today's, not the entire dataset again. This works because of the same
copy-on-write model covered for Btrfs and shared by ZFS -- a snapshot
is a point-in-time reference, and an incremental send can compute
precisely which blocks differ between two snapshots and transmit only
those, reconstructing the current state on the receiving end by
applying just that delta on top of what it already has from the prior
send.

For this team's scenario, switching to a nightly snapshot plus
incremental send (after one initial full send to establish the
baseline on the remote host) means each night's replication only
has to transfer roughly the size of that day's actual changes -- not
the full 2TB -- dramatically reducing both the time and bandwidth
each nightly backup consumes, while still ending up with a fully
current, complete replica on the remote host every single night.

WHY THIS WORKS AS AN ANSWER
------------------------------
This identifies the specific waste in the current approach (re-transferring
unchanged data every night) and explains, using the chapter's own
incremental-send example, exactly why and how snapshot-based
incremental replication avoids that waste rather than just naming
"send/receive is more efficient" as a given fact.