rsync copies between disks and hosts. rclone does the same job for cloud storage, and it will show you the plan before it runs it.
Sync and mount S3, B2 and Google Drive, preview every change with --dry-run, and encrypt with crypt remotes. rclone calls each configured storage account a remote, and every path is written remote:path. The same commands work whether the remote is an S3 bucket, a B2 bucket, a Google Drive folder or a local directory. rclone 1.75.2 lists 70 storage backends, and many of them, S3 included, cover several providers each. The examples were run with rclone 1.75.2 on Debian 13, against a local S3 server (more on that below), not a paid account.
Between two disks or two machines over ssh, rsync is still the simpler tool. rclone is for when one side is a storage service.
install
# The official script installs the current release to /usr/bin/rclone (/usr/local/bin/rclone on macOS). It needs unzip
curl -fsSL https://rclone.org/install.sh | sudo bash
Debian and Ubuntu also package it (sudo apt install rclone), but the Debian 13 package is 1.60.1, years behind. Flags and backends on this page assume a current release, so check rclone version first.
set up a remote
rclone config walks you through a new remote with questions. Pick the storage type (s3, b2, drive and so on) and give it credentials: an access key and secret for S3, an Application Key ID and Application Key for B2. Google Drive signs in through your browser instead, and needs your own Google client ID, because rclone's shared one stops working during 2026. Defaults are fine for most other questions. The answers land in one file:
# Where the remotes are stored. It holds your keys, so keep it private
rclone config file
Configuration file doesn't exist, but rclone will use this path: /home/sysop/.config/rclone/rclone.conf
To try everything below without an account, rclone can be its own S3 server. rclone serve s3 serves a local directory over the S3 API, and config create adds a remote without the questions:
# Terminal 1: a throwaway S3 server on localhost, buckets are folders in ~/s3data
mkdir -p ~/s3data/backups
rclone serve s3 ~/s3data --addr 127.0.0.1:8333 --auth-key labkey,labsecret
# Terminal 2: a remote called s3lab that points at it
rclone config create s3lab s3 provider=Rclone endpoint=http://127.0.0.1:8333 access_key_id=labkey secret_access_key=labsecret
# List remotes, then the buckets on one
rclone listremotes
rclone lsd s3lab:
s3lab:
-1 2026-11-04 21:09:10 -1 backups
dry run, then sync
rclone sync SRC DST makes DST match SRC, which includes deleting files in DST that SRC doesn't have. rclone copy only adds and updates. Run either with --dry-run (-n) first:
# Show what a sync would do, change nothing
rclone sync ~/photos s3lab:backups/photos --dry-run
NOTICE: notes.txt: Skipped copy as --dry-run is set (size 6) NOTICE: 2026/img1.jpg: Skipped copy as --dry-run is set (size 195.312Ki) NOTICE: 2026/img2.jpg: Skipped copy as --dry-run is set (size 195.312Ki) NOTICE: 2026/img3.jpg: Skipped copy as --dry-run is set (size 195.312Ki) Transferred: 4 / 4, 100%
Output trimmed: each NOTICE line starts with a timestamp, and the totals block has a few more lines.
# Run it for real, with a progress display
rclone sync ~/photos s3lab:backups/photos -P
# Compare both sides by size and hash, change nothing
rclone check ~/photos s3lab:backups/photos
NOTICE: S3 bucket backups path photos: 0 differences found NOTICE: S3 bucket backups path photos: 4 matching files
Now delete notes.txt locally, change one photo, and preview again. The delete is the line to look for:
NOTICE: 2026/img1.jpg: Skipped copy as --dry-run is set (size 195.320Ki) NOTICE: notes.txt: Skipped delete as --dry-run is set (size 6) Deleted: 1 (files), 0 (dirs), 6 B (freed)
# Sync, but move replaced and deleted files into a dated folder instead of losing them
rclone sync ~/photos s3lab:backups/photos --backup-dir s3lab:backups/old/2026-11-08
# What the backup folder caught
rclone ls s3lab:backups/old
200000 2026-11-08/2026/img1.jpg
6 2026-11-08/notes.txt
--backup-dir has to be on the same remote as the destination, outside the synced path. A local folder, or one inside backups/photos, stopped our test with a fatal error. Other read-only helpers worth knowing: rclone ls, rclone lsf, rclone tree and rclone size. Filters work on every command: --include '*.jpg', --exclude '*.tmp', --max-age 1h.
encrypt with a crypt remote
A crypt remote wraps another remote. You read and write plain files through it, and the storage underneath only ever sees encrypted contents and encrypted names. The password in the config file is only obscured: rclone reveal turns it back into the passphrase, which is why the config file has to stay private.
# A crypt remote called secret, stored in backups/crypt on s3lab. Use your own passphrase
rclone config create secret crypt remote=s3lab:backups/crypt password=$(rclone obscure 'your passphrase here')
# Copy through the crypt remote, then look at it both ways
rclone copy ~/photos secret:photos
rclone ls secret:photos
rclone ls s3lab:backups/crypt
200000 2026/img3.jpg 200008 2026/img1.jpg 200000 2026/img2.jpg 200096 4utn93lu3fao40r8ilc0k8vma4/vgjkej1234n087ic9v4f1fhbqg/du0putu5i2gl1i0n8qa4sso800 200104 4utn93lu3fao40r8ilc0k8vma4/vgjkej1234n087ic9v4f1fhbqg/ep6dh18k9v1b8a895ivngpgpt8 200096 4utn93lu3fao40r8ilc0k8vma4/vgjkej1234n087ic9v4f1fhbqg/vi6f67kr7v02mlfrdmog1cmtjc
The first three lines come through secret:, the last three are the same files as the bucket stores them. Each encrypted file is a little larger than the original.
# Check encrypted copies against the originals without downloading them
rclone cryptcheck ~/photos secret:photos
NOTICE: Encrypted drive 'secret:photos': 0 differences found NOTICE: Encrypted drive 'secret:photos': 3 matching files
mount a remote as a folder
rclone mount shows a remote as a local directory through FUSE (sudo apt install fuse3 on Debian and Ubuntu).
# Mount in the background. --vfs-cache-mode writes makes normal file writes work
mkdir -p ~/mnt
rclone mount s3lab:backups ~/mnt --daemon --vfs-cache-mode writes
# Unmount on Linux
fusermount3 -u ~/mnt
A file you write into the mount isn't uploaded straight away. rclone waits until it has been closed for --vfs-write-back, 5 seconds by default. In our test, a copied file showed up in the bucket on the next check after that wait, not one second after the copy.
pro tip
Point a dry run at the real destination before every new sync command, and read it for Skipped delete. The direction of sync is easy to swap, and a swapped sync deletes the files you meant to keep. Writing files into a mount and then syncing from local without them is the same mistake: in our test, the four files added through the mount all showed up as deletes in the next dry run.
honest limits
Everything on this page ran on Debian 13 with rclone 1.75.2, against rclone serve s3 on the same machine. We didn't run it against AWS S3, Backblaze B2 or Google Drive: each one needs its own account and keys, and Google Drive needs your own Google API client ID (see rclone's Making your own client_id guide) plus a browser sign-in during rclone config. On a server with no browser, answer n to the auto-config question and run rclone authorize "drive" on a machine that has one. The commands are the same once a remote exists, but speed, costs and limits are the provider's. The mount wasn't tested on macOS. There, rclone mount needs macFUSE or FUSE-T and the rclone.org binary: the Homebrew build of rclone has mount support removed. rclone nfsmount avoids FUSE by using macOS's built-in NFS client. A crypt remote is only as safe as its passphrase: lose it and the files are unreadable, rclone included.