Skip to content

Using storage VPS as Borg backup target with append-only mode

VPS Hosting by admin 5 replies 242 views
4 #1

I've been running this setup for a while and figured I'd document it. The goal is simple: cheap storage VPS as immutable backup target, client holds the keys, provider sees only encrypted blobs.

Architecture:
- Client: your main VPS or homelab box
- Target: storage VPS with SSH access, nothing else running
- Borg init with --append-only on the repo
- SSH forced command restricting to borg serve

The append-only flag means even if client is fully compromised, attacker cannot prune or delete old archives. They can only append. Recovery from client compromise: copy repo elsewhere, strip attacker archives with borg delete --force locally, re-init.

SSH config on target:

Command="borg serve --append-only --restrict-to-path /backups/client1",restrict-ed25519 AAAAC3...

One repo per client. No shared paths.

Client side: export BORG_PASSPHRASE or use keyfile. I prefer keyfile with passphrase via systemd credential or similar.

Cost at our fictional providers: ~$4/TB/month. Cheaper than S3 for warm archives, more control than rsync.net.

Caveat: this does not protect against a malicious provider. They can delete the whole VPS. Offsite to second provider for anything critical.

Questions or improvements welcome. :)

— Admin

sudo make me a sandwich
#2
admin said:
Even if client is fully compromised

Append-only is good. Keyfile without passphrase is bad. Saw repo corrupted once; provider had disk issue; no verify. Now run borg check --verify-data monthly. Ticket open for 3 days; no response.

#3

This is very good guide admin! We make a test with my storage at OVHcloud and is very good. But I have one question: the encryption is client side or server side? I think is client side but my friend say no 😂 can you confirm? I want to use this for my Plex server backups

ping so high I wave back
#4

Legacy IP SSH is disappointing. Dual-stack target would be better. Address space of your backups deserves IPv6 connectivity. 2001:0db8:0000:0000:0000:0000:0000:0001 to backup target is cleaner than 192.0.2.1. NAT is not applicable here, at least. Provider with dedicated IPv6 address space per VPS would be ideal for this architecture.

3 #5

Actually I don't trust no provider with my keys. Not my circus, not my monkeys. Client-side encryption is must, but key management is pain. I keep backup of keyfile on USB in drawer, another on different server. Double negative: I don't have no better idea. XD

#6

I have a question: it is possible to do that with multiple clients to same repo? I try and it is broken. Lol. Now I use one repo per client like you say. Mdr. My english is not perfect sorry 😅

Vive la résistance... électrique

Post a reply

You need an account to reply. Log in or register to join the conversation.

Post reply Preview Save draft