Backups are the part of personal security most people treat as solved. They set up iCloud or Google Photos, their phone backs up every night, and they feel covered. For the threat model of "I dropped my phone in the ocean," this is fine. For the threat model of "who else can read my data," it is not.
The distinction that matters is not whether your backup is encrypted — almost all cloud backup services encrypt data in transit and at rest. The distinction is who holds the encryption keys.
Client-Side vs. Server-Side Encryption: The Key Distinction
Server-side encryption means the cloud provider encrypts your data using keys they manage. Your data is protected from third parties who might compromise the storage infrastructure — a rogue employee, a breach of the storage layer — but not from the provider itself. The provider can decrypt your data at will, which means they can hand it to law enforcement, use it to train AI models (subject to terms of service), or expose it in a future breach that compromises their key management.
Client-side encryption means your data is encrypted on your device, using a key derived from a secret you control, before it is transmitted anywhere. The server receives ciphertext. Without your key, nobody — including the service you are backing up to — can read your data.
Can the backup service reset your access if you forget your password? If yes, they hold the keys — which means so does anyone who can compel them. If your data is irrecoverably lost when you forget your passphrase, the keys are yours. Both situations have trade-offs; the important thing is knowing which model you are using.
Most consumer cloud backup services use server-side encryption. This is a deliberate choice — it makes account recovery possible, which reduces support burden and improves retention. It is not a technical limitation. Client-side encryption is entirely achievable for backup workflows; it just shifts the key custody to you.
What iCloud and Google One Actually Protect
Apple's approach to iCloud encryption has evolved. As of late 2022, Apple offers "Advanced Data Protection" — an opt-in setting that extends end-to-end encryption to most iCloud data categories, including iCloud Backup, iCloud Drive, Photos, Notes, and several others. If you enable this setting, Apple cannot decrypt your backed-up data. The trade-off is explicit in Apple's documentation: if you lose access to all your trusted devices and recovery contacts, Apple cannot help you recover your data.
Standard iCloud (without Advanced Data Protection) uses server-side encryption for most categories. Apple holds the keys. iCloud Backup in standard mode specifically includes messages, photos, and device data, all decryptable by Apple.
Google's backup encryption is less granular. Google One backups are encrypted in transit and at rest using server-side keys. Google can access the content of your backup and has responded to government legal demands with backup data. Google does not offer a client-side encryption option for standard device backups comparable to Apple's Advanced Data Protection.
Tools for Client-Side Encrypted Backups
For users who want genuine client-side encryption, several open-source tools provide it cleanly:
| Tool | Encryption | Deduplication | Platforms | Best For |
|---|---|---|---|---|
| Restic | AES-256-CTR + Poly1305 | Yes (content-defined) | Linux, macOS, Windows | General-purpose encrypted backup to any backend |
| Borg Backup | AES-CTR / BLAKE2b-256 | Yes (variable block) | Linux, macOS | Local or SSH-remote encrypted backups, strong dedup |
| Duplicati | AES-256 | Partial (block-level) | Linux, macOS, Windows | GUI-driven backups, many cloud backends |
| Cryptomator | AES-SIV + AES-CTR | No | Linux, macOS, Windows, iOS, Android | Encrypting files inside an existing cloud drive (Dropbox, Drive) |
Restic is the most widely recommended of these. It supports a wide range of backends — local disk, SFTP, S3-compatible storage, Backblaze B2, and others — and handles encryption transparently. You provide a passphrase; Restic derives a key and encrypts every chunk before upload. The repository index is also encrypted, so the backend operator cannot infer anything about your file structure or sizes from the repository contents alone.
Borg Backup is similarly capable and especially strong for local or SSH-backed repositories. Its deduplication is more aggressive than Restic's in some workloads, which matters when backing up large datasets over time. BorgBase offers hosted Borg repositories if you do not want to manage your own server.
Cryptomator takes a different approach: rather than being a backup tool itself, it creates an encrypted virtual vault inside an existing cloud storage location. Your Dropbox or Google Drive holds encrypted file chunks; Cryptomator handles the encryption and decryption locally. This allows you to keep using the cloud provider's sync client while ensuring that provider cannot read your file contents.
The Key Management Problem
Client-side encryption shifts a burden onto you that server-side encryption absorbs: key management. With server-side encryption, forgetting your password is recoverable — the provider can verify your identity and restore access. With client-side encryption, forgetting your passphrase means permanent data loss.
This is not an argument against client-side encryption. It is an argument for taking key management seriously.
Practical approaches that work:
- Store the passphrase in a password manager, and back up the password manager's export to a separate encrypted location (offline, or with a different key). This creates a dependency chain, but a manageable one.
- Write the passphrase on paper and store it in a physically secure location — a safe, or a trusted person's home. Paper does not get malware. Its threat model is physical theft or fire, which is manageable.
- Use a hardware security key as part of a key derivation scheme if your backup tool supports it. This ties decryption to physical possession of the key.
The goal is not to make your backup passphrase impossible to lose — it is to ensure that losing any single copy of it does not lose the passphrase entirely. Redundancy applies to keys as much as it applies to the data they protect.
Full-Disk Encryption and Its Limits
Many users rely on full-disk encryption — FileVault on macOS, BitLocker on Windows, LUKS on Linux — as their primary data protection. This is valuable and you should use it, but it protects against a specific threat: physical access to your device while it is powered off. It does not protect your data once the device is unlocked and running.
A backup workflow sends data off your device. If you back up to an unencrypted destination, the data is exposed at that destination regardless of your disk encryption. Full-disk encryption and encrypted backups serve different threat models and are not substitutes for each other. Our post on disk encryption covers what full-disk encryption does and does not protect.
A Practical Backup Architecture
For most users who want genuine privacy-preserving backups, a reasonable architecture looks like this:
- Full-disk encryption enabled on all devices — protects data at rest if a device is stolen.
- Restic or Borg backing up to a backend you control (your own server or a provider like Backblaze B2), encrypted with a strong passphrase you have stored redundantly.
- Cryptomator vault inside an existing cloud storage account for files you want continuous sync on, keeping those files opaque to the cloud provider.
- Offline copy of the most critical data — an encrypted external drive stored off-site, rotated periodically.
This is more effort than the default "set up iCloud and forget it" approach. Whether that effort is warranted depends on your threat model — which is the subject of our post on building a personal threat model. The right starting question is not "what tools should I use" but "what am I actually protecting, and from whom."