Syncthing vs rsync vs Unison: comparison for two-way synchronization between VPS servers

By · Published on · 8 min read

Man and woman in an office looking at a laptop screen; one holds another closed laptop
Team evaluating solutions and synchronization between VPS servers Photo: Mikhail Nilov / Pexels

Compare Syncthing, rsync and Unison for two-way synchronization between VPS servers. Learn when each tool is the better fit, how they handle conflicts, performance, security and automation. The page provides objective criteria by scenario and a simple test plan you can run in your environment before standardizing a solution.

When two-way synchronization between VPS servers is needed

Two-way synchronization is useful when both servers may receive changes and you want automatic convergence without overwriting data. Typical examples: collaborative file editing, active nodes sharing content, or staging and production environments that exchange controlled data.

If you only need one-way copy (backup, mirror), unidirectional sync is usually simpler and safer. For two-way sync, conflicts and deletions require clear rules and tools that correctly detect changes.

A well-defined exclusion and retention policy reduces risk. Combine it with periodic sample checks to detect divergences early.

  • Active-active environment with mutable content on both sides
  • Continuous sync of working directories between VPS servers
  • Gradual migration between servers with temporary two-way traffic
  • Clusters without shared storage, relying on eventual consistency

Overview: Syncthing, rsync and Unison in 1 minute

Syncthing is P2P, bidirectional by default, with discovery, end-to-end encryption and detection of renames and changed blocks. It runs continuously and copes with NAT using relays and introducers.

rsync is unidirectional. For two-way sync you need orchestration in both directions and extra logic for conflicts. It shines for mirrors and scheduled jobs, with powerful filters and delta transfers.

Unison provides true two-way syncing over SSH, with declarative profiles, conflict and rename detection. It runs in batch or interactive mode, useful when you want explicit control over convergence.

Comparative table of features and limitations

Quickly compare criteria that often matter when choosing. Use this as a checklist for your case. Adjust ignores/filters and topology before measuring performance.

Criterion Syncthing rsync Unison
Synchronization model Continuous bidirectional (near real-time) Unidirectional per run; bidirectional only with orchestration Bidirectional by design (batch)
Transport Direct connections, relays; end-to-end TLS Typically over SSH (or rsyncd daemon) Native SSH (or local socket)
Change detection inotify + periodic scanning stat/mtime + checksums on demand State tracking + efficient scanning
Renames/moves Detects and reuses blocks Treated as delete+add in most cases Detects moves/renames
Conflicts Optional conflicted versions/files No native resolution (last write may win) Marks conflicts and prompts/applies rules
Encryption in transit TLS with device IDs Via SSH (when used) Via SSH
Working behind NAT Works with relays/UPnP Depends on SSH access/open port Depends on SSH access/open port
Scheduling Continuous by default Scheduled via cron/systemd timers Run on demand or scheduled
Delta granularity Block-level (streaming) Efficient block deltas Block deltas between replicas
Scalability (n nodes) Multiple peers; P2P topologies One-to-many with scripts Defined pairs; can scale with profiles
Visibility / GUI Native GUI and API Command line; wrappers available Command line; third-party interfaces
Filtering/ignore .stignore patterns per folder Powerful include/exclude Patterns in profiles
Typical use Continuous sync with changes on both sides Deploys, mirrors, incremental backups Controlled, declarative two-way sync

Performance and resource usage: what really matters

Performance depends more on change patterns and the network than on the tool. Many small files penalize scanning and latency. Large files favor protocols with block-level delta.

CPU and disk matter for calculating checksums and reading blocks. On high-latency networks, compression and block pipelining help. On bandwidth-limited links, throttling avoids contention with production traffic.

rsync offers fine-grained tuning (compression, delta, inplace, partial). Syncthing balances continuous scanning and hashing to minimize block retransmission. Unison works with profiles, useful to isolate noisy subtrees.

For heavy loads, consider scheduling in off-peak windows and monitor disk I/O so synchronization doesn't interfere with databases or queues.

  • Optimize noisy directories with ignores to reduce scanning
  • Batch small changes into short windows when possible
  • Avoid syncing temporary files and caches (node_modules, .cache, tmp)
  • Monitor CPU/IO to avoid competing with critical workloads

Security and connectivity between servers

For secure traffic, rsync and Unison commonly use SSH, inheriting keys, policies and logs. Syncthing encrypts end-to-end and authenticates by device IDs, without requiring SSH.

Behind firewalls, SSH access simplifies rsync/Unison. Syncthing can connect via relays when there’s no direct route. Control ports and policies with your firewall and audit access. See a practical firewall guide at How to set up a firewall on Ubuntu with UFW.

If you need secure access between networks, a site-to-site VPN avoids exposing ports publicly and stabilizes latency. There is a walkthrough at WireGuard site-to-site between two Debian VPS.

For centralized SSH administration, a jump host helps standardize policies and auditing. See How to set up an SSH bastion on Ubuntu 22.04.

  • Restrict ports with clear ingress and egress rules
  • Require SSH keys and rotate them periodically when applicable
  • Consider a site-to-site VPN for internal sync traffic

Automation, observability and operations

Predictability matters in operations. rsync excels with scheduling via timers, logs and simple exit codes that integrate well. Unison can also run in jobs and log conflicts for review.

Syncthing exposes a native GUI and API to observe peers, queues and events. Monitor resource usage and failures, and handle conflicts with versioning when simultaneous edits occur.

Centralize logs and metrics to detect connection drops, out-of-spec directories and anomalous queue growth. A logging stack helps, for example Fluentd + Elasticsearch: PHP logs on a VPS, and metrics/alerts with Prometheus & Grafana with Docker Compose on VPS.

  • Use systemd timers for controlled synchronization windows
  • Monitor latency, throughput and file backlog
  • Version conflicts in separate directories for auditability

Choose by scenario: practical recommendations

Choices depend on who edits, when they edit and operational requirements. Use these criteria to reduce risk and effort. If strong audit requirements and defined windows exist, prefer batch modes; for continuous collaboration, favor P2P.

  • Near real-time, two sides editing and NAT in the path: Syncthing
  • Controlled mirror with strong filters and job auditing: rsync (one-way)
  • Two-way under control, with conflict review: Unison
  • Deploys and artifact distribution: rsync
  • Environments with many renames/moves: Syncthing or Unison (native detection)
  • Unstable links with resume and delta: any tool with block delta; validate with your traffic

How to test in your environment (no assumptions)

Before standardizing, run a short, representative test. Build a realistic dataset, perform an initial sync, then apply: a few renames, small edits within large files and create/remove many small files. Measure total time, CPU/IO and force a deliberate conflict.

Avoid absolute numbers and focus on comparisons on the same host/link. Document flags, filters and windows used so you can repeat the test after infrastructure changes. If possible, run under bandwidth limits to observe retries and delta behavior.

This test plan verifies objectively what this comparison anticipates — but always validate with your data and change patterns.

  • Create profiles/filters to exclude temporaries and caches
  • Measure three runs: initial, light incremental and heavy incremental
  • Simulate conflict by editing the same file concurrently
  • Test under bandwidth limits to observe behavior

Frequently asked questions

Can you do two-way synchronization using only rsync?

Technically possible by orchestrating two rsync flows and extra logic to resolve conflicts, but it's risky. rsync doesn't detect renames natively and “last write wins” can cause data loss. For true two-way sync, consider Syncthing or Unison.

Is Syncthing suitable for production-critical servers?

It can be, if you handle governance: conflict versioning, well-filtered directories and observability. Run it as a service, limit resources and validate scan impact during peak hours. In regulated environments, document exclusion and retention policies.

Is Unison still a viable option today?

Yes — for declarative, controlled two-way synchronization. It detects conflicts and renames, works well over SSH and supports reproducible profiles. It's handy when you prefer sync rounds with review instead of continuous flow.

How to avoid data loss from synchronization conflicts?

Define rules: version conflicts into a separate directory, update windows, lock sensitive file types and protected excludes. In two-way setups, test simultaneous-edit scenarios and document conflict resolution procedures before going to production.

How to monitor whether synchronization is working?

Collect logs and exit codes from jobs (rsync/Unison) and metrics/state from Syncthing. Centralize them in an observability stack and set alerts for repeated failures, growing backlog and connection drops. Periodic sampling audits help detect drift.

Want to decide with confidence?

If you need to design, validate and automate synchronization between VPS servers with low conflict risk, we can discuss scenarios and practical tests.

Talk about your case

See also