Homelab from Zero #6: Backups that actually happen

6/23/2026/10 minutes to read/Tags: homelab-from-zero, homelab, devops

This is part 6 of Homelab from Zero. In part 5 you added Uptime Kuma and you now know the moment a service goes down. Today we make sure that when something goes badly wrong (a failed drive, an accidental rm -rf, a corrupted volume), you don’t lose the data you’ve spent weeks building up.

The 3-2-1 rule

Three copies of your data, on two different media, with one copy offsite. That’s it. It sounds like overkill until the morning you boot your server and the drive is silent.

For a homelab you can start with just copies 1 and 2 and add the offsite later. What matters now is that the backup actually runs automatically and that you’ve tested restoring from it.

What to back up

Look at the Docker volumes you’ve created across the series:

• ~/uptime-kuma: your monitors and alert history
• /etc/pihole and /etc/dnsmasq.d, Pi-hole’s config and block lists
• ~/heimdall: your dashboard layout

These directories are small (a few hundred megabytes at most) and annoying to rebuild by hand. They’re what we’ll back up.

Step 1: Install Restic

Restic is a fast, encrypted backup tool. One binary, no daemon.

sudo apt install restic

Confirm it’s there:

restic version

Step 2: Initialise a repository

A Restic repository is a directory where Restic stores snapshots. Create one on a USB drive or a second disk mounted at /mnt/backup:

restic init --repo /mnt/backup/homelab

Restic asks for a password; pick a strong one and write it somewhere safe offline. Lose this and you lose access to all your backups.

Step 3: Take your first snapshot

restic backup \
  --repo /mnt/backup/homelab \
  ~/uptime-kuma \
  ~/heimdall \
  /etc/pihole \
  /etc/dnsmasq.d

Restic prompts for the repository password, then deduplicated chunks the data and stores only what changed since the last run. The first snapshot takes the longest; subsequent ones are fast.

List snapshots to confirm it worked:

restic snapshots --repo /mnt/backup/homelab

You should see one entry with a snapshot ID, a timestamp, and the paths.

Step 4: Test a restore

This is the step most people skip, and it’s the only step that actually matters. A backup you’ve never restored is a hope, not a backup.

Restore the Uptime Kuma directory to a scratch path and check the files:

restic restore latest \
  --repo /mnt/backup/homelab \
  --target /tmp/restore-test \
  --include ~/uptime-kuma

Browse /tmp/restore-test and confirm the files look right. If they do, delete the scratch copy. You now have proof your backup works.

Step 5: Automate it with cron

Open the crontab for your user:

crontab -e

Add one line at the bottom to run the backup every night at 3 AM:

0 3 * * * restic backup --repo /mnt/backup/homelab --password-file /root/.restic-pw ~/uptime-kuma ~/heimdall /etc/pihole /etc/dnsmasq.d >> /var/log/restic.log 2>&1

Create /root/.restic-pw (or ~/.restic-pw) containing just the password on a single line, then lock it down:

chmod 600 ~/.restic-pw

Check the log after the first scheduled run to confirm it completed.

Keep snapshots from piling up

Restic keeps every snapshot unless you tell it otherwise. Prune old ones on a schedule (monthly, say) so the backup drive doesn’t fill silently:

restic forget --repo /mnt/backup/homelab \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 3 \
  --prune

Add this after the backup line in your crontab (or run it on a separate weekly schedule).

What you have now

Your lab data is automatically snapshotted every night, encrypted at rest, and you’ve personally confirmed you can restore from it. One attached drive doesn’t satisfy the full 3-2-1 rule yet (offsite is the next step), but automated, tested, local backups are already miles ahead of no backup at all.

In part 7 we look at reverse proxies: what they are, why your lab needs one, and how they set up everything that comes next.