One CLI to sync, mount, encrypt, and move terabytes across 70+ cloud providers — and the flags that keep you from deleting your own files.

I manage files across four cloud providers, two VPS boxes, and a NAS that lives under my desk. For years my "workflow" was a graveyard of vendor CLIs, half-remembered web dashboards, and browser tabs uploading 40 GB ISOs one at a time. Then I installed rclone, and the whole mess collapsed into one binary with one config file.

rclone calls itself "rsync for cloud storage," which undersells it. It's closer to a universal remote: one command set that talks to Google Drive, S3, Backblaze B2, Dropbox, OneDrive, SFTP, WebDAV, and dozens of others, with the same flags everywhere. If you run Linux and touch cloud storage, this is the tool.

Install it the boring way

Most distro packages ship rclone versions that are months — sometimes a year — behind. The project's own install script is the sane path:

sudo -v ; curl https://rclone.org/install.sh | sudo bash

It drops a current binary into /usr/bin with the man pages alongside. Verify with rclone version; if it's older than a few months, something's off.

Your first remote

Everything in rclone starts with rclone config. It walks you through an interactive setup: name the remote, pick the backend, answer a few questions. For Google Drive, the defaults are almost always right — leave the client ID and secret blank (it uses rclone's own), pick full "drive" scope, and say yes to auto config so your browser handles the OAuth dance.

On a headless server there's no browser. Answer "no" to auto config, then on any machine with a browser run rclone authorize "drive" and paste the resulting token back into the server's prompt. It feels clunky the first time; the second time it takes thirty seconds.

S3-compatible storage (MinIO, Wasabi, Backblaze B2's S3 endpoint) is even simpler: pick "S3", choose "Other" as the provider, and hand over the access key, secret key, region, and endpoint. Test with rclone lsd myremote: — if you see your buckets, you're in.

The three verbs that matter

rclone has dozens of subcommands. You need three, and you need to understand exactly how they differ, because one of them will delete your files if you're careless:

  • rclone copy source: dest: — one-way copy. Never deletes anything at the destination. This is the safe default.
  • rclone sync source: dest: — makes the destination identical to the source. Files at the destination that don't exist at the source get deleted. This is the loaded gun.
  • rclone move source: dest: — copies, then deletes from the source. A one-way conveyor belt.

The first time I ran rclone sync, I pointed it at the wrong end and watched a destination folder get "synchronized" into oblivion. Nothing was unrecoverable, but I aged a year. So here is the rule tattooed on my workflow: never run sync without --dry-run first, and for anything that matters, add --backup-dir:

rclone sync ~/photos gdrive:photos --dry-run -v
rclone sync ~/photos gdrive:photos --backup-dir gdrive:trash/$(date +%F) -v

The --backup-dir flag moves anything sync would delete into a dated trash folder instead of destroying it. It turns the loaded gun into a water pistol. For extra paranoia, --max-delete 10 aborts the run if more than ten files would be deleted — a typo in a path shouldn't be able to nuke a library.

Turn the cloud into a folder

Copy and sync move data; mount makes the cloud feel local:

rclone mount gdrive: ~/gdrive --vfs-cache-mode writes --daemon

Now ~/gdrive behaves like a directory. Media players, file managers, and scripts all work against it without knowing the files live in a datacenter. The --vfs-cache-mode writes flag is the one that makes it usable: without it, many applications can't save files to the mount at all. (full mode caches reads too, at the cost of disk space — worth it for media libraries.)

For a mount that survives reboots, wrap it in a systemd user service at ~/.config/systemd/user/rclone-gdrive.service:

[Unit]
Description=rclone mount for Google Drive
After=network-online.target
Wants=network-online.target

[Service]
Type=notify
ExecStart=/usr/bin/rclone mount gdrive: %h/gdrive --vfs-cache-mode writes
ExecStop=/bin/fusermount -uz %h/gdrive
Restart=on-failure
RestartSec=10

[Install]
WantedBy=default.target

Then systemctl --user enable --now rclone-gdrive. You need FUSE installed and your user in the fuse group; most desktop distros already handle this.

Encrypt before it leaves your disk

The crypt remote is rclone's best trick: it wraps any other remote in transparent client-side encryption. Create it with rclone config, pick "crypt", point it at something like gdrive:encrypted, choose a password, and from then on everything written through gdrive-crypt: is encrypted before upload — filenames and directory names too, if you enable it.

The provider sees only noise. Lose the password and the data is gone forever, so store it in your password manager, not in a sticky note. And set a password on the rclone config file itself with rclone config password — the default "obscured" passwords in the config are obfuscation, not encryption.

The migration playbook

Moving terabytes between providers is where rclone earns its reputation. The flags that matter:

rclone copy oldremote: newremote: --transfers 8 --checkers 16 \
  --bwlimit 80M --tpslimit 10 --progress

--transfers and --checkers control parallelism; --bwlimit keeps you from saturating the pipe (suffixes like 80M, or time-based schedules like 08:00,512k 18:00,10M, both work); --tpslimit keeps Google's API from rate-limiting you into a timeout. When the provider supports it, rclone does server-side copies — data moves provider-to-provider without touching your machine.

Run rclone check oldremote: newremote: afterward. It compares hashes and tells you exactly what didn't make it, which beats discovering the gap six months later.

Five traps, learned the hard way

  1. Sync direction. rclone sync A B deletes in B. Swap A and B and it deletes in A. Read the command twice.
  2. Google's limits. Drive throttles around 750 GB of uploads per day and punishes aggressive parallelism. If transfers stall, lower --transfers and add --tpslimit 10 before you blame your network.
  3. Expired tokens on headless boxes. The OAuth token refreshes itself — until it doesn't, usually after months of disuse. If a cron job starts failing, re-run rclone config and reconnect; don't debug the script first.
  4. Case sensitivity. Drive is case-insensitive; your ext4 disk isn't. rclone dedupe exists for exactly the duplicate-name mess this creates.
  5. Mounts die quietly. A mount dropped by a network hiccup looks like an empty folder. Restart=on-failure in the service helps; a cron job that touches a sentinel file and alerts you helps more.

When not to reach for it

rclone is a transfer tool, not a backup tool — sync mirrors deletions, which is the opposite of what backups do. For real backups, use copy with --backup-dir, or a dedicated tool, and keep rclone as the transport. And rclone bisync does two-way sync, but treat it as experimental until you've tested it on data you can afford to lose.

Still: one binary, one config, dozens of providers, and flags that behave the same everywhere. My vendor-CLI graveyard is empty now. The browser tabs are closed. The ISOs upload themselves at 2 AM via a systemd timer, and I sleep through it.

Sources: