Why hypervisor-level backup isn’t enough on its own

A PBS backup (or a VM snapshot) captures the entire disk image, which technically includes your Docker volumes, buried inside it. That’s real protection, but it’s coarse: restoring means bringing back the whole VM/container state as of that snapshot, not “just give me yesterday’s Vaultwarden database” or “just show me what this config file looked like before I broke it.” It’s also usually daily at best, meaning up to 24 hours of data loss in the worst case, and it doesn’t give you an easy way to browse what changed between backups.

App-level backup tools solve a different, complementary problem: fine-grained, deduplicated, easily browsable backups of specific directories and volumes, run as often as you want, with the ability to restore a single file or database from a specific point in time without touching anything else.

Restic vs Borg: what actually differs

Both are content-addressable, deduplicating, encrypted backup tools built for exactly this job, and both are solid choices. The practical differences:

Restic is a single static binary, no server component required, and it natively supports a wide range of storage backends out of the box, local disk, SFTP, S3-compatible object storage (Backblaze B2, Wasabi, MinIO), and more, without needing extra infrastructure. This makes it the simpler choice if you want to back straight up to cloud storage (B2 pairs especially well with Restic and is commonly the cheapest S3-compatible option per TB), or if you just don’t want to run a dedicated backup server at all.

Borg (BorgBackup) generally edges out Restic on deduplication efficiency and compression ratio in most real-world comparisons, which matters more the larger your backed-up data set gets. Its tradeoff is that it wants a repository it controls directly, either local/mounted storage or a remote host reachable over SSH running Borg itself (or a compatible remote-repo tool like borgmatic’s companion setups), it doesn’t speak S3-style object storage natively the way Restic does. If you’re backing up to a Linux box you control (a second local machine, a cheap VPS, another homelab box at a different location), Borg’s efficiency advantage is worth having. If your target is cloud object storage, Restic is the more direct fit.

Neither is a wrong choice for a homelab. If you’re already planning to push backups to S3-compatible cloud storage, pick Restic. If you’re backing up to a Linux box you control, pick Borg for the better dedup, or Restic if you’d rather not think about the difference and just want something that works everywhere.

What to actually back up in a Docker-based self-hosted stack

Two categories, and they need different treatment:

Bind-mounted config and data directories. Anything mapped as ./data:/app/data or similar in a docker-compose.yaml, the app’s actual working files, is a plain directory on the host filesystem and both Restic and Borg can back it up directly with no special handling, same as any other files.

Named Docker volumes. These live inside Docker’s own storage area (/var/lib/docker/volumes/ by default), not somewhere you’d casually browse. You can back them up directly from that path, but the cleaner, safer pattern is to spin up a throwaway container that mounts the named volume and pipe the backup tool through it, or stop the dependent container briefly and back up the volume’s underlying directory directly. For anything with a live database inside (Postgres, MySQL, SQLite-backed apps), back up a proper database dump (pg_dump, etc.) alongside or instead of the raw files, a backup taken mid-write on a live database file can be internally inconsistent even if the backup tool itself ran without error.

Also back up the docker-compose.yaml files themselves and any .env files. These aren’t data, but without them a restored volume is just orphaned files with no stack definition to bring them back online. Keeping compose files in a private git repo (never commit .env secrets to it) alongside the data backups from Restic/Borg means a full rebuild is “clone the repo, restore the volumes, docker compose up -d”, not a reconstruction project from memory.

A workable schedule

There’s no need to overthink cadence. A reasonable default: nightly backups via cron (both Restic and Borg are trivially cron-friendly, or wrap them with borgmatic or Restic’s own scheduling helpers for cleaner config management), with a retention policy keeping recent daily snapshots plus a thinning schedule further back, both tools support this natively (restic forget --prune with retention flags, Borg’s prune command). Something like 7 daily, 4 weekly, 6 monthly is a common, sane starting point, adjust based on how much churn your data actually has and how much backup storage you’re willing to spend.

Test the restore, not just the backup

This is the step almost everyone skips and the one that actually matters. A backup job completing without error tells you the tool ran, it doesn’t tell you the backup is actually restorable. Periodically (quarterly is a reasonable minimum) actually restore a real backup, ideally into a throwaway test environment, and confirm the app comes back up correctly with real data intact. Both Restic and Borg support mounting a backup repository as a browsable filesystem (restic mount, borg mount) specifically to make spot-checking easy without doing a full restore every time, use that for lighter-weight periodic sanity checks between the less frequent full restore tests.

Bottom line

Hypervisor-level backups (PBS, VM snapshots) protect you against hardware and whole-box failure. App-level backups with Restic or Borg protect you against the much more common failure mode, a bad update, a mistaken command, a config you overwrote, by giving you fine-grained, frequent, easily restorable copies of the actual data and configs that make your self-hosted stack yours. Run both. Pick Restic if you’re backing up to cloud object storage or want zero server infrastructure, pick Borg if you’re backing up to a box you control and want the better deduplication. Either way, actually test a restore periodically, a backup job that’s never been restored from is a hope, not a plan.

Three copies: what actually counts as a copy

The rule says three, but it means three independent copies, not three places the same failure can take out at once. Your live array plus a snapshot on that same array is not two copies, it’s one copy with a rollback option, a controller failure, a bad firmware update, or ransomware that reaches the snapshot pool takes both out together. A real second copy needs to survive whatever kills the first: separate hardware, ideally a separate power source, ideally not mounted and writable at all times.

At data-hoarder scale, this usually shakes out as: the live/working array (fast, always online, what you actually use day to day), a local backup copy (a second NAS, or a backup-dedicated pool on the same box using different physical disks) that’s slower but survives a drive failure or controller death on the primary, and the off-site copy covering the scenario neither of the first two can, the building itself.

Two different media: don’t overthink this one

“Two different media types” trips people up more than it needs to. The intent is avoiding a single failure mode wiping out every copy at once, a bad batch of drives from the same manufacturing run, a firmware bug specific to one drive model, a RAID controller that corrupts everything it touches. In practice for a data hoarder this means: don’t build your primary array and your local backup out of the exact same drive model bought in the same order, and don’t rely on optical media or tape as your only “different media” unless you’re already invested in that workflow (tape especially becomes genuinely cost-effective again once you’re well past 100TB, LTO media cost per TB drops below spinning disk at that scale, but it’s a real workflow commitment, not a casual add-on).

For most homelab-scale hoarders, “two media types” in practice means two separate arrays, ideally different drive models or at least different purchase batches, rather than a literal tape vs. disk split. That satisfies the intent without forcing a workflow most people don’t actually want.

One copy off-site: the part that actually gets skipped

This is the step almost everyone skips at scale, and it’s the one that matters most, because it’s the only piece of 3-2-1 that protects against fire, flood, theft, or a lightning strike that takes out every drive in the house at once. The honest reason it gets skipped isn’t laziness, it’s that off-site storage for tens of terabytes is genuinely expensive or genuinely inconvenient, usually both. There’s no way around picking a real tradeoff here.

Cloud cold storage (Backblaze B2, Wasabi, or similar). Priced per TB/month, meaningfully cheaper than mainstream cloud storage (S3 Glacier-style tiers exist too but retrieval costs and delays make them a worse fit for a working backup). At 50TB, expect real, ongoing monthly cost, not a rounding error, this is the tradeoff: convenient and automatable, but you’re paying every month indefinitely, and the entire point of a backup, restoring after a real disaster, could mean pulling 50TB back down over a home internet connection, which is a multi-day proposition even on a fast link. Worth pricing out egress/retrieval costs specifically, not just storage cost, before committing, some providers charge meaningfully more to pull data back down than to store it.

A second physical NAS at a friend’s or family member’s house. Zero ongoing cost beyond the hardware itself and whatever bandwidth it uses to sync, and restore speed is whatever your connection to that location allows, often faster than pulling 50TB from the cloud. The tradeoffs are real too: you’re depending on someone else’s power, internet, and willingness to keep a box running indefinitely, and the initial data transfer (the “seed”) for tens of terabytes over the internet can take weeks, most people physically drive the drives to the site once for the initial seed rather than trying to push it all over a home connection.

A rotating drive taken to a safe deposit box or a workplace. The lowest-tech option and the one most likely to actually happen for a solo operator, since it requires no ongoing service cost and no dependency on someone else’s hardware. The tradeoff is currency, a drive that only gets swapped monthly means your off-site copy is, worst case, a month stale, and it’s entirely manual, nothing enforces that the swap actually happens on schedule.

There’s no universally right answer among these three, pick based on what you’ll actually keep doing consistently. A technically superior plan you abandon after two months protects you less than a simpler one you actually maintain.

What to actually back up, since “everything” usually isn’t realistic

At data-hoarder scale, backing up literally everything off-site is often neither affordable nor necessary. Split your data by how replaceable it actually is:

• Irreplaceable (family photos, personal documents, anything that doesn’t exist anywhere else): this is non-negotiable for the off-site copy regardless of cost, it’s usually a small fraction of total array size anyway.
• Expensive to re-acquire but technically replaceable (a media library built up over years of ripping/collecting): worth backing up if the off-site option is affordable at that scale, but a real candidate for being excluded from the expensive tier if cost is the limiting factor, since it’s re-buildable, just slowly and annoyingly.
• Trivially re-downloadable (Linux ISOs, anything you could re-acquire in an afternoon): generally not worth off-site backup budget at all.

Sorting your array into those tiers before pricing out an off-site solution usually cuts the actual off-site footprint by more than half, which materially changes which of the three options above becomes affordable.

Bottom line

3-2-1 doesn’t get easier at data-hoarder scale, it gets more expensive and more inconvenient at exactly the point where skipping the off-site step feels most tempting, because the local array already feels safe with RAID/RAIDZ redundancy. Redundancy protects against a drive failing. It does nothing against fire, flood, theft, or ransomware hitting the whole box at once, that’s what the off-site copy is actually for. Sort your data by how replaceable it is first, then pick whichever off-site option (cloud cold storage, a second box at another location, or a rotating physical drive) you’ll actually keep maintaining, rather than the one that looks best on paper and quietly stops happening after month two.