Encrypt Your Backups Before They Leave the Server

Encrypt your backups on the server, before they ever leave it, so that whatever storage they land in only ever holds ciphertext. This is client-side encryption, and for a self-hosted setup it is not optional. Your offsite backups sit in object storage on someone else's infrastructure, and the entire safety of that arrangement rests on one fact: they cannot read what you sent. If you encrypt before uploading, a breach of that bucket, a misconfigured permission, or a curious provider employee exposes nothing but noise. If you do not, your whole business is sitting readable in a bucket you do not fully control. I encrypt every backup client-side across my portfolio, and the reason is simple: the copy you send away is the copy you have the least control over.

Why the offsite copy is the exposed one

Good backup practice pushes an offsite copy to object storage, following the 3-2-1 rule. That offsite copy is the one that saves you when the provider dies or the account locks. It is also the one most exposed, because it lives outside your walls, on storage you rent rather than own.

Object storage buckets leak. Sometimes it is a permission set to public by mistake. Sometimes it is a leaked access key. Sometimes it is the provider's own breach. However it happens, the contents of that bucket can end up in the wrong hands, and if the contents are your unencrypted database, that is a full breach of everything: customer records, credentials, the lot. Encryption is what turns a bucket leak from a catastrophe into a non-event, because leaked ciphertext is worthless without the key.

Client-side, not server-side, encryption

There is a critical distinction. Server-side encryption, where the storage provider encrypts your data at rest, sounds reassuring but protects against the wrong threat. The provider holds the keys, so the provider can read your data, and anyone who compromises the provider's key management can too. It protects against someone stealing the physical disk. It does not protect against the provider itself or a breach of the provider's systems.

Client-side encryption flips who holds the key. You encrypt on your server, with a key you control, before the data leaves. The storage provider receives ciphertext and never sees the key. Now the provider cannot read your data, a breach of their systems exposes nothing, and you are not trusting them with anything but the storage of opaque blobs. This is the model that fits self-hosting, because the whole reason you self-host is to not hand control to a provider. Handing them readable backups would undo that.

Modern backup tools make this the default. Both restic and Borg, the two I compare in restic vs Borg for VPS backups, encrypt client-side before sending. You do not have to build this. You have to not turn it off.

Where the key lives is the whole game

Client-side encryption moves the problem to one place: the key. The backup is only as safe as the key is protected, and the key must not be stored where it defeats the purpose.

The mistake is keeping the encryption key on the same box you are backing up, and only there. If that box dies, you have an encrypted backup and no key to open it, which is the same as having no backup. If the box is compromised, the attacker gets the key and the backup together. Neither is acceptable.

The key belongs in your secrets management, kept separately and backed up separately from the data it protects. This is exactly the discipline I cover in managing secrets without a cloud vendor: the key lives where you can retrieve it during a rebuild but where a single compromised server does not hand it over. During a restore drill, retrieving the key from its separate home is part of the test, because a restore that cannot get the key is a restore that fails.

Make it the default, then forget it

The good news is that once client-side encryption is set up, it costs nothing ongoing. The backup tool encrypts every run automatically, the storage provider only ever sees ciphertext, and you sleep fine knowing a bucket leak is not a breach. There is no performance penalty worth mentioning and no recurring effort. It is a one-time setup that permanently changes the worst case from "everything exposed" to "nothing exposed."

I encrypt every backup client-side across my whole portfolio, pushing ciphertext to object storage from VPS boxes on HostSSH, with keys held separately from the data. The bucket could leak tomorrow and I would not lose a minute of sleep, because there is nothing readable in it. Encrypt on the server, hold the key apart, and the offsite copy that protects you can never betray you.