Snapshots Aren't Backups: Building the Lab's Safety Net

The short version

In October 2026 my homelab crossed a line: it stopped being a toy and became load-bearing. It held the domain controller, the DNS for the whole house, and — after I walked away from Google Drive — the only copy of my family's files, on a self-hosted Nextcloud. It had no VM-level backups. None. Snapshots, optimism, and a nice vSAN were the entire disaster-recovery plan.

This is the build that fixed it: Veeam Backup & Replication Community Edition on a dedicated backup VM, a local repository on ReFS, restic shipping everything off-site to Backblaze B2 every night, and a separate scheduled backup for vCenter itself. It cost zero dollars in licensing. It has been restore-tested, and its first fully unattended weekend passed every check I set for it.

What "done" meant before I started

Homelab projects die of vague goals, so the requirements went on paper first:

  • Cover what matters. The domain controller, Nextcloud, both Pi-hole DNS servers, and the operations appliance. Five VMs.
  • vCenter covers itself. The VCSA doesn't sit in a Veeam job the way a normal VM does, so it needed its own answer, not an exception I meant to get back to.
  • An off-site copy, encrypted. A backup that lives in the same rack as the thing it protects is a copy, not a backup.
  • Restore-tested. A backup you have never restored is a rumor. The build wasn't done until something had been brought back from it.
  • Clamped. Dedicated accounts, scoped access, nothing with domain-admin-for-convenience. A backup system is the most powerful box in the building; it gets treated that way.

The design

Veeam Backup & Replication 13.1 Community Edition runs on its own Windows Server 2025 VM whose only job is backups. Jobs land on a local repository formatted ReFS with 64K blocks — ReFS block cloning is what makes Veeam's synthetic fulls cheap: the weekly "full" is assembled from blocks already on disk instead of re-reading every VM. The Saturday synthetic full for the fleet came to 50.9 GB and finished in 28 minutes with zero warnings and zero errors.

Off-site is a second tool doing one job. A scheduled restic run at 02:00 ships the repository to a private Backblaze B2 bucket, encrypted, every night. Local copy for fast restores, cloud copy for the house-is-gone scenario, different failure domains, no single product trusted with both halves.

vCenter got its own lane: scheduled file-based backups from the appliance itself, landing on an SMB share on the backup server. That share has exactly one account with access, a dedicated local account created for nothing else. The share retains seven sets, and the backup itself is encrypted. Nobody's daily credentials touch it.

The exclusions, which are also design

Two things are deliberately not backed up:

  • The VCF license server is excluded because it's rebuildable. If it ever dies, it gets redeployed and relicensed; spending backup budget on it protects nothing.
  • Plex media is excluded because it's re-acquirable. What is backed up is Plex's data directory — the configuration, metadata, and watch state that can't be re-downloaded. That backup is restic too, and it has been restore-tested like everything else.

Knowing what not to back up is half of backup design. The other half is proving the rest works.

The proofs

The build ran October 15–16, 2026. The first full backup and the first restore test happened the same day — not "later," not "when I get to it." A VM came back from the repository and booted. Only then did the schedule go live.

The real exam was the first fully unattended weekend, October 17–18:

  1. The Saturday synthetic full completed 5-for-5 VMs, zero warnings, zero errors.
  2. The 02:00 restic shipment to B2 returned success.
  3. The first scheduled vCenter backup set landed on its share, on time, without a hand on it.
  4. The rest of the lab's nightly automation ran through the same window untouched.

Four for four. That's when I wrote "now it's a properly maintained lab" in my notes, and I meant it as a technical statement, not a celebration.

The honest wrinkles

Two, for the record. The backup server runs a Windows Server evaluation license, because homelab; its rearm date is on my calendar like any other maintenance item, months ahead. And the whole design rests on Community Edition limits — five VMs is a comfortable fit, but a bigger fleet would mean rethinking the licensing, and I'd rather say that in the article than have a reader discover it in the third paragraph of a forum reply.

The lesson

Everything in this lab had redundancy except recovery. vSAN tolerates a host dying; it does nothing for a fat-fingered delete, a corrupted VM, or a bad patch — those replicate faithfully. The fix wasn't a product, it was a standard: no system is "done" until it has survived being restored. Backups are a promise. Restores are the proof.


Daniel Barnes

Fort Worth, TX.

Technical Support Engineer, VMware Cloud Foundation Division at Broadcom. Customer-facing work on VMware vSAN, ESXi, and VMware Cloud Foundation — storage, HCI, and virtualization troubleshooting.

Started in 2018.

Homelab is a 3-host vSAN ESA cluster on ESXi 9.1 running self-hosted services (Nextcloud, Pi-hole DNS, Veeam). That's where the write-ups come from.