A command line program that copies, syncs, mounts and serves data across more than seventy storage systems, from S3 and Backblaze B2 to Google Drive, SFTP and WebDAV. It replaces vendor sync clients and one-off migration scripts, and it is the transport layer many backup tools sit on top of.
Our verdict on rclone#
rclone is a sync and transfer tool, not a backup tool, and treating it as one is how people lose data. rclone sync makes the destination match the source, which means it deletes anything at the destination that is no longer at the source. Delete a folder locally, or let ransomware encrypt it, and the next scheduled sync faithfully propagates that to your only remote copy. rclone's own documentation puts it plainly: since sync can cause data loss, test first with --dry-run or --interactive. If you want history, either use rclone copy with --backup-dir so replaced and deleted files are moved aside into a dated directory, or run restic or Kopia and point their rclone: backend at the remote, which is what rclone is genuinely excellent for. Version 1.75.1 landed 4 September 2026 and the release cadence is roughly quarterly with a large backend surface, so read the changelog for the backends you actually use.
Who rclone is for#
Choose it if
- Moving a large data set between providers once, where checksums and resumability matter more than history.
- Serving as the transport for restic or Kopia, giving them access to backends they do not implement natively such as Google Drive or Jottacloud.
- Mirroring already-immutable data (finished media, archives) where deletions really are intentional and there is a second copy elsewhere.
- Mounting a remote bucket with
rclone mountfor read-mostly access from an application that expects a filesystem.
Look elsewhere if
- You want versioned backups with retention. rclone has no snapshot concept, and
--backup-diris a workaround, not a history model. - You need deduplication or client-side compression across versions of the same file; every changed file is re-uploaded whole.
- The destination has to be resistant to a compromised source machine. rclone runs with full delete rights on the remote by design.
What running it actually looks like#
One static binary and one config file. rclone config walks you through each remote interactively, including the OAuth dance for consumer providers, and writes ~/.config/rclone/rclone.conf. From there it is cron or systemd timers calling rclone copy or rclone sync with flags. Long-running shapes exist and each is a service you own: rclone rcd exposes the remote control API on localhost:5572, rclone mount needs FUSE on the host and a --vfs-cache-mode decision, and rclone serve speaks HTTP, WebDAV, SFTP, FTP, S3 and more. The official image is rclone/rclone and it is multi-arch, but a mount inside a container needs --device /dev/fuse and --cap-add SYS_ADMIN. Upgrades are a binary swap and the config format is stable across versions.
Resource profile#
- Memory
- 40 MB idle, around 300 MB in ordinary use. Estimates during a transfer. Memory tracks `--transfers` times the buffer size plus the directory listings held in memory, so `--fast-list` on a bucket with millions of objects is the thing that turns 300 MB into several GB.
- CPU and acceleration
- Mostly IO bound, but crypt-backend encryption and many parallel checksum comparisons will use whatever cores you have; `--checkers` defaults to 8 and drives listing load on the remote.
- Storage growth
- Stores nothing locally beyond the config file and an optional VFS cache for `rclone mount`, which can grow to the size of the files you touch unless you cap it with `--vfs-cache-max-size`.
- Operational load
- 2 of 5, Light. A binary in cron or a systemd unit with no state to migrate and no service to babysit. The ongoing attention is credential rotation in rclone.conf, watching for backends whose APIs change, and reviewing that your sync flags still do what you think.
Figures describe a small single-household install and are the working assumptions behind our stack planner. Your numbers will differ with library size, user count and hardware. See methodology.
Data and backup surface#
What you must protect is rclone.conf, because it is the keys to every account you configured. The passwords in it are obscured, not encrypted, and rclone obscure is reversible by design, so anyone who reads that file owns your cloud storage. Either encrypt the whole config with rclone config password protection and feed it via --password-command, or keep it root-owned at mode 0600. If you use the crypt backend, the password and salt are the only things standing between you and unreadable data, and there is no recovery path; export them with rclone config show and store them offline before you upload a terabyte. For integrity, rclone check compares hashes both sides and rclone cryptcheck does the same through a crypt remote.
Derived backup shape
File copy. Copy the config and data directories. Safe while running for anything that writes atomically.
Traps and surprises#
sync deletes at the destination, every time
rclone sync source: dest: is not rclone copy. It removes files at the destination that are absent at the source, so an accidental local deletion becomes a permanent remote deletion on the next scheduled run. The documented safeguards are --dry-run and --interactive, and the real fix for anything backup-shaped is --backup-dir remote:archive/$(date +%F), which moves overwritten and deleted files aside instead of destroying them.
rclone.conf credentials are obscured, not encrypted
Backend passwords in the config file are scrambled with a fixed, publicly known key. Copying rclone.conf to a shared host, committing it to a repository, or including it in a world-readable backup gives away every account in it. Set a config password so the file is genuinely encrypted, supply it non-interactively with --password-command, and remember that the same protection does not extend to credentials you pass on the command line.
The remote control API is equivalent to shell access
rclone rcd binds localhost:5572 and requires authentication by default, but --rc-no-auth is widely copied from tutorials. The API can read, write and delete on every configured remote and run arbitrary rclone operations, so exposing it unauthenticated on a LAN address hands over all your storage. If you need it remotely, use --rc-user and --rc-pass with TLS, or keep it on loopback behind an authenticating proxy.
Backends without hashes or modtimes re-upload forever
rclone decides what to transfer using size, modification time and hash. Backends that cannot store modification times, or transfers through crypt where hashes do not line up, can make every run consider every file changed. The symptom is a sync that never converges and a large monthly egress bill. Diagnose with rclone check --one-way, then pick the right comparison explicitly with --size-only, --checksum or --update for that specific pair.
crypt filename encryption is a one-way decision
The crypt backend's password, salt and filename encryption mode are baked into the data at upload time. You cannot change the password without re-uploading everything, and losing the password or salt makes the remote data permanently unreadable, filenames included, so you cannot even tell what you lost. Record both from rclone config show and keep that record somewhere that does not depend on the machine holding rclone.conf.
Specifications#
- Category
- Backup and object storage
- Licence
- MIT (Permissive)
- Written in
- Go
- First release
- 2014
- Maturity
- Mature
- Datastore
- None. A single INI-style config file at ~/.config/rclone/rclone.conf
- Default ports
5572- Ships as
- native binary, docker, distro package
- arm64 builds
- Yes
- Identity
- Not applicable. No user accounts. The remote control API and `rclone serve` use HTTP basic auth or certificates; everything else is per-backend credentials in rclone.conf.
- Replaces
- Dropbox, Google Drive for desktop, Cyberduck, Mountain Duck
- Project site
- rclone.org
- Source
- github.com/rclone/rclone
- Documentation
- rclone.org/docs
Alternatives to rclone#
Everything else in backup and object storage, closest in operational weight first.
| Tool | Ops load | Idle RAM | Licence |
|---|---|---|---|
| BorgBackup | 2, Light | 80 MB | BSD-3-Clause |
| Kopia | 2, Light | 200 MB | Apache-2.0 |
| restic | 2, Light | 100 MB | BSD-2-Clause |
| Duplicati | 3, Moderate | 200 MB | MIT |
| Garage | 3, Moderate | 150 MB | AGPL-3.0-only |
| MinIO | 4, Heavy | 250 MB | AGPL-3.0 (repository archived) |
Where rclone comes up elsewhere#
Migration guides
Sources#
Facts on this page were checked against the project's own material. Where a number is our own estimate rather than a published figure, the text says so.
Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.