There are programs I install, use once and forget. Then there are programs that quietly become part of how I run my computers. rclone belongs in the second group.

It's a command-line tool that talks to OneDrive, Google Drive, S3-compatible storage, SFTP servers, WebDAV and many other backends. It can copy directories, compare files, encrypt uploads and even mount a remote as if it were a local disk. No giant dashboard required. I like that very much.

Better still, the workflow is nearly identical on Windows and Linux. The paths and installation commands change, but the important part stays the same. Let's build a working setup rather than admire a wall of flags.

1. Install it #

Windows 10/11: open PowerShell. If you have winget, installation is pleasantly boring:

Open a new PowerShell window if rclone isn't recognized immediately. There's also a portable executable on the official download page.

Linux (Debian/Ubuntu): open a terminal. The repository package is the easy route:

Distribution packages can lag behind. If you need a newer release, use the official installation instructions and review the install script before running it with administrator privileges. On other distributions, use their package manager or the official binary.

2. Give your cloud a name #

rclone calls a configured storage connection a remote. We'll name ours cloud, so every example works the same on both systems. I'm using OneDrive here because its browser-based setup is straightforward. Dropbox, SFTP and most other providers follow the same basic logic.

Run this on either operating system:

Choose n for New remote, enter cloud as its name, select onedrive as the storage type, and normally leave the client ID and secret blank. Skip advanced settings unless you know you need them. Allow browser authentication, sign in, pick your OneDrive drive when prompted, and save the configuration. Menu numbers may change between rclone versions, so follow the labels, not someone else's screenshot from 2021.

Test it:

That trailing colon matters: cloud: is your remote. Without it, cloud could be interpreted as an ordinary local folder.

Prefer Google Drive? Choose drive instead of onedrive in the same wizard. One important 2026 detail: rclone's shared Google Drive client ID is being retired, so its documentation now tells you to create your own OAuth client ID. Do that before relying on a new Drive setup. The commands below don't change; only the remote configuration does.

3. Your first copy, without the anxiety #

We'll create a tiny test folder. These commands deliberately use a folder under your home directory, not your entire Documents collection.

Windows / PowerShell:

Linux / Bash:

Now the same idea on both platforms. First simulate, then actually upload. Use the source path that belongs to your system.

Windows:

Linux:

--dry-run shows what would happen without transferring anything. -P displays progress. copy skips unchanged files and does not remove extra files at the destination. One small detail that catches people: rclone copies the contents of the source directory into the destination directory.

Check the result, then test a restore. These commands are shared apart from the local path:

Replace LOCAL_FOLDER with "$HOME\rclone-lab" in PowerShell or "$HOME/rclone-lab" in Bash. For RESTORE_FOLDER, use "$HOME\rclone-restore" or "$HOME/rclone-restore", respectively. check compares the two locations without changing either. A backup you have never restored is still a bit of a theory.

4. The command that deserves a warning label #

Here's the distinction worth remembering:

• rclone copy copies new or changed files, keeping extra files already at the destination.
• rclone sync makes the destination match the source, including deleting destination-only files.

That makes sync useful for mirrors and risky for casual backups. Always preview it:

A particularly useful trick is --backup-dir. Files that sync would overwrite or delete can be moved to a separate folder on the same destination remote, provided the provider supports the required server-side move or copy:

This single-line command works in either PowerShell or Bash after replacing LOCAL_FOLDER with your local path. Remove --dry-run only after reviewing the preview. Use a new history folder for each real run; do not store it inside cloud:rclone-lab. This is a recovery cushion, not a full versioned-backup system.

If you're after two-way synchronization, rclone also has bisync. I would not start there. It is an advanced operation with its own conflict and first-run rules. Read the bisync manual before even thinking of scheduling it.

5. Six little tricks worth stealing #

1. Stop backups from eating your connection. Add --bwlimit 2M to a transfer to cap bandwidth at roughly 2 MiB/s. The unit is bytes per second, not megabits. Pair it with --transfers 2 if a provider gets upset by too many simultaneous uploads. Bigger numbers are not automatically faster.

2. Ignore rubbish. Use --exclude "*.tmp" when copying folders with temporary files. For a real project, put your rules in a text file and use --exclude-from filters.txt. Keep filters readable, and test them with rclone ls or --dry-run before automating. See the filtering guide.

3. Find out where your space went. rclone size cloud:some-folder reports object count and total size. rclone ncdu cloud: opens a navigable terminal view of remote storage. Wonderful for finding unexpectedly enormous folders. Be careful: the interactive tool also has deletion controls.

4. Mount the cloud as a drive. On Windows, install WinFsp first, then:

On Linux, ensure FUSE support is installed (for example, sudo apt install fuse3 on Debian/Ubuntu), then:

Keep that terminal running while the mount is in use; stop it with Ctrl+C when you're finished. writes improves application compatibility by buffering writes locally, which also uses disk space. A mounted cloud is not an offline copy or a substitute for a backup. Full details are in the mount documentation.

5. Encrypt before uploading. Create another remote with rclone config, choose the crypt backend, name it vault, and point it at a dedicated path such as cloud:encrypted-archive. Then rclone copy LOCAL_FOLDER vault:files -P encrypts contents and, by default, filenames on your machine before upload. Keep the password and salt safe. Don't confuse crypt's lightly obscured configuration values with secure configuration-file encryption. Read the crypt guide.

6. Give future-you a paper trail. Add --log-file rclone-backup.log --log-level INFO to a command. Keep logs somewhere private, since filenames and connection details can reveal more than you'd expect. For scheduled jobs, use absolute paths, run them under the same user that configured the remote, and monitor failures rather than assuming a silent job succeeded.

6. Make it automatic, but not mysterious #

On Windows, save a tested command in a PowerShell .ps1 script, for example:

Test the script manually. Then use Task Scheduler to run PowerShell with -NoProfile -File "C:\Scripts\rclone-backup.ps1" at a suitable interval. Use the account that owns the rclone configuration and check the task history. If the executable isn't on the task's PATH, specify its full path in the script.

On Linux, put the same tested action in your crontab (crontab -e):

That example runs daily at 02:00 according to the machine's clock. Verify your actual rclone path with command -v rclone, and remember that a sleeping laptop won't run a missed cron job automatically. If you need missed-run handling, consider a systemd timer instead.

For a backup you care about, keep independent copies. The 3-2-1 rule explained by Backblaze is a useful sanity check. A cloud mirror cannot rescue a file that you accidentally deleted everywhere.

A few rabbit holes for later #

The rclone forum is excellent when a particular provider behaves strangely. For moving authentication to a server with no browser, read the headless setup guide. For more ambitious Linux mounts and services, the Arch Linux rclone manual is a practical reference even if you don't use Arch. And if you want the official word on why sync can be dangerous, start with the copy and sync command pages.

My favorite rclone trick isn't a flag. It's remembering that the destination could be a cloud account, an SFTP server at home, a NAS or a rented machine somewhere else. Once you've got the basics, you can build a little personal off-site archive, move collections between providers or make a tidy backup pipeline without buying into anyone's ecosystem.

What are you using rclone for? If you've built an unusual setup or found a clever flag I missed, send it my way. I'm always looking for another good excuse to open a terminal.