From 8aae261018ede4919b68e5eb8ebb59aff4a0c3c3 Mon Sep 17 00:00:00 2001 From: flan Date: Mon, 13 Jul 2026 14:52:41 +0000 Subject: [PATCH] Nested snapshots validated in production; drop the untested caveat An unattended scheduled backup of a live 252-dataset pool ran through the staging tree end to end: task 5 /mnt/Tap SUCCESS 18m14s - 252 datasets recursively snapshotted; 173 bind mounts built and verified - zero orphaned ZFS snapshots and zero stale mounts afterwards -- the failure that would otherwise have accumulated 251 snapshots on every single run - the same task previously stalled at 74% for over 12 hours reading live files The README said the mount --bind staging step had not been exercised by a live backup run. That is no longer true, so it is removed rather than left to understate the state of the code. The advice to verify your own first backup actually contains child-dataset data stays -- that one is not boilerplate. --- CHANGELOG.md | 11 +++++++++++ README.md | 16 ++++++++++------ 2 files changed, 21 insertions(+), 6 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 5c162d4..24cee6c 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -187,6 +187,17 @@ middlewared-restart case (which empties it) that must not orphan a snapshot tree. One record, on disk, or none. +### Validated in production + +An unattended scheduled backup of a live 252-dataset pool (`/mnt/Tap`, TrueNAS +25.10) ran through the staging tree end to end: + +- 252 datasets recursively snapshotted, 173 bind mounts built and verified +- completed in **18m14s**, `SUCCESS` — the same task previously stalled at 74% + for over 12 hours reading live files +- **zero** orphaned ZFS snapshots and **zero** stale mounts afterwards, which is + the failure mode that would otherwise have accumulated 251 snapshots per run + ### Known issues - Stock `restic_backup()` deletes the ZFS snapshot in its own `finally`, which diff --git a/README.md b/README.md index 270dd98..5b54101 100644 --- a/README.md +++ b/README.md @@ -38,8 +38,8 @@ knowing: log after an update. - If you file a TrueNAS bug report, **remove the patch first** and reproduce on a stock system. -- **Test your restores.** That is true of any backup, but it matters more here — - see [Verifying it works](#verifying-it-works). +- **Test your restores.** True of any backup, but it matters more here — see + [Verifying it works](#verifying-it-works). - Provided as-is, no warranty. See LICENSE. The patch is two independent modules — **providers** (B2/S3) and **nested** @@ -112,10 +112,14 @@ bash install.sh --disable-nested-snapshots With neither flag `install.sh` leaves the setting alone, so `git pull && bash install.sh` won't flip it. The providers module is unaffected either way. -The planner and the snapshot lifecycle have been validated against a real -250-dataset pool. The `mount --bind` staging step has not yet been exercised by a -live backup run, so confirm your first backup actually contains child-dataset -data before relying on it — see [Verifying it works](#verifying-it-works). +Validated end to end on a live 252-dataset pool: an unattended scheduled backup +of `/mnt/Tap` built a 173-mount staging tree, completed in **18m14s**, and left +**zero** orphaned snapshots and **zero** stale mounts behind. The same backup +previously stalled at 74% for over 12 hours reading live files. + +Still: verify your own first run actually contains child-dataset data before you +rely on it — see [Verifying it works](#verifying-it-works). That advice is not +boilerplate; it is the specific thing this feature exists to make true. TrueCloud Backup's **Take Snapshot** option makes restic read from a frozen ZFS snapshot instead of live files. Without it the backup reads data *while apps are