Rclone on Linux: Test a Cloud Copy Before You Sync

You will finish with a small, repeatable rclone workflow: configure a named remote, list its contents, rehearse a transfer, copy without removing destination files, and verify the result. The examples use the rclone command installed on this machine, package version 1.60.1+dfsg-3ubuntu0.24.04.6+esm1, reporting rclone v1.60.1-DEV.

Allow about 20 minutes for the first remote, plus the time needed for your provider's login. You need a shell, an account with access to the storage, and a local directory that you are willing to copy. No command in this guide needs sudo. Elevated privileges do not make cloud authentication safer or more correct.

1. Confirm the installed command

Check the binary and version before relying on examples. This is read-only:

$ command -v rclone
/usr/bin/rclone
$ rclone version
rclone v1.60.1-DEV
...

The exact build details may differ on another host. The local manpage describes this installation and uses ~/.config/rclone/rclone.conf as the default configuration path. Confirm the path rclone will use:

$ rclone config file
Configuration file is stored at:
/home/your-user/.config/rclone/rclone.conf

Checkpoint: if the command is missing, stop and install rclone using your distribution's documented package source. Do not copy a configuration file from an untrusted machine.

2. Create one named remote

Run the interactive configuration command as your ordinary user:

$ rclone config

Choose n to create a new remote, give it a short name such as backup, and select the storage provider shown by the installed prompt. Follow that provider's authentication flow. Some providers open a browser; others ask for a token or a service-account detail. Do not paste secrets into a shell history or this article's command examples.

The result is a named path. In later commands, backup:photos means the photos path on the remote called backup. A bare backup: refers to the remote root. Names are local labels, not provider usernames.

Checkpoint: list configured remote names without displaying decrypted credentials:

$ rclone listremotes
backup:

If you need to change or remove a remote, use rclone config and make a copy of the configuration file first. The file contains authentication material. Protect it with normal user-file permissions and never publish it. The config wizard can also set a password for the configuration.

3. Inspect the destination before writing

List a remote path before copying into it. lsd lists directories and does not recurse by default:

$ rclone lsd backup:photos
          -1 2026-09-26 18:00:00        12 camera

Dates and sizes are examples of the shape of the output, not values to expect. For a machine-readable inventory, use lsjson. For a quick human-readable recursive file list, use ls, but remember that ls recurses by default. Add --max-depth 1 when you only want the first level.

Checkpoint: ensure the remote name and destination prefix are exactly right. A typo can create a new remote-side directory rather than producing the backup you intended.

4. Rehearse a copy with no changes

Suppose the local source is /srv/photos. First ask rclone what it would transfer:

$ rclone copy --dry-run /srv/photos backup:photos
2026/09/26 18:00:00 NOTICE: holiday.jpg: Skipped copy as --dry-run is set (size 4.2Mi)
2026/09/26 18:00:00 NOTICE:
Transferred:            1 / 1, 100%

With --dry-run, rclone goes through the operation without copying or deleting files. Output depends on your files and backend. Look for unexpected paths, a reversed source and destination, or a destination outside the intended remote. Repeat the dry run after changing filters or flags.

While learning, --interactive or -i is another guard recommended by the manpage. It asks before operations, but it is not a substitute for checking the paths. --progress or -P shows transfer statistics; it does not make an operation reversible.

5. Copy without deleting destination files

Once the dry run is correct, use copy for an additive backup:

$ rclone copy --progress /srv/photos backup:photos

copy transfers new or changed files and does not delete files already at the destination. Rclone copies the contents of a directory, not an extra directory level. Thus /srv/photos places its contents below backup:photos, rather than creating backup:photos/photos.

To limit a scheduled run to recent files, the installed command supports a duration such as:

$ rclone copy --dry-run --max-age 24h /srv/photos backup:photos

Read the dry-run output carefully. A time filter can omit older files that you expected to protect.

6. Verify both sides

After a copy, compare source and destination:

$ rclone check /srv/photos backup:photos
2026/09/26 18:02:00 NOTICE: Local file system at /srv/photos: 12 matching files
2026/09/26 18:02:00 NOTICE: S3 bucket backup:photos: 12 matching files

A successful check reports matching files and exits successfully. The exact wording and counts vary. By default, check compares sizes and hashes where available and does not alter either side. Use --download when you specifically need content downloaded and checked, accepting the bandwidth cost. Use --one-way only when extra destination files should be ignored; it will not detect those extras.

If the check reports a file missing on the destination, inspect authentication, filters, path spelling and the transfer log before retrying. Do not jump straight to sync.

7. Treat sync as a deletion operation

Use sync only when the destination really must become identical to the source:

$ rclone sync --dry-run /srv/photos backup:photos

The dry run is the checkpoint. Any destination-only file shown for deletion must be accounted for. If the proposed changes are correct, run the same command without --dry-run:

$ rclone sync --progress /srv/photos backup:photos

There is no general undo for a remote deletion. For a recovery path, use a separate destination or configure a provider feature such as versioning or trash where available. Rclone also supports --backup-dir REMOTE:PATH for keeping replaced or removed destination files in a backup hierarchy, but test that policy with a dry run and confirm the provider's storage costs before relying on it.

The global --max-delete option can limit deletions during synchronisation. Treat it as a second safety net, not permission to skip the dry run. Do not use --force to bypass a safety check unless you have reviewed the complete change set and have recovery coverage.