Every backup solution announces encryption. It has become a box to tick, much like "GDPR compliant". Yet behind the same word sit models that do not protect against the same threats.
The useful question is not "is it encrypted?" but "who holds the key, and where is decryption possible?"
Three models, three scopes
Encryption in transit
The data travels over TLS between the machine being backed up and the server. This is the absolute minimum, and nobody skips it any more.
Protects against: network eavesdropping. Does not protect against: anything that happens once the data has arrived.
Encryption at rest, server side
The data is encrypted on the backup server's disk. The key is held by the server, which encrypts on write and decrypts on read.
Protects against: physical theft of a disk, decommissioning of hardware, direct access to the storage. Does not protect against: anyone who gains access to the server — since the server does have the key. That is as true of a legitimate administrator as of an attacker.
This is the most widespread model, and it is often presented simply as "AES-256 encryption", which is accurate but incomplete.
Encryption at source
The data is encrypted on the machine being backed up, before it leaves, with a key that never leaves that machine. The server receives and stores nothing but unintelligible blocks.
Protects against: disk theft, compromise of the server, a curious hosting provider, a curious service provider, a curious software vendor. Does not protect against: compromise of the machine itself, where the data is in the clear anyway.
Integrity checking without the key
A legitimate technical objection: if the server cannot decrypt, how does it verify that the data is not degrading over time?
The answer lies in where the fingerprints are computed. If each block carries its own fingerprints, before and after compression, the server can read a block back, recompute its fingerprint, compare it with the one recorded, and conclude that the block is intact — without ever knowing what it contains.
That is what reconciles two requirements often thought incompatible: absolute confidentiality towards the hosting provider, and integrity checking on the server side.
What it changes in the event of a data breach
This is where the model has very concrete consequences, and not only technical ones.
The GDPR requires a breach to be notified to the supervisory authority within 72 hours (Article 33), and the data subjects to be informed where the breach is likely to result in a high risk to their rights and freedoms (Article 34).
Article 34 explicitly provides that this communication to the data subjects is not required if the controller has implemented measures rendering the data unintelligible to any unauthorised person — encryption being cited as an example.
In practical terms: if a backup server is compromised and the data was encrypted at source, the key never having travelled to or resided on that server, the risk to the data subjects is considerably reduced. That bears directly on the obligation to notify each person concerned — and on the nature of the conversation you will have with your client.
With encryption at rest on the server side, the attacker who compromised the server has the key as well. The argument no longer holds.
This describes a principle, not an automatic exemption. Analysing a breach remains a case-by-case exercise, with your legal counsel or your data protection officer.
The trade-off you have to accept
Encryption whose key stays with the client has one non-negotiable consequence: if the key is lost, the data is lost too. Nobody can regenerate it. Not the software vendor, not the hosting provider, not you.
This is not a flaw: it is exactly the same property seen from the other side. A solution able to give you back access to your data without your key is, by construction, able to access it without you.
Custody of the recovery key therefore has to be treated as an operational task in its own right:
- Kept somewhere other than the machine being backed up. A key stored on the server it protects protects nothing.
- In a password vault, with traced access and at least two authorised people.
- Verified: a key that has never been tried is a hypothesis. A restore test validates it along the way.
- Documented in the recovery procedure, not in the memory of whoever installed it.
For a provider running several dozen clients, this is worth organising before the first deployment, not after the fiftieth.
The questions to put to a vendor
Four are enough to place any solution:
- Where does the encryption happen? On the machine being backed up, or on the server?
- Does the key travel over the network? If so, it has left the trust boundary.
- Can the server verify integrity without decrypting? The answer reveals the real design.
- What happens if I lose the key? If the vendor can bail you out, then the vendor can read your data.
The fourth is the most revealing, and the one asked least often.
At BeBackup, AES-256 encryption takes place on the workstation, the key never travels, and the server holds nothing but its fingerprint. See the security page or ask for a demo.