Rclone

Last reviewed Aug 26, 2026 · 969 words

rclone sync makes the destination identical to the source, which means it deletes from the destination whatever is missing at the source. Run it once with the arguments reversed, or after a restore leaves a folder empty, and your cloud copy is gone too. Every rclone data-loss story I have read is a variant of that sentence. So the first habit is --dry-run on every new sync line and --backup-dir on every scheduled one. With that habit installed, rclone is the most dependable file-mover in self-hosting: one Go binary, 70-plus storage backends, in continuous service since 2014, and needing 128 MB of RAM to do it.

Configure a remote once, then guard the config file

rclone config

The interactive wizard writes ~/.config/rclone/rclone.conf. For Backblaze B2 choose type b2 and paste the key ID and application key. For anything S3-flavoured (MinIO, Wasabi, Cloudflare R2, AWS) choose s3 and pick the provider from the list. Google Drive and OneDrive use OAuth, which needs a browser; on a headless server run rclone authorize "drive" on your laptop and paste the resulting token into the wizard. Test with rclone lsd b2: and you should see your buckets.

That config file now holds credentials to every store you own. chmod 600 it, and consider the wizard's "set configuration password" option, which encrypts the file and prompts (or reads RCLONE_CONFIG_PASS) at run time. Keep the passphrases in Vaultwarden, not a sticky note.

Copy, sync, and move are three different verbs

rclone copy adds and updates files at the destination and never deletes. rclone sync also deletes to make both sides match. rclone move deletes from the source after a successful transfer. Nine out of ten jobs want copy; the tenth is the one you should write carefully:

rclone sync /srv/photos b2:my-bucket/photos \
  --backup-dir b2:my-bucket/photos-trash/$(date +%F) \
  --transfers 8 --checkers 16 --fast-list -P

--backup-dir moves anything sync would delete or overwrite into a dated folder instead of destroying it, so a bad run costs storage rather than data. --transfers and --checkers control parallelism; 8 and 16 saturate most home uplinks. --fast-list uses fewer listing calls on bucket-style stores, which matters on B2 where list operations are metered. -P prints progress. Afterwards, rclone check /srv/photos b2:my-bucket/photos compares hashes on both sides and tells you exactly what differs.

Crypt remotes and mounts: one to trust, one to be careful with

A crypt remote wraps another remote and encrypts file contents and, by default, file names, so the provider sees b2:my-bucket/enc/3k2j8s.../v9q1... and nothing else. Create it with rclone config, type crypt, remote b2:my-bucket/enc, and set two secrets: the password and the salt. Then rclone sync /srv/docs secret:docs works exactly like an unencrypted sync. Lose either secret and the data is unrecoverable by design, so those two strings go in the password manager the moment you generate them. File sizes are still visible, padded by a few bytes, which is a fair trade for zero-knowledge storage on a $6-per-TB-month bucket.

Mounting is the other headline feature, and it deserves a narrower welcome. rclone mount b2:my-bucket/media /mnt/media --vfs-cache-mode full turns any remote into a FUSE directory. It is a fine way to give Jellyfin a library that lives in object storage, or to browse an encrypted remote in a file manager. It is a terrible place for SQLite files, Docker volumes, or anything that does partial writes; the VFS layer hides latency, it does not remove it. Run mounts from a systemd unit so they survive reboots, and add --dir-cache-time 24h on read-mostly remotes to stop rclone re-listing the same folders.

Rclone is a mover, restic is the backup

The catalogue's warning, "not a snapshot backup tool", is the one to internalise. A sync gives you today's state and, with --backup-dir, an improvised trash. It does not give you deduplication, point-in-time restore, or a way to recover the version of a file from 3 weeks ago. For that, put restic on top and let rclone be the transport:

restic -r rclone:b2:my-bucket/restic init
restic -r rclone:b2:my-bucket/restic backup /srv/docs

Restic handles snapshots, encryption, and pruning; rclone supplies the 70 providers. Kopia works the same way. BorgBackup vs restic settles which snapshot tool, and the 3-2-1 backup guide shows where rclone fits in the full picture: usually as the off-site leg.

Schedule it and log it

0 3 * * * rclone sync /srv/photos b2:my-bucket/photos --backup-dir b2:my-bucket/photos-trash/$(date +\%F) --log-file /var/log/rclone.log --log-level INFO

Note the escaped % in cron. Watch the log for a week before trusting it, and prune the trash folder monthly with rclone delete --min-age 30d. The official rclone/rclone Docker image exists and works with the config file mounted in, but on a host where you already have a shell, the binary is simpler.

What I'd do

Config file encrypted, one crypt remote per bucket, copy for one-off moves and sync with --backup-dir for the nightly job, --dry-run before any new line goes into cron. Restic over an rclone backend for anything I would cry about, plain rclone sync for the media library where a mirror is all I need. That split has run for years on my systems without a single "where did that file go" moment, and the one time a sync went sideways, --backup-dir had every file waiting.