Tim Farrell

Homelab · Guide

A backup plan that survives the thing that kills backups

My server's only backup was on the same drives as the data it protected. This is the nightly setup that replaced it, and the part that is still missing.

October 2026 · 7 min read

In September I went looking for my server's backup and found it on the same pair of drives as the data it was protecting.

Every service on the server keeps its settings and databases in one folder of app data: the photo library's database, the media server's watch history, the DNS filter's lists. That folder lives on a mirrored pair of NVMe drives. The only backup of it was a 21 GB folder from July 30, sitting on that same pair, left behind when I renamed some shares. The backup job had been switched off since the same day. One failure of that pool would have taken the data and the backup together.

This is the fix: a nightly copy to a second small box, in a format the server can add to and never delete.

SERVERBACKUP BOXApp dataevery container's folderArchivesone tar per app, uncompressedBackrest04:00 boot drive04:30 archives03:00 stop, archive,start againadd onlyhome networkWeekly cleanupSun 05:00 forget, prune, checkrestic repositoryencrypted, deduplicatedrest-serverappend-only: new snapshots in,nothing deleted from outsideOff-site copynot built yet
Every night, from app data to a box that will not let the server delete anything. The dashed box is the part that is still missing.

What this gets you

  • A nightly snapshot of every app's data and the server's boot drive, on a different machine.
  • History. Any night's version can come back, one file or the whole lot.
  • Protection from the server itself. The server can write new backups and cannot delete old ones, so ransomware or a bad script on the server cannot reach back and wipe them.
  • Restores from a web page, by clicking through folders.

What you need

  • A second always-on box. Mine is a retired Datto Alto, a palm-sized backup appliance that businesses used to rent, with a 480 GB SSD and Debian. It draws about 5 W. Any spare mini PC or old laptop works.
  • restic, which does the backing up. It encrypts and deduplicates, so thirty nights of a 20 GB folder take far less than 600 GB.
  • rest-serveron the second box, in append-only mode.
  • Backreston the server, a web interface for restic that runs the schedules and does the restores.
  • On Unraid, the Appdata Backup plugin.

How it fits together

  1. 03:00, on the server

    The Appdata Backup plugin stops each container in turn, writes its folder to a tar archive, and starts it again. A container that is stopped cannot be halfway through writing its database, so every archive is consistent.

  2. 04:00 and 04:30, on the server

    Backrest sends the boot drive and the night's archives to the second box over the home network.

  3. On the second box

    rest-server stores them in append-only mode: new snapshots in, nothing out.

  4. Sunday 05:00, on the second box

    A weekly job there forgets old snapshots, prunes the space they used, and checks the repository. The server's credentials cannot do this, which is the point.

The archives are left uncompressed on purpose. restic deduplicates, and it finds far more repeated data in a plain tar than in a compressed one. The first night's repository was 17.8 GB. The second night added about 400 MB.

I asked about Syncthing along the way, because a live mirror sounded simpler. A mirror copies deletions and ransomware-encrypted files as faithfully as everything else, so it protects against a dead disk and nothing more.

The parts that bit me

  • The photo database was silently skipped. Its folder sits just outside the path the plugin backs up, so the first night's run finished green without it. I only caught it by opening the archives and checking what was inside. It is in now, along with the app's compose file and settings.
  • Backrest's machine name changed with every update. restic labels each snapshot with the host it came from, and inside a container that is the container's ID, which is new after every update. Cleanup grouped by host would have treated each update as a different machine and kept everything forever. The fix was a fixed hostname for the container and grouping the weekly cleanup by tag.
  • Some containers borrow another container's network. Stopping the lender for the backup cuts the others off, so that one is marked "don't stop".
  • A backup that has never been restored is a guess. I restored a file through Backrest's web page and compared it byte for byte, then restored again directly on the second box with the server out of the picture.

Where it falls short

Nothing leaves the house yet. A fire, a flood or a theft takes the server and the second box together. The next step is an encrypted copy of the restic repository toBackblaze B2, which at about 30 GB costs a few dollars a year. Home Assistant's own backups also land on the server every night but are not yet in Backrest's plan.