Offsite Backup on a Budget: A Pi at Your Sister's House

Everyone who has read the 3-2-1 rule and actually implemented it hits the same wall at the same place: the off-site copy. The three copies are easy, the two media types are easy, and then you get to “one copy off-site” and the cheap options all feel like a tax. Cloud object storage is a monthly bill that grows with your data. A safety deposit box full of rotated drives means driving somewhere every fortnight, and I know myself well enough to know that after three trips I would stop going.

So a few years ago I did the obvious thing and put a Raspberry Pi with a single USB disk in my sister’s spare room. It has been sitting there quietly ever since, receiving encrypted backups every night over an encrypted tunnel, costing me roughly the price of a pint a year in electricity and nothing at all in monthly fees. This post is the whole recipe: the hardware, the network path, the encryption, and the append-only backup server that makes the thing genuinely safe rather than merely present.

Why a relative’s spare room beats the cloud

The off-site copy exists to survive events that take out your whole home at once: fire, flood, theft, a lightning strike that fries everything on the same mains. That is the entire job. It does not need to be fast, it does not need five-nines uptime, and it does not need to be in a data centre. It needs to be geographically separated from your house and under enough control that you can trust the encryption.

A relative’s house 20 miles away satisfies the geography for free. The economics are the real argument. A second-hand Pi 4 and a 4 TB USB disk is a one-off cost of well under a hundred pounds, and the running cost is a few watts drawn continuously — call it £3 to £5 a year at UK electricity prices. Store the same few terabytes in cloud object storage and you are paying that every month, forever, with egress fees waiting for you on the day you actually need to restore. The Pi pays for itself inside a year and then keeps paying you back.

There is a social cost the cloud does not have: you are putting a box in someone else’s home and asking them not to unplug it. I will come back to that, because “my sister vacuumed and switched off the wrong socket” is a genuine failure mode you have to design around.

The hardware, kept deliberately boring

The parts list is short on purpose. Exotic hardware is one more thing to fail in a location you cannot easily visit.

• A Raspberry Pi 4 (2 GB is plenty; restic’s server side is light) or any equivalent single-board computer you have spare.
• A good-quality USB 3.0 disk. A 2.5-inch drive powered off the Pi’s USB bus is tidy, but a 3.5-inch drive with its own mains power supply is far more reliable — under-powered USB disks are the number-one cause of mysterious corruption on Pi setups.
• A decent power supply for the Pi itself. Cheap ones cause under-voltage, and under-voltage on a Pi manifests as random filesystem corruption that looks exactly like a failing disk.
• Ideally boot the Pi from an SSD or a good USB stick rather than a microSD card. SD cards wear out under constant writes and die at the worst possible moment.

Do not run the backups onto the SD card. The card is the operating system; the USB disk is the data. Keeping them separate means a dead card costs you a ten-minute reflash while the data survives untouched on the USB disk.

Getting a network path in without a public IP

The Pi lives behind your relative’s home router, which almost certainly has no static public address and may well be behind carrier-grade NAT, so there is nothing to port-forward to even if you wanted to. The clean answer is a mesh VPN, and Tailscale is the least-effort option that exists. It builds a WireGuard tunnel between your machines using their coordination server for the handshake, punches through NAT on both ends, and gives every device a stable address on the 100.64.0.0/10 range that never changes even when the underlying home IP does.

Install it on both the Pi and the machine that will push backups:

1
2
3

# On the Pi (Raspberry Pi OS / Debian)
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --hostname backup-pi --ssh

The --ssh flag lets you reach the Pi over Tailscale SSH, which matters when the box is 20 miles away and you need to poke at it. Once it is up, the Pi is reachable from your homelab as backup-pi (or backup-pi.your-tailnet.ts.net) regardless of what your sister’s ISP does to her public address. If you would rather run plain WireGuard and own the whole tunnel yourself, that works too, but you then need one end with a reachable address, which is exactly the problem Tailscale solves for you.

Lock the tailnet down with an ACL so the Pi can only be reached by the machines that back up to it, and cannot itself reach into your home network. The backup box should be a dead end, so that if it is ever stolen it is a stolen encrypted disk and a de-authorised node, nothing more.

Encrypt the disk at rest, because it lives in someone else’s house

The single most important thing about a backup you keep in a building you do not control: assume the disk could be stolen. Encrypt it at rest with LUKS so that a stolen drive is a paperweight.

1
2
3
4
5

sudo cryptsetup luksFormat /dev/sda
sudo cryptsetup luksOpen /dev/sda backupcrypt
sudo mkfs.ext4 /dev/mapper/backupcrypt
sudo mkdir -p /srv/backup
sudo mount /dev/mapper/backupcrypt /srv/backup

Now the awkward question: how does a headless Pi in another town unlock that disk after a power cut, when it reboots with nobody there to type the passphrase? You have two honest choices, and you should pick deliberately.

The convenient option is a key file stored on the Pi’s own boot media, referenced from /etc/crypttab, so the disk auto-unlocks on boot. This protects against the disk being stolen on its own, which is by far the likeliest theft. It does not protect against the whole Pi being stolen, because the key travels with it. For most people, “someone nicked the little computer and the disk” is an acceptable-if-annoying risk, and auto-unlock is worth it for the uptime.

The paranoid option is dropbear-initramfs, which brings up SSH in the initramfs so you can log in over the tunnel after a reboot and type the passphrase remotely. The disk key never lives on the box. The cost is that every power cut means you have to notice and manually intervene before backups resume. I run auto-unlock, because a backup target that silently stops working after a power cut is worse than one with a slightly weaker theft story. Decide based on what you are actually protecting against.

The backup server: append-only restic REST

You could just restic backup over SFTP to the Pi, and that works. I run the restic REST server in append-only mode instead, for one reason: ransomware resistance. If my homelab is compromised, the attacker gets the credentials my backup job uses. In append-only mode those credentials can write new data and read nothing back, and critically cannot delete or overwrite existing snapshots. A compromised client cannot wipe its own backup history, which is the whole game.

Run it in a container on the Pi:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# /srv/rest-server/docker-compose.yml
services:
  rest-server:
    image: restic/rest-server:latest
    restart: unless-stopped
    ports:
      - "8000:8000"
    environment:
      OPTIONS: "--append-only --private-repos"
    volumes:
      - /srv/backup/restic:/data

--append-only is the important flag; --private-repos scopes each user to their own repository path. Add a user with the bundled htpasswd helper, then point your homelab’s nightly job at the Pi over the tunnel:

1
2
3

export RESTIC_REPOSITORY="rest:http://backup-pi:8000/homelab"
export RESTIC_PASSWORD="the-repo-encryption-passphrase"
restic backup /srv /etc /home --tag nightly

Note the two separate secrets doing two separate jobs: the REST server’s htpasswd login controls access, and RESTIC_PASSWORD is the encryption passphrase that means the Pi never sees a byte of your plaintext. Even your sister, even someone who steals the whole unit and somehow defeats LUKS, holds only ciphertext.

Because the client cannot delete anything in append-only mode, pruning has to happen on the Pi itself, out of band, by a trusted local process that is not reachable from the internet. A weekly restic forget --prune run locally on the Pi against the repository keeps it from growing forever while never handing delete rights to the machine being backed up.

Monitoring: know it is alive before you need it

A backup target you cannot see is a backup target you cannot trust, and this one lives where you cannot walk over and check the lights. Wire up a dead-man’s-switch style alert so that silence is what triggers the alarm. Have the Pi’s local prune job, on success, ping a healthcheck URL:

1
2

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune \
  && curl -fsS -m 10 https://hc.example.com/ping/your-uuid

If the ping stops arriving, the healthcheck service emails you. That covers the disk filling up, the tunnel dropping, the SD card dying, and the “someone unplugged it” case all at once, because every one of them ends in the ping not arriving. This matters more here than in any other backup because you cannot glance at the box.

Troubleshooting

Under-voltage corruption. If you see dmesg warnings about under-voltage, or ext4 errors that come and go, suspect power before you suspect the disk. Use a good Pi PSU and a self-powered 3.5-inch drive. A USB disk drawing too much from the Pi’s bus will corrupt data intermittently and drive you mad chasing a “failing” drive that is fine.

The tunnel is up but restic times out. Check that the container is actually listening (docker compose ps) and that Tailscale ACLs permit the backup client to reach the Pi on port 8000. A tailscale ping backup-pi from the client confirms the mesh path independently of the app.

Disk did not unlock after a power cut. If you chose auto-unlock, check /etc/crypttab and the key file survived. If you chose dropbear-initramfs, this is expected — SSH into the initramfs and enter the passphrase. Either way, the healthcheck ping stopping is what should have told you.

Backups suddenly failing with “repository is append-only”. That is the server doing its job. Any operation that would delete or rewrite data is refused for the client. Run prune locally on the Pi, never from the client.

First backup is painfully slow. The initial run ships everything and is gated by your home upload speed, which is the narrow pipe here. Seed the repository at home over the LAN, then physically carry the disk to your relative’s house for the first sync. Every night after that only moves changed chunks and finishes in minutes.

Verdict: is it worth it, and for whom?

If you have more than a token amount of data and you have been putting off the off-site leg because the cloud bill annoys you, this is the setup I would push you towards. The up-front effort is a weekend; the running cost is a few pounds a year and one awkward conversation about not unplugging the little box. In return you get a genuinely off-site, encrypted, ransomware-resistant copy that satisfies 3-2-1 without a subscription.

It is not for everyone. If you have only a few gigabytes of documents and photos, a cloud object bucket is simpler and the pennies-per-month cost is beneath caring about. If you cannot rely on the host location — a flatmate who moves every year, a relative who genuinely will unplug it — the social fragility outweighs the savings. And whatever you build, the copy is worthless until you have proved it comes back: go and read the restore you never rehearsed, then actually pull a file back from that Pi before you trust it with anything you would cry over losing.