The fragmentation problem

Everyone ends up with more storage than they planned. A personal drive for photos, a work account for documents, an object store where an application keeps its uploads, a cheap archive tier for the things that must be kept but never opened. Each comes with its own client, its own idea of what a folder is, and its own way of telling you how much space is left. Moving data between them usually means downloading to a local disk and uploading again, which is absurd when both ends are already on the network.

rclone replaces that pile of clients with one vocabulary. Around seventy storage backends are mapped onto the same handful of verbs, so syncing a local folder to one provider and one provider to another are the same operation with a different destination. If you have used a command line for file work, the grammar is already familiar, and if you have not, the documentation is unusually patient about the two or three commands that cover most of what people need.

The two abilities that matter

Encryption at the client is the first. Files are encrypted before they leave the machine, then uploaded as opaque blobs with scrambled names, which means the provider stores data it cannot read and cannot index. For anyone whose backup destination is somebody else's computer, this changes the risk calculation entirely: a breach at the provider leaks nothing but noise.

Mounting is the second. Any configured remote can be attached as a drive letter or mount point, and applications that know nothing about cloud storage can read and write through it. This turns an archive tier into a folder you can open, a remote backup target into something a normal file copy can target, and it removes the need for a dedicated sync client on machines where you only occasionally need access.

Around these sit the features that make automation practical. Checksums are compared rather than timestamps, so a sync moves only what genuinely differs. Transfers resume and retry, which matters on links that drop. Bandwidth can be limited so a nightly job does not saturate the household connection at dinner time. And a web interface arrived for people who want a dashboard without memorising flags.

What it asks in return

It is a command line tool, and there is no pretending otherwise. The learning curve is short but not zero: an evening with the documentation gets most people to a working sync, and a week of real use gets them comfortable. Configuration lives in a plain text file, which means it can be versioned, copied between machines and read by a colleague, and also means a typo produces a cryptic error rather than a helpful dialog.

The other cost is that the tool does exactly what you tell it. Sync is one-directional and can delete files at the destination that are missing at the source, which is correct behaviour and a genuine hazard if you point it the wrong way. The dry-run flag exists precisely for this, and using it before every first run of a new job is not caution, it is basic hygiene.

This is what a good command line tool feels like after a decade: it does not flatter you, it does not hold your data hostage, and it will still be doing the same job correctly long after the interface fashions have moved on.

Practical setup advice. Create one remote per account with a clear name, and test it with a listing command before writing any sync. Always run a dry pass first and read the list it prints. Keep the configuration file under version control but never the encryption password, since losing that password loses the data. And schedule jobs with logging enabled, because automation without a log is a rumour rather than a system.