RunBSD

Minecraft Backups

2 August 2026 (updated 8 August 2026)

Overview

The JJAC_Survival_World Minecraft world gets backed up through a chain of unattended steps spread across a few machines. Each branch of the process now has its own page:

  1. Shockbyte Backup Download — every night at 2AM, a Mac mini logs into the Shockbyte panel (behind Cloudflare bot protection) and downloads the latest instance.zip.
  2. backup.sh & DVD Archiving — on that same Mac mini, immediately after the download: unzip, run world-integrity checks, rsync the trimmed (no longer nightly-pruned) world to both gmktec and seneca, archive a dated copy to iCloud (GFS-rotated), and — on a weekly cadence — burn a chunk-pruned DVD and run a lightweight restore verification. Also handles alerting on failure via Mail.app. As of 8 August, gmktec forwards its own copy on to batcave over SSH (ZFS snapshots, no more SMB mount from the Mac) and all SSH auth uses a dedicated automation key instead of an agent-loaded personal one.
  3. ZFS-to-Tape Backup — a daily ZFS snapshot of the world, sent incrementally to tape. Migrated off gmktec/FreeBSD to seneca (Debian Linux) in early August 2026, after ongoing USB/CAM driver issues on FreeBSD.
  4. Tarsnap Backup — a nightly encrypted offsite archive via tarsnap, running on gmktec.
  5. Daily Pipeline-Health Digest — added 8 August 2026, once nightly: pulls today's log lines from all four machines above and emails one combined summary, closing the "Needed improvements" gap below once it's proven stable over a few nights.

Why split like this

Each branch now runs on different hardware and fails independently, so each gets its own troubleshooting page, dependencies, and exit codes rather than one long document covering all of it.

Needed improvements

Identified during a full-pipeline review (August 2026). Individually the branch pages are solid, but looking at the whole flow at once surfaced a few structural gaps. Update (5 August 2026): the first three are now addressed — see backup.sh & DVD Archiving for the details.

  1. Alerting on the Shockbyte/backup.sh branch. Done. backup.sh now has its own mail_alert(), driving the signed-in Mail.app account via AppleScript (no MTA available on this Mac, unlike the tape-backup host) — see "Alerting" on the backup.sh & DVD Archiving page. Fires on unzip/zip/rsync/DVD/iCloud/forward-to-batcave.sh-trigger failures, plus advisory alerts from the integrity checks below. (There's no ssh-agent failure mode left to alert on as of 8 August — see "SSH authentication" on that page.)
  2. Integrity check before fan-out. Done — and more thoroughly than originally scoped. Three checks now run against the raw unzipped world before it fans out: a size/region-file-count trend, an rsync dry-run delete-count check (per destination host), and a level.dat Data.Time check (the most precise of the three — a documented-always-increasing NBT tick counter). See "World integrity checks" on the backup.sh & DVD Archiving page.
  3. Re-evaluate the DVD burn cadence. Done. DVD burns moved from nightly to weekly, and chunk pruning (via mcaselector) now only happens for the DVD's own clone rather than for every destination — gmktec, seneca, iCloud, and batcave all get the unpruned world now. See "DVD burn cadence & DVD-only pruning" on the backup.sh & DVD Archiving page.
  4. One daily pipeline-health digest. Confirming a clean night now means checking logs across four machines (Mac mini, gmktec, seneca, and — as of 8 August — batcave, which now runs its own snapshot/prune script and log) rather than two, since the tape-backup branch moved hosts and batcave stopped being a passive SMB target. Built 8 August 2026 — see the Daily Pipeline-Health Digest page — but not yet confirmed stable across multiple nights in production, so this item stays open until then.

Two related additions came out of the same review pass, not on the original gap list: a GFS-style rotation policy for iCloud's dated folders (batcave moved off dated-folder rotation entirely on 8 August, onto native ZFS snapshot pruning instead — see backup.sh & DVD Archiving), and a weekly lightweight restore-verification check (the "0" in 3-2-1-1-0) against the latest iCloud copy. Both are covered on the backup.sh & DVD Archiving page.