A one-way transfer is often described as the safer choice because it does not remove destination-only files. That is true of rclone copy, but it is not enough to make the command safe to place in a scheduled job. The source and destination still need to be named correctly, a dry run must show the expected scope, and a successful transfer needs a separate comparison before it becomes evidence that the copy is usable.
This guide tests those boundaries with rclone 1.75.1 on Linux AMD64 in a disposable local directory. A source directory held two synthetic files and the destination began with one different file. rclone copy --dry-run reported that the two source files would be copied while leaving the destination unchanged. The real copy transferred both files and retained the destination-only file. rclone check --one-way then reported zero differences. After one destination file was changed, the same check exited nonzero and reported a size difference. The useful result is that dry-run proves planned scope, while check catches a later mismatch; neither result authorizes an unreviewed source or destination path.
The test uses only local directories and synthetic text. Do not substitute a backup repository, a mounted production share, a customer export, or a remote name into a first validation run. A remote introduces its own credentials, retention, lifecycle, encryption, and server-side behavior. Establish the command boundary locally, then test the approved remote in a separate authorized change.
Decide what copy is allowed to preserve
rclone copy makes the destination contain the files present at the source, but it does not delete files that exist only at the destination. That makes it suitable for an additive transfer where the destination may have retained files, separate writer output, or a deliberately longer retention period. It is not a mirror operation. If the desired result is that destination contents exactly match the source, investigate rclone sync separately and treat its deletion behavior as a higher-risk change.
Start by writing down the direction in plain language: “copy this reviewed source into this approved destination without deleting destination-only files.” That sentence should still be true after variables, shell aliases, mounts, and remote names are expanded. Do not rely on directory names such as backup or production to supply that meaning.
Use explicit variables during a reviewable local test:
source_dir=<source-dir>
destination_dir=<destination-dir>
rclone copy --dry-run --stats 0 "$source_dir" "$destination_dir"
The first positional path is the source and the second is the destination. --dry-run makes rclone report the file actions it would take without writing them. --stats 0 suppresses periodic progress reports so a small log is easier to inspect; it does not change transfer behavior. Keep --dry-run on the command until every planned create, update, and skip makes sense. A quiet command is not a clean plan if its paths are wrong.
A dry run does not validate access to every storage layer in the same way as a real transfer, and it cannot prove that a remote’s credentials, quota, object lock, or server-side policy will allow the later write. It is a scope check. For a remote operation, run it with the exact remote configuration and least-privilege credentials that the real job will use, but keep those credentials and remote definitions out of transcripts and repositories.
Build a disposable local test
Use a new directory and names that cannot be confused with a real transfer target. The destination starts with keep.txt to demonstrate the behavior that distinguishes copy from a destructive mirror.
work=$(mktemp -d)
mkdir -p "$work/source" "$work/destination"
printf 'first synthetic file\n' > "$work/source/first.txt"
printf 'second synthetic file\n' > "$work/source/second.txt"
printf 'destination-only file\n' > "$work/destination/keep.txt"
The files are intentionally small because the question is file selection, not throughput. A throughput test needs a separately designed data set, storage metrics, and a defined network boundary. Do not turn a scope check into an unbounded performance job by pointing it at a large tree.
Now preview the operation:
rclone copy --dry-run --stats 0 "$work/source" "$work/destination"
In the validation run, rclone 1.75.1 reported first.txt and second.txt as skipped because --dry-run was set. Neither file appeared in the destination afterward, and keep.txt remained present. That is the decision point to inspect the names and count. If an unexpected path appears, stop and correct the source selection or destination mapping before removing --dry-run.
For a scripted check, assert the state rather than trusting a visual scan of the log:
test ! -e "$work/destination/first.txt"
test -e "$work/destination/keep.txt"
The first assertion confirms that dry-run did not write the planned source file. The second confirms that the pre-existing destination file is still present. These are useful local assertions, but a remote test may need an API listing, storage console review, or an approved read-only inventory command to prove the equivalent state.
Copy, then compare the resulting files
Only after the dry-run has the intended scope should the write command run:
rclone copy --stats 0 "$work/source" "$work/destination"
rclone check --one-way --stats 0 "$work/source" "$work/destination"
test -e "$work/destination/keep.txt"
check compares the source with the destination. --one-way makes the comparison focus on whether each source file has a matching destination file; a file that exists only at the destination does not make the check fail. That matches the contract for copy. Do not omit this distinction when turning the command into automation: a two-way expectation or a cleanup requirement needs a different policy and likely a different command.
The local 1.75.1 run copied both synthetic source files, reported zero differences and two matching files, and kept keep.txt. This demonstrates that a clean one-way check and retention of a destination-only file can both be true. It does not prove that an application can read the copied data, that a remote storage class meets recovery requirements, or that the files are protected from deletion later.
A positive comparison should have a negative companion. Change one destination file after the copy, then require the same check to fail:
printf 'modified destination bytes\n' > "$work/destination/first.txt"
if rclone check --one-way --stats 0 "$work/source" "$work/destination"; then
printf '%s\n' 'unexpected check success' >&2
exit 1
fi
The validation run exited nonzero and identified first.txt as having different sizes. Exact diagnostic text can vary with rclone versions and backend behavior, so make automation depend on the nonzero status, then retain the restricted log needed to diagnose the difference. Do not add || true to make a scheduled job appear healthy. A difference can be an interrupted transfer, a changed source, an overwriting writer, a transformation option, or a storage problem; each needs an operator decision.
Put the boundary into an operational job
A production wrapper should keep its policy visible: fixed source and destination inputs, dry-run used during change review, a real copy only after approval, and check before reporting success. Record the rclone version and the selected flags with the job. Options that transform names, filter files, change checksums, or delete data can change what “matching” means.
Run the job under an account that can read only the intended source and write only the intended destination. Keep remote configuration and any provider credentials in the approved secret store or service account mechanism, not in a shell variable shown in a ticket. For a recovery or archival workflow, follow the storage owner’s retention, encryption, restore-test, and monitoring requirements in addition to this file-level check.
Remove the disposable directory only after confirming its path is the temporary test location:
rm -rf "$work"
Do not adapt that cleanup line to a shared or production directory. The test directory exists solely because mktemp -d created it for this run.
A one-way copy has two separate claims to prove. Dry-run shows which files rclone plans to affect, while rclone check --one-way tests whether the copied source files still match at the destination. The local test also shows why destination-only files need an explicit policy: copy can preserve them while the comparison still succeeds. Make that behavior deliberate before a transfer job is trusted with real data.