rsync Over a VPN: Which Side Is the Source of Truth?

Two servers, one VPN, one directory that must exist in both places, and a command that is easy to run and hard to undo. Before typing it, decide which copy is authoritative, because every rsync question that follows depends on that answer. A one-way replica, a shared working folder and a versioned archive need different rules for edits and deletions. The tunnel supplies the path and has no opinion about any of them.

Decide which copy wins before you type a command

Write the direction down in one sentence, including the hostname and the path on each side, and get it agreed by whoever owns the data. In this walkthrough the source is /srv/publish/ and the destination is an account on fileserver.example that may write only /srv/mirror/.

Confirm the transport facts before the copy: the SSH host key has been verified, the destination account can write the replica area and nothing else, and both hosts have compatible rsync versions. Those preconditions stop a small scheduling mistake from becoming a permission incident. They also tell you which account will appear in the destination's logs when something does go wrong.

Preview the copy and read the itemized list

Run the copy with the preview flag first, and keep the output. The itemized changes tell you what would happen to each path, which is far more useful than a completion summary after the fact. Keep the output in the change record so the next run has something to be compared against.

rsync -rt --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

The trailing slash matters. On the source, it means the contents of that directory, while omitting it adds a directory level named after the source. The rsync manual documents both forms along with the preservation flags, and the option set you need depends on the data rather than on habit.

Read every line against the destination you intended. Removing the preview flag performs the copy and can overwrite files, and without a deletion option the extra files already at the destination simply stay where they are. That is the safe default only if you have actually decided stale files behind are acceptable. When the answer is no, the deletion decision below is the one to make, not an extra flag to sprinkle into this command.

Then decide whether deletion travels

Making the destination a mirror is a second decision, not a refinement of the first. Preview it on its own, with the deletion flag added and nothing else changed, so the difference in the list belongs entirely to that decision.

rsync -rt --delete --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

Deletion removes extraneous receiving-side files inside the synchronized scope, which is why a mistaken source path, an unmounted directory or a filter that excludes more than intended can make a destructive run look like a clean mirror. The preview list is the only place that difference becomes visible before it is expensive. Keep an independent recovery copy wherever the data justifies one, and remember that a mirror faithfully reproduces an accidental deletion instead of preserving history.

A preview also locks nothing. People edit files between the dry run and the real one, and filesystems have opinions of their own, so the run you approve and the run that executes are not the same operation unless both trees are quiet.

Two one-way jobs do not make a two-way sync

Running the same command in both directions is the most common way to lose data in this scenario. Each direction treats the other side as the destination and happily overwrites newer content, and deletions mirror in whichever order the schedule fires.

If users must edit both copies, that is a different product decision: conflict handling, deletion tracking and a tool designed for the model. Approximating it with schedule ordering is how a shared folder acquires two versions of every document nobody can reconcile. Decide it explicitly instead of approximating it with two cron entries and hope.

Automate only after the policy is written

A scheduled job should carry the direction, the paths, the metadata policy and the deletion decision that were approved. Put those five facts in the job file itself, not in a wiki page that the next administrator may never read. Prevent overlapping runs, because two copies writing the same tree at once produce a state neither of them intended.

When the source is a live database or another multi-file dataset, take an application-consistent export or a coordinated snapshot first. A recursive file walk is not a transaction, and a copy of a changing dataset is not a consistent one.

Record completion and failures, and check the dataset at the destination rather than only the exit status. Restoring the VPN after an outage restores connectivity; it says nothing about whether the last copy finished or whether conflicting edits were ever resolved.