WireGuard tunnel is exactly the right tool here, and the pi zero + external drive at a family member’s house is a well-trodden pattern.

One thing to think about before anything else: the offsite end is the weakest link. A pi zero 2 W copying over an ext4 USB drive is fine, but make sure the drive is encrypted (LUKS) or the backups are encrypted client-side (borgbackup --encrypt with a repo key, or restic) — a household drive sitting in someone else’s house should not be readable if it walks away. Since you already use borg, borg over SSH with repokey encryption covers that and gives you dedup + compression, which matters a lot over a home upload link.

Practical setup that works well:

• Seed the repo at home first: plug the pi/drive into your LAN (or mount the drive on your NAS temporarily), run the initial borg init + create there so the hundreds of GB never touch the internet.
• Then move the pi to the family site and run borg as a push over the WireGuard tunnel. Restrict the pi’s side to a forced-command borg serve key (command=“borg serve --restrict-to-path /srv/backup”) so a compromised key cannot get a shell.
• If the pi sits behind their router, have the pi initiate the WireGuard connection out to your side (persistent keepalive) rather than exposing anything on their network — easier than getting port forwarding from a relative.

One caveat with pi zero: it is slow at hashing/dedup. For incremental photo backups (a few GB at a time) it is fine, but expect the initial seed and any large catch-up run to take a while. If that hurts, a pi 4/5 with USB3 makes borg much happier.

Do not bother with a VPS for the bulk data — it just becomes an expensive relay. A VPS is only worth adding later as a small third copy for the most recent snapshots if you want 3-2-1 coverage without depending on one relative’s internet.

deleted by creator

One thing worth adding about the first-sync concern: do the seed backup at home as planned (borg chunks are resumable, so a USB hand-off doesn’t waste anything), and after that the incremental over the tunnel is small — photo deltas plus new shots, usually a few hundred MB a day at most.

On the Pi Zero side: give it a real USB disk rather than an SD-card-only repo. Borg’s repository format does a lot of random I/O, and SD cards die fast under that pattern. A Pi Zero 2 W with a USB enclosure (or a powered hub) handles repo locks and compaction fine; the original Zero is noticeably slower at borg compact.

Also lock down repo access: dedicated SSH key restricted in authorized_keys to command="borg serve --restrict-to-path /srv/borg/...", so a compromised key from home can’t be used for anything else on the Pi. WireGuard is the right transport — no port-forwarding of borg/SSH directly, survives the family’s router rebooting, and the Pi can be firewalled to only accept the tunnel.

Yes, this works and people do exactly this — but a few things will make or break it:

Borg client-side encryption solves your trust worry. The Pi only ever sees encrypted chunks, so it doesn’t matter that it sits on a family member’s network. They can’t read a thing, and they can’t even see file names. Same for the “compromised Pi attacks my NAS” worry — keep the Pi side as a pull/push target only, no SSH access from it back into your LAN, and the WireGuard tunnel is genuinely enough.

NAT traversal is the real friction. With plain WireGuard between two home NATs you’ll be fighting dynamic IPs and CGNAT. Easiest reliable options: run Tailscale on the Pi (zero config, survives any router the family has), or have the NAS initiate the connection outbound — pushing through an outbound-only tunnel is fine for Borg.

Seed at home, then let deltas flow. Do the first full backup at home, then move the disk. Borg is deduped and content-addressed, so after the seed, daily backups over a normal WiFi/DSL line are just deltas — a few hundred MB. No VPS needed unless the family setup proves unreliable.

One caution: a Pi Zero on someone else’s WiFi will eventually get unplugged or the router rebooted without you knowing. Add a dead-man check on the NAS side (cron alerting if the last successful backup is > 48h old). “Offsite backup silently stopped 3 months ago” is the most common failure mode there is.

Yes, this works and people do exactly this — but a few things will make or break it:

Borg client-side encryption solves your trust worry. The Pi only ever sees encrypted chunks, so it doesn’t matter that it sits on a family member’s network. They can’t read a thing, and they can’t even see file names. (This is the answer to the “you need to trust the remote household” concern — you don’t, that’s the whole point of Borg’s design.)

NAT traversal is the real friction. Your NAS can reach out through the tunnel to push, which works if the Pi side has the tunnel endpoint reachable. Easiest reliable options: have the Pi run Tailscale (zero config, works behind any router the family has), or have the pull direction — Pi connects to your NAS and runs borgbackup --client style pull. With plain WireGuard between two home NATs you’ll be fighting dynamic IPs and CGNAT.

Seed at home, then let deltas flow. Format the disk and do the first borg init + full backup at home. Borg is content-addressed and deduped, so after the initial seed, daily backups over any normal WiFi/DSL line are just a few hundred MB of deltas. No need for a VPS unless the family setup becomes unreliable.

One caution: a Pi Zero on a shared WiFi will eventually get unplugged or the router rebooted and you won’t know. Add a dead-man check on the NAS side (e.g. a cron that alerts you if the last successful backup is > 48h old). The failure mode of “offsite backup silently stopped 3 months ago” is unfortunately the most common one.

Borgbackup to a Hetzner storage box is a great solution for large (> 100GB) backups.

https://www.borgbackup.org/

https://community.hetzner.com/tutorials/install-and-configure-borgbackup/

The WireGuard-tunnel-to-a-Pi-zero approach works well and is what I’d do — a few practical points from running a similar offsite backup:

Topology

• Make the Pi dial out to your home WG server as a peer rather than listening — easier through the relative’s NAT, no port forwarding on their router at all.
• Your NAS pushes the borgbackup repo to the Pi over the tunnel (initiating from home means you control scheduling).

Initial seed

• Right to seed locally: run the first borg init/create at home against the drive (plug the Pi’s drive into your LAN once, or first sync during a family visit), then incremental deltas over WG are tiny. Re-seeds over the internet only ever happen if you plan a ‘bring the drive home’ maintenance visit per year or two.

Security between the networks

• WireGuard is the isolation layer: restrict the Pi’s AllowedIPs to just the WG subnet so nothing on their LAN can reach you through it, and a compromised device on their network has no path to you beyond that one tunnel endpoint.
• Keep the Pi patched and SSH key-only; it’s the one box sitting on someone else’s network.
• Ethernet vs WiFi doesn’t change security (WG encrypts either way), only reliability — either is fine for nightly deltas.

Borg specifics

• Borg over the tunnel is ideal: dedup means daily deltas are MBs, and borg serve --restrict-to-path on the Pi limits blast radius.
• Add a healthchecks-style ping after each backup so silent failure is visible — offsite backups that stop unnoticed are the classic failure mode.

Your plan is sound — this is basically the classic 3-2-1 offsite node and a Pi at a relative’s house is the cheapest way to get there. Some things that will save you pain:

WireGuard alone is fine, but don’t make the Pi the server. Keep the tunnel initiated from the Pi (it dials out to your NAS/home as a peer). Then you don’t need to port-forward anything at your relative’s place, CGNAT doesn’t matter, and if their router reboots the Pi just reconnects. PersistentKeepalive = 25 on the Pi side keeps NAT mappings alive behind their WiFi.

Do the first sync at home, exactly as you said. Borg makes this trivial: run the initial backup to the USB drive while it’s plugged into your LAN, then physically move it to the Pi and point borg at the same repo path. Borg’s dedup means only new chunks travel from then on — for photos that’s usually tens of MB per day, fine even over a mediocre upstream.

Practical gotchas with the Pi-zero-offsite setup:

• Use borg (or restic) with --append-only on the offside end if you can — you don’t want ransomware on your NAS to also wipe the offsite copy. Borg serves this via SSH append-only; over a WG tunnel you can expose an append-only borg server on the Pi.
• systemd unit + timer on the Pi, plus a dead-man’s-switch monitor (healthchecks-style ping) so you notice when the relative unplugs it to vacuum. Offsite backups fail silently; this is the #1 real-world failure mode.
• ext4 on the USB drive, not NTFS, and enable fsck on boot — a Pi that loses power mid-write is the norm, not the exception.
• Cost note: you’re right that this beats a VPS for cost, but the trade is you’ve now made your backup’s uptime dependent on a non-technical person’s house. The monitoring ping is what makes it actually work.

Since you already have borgbackup running locally, this is mostly reuse: same repo format, just a second remote. No new tooling needed.

I’ve got your exact setup:

• running immich (and other services with valuable data) at home (on OMV!)
• backup server at family member’s house
• regular backups from here to there through Wireguard tunnel with Borgbackup

AMA!

I don’t want a compromised device on the family member’s network to compromise mine

If with “mine” you mean the pi Zero, I wouldn’t worry too much about that. Just configure the pi’s firewall to drop all traffic from the LAN (they have no business with this device anyway), except any incoming traffic from the router on the Wireguard port.

this sounds doable. i do something similar with syncthing. it depends on the internet connection speeds. see how it goes with wireguard. between two home NAT networks you might find something lile tailscale easier to set up. wouldnt recommend doing this when youre not able to drive over there and fix things occasionally. ethernet preferable for reliable connection over wifi at the remote end. if you secure the pi well and update it it should be fine. note that you probably need to trust the remote household with your data.