rclone Crypt: Encrypted Cloud Buckets That Stay Yours

Your Cloud Provider Reads Your Backups. Encrypt Them First.

You’re backing up to Backblaze B2, or maybe AWS S3, or Dropbox. Good on you, that’s more than most people do. But here’s the uncomfortable truth: every file sitting in that bucket is technically readable by your provider. They have the keys. They’re not evil about it, their ToS probably promises they won’t peek, but “won’t” isn’t “can’t.”

Then there’s AI training. Cloud providers have been caught scraping buckets to feed machine learning pipelines. And then there’s the government. And ransomware that gets access to your provider’s credentials somehow. Or a disgruntled employee. Or someone buys the provider’s assets in a bankruptcy.

rclone crypt solves this. It encrypts your files before they leave your machine, so your cloud bucket looks like gibberish even to the people running the bucket. The provider can’t read it. The government can’t read it without the key. The AI crawler just gets ciphertext. You get the keys, and they stay yours.

This is how cloud backup should feel.

How rclone Crypt Works (Without the Crypto Handwaving)

rclone crypt isn’t magic, it’s boring, peer-reviewed, well-understood encryption. Here’s the model:

Cipher: XSalsa20-Poly1305. That’s a stream cipher (XSalsa20) for data + an authenticator (Poly1305) to detect tampering. Fast, modern, no patents. Works on your laptop and your 1GB ARM NAS at 3 AM.

Key derivation: Your password + a random salt get fed through scrypt, which is intentionally slow (costs CPU time, so brute force is expensive). The salt is stored with your crypt config, it’s not secret, but it makes rainbow tables useless.

Filenames: Here’s where it gets clever. In most encryption setups, your filenames are readable, you can see which files exist without the key. rclone crypt can encrypt those too. “my-vacation-2025.jpg” becomes something like “abc123def456/ghi789”. The directory structure stays, but the names vanish. Good for privacy; slightly annoying for restore operations (more on that later).

Two-layer remotes: The pattern is simple: you create a base remote (pointing to your B2 bucket or S3 or whatever), then layer a crypt remote on top of it. The crypt remote encrypts on write and decrypts on read, transparently.

uncrypt (your crypt remote)
    ↓ (encrypt/decrypt)
b2-raw (your B2 bucket)
    ↓ (actual files)
Backblaze B2 (the cloud)

You never touch b2-raw directly. You sync to/from uncrypt, and the layer handles the crypto.

The Real Disaster Vector: Key Management

Here’s what nobody wants to admit: the cipher is the easy part. Key management is where people burn their houses down.

Your password needs to be:

1. Backed up somewhere, because if you forget it, your 5TB of encrypted cloud backups become a very expensive paperweight.
2. Not stored on the machine you’re backing up from, because ransomware that locks your PC also locks your backup password if it’s sitting in a text file.
3. Not stored only in your head, because humans are terrible at remembering 32-character random strings.

Most people do this wrong. They write it down on a sticky note (now it’s printed and someone can photocopy it). Or they put it in their password manager, which syncs to the cloud (if that sync is compromised, goodbye encryption). Or they tell themselves they’ll remember it, then forget it after a year.

Here’s what I do: password manager on a USB stick that lives in a physical safe. The USB stick has only the backup encryption keys, nothing else. If my whole digital life goes sideways, ransomware, cloud breach, whatever, the safe stays put. Takes 2 minutes to pull the stick, boot the NAS, and start a restore.

If you don’t have a physical safe, use Vault, or Bitwarden with an offline backup, or a password manager on a Yubikey. Whatever. Just don’t trust only your brain.

Why Two Layers, and When You Double Up

So you’ve got rclone crypt encrypting everything before it hits the cloud. Good. But now ask yourself: does your backup tool also encrypt?

restic does. It encrypts everything end-to-end; the restic repo is unusable without the password.

Duplicacy does. Same deal.

Tarsnap does (and is amazing for this reason, but expensive).

So here’s the question: if restic already encrypts, why layer rclone crypt on top?

Answer: restic encrypts the repositorythe tar-like archive structure, metadata, dedup tables, indexes. But it assumes your repo backend (the actual storage) is basically hostile. rclone crypt gives you a second opinion. It’s defense-in-depth.

When to double up: You’re paranoid, you’re storing in a jurisdiction you don’t trust, or you want to hide the fact that you own a lot of data (encrypted filenames hide volume). The CPU cost is minimal; the peace of mind is real.

When to skip it: You’re running restic on top of rclone crypt, one layer is enough. Just make sure restic’s password is different from rclone crypt’s password, so a single compromised credential doesn’t unwind both.

Key Rotation (And Why It’s a Mess)

Here’s the awkward truth: rclone crypt doesn’t support key rotation. If you want to change your password, you can’t just re-derive the key with a new salt. You have to:

1. Decrypt the whole bucket (reading all files once).
2. Re-encrypt with the new key.
3. Upload everything back.

For a 5TB bucket on residential internet, this is a weekend operation. For a 100TB bucket, this is “okay, maybe never.”

So your strategy is: pick a password that’s random enough that you’ll never need to rotate it, and back it up so thoroughly that even if it leaks, you’ve already retired that bucket by the time you notice.

Most people just… don’t rotate. Ever. And honestly? For backups sitting in your own cloud bucket (not shared, not exposed), that’s probably fine. You’re not a bank; your threat model doesn’t need that level of paranoia.

The Restore Drill: It’s Slower Than You Think

Let’s say your house burns down. You grab a borrowed laptop, plug in your USB stick, boot up rclone, and start pulling your backups from the cloud.

rclone decrypt will:

1. List the bucket (fast, API call).
2. Download each encrypted file (network bound).
3. Decrypt on the fly (CPU bound, moderate).
4. Write to disk.

For a small restore (50GB), you’re looking at 2 to 4 hours over fiber. For a full restore, add a day or two. It’s not broken, but it’s slow enough that you should test it once a year. Don’t wait for your house to burn down to find out your password is wrong.

Real Configs: B2 + Crypt

Here’s your rclone.conf (usually ~/.config/rclone/rclone.conf):

[b2-raw]
type = b2
account = your-b2-app-key-id
key = your-b2-app-key
bucket = my-backup-bucket

[b2-crypt]
type = crypt
remote = b2-raw:/crypt
password = your-encryption-password-here
password2 = ""

One gotcha that bites everyone: rclone won’t accept a plaintext password in rclone.conf. The password/password2 values have to be obscured (lightly scrambled) blobs. If you build the remote with rclone config it does this for you; if you’re hand-editing, run rclone obscure 'your-real-password' and paste that output into the field. The placeholders above are illustrative, don’t drop your raw password in there and wonder why it errors.

And your sync command:

rclone sync /home/user/important-stuff b2-crypt: \
  --fast-list \
  --verbose \
  --log-file /var/log/rclone/sync.log

This reads from /home/user/important-stuff, encrypts, and uploads to b2-raw:/crypt (which is the my-backup-bucket/crypt/ folder on B2). The encrypted filenames live inside that folder; the bucket root is clean.

For a restore:

rclone copy b2-crypt: /mnt/restore/important-stuff \
  --fast-list \
  --progress

It downloads, decrypts, and dumps the files. No config changes, no key re-entry. rclone remembers the password from your config.

Google Drive + Crypt (The Free Tier Trap)

Google Drive is free (or cheap if you need more space), and rclone supports it. But there’s a catch: Drive has aggressive rate limits if you’re hammering it with a million tiny encrypted files. So here’s the pattern:

[gdrive-raw]
type = drive
client_id = your-oauth-client-id
client_secret = your-oauth-secret
token = {...}
folder_id = your-backup-folder-id

[gdrive-crypt]
type = crypt
remote = gdrive-raw:/
password = your-password-here
password2 = ""

The difference: no /crypt subfolder here. Google Drive handles nested hierarchy weirdly, so we just encrypt at the root of the folder.

And your sync (with a longer retry period, because Drive’s API is slow):

rclone sync /home/user/data gdrive-crypt: \
  --drive-chunk-size 256M \
  --retries 3 \
  --log-file /var/log/rclone/gdrive-sync.log

The drive-chunk-size is important; smaller chunks = more API calls = slower. 256M is a good middle ground.

rclone Crypt vs. age, gocryptfs, fscrypt

People sometimes ask: “Why not just use age or gocryptfs or fscrypt?”

age: Lightweight, modern asymmetric encryption. Great for encrypting individual files before upload. But it’s not a remote encryption layer, you’d encrypt manually, then sync. More steps. Harder to automate backups.

gocryptfs: Encrypts entire filesystems. Overkill if you just want encrypted backups. Also needs FUSE, which doesn’t work on all systems (looking at you, NAS vendors).

fscrypt: Per-file encryption at the filesystem level. Only works on ext4/f2fs, so not portable to your cloud bucket. Nice for encrypting data at rest on your local drive, but doesn’t help the cloud part.

rclone crypt is specifically for encrypted cloud buckets. It’s the right tool for this job.

Integration: Where Does This Fit in Your Stack?

Here’s a mental model:

Local drive
    ↓
restic (dedup, versioning, encryption)
    ↓
rclone crypt (additional encryption layer)
    ↓
B2/S3/Drive (encrypted bucket)

Or simpler, if you don’t need versioning:

Local drive
    ↓
rclone crypt (encryption)
    ↓
B2/S3/Drive (encrypted bucket)

You could also do:

Local drive
    ↓
rclone crypt (encryption)
    ↓
restic (dedup + versioning of encrypted data)
    ↓
B2/S3/Drive

All three work. Pick based on whether you want versioning (restic) or speed (raw rclone). The important thing: encrypted data leaves your machine.

Scheduling and Forgetting (The Luxury)

Once you’ve got your config right, toss it in a cron job:

0 2 * * * /usr/bin/rclone sync /home/user/important-stuff b2-crypt: --fast-list >> /var/log/rclone/sync.log 2>&1

Every night at 2 AM, your data encrypts and uploads. You don’t think about it. The cloud provider doesn’t see your data. Your key sits safe somewhere offline. This is the dream.

When rclone Crypt Earns Its Keep

rclone crypt is worth the CPU cycles if:

• You’re backing up to untrusted or foreign cloud providers.
• Your data includes things you don’t want anyone (provider, government, employee) to see.
• You’re storing on-budget (B2, Wasabi, Hetzner) where the cheapness sometimes comes with, uh, “different” privacy standards.
• You want to hide the fact that you own lots of data (encrypted filenames do this).
• You’re paranoid. No judgment, paranoia about backups is healthy.

Skip it if:

• You’re backing up to your own Minio server (you already control it).
• You’re already using Tarsnap or Wasabi Glacier (they handle the encryption).
• The data is public anyway (your blog, your GitHub repos).

For everyone else? rclone crypt + a USB stick in a safe + a cron job at 2 AM = your cloud backups are actually yours. No provider reads them. No ransomware decrypts them. No government asks for them without the key.

That’s worth the weekend you spend learning it.

Related Reading

• 3-2-1-1-0: The Backup Strategy That Survives Ransomware
• Backblaze B2 + rclone: Tiered Backup at Real-World Costs
• Backup Workflow Patterns That Work
• Borg vs Duplicacy: Dedup Backup Wars
• Borgmatic: Borg Backup, Done Right