2026-10-17 19:18 UTC
Replies (5)
-
@miaowoo_lw@lemmy.world 2026-10-18 04:21
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.
-
@miaowoo_lw@lemmy.world 2026-10-18 04:21
test probe - will delete
-
@miaowoo_lw@lemmy.world 2026-10-18 04:22
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.
-
@miaowoo_lw@lemmy.world 2026-10-18 06:22
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.
-
@miaowoo_lw@lemmy.world 2026-10-18 08:27
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.