rclone Remote Backup with Client-Side Encryption

rclone is the universal adapter for remote storage: S3, Backblaze B2, Google Drive, WebDAV, SFTP and dozens more behind one command set. That makes it the pragmatic answer to offsite backup — but only if you add client-side encryption and understand the difference between sync, copy and a real backup history. This guide covers the remotes, crypt encryption with key management, a versioned backup strategy, bandwidth control, and the systemd framework that makes it reliable.

Remote + crypt, not just remote

rclone sync /data remote:bucket/data        ! plaintext in the cloud
rclone sync /data crypt:data                ! encrypted before upload
crypt: layer wraps a normal remote; filenames and contents are encrypted

If your remote is a third-party S3-compatible service, assume the provider can read objects. Client-side encryption is the only control you actually hold. The reasoning is the same one that drives encrypted backup tools generally — see Borg encrypted backups for the deduplicating alternative.

Configure remotes

rclone config create b2 b2 account  key 
rclone config create crypt crypt remote b2:bucket/backup \
    filename_encryption standard \
    directory_name_encryption true \
    password $(rclone obscure 'YourLongPassphrase') \
    password2 $(rclone obscure 'OptionalSecondSalt')

rclone lsd crypt:            ! listing through the encryption layer
rclone lsd b2:bucket/backup  ! what the provider actually sees (gibberish)

Store the passphrase separately from the config file. Losing it means the backup is unrecoverable — there is no vendor recovery path, which is the point, but it must be an explicit operational decision recorded somewhere other than the machine doing the backup.

Backup strategy: sync is not a backup

rclone sync   makes the destination an exact mirror -> deletions propagate
rclone copy   adds/updates only, never deletes at the destination
rclone sync with --backup-dir gives you both:
               current state mirrored, displaced versions archived

rclone sync /data crypt:data \
  --backup-dir crypt:versions/$(date +%Y-%m-%d_%H%M) \
  --suffix .$(date +%s) \
  --transfers 8 --checkers 16 --fast-list \
  --log-file /var/log/rclone-backup.log --log-level INFO

A plain sync to an offsite location is a replication strategy, not a backup: ransomware or an accidental rm -rf is mirrored within minutes. --backup-dir with a timestamped path is the minimum viable history, combined with retention pruning:

rclone delete crypt:versions --min-age 30d      ! keep 30 days of versions
rclone mkdir crypt:data                          ! idempotent pre-step

Bandwidth and scheduling discipline

--bwlimit 20M                   cap offsite upload
--bwlimit "08:00,5M 19:00,off"  time-based limits
--max-age 30d                   only back up recently changed data
--exclude "/tmp/**" --exclude "*.iso"
--tpslimit 10                   for providers with aggressive rate limits

Providers throttle in different ways; S3 cares about request rate, B2 about transaction counts. --tpslimit and --transfers are the two knobs that stop you tripping provider limits mid-run.

Make it a systemd timer, not a cron line

# /etc/systemd/system/rclone-backup.service
[Unit]
Description=rclone encrypted backup
After=network-online.target
[Service]
Type=oneshot
User=backup
EnvironmentFile=/etc/rclone/backup.env
ExecStart=/etc/rclone/backup.sh
Nice=10
IOSchedulingClass=idle

# /etc/systemd/system/rclone-backup.timer
[Unit]
Description=Nightly rclone backup
[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true
RandomizedDelaySec=15m
[Install]
WantedBy=timers.target

systemctl enable --now rclone-backup.timer
systemctl list-timers rclone-backup.timer
journalctl -u rclone-backup.service -n 50

Persistent=true catches up a missed run after downtime, and RandomizedDelaySec avoids a fleet all hitting the provider at 02:30 exactly.

Verification: the part everyone skips

rclone check /data crypt:data --one-way --size-only
rclone about crypt:
rclone lsjson crypt:data --stat | head
# and a real restore test, into a scratch directory, monthly
rclone copy crypt:data/important.tar.gz.age /tmp/restore-test/

Pitfall                            Consequence
Only sync, no --backup-dir         deletions and ransomware mirrored
Passphrase lost                    data unrecoverable
Never testing a restore            backup is a hypothesis
Versioning without pruning         storage cost grows without bound
No logging                         silent failures for weeks

A backup that has never been restored is a hypothesis, not a control. Schedule the restore test, compare a checksum, and record the result. For local history plus offsite, the usual pairing is filesystem snapshots (Btrfs send/receive) or simple hard-linked trees (rsync --link-dest) on the source side, then rclone for the offsite leg.

FAQ

Q: rclone crypt or provider-side encryption? Both, if offered — crypt protects against the provider, SSE protects against physical disk theft at their end. Crypt is the one you control.
Q: Does crypt deduplicate or compress? No. Use a deduplicating tool (Borg, restic) before rclone if dedupe matters.
Q: How do I rotate the crypt password? You must re-upload: decrypt into a new crypt remote with the new key, then delete the old one. Plan a window.

原文链接：https://rclone.org/crypt/