BorgBackup Server's Security Model: Surviving a Breach on Either Side

Modern ransomware crews don't start by encrypting your data — they start by finding your backups and deleting them. Once the safety net is gone, the extortion math flips in their favor. That's why the most interesting question to ask any backup system in 2026 isn't "how fast does it restore?" but "what happens when one end of it is owned?"

BorgBackup Server, an MIT-licensed web control plane for the venerable BorgBackup deduplicating archiver, has one of the cleaner answers to that question we've seen in the self-hosted space. Its security model is built around a blunt assumption: sooner or later, something in the chain gets compromised — and the design should limit the blast radius on either side.

If a client is compromised

This is the ransomware scenario: an attacker gets root on a server you back up. With most backup setups, root on the client means credentials to the backup target — and the first thing a competent attacker does is purge your history.

BorgBackup Server closes that door with append-only mode enforced at the SSH layer. Each agent connects through an SSH forced command pinned to borg serve --append-only, which means the only operation a client can ever perform against the repository is adding new archives. Deleting, pruning, or overwriting existing backups simply isn't in the protocol vocabulary the server will accept — even for an attacker with full root on the client machine.

Isolation extends sideways, too. Every agent gets its own dedicated SSH user, a unique API key, and a home directory it can't escape — so one popped web server can't enumerate or touch the repositories of the forty other machines reporting to the same backup host. The agents have no shell access at all; they speak Borg's protocol and nothing else.

If the server is compromised

The reverse scenario is where most centralized backup tools quietly fail: the management server is a credential vault for your whole fleet, and owning it means owning everything it backs up.

Here the design choice that matters is the pull architecture. Agents poll the server over HTTPS for work; the server never initiates connections and — critically — never stores SSH credentials or tokens into client machines. An attacker who fully controls the backup server has no path for lateral movement, because there are no keys to steal that point back at your infrastructure.

What about the backup data itself? That's covered by Borg's client-side encryption — AES-256 with the repokey-blake2 scheme by default. Archives are encrypted before they leave the client, so the server stores ciphertext it cannot read. A stolen disk, a leaky datacenter, or a malicious admin gets deduplicated noise without the passphrase.

The application layer is hardened with the boring-but-essential checklist: passphrases, SSH keys and TOTP secrets encrypted at rest with AES-256-GCM under a server-specific key, bcrypt for user passwords, TOTP two-factor with single-use bcrypt-hashed recovery codes, rate limiting on login and 2FA endpoints, parameterized queries, CSRF tokens with constant-time comparison. None of it is novel; all of it is the difference between a tool you can defend and one you apologize for.

S3 sync closes the 3-2-1 loop

A backup architecture isn't finished until it survives the building burning down. The classic 3-2-1 rule — three copies of your data, on two different media, with one off-site — needs that last leg, and BorgBackup Server handles it with built-in S3 off-site synchronization to AWS S3, Wasabi, Backblaze B2, or any compatible object store, including disaster-recovery tooling and orphaned-repository detection.

Stack it up and the 3-2-1 strategy is effectively set in stone: the live data on your machines (one), the encrypted append-only repositories on the backup host (two), and the synced copy sitting in object storage in another failure domain entirely (three). Each layer assumes the one before it can fail — or be actively sabotaged.

The honest caveats

No design exempts you from operations. Append-only mode means pruning old archives becomes a deliberate, server-side administrative act — which is the point, but someone has to do it. Client-side encryption means the passphrase is genuinely yours to manage; lose it and no one can help you. And a web control plane is itself attack surface — keep it patched and behind 2FA, exactly as its own threat model insists.

But the core trade is the right one: a backup system where root on a client buys an attacker nothing but the ability to add more backups, and root on the server buys ciphertext and no road back to your fleet. For teams self-hosting their backup infrastructure, that's the bar — and it's refreshing to see it cleared with mechanisms you can read, audit, and verify yourself.