Between the backup tools of the previous articles and the raw storage backends sits a tool whose job is the plumbing: moving data between locations, one-way or two-way, with the same forty-cloud vocabulary regardless of what sits at each end. Rclone speaks more than seventy backends, from the S3 family through every consumer cloud drive to plain SFTP and local paths, and wraps them all in one command surface, rsync's vocabulary extended to the sky. This article builds the two features that elevate it from a copy tool to a storage platform: the crypt remote, which encrypts content and filenames on the client so the backend stores only opaque data, and bisync, the bidirectional synchronization that keeps two locations honest about each other's changes.
The remote abstraction and the interactive configuration
Every destination rclone knows is a remote, a named configuration holding the backend type and its credentials, and the list is the tool's map of the world:
$ rclone listremotes
backups:
archive:
minio:
Creating one is the interactive walk:
$ rclone config
n) New remote
name> archive
Storage> s3
provider> Minio
endpoint> https://minio.internal:9000
and the same session configures any other backend: the S3 family with its endpoint and keys, the consumer drives with their OAuth flows, SFTP with the key path and host, each backend's questions answered once and remembered under its name. The configuration lives in a single file, ~/.config/rclone/rclone.conf, and the production pattern treats it like the credentials document it is: versioned in the secrets manager, distributed through configuration management, never committed in the clear.
The commands that read before writing belong to the working vocabulary early: rclone lsd archive:backups lists the directories of a remote path, rclone ls the files, rclone size the totals, and rclone about the backend's capacity where the provider reports it, the reconnaissance set that makes every later command deliberate.
One-way sync and the honest core vocabulary
The flagship command is sync, one-way and authoritative:
$ rclone sync /srv/data archive:backups/app01
which makes the destination identical to the source, copying new and changed files, deleting destination files that no longer exist at the source, and the semantics are the ones rsync taught the industry: the source is the truth, the destination is the mirror. The copy sibling does the same minus deletion, adding files without removing anything, the right tool for the append-style archive, and the move sibling deletes from the source after the upload verifies, the migration command. Every destructive verb supports the dry run, --dry-run, whose output belongs in every runbook's first attempt, and the check command completes the vocabulary, comparing two locations by size and by hash where the backend supports it, the verification pass that the backup discipline of this series always pairs with the copy.
The parallelism and pacing knobs deserve their line: --transfers 8 and --checkers 16 control the concurrent uploads and the verification threads, and --bwlimit keeps the nightly sync from monopolizing the office line, the same bandwidth consideration the rsnapshot article raised for its rsync underneath, the small transfers of many files and the large transfers of few files wanting different balances on different links.
The crypt remote, encryption on the client side
The crypt remote is a wrapper, a configuration layer that sits above another remote and encrypts everything before it reaches the wrapped backend, and the composition is the entire point: the S3 bucket behind a crypt remote stores filenames and contents that are opaque to the operator, to the provider, to anyone with the credentials but not the password. The setup is another config session:
$ rclone config
name> secrets
Storage> crypt
remote> archive:encrypted
password> the-client-side-secret
password2> an-optional-second-factor
and from that moment, every path under secrets: reads and writes through the encryption layer:
$ rclone sync /srv/private secrets:docs
uploading encrypted chunks and names to the archive backend, and reading back transparently, the same command shape as an unencrypted remote with the cryptography entirely underneath. The two passwords are the custody story: the first encrypts the content, the second the filenames, and the loss of either is the loss of the data, the same master-secret discipline the restic and Borg articles established, the password manager, the paper copy, the tested restore. The pragmatic architecture puts the crypt layer on exactly the destinations that need it, the public backends and the shared internal stores, while the trusted local paths ride plain, one tool covering both postures with a one-word difference in the destination name.
Bidirectional sync with bisync
One-way sync answers the mirror question, and the two-way question, two locations that both receive changes and must converge, is bisync's territory:
$ rclone bisync /srv/project drive:project --resync
The resync flag belongs to the first run only: it establishes the pairing, treating the first path as the authoritative baseline and building the state that every later run consults. The subsequent runs are the plain invocation:
$ rclone bisync /srv/project drive:project
and each run's logic reads as a three-way conversation: the paths changed on side one since the last run copy to side two, the paths changed on side two copy to side one, and the conflict, the same path changed on both sides, is reported rather than resolved, the tool refusing to guess what the human meant, and the conflict list is the output that belongs in the runbook's error handling section, the sync that ends with conflicts needs a human's next step.
The pairing state is the operational detail worth knowing: bisync tracks what it saw last time, and the state lives on the local side, which means a machine change without the state's migration produces the first-run situation again, and the recovery is the resync with the correct direction chosen deliberately. The two patterns that keep bisync healthy in production: the dry-run flag on every schedule's first cycle after any interruption, and the conflict resolution discipline, the human resolving in one direction and the next sync converging the pair, the workflow that keeps the bidirectional tool honest on the days when both sides were busy.
Filters, mounts and the scheduled operation
The filter system controls what a sync touches, and the filter file, --filter-from, is the versioned artifact that encodes the policy:
+ /srv/data/**
+ /etc/app/**
- *
the include patterns white-listing the trees the sync owns and the final exclude catching everything else, the same explicit-listing discipline the iptables OUTPUT article brought to the network. The mount command completes the read side:
$ rclone mount secrets:docs /mnt/cloud --vfs-cache-mode writes
exposing the remote, through the crypt layer where it wraps one, as a filesystem, the applications that speak only files reading and writing the cloud storage directly, and the cache mode on writes being the detail that makes the mount responsive, the local cache absorbing the writes and the background flush matching the cloud's eventual consistency.
The scheduled operation is the systemd timer pattern from across the series, and the two habits that keep a scheduled rclone healthy are the log and the dry run: the timer's service unit writing rclone's log output with the -v flag to the journal, and any schedule change running one manual dry-run cycle before the calendar takes it over. The monitoring story is the newest-snapshot-age pattern the backup articles built, translated to the sync's vocabulary, the last successful sync's timestamp as the health metric, and the alert that fires when the mirror has been quiet for longer than its schedule allows.
The closing position on the tool
Rclone's niche in the storage stack is the connective tissue: the tool that moves data between the platforms this series built, the backup tool whose repository it ships off-site, the archive tier it bridges to the object store, the two machines whose project directory must converge. The crypt layer adds the custody control, the bisync mode adds the two-way intelligence, and the seventy backends mean the plumbing never becomes the project, the destinations are names in a config file, and the movement of data is one command regardless of what the two ends are made of, which is exactly what connective tissue is supposed to feel like.
## Serving remotes, the unexpected direction
Rclone's mount turns a remote into a client-side filesystem, and the serve family turns the tool itself into a server, exposing any remote, local path or crypt-wrapped layer through a standard protocol:
$ rclone serve sftp archive:backups --user reader --pass ephemeral
$ rclone serve http minio:public --addr :8080
the SFTP form serving a read-only view of the archive over SSH, the HTTP form turning a bucket into a simple file tree for a browser or a download link, and the WebDAV and S3-server forms completing the protocol set for the consumers that speak each. The serve mode earns its paragraph because it inverts the plumbing: the tool that was the client becomes the adapter, the storage that speaks only one cloud API becomes reachable through every standard protocol, and the operational pattern of serving an internal archive to a team that expects SFTP is a one-line service rather than a new component to maintain.
Copying between backends and the bridge pattern
The pattern that makes rclone the storage platform's glue is backend-to-backend copying, the tool reading from one remote and writing to another, the local disk as an optional participant rather than a required waystation:
$ rclone copy minio:app-backups archive:app-backups
the migration between object stores, the off-site shipping of a backup repository, the consolidation of scattered drives into the corporate bucket, all one command with the same sync semantics and the same parallel machinery as any local transfer. The bridge pattern completes the backup architecture from the previous three articles: the restic or Borg repository that lives on the local or S3 backend gets its second copy on the off-site backend through a scheduled rclone copy, the four-line cron entry that closes the off-site gap without asking the backup tool to speak another backend's protocol, the single-responsibility design where each tool does its own job and the glue between them is one command.
The comparison with the series' other movers draws itself cleanly: rsync's domain is the filesystem-to-filesystem edge, and rclone's domain is everything beyond it, the two tools sharing enough vocabulary that the operator who learned one reads the other immediately. The consumer-drive backends deserve one honest sentence about the working reality: the OAuth flows and the API limits of the consumer clouds are a different contract than the S3 family's keypair, and the operational pattern for the drives carries the throttle awareness and the daily-quota respect that the vendor's terms ask for, while the S3-family backends behave like the predictable storage the earlier articles built them as.
The closing measurement
The rclone setup's report card matches the backup trio's: the last successful sync's age, the log's error count on the last window, the bisync conflict list empty, and the crypt destination verified by a quarterly readback through the mount. The four answers fit on one dashboard line, the quarterly rehearsal exercises the readback through the same commands the daily work uses, and the tool that took an evening to configure spends the rest of its life as infrastructure nobody notices, which is the highest compliment that plumbing can earn.