How to Sync Two Synology NAS in Different Locations — 20 TB Across the Ocean in 60 Hours
Keeping a Synology in Japan and a Synology in the US identical at ~110 MB/s on ordinary home fiber — and where Synology’s own sync tools still fit.
You have two NAS boxes in two places — say one in Tokyo and one in California — and you want them to hold the same files. Every NAS vendor ships something for this, and most of it was designed in the LAN era. It shows the moment your packets have to cross an ocean: add 120 milliseconds of round-trip time, and “sync” quietly turns into a background chore that runs for days.
This article is the guide I wish I’d had: how to set up cross-region NAS-to-NAS replication with WarpSend, why it’s fast (with real numbers from a Japan↔US deployment), and a proper look at each of Synology’s built-in options so you can tell when one of those is actually the right tool.
Meet WarpSend
WarpSend is a NAS-to-NAS transfer and replication tool built for exactly one painful scenario: moving serious amounts of data between machines that are far apart on imperfect networks.
The shape of it is simple. A small agent runs on each endpoint — Synology (DSM 7.0+, x86–64 models), macOS, or Windows — and a web console coordinates them. File data moves directly between your machines over an encrypted QUIC tunnel; the cloud handles identity, pairing, and orchestration, and never holds a decryption key. When two endpoints genuinely can’t reach each other directly, transfers can relay through Cloudflare’s edge instead — as ciphertext the relay cannot read.
The pitch in one measurement: between a Synology in Japan and a Synology in the US — ~120 ms RTT, ordinary 1 Gbps home fiber on both ends — WarpSend sustains around 110 MB/s. That is roughly 88% of what the line can physically carry, across the Pacific, with encryption on. In that deployment, the initial replication of a 20 TB dataset finished in about 60 hours, completely hands-off; the same dataset over Synology’s own Drive ShareSync took twelve days.
The rest of this article explains the setup (it’s four screenshots long) and then the physics of that gap.
The whole setup, in four steps
There is no command line in this walkthrough, no port forwarding, and no editing rsyncd.conf. If you've installed a DSM package before, you already know the hard part.
Step 1 — Download the agent
Sign up at warpsend.io, open Agent Download, and grab the package for each machine. For a Synology NAS that’s an .spk file, about 19 MB.
Step 2 — Install it on the NAS
In DSM, open Package Center → Manual Install, pick the .spk, click through. A few seconds later WarpSend shows up as Running. Do the same on the second NAS.
Package Center after the install — WarpSend runs as a background service on the NAS.
Step 3 — Connect the device
Open WarpSend from Package Center and click Sign in with WarpSend. Your browser opens, you approve the device, and the agent connects to your account. Both NAS now appear as endpoints in the web console, with live online/offline status.
Step 4 — Create a sync pair
In the console, go to Replication → Sync Pairs and hit +. Pick the source NAS and folder, the target NAS and folder, and how you want it to run:
- Transport — Tunnel (Direct) is the default and the fast path: the two endpoints connect straight to each other. Shuttle relays through the WarpSend network for the cases where a direct connection isn’t possible or the receiver isn’t always online.
- Direction — one-way push, or bidirectional (bidirectional runs over the direct tunnel).
- Schedule — Continuous (the agent watches the filesystem and reacts within seconds) or fixed intervals from every 15 minutes up to daily.
- Bandwidth — unlimited, or capped anywhere from 10 Mbps to 1 Gbps if the NAS shares the uplink with people who’d like to keep using it.
- Propagate deletions — off by default. Sync tools that mirror your deletions by default have ruined enough weekends; with WarpSend you opt in.
Save it, and the pair goes to work. The list shows each pair’s state, transport, and last sync at a glance.
That’s the entire setup. From box-fresh NAS to replicating across the planet is comfortably under ten minutes.
The numbers
The test deployment is deliberately unglamorous — no datacenter links, no tuned kernels. Two Synology boxes, two continents, home fiber:
For scale: the same dataset over Drive ShareSync took about 12 days — nearly five times longer on the same wire, averaging ~19 MB/s.
At 110 MB/s the bottleneck is the line itself, not the software. That’s WarpSend’s design goal in one sentence: whatever your two sites can physically carry, the sync should use nearly all of it.
And to be clear about what the comparison means: ShareSync isn’t broken — it’s a fine product doing what a single-TCP-connection design can do at 120 ms. The gap is structural, which brings us to the interesting part.
Why long distance kills ordinary sync — and what WarpSend does about it
The problem is the bandwidth-delay product. A 1 Gbps path with 120 ms of round-trip time only runs at full speed if about 15 MB of data is in flight — sent, but not yet acknowledged — at every moment. One TCP connection with default settings rarely keeps a fraction of that airborne. Worse, classic congestion control halves its sending rate on a single lost packet and then takes ages to climb back, because every step of the climb costs a 120 ms round trip. Tools that ride one TCP connection — the rsync family, Drive’s sync protocol — are structurally capped long before your line is.
Get Barry’s stories in your inbox
Join Medium for free to get updates from this writer.
WarpSend’s engine (written in Rust) attacks exactly that:
Parallel QUIC, tuned for fat pipes. The direct tunnel runs on QUIC over UDP with BBR congestion control, which probes for available bandwidth instead of treating every lost packet as a catastrophe, and fans a transfer out over multiple parallel connections — up to 16, scaled to the hardware — under a shared in-flight budget that keeps the pipe full without blowing up the NAS’s RAM. The stack itself is tuned for bulk data (larger transmit budgets, loss-adaptive pacing); stock QUIC settings are built for web pages, not terabytes.
Direct connection without router surgery. The two agents find each other by NAT hole punching — STUN candidates exchanged over a signaling channel, then a simultaneous QUIC punch — which works through typical home and office routers with zero port forwarding. Once the tunnel is up, bytes flow NAS-to-NAS and nowhere else.
A relay that stores ciphertext, for when direct is impossible. Shuttle mode cuts files into content-defined chunks (1–16 MB), names each by its BLAKE3 hash, encrypts it, and moves it through Cloudflare R2 with parallel uploads and downloads. Content addressing means a chunk already on the relay never uploads twice, an edit inside a big file ships only the chunks that changed, and an interrupted run resumes exactly where it stopped. Sender and receiver are decoupled — the target NAS can be offline while the source uploads.
End-to-end encryption the operator can’t undo. Keys come from an X25519 exchange between the two endpoints (HKDF-SHA256 derivation); payloads are AES-256-GCM-encrypted before they leave your NAS; every file is verified with BLAKE3 on arrival. The cloud stores public keys and coordination state — never private keys, never plaintext.
A sync engine that sweats the boring cases. Change detection uses native filesystem events with a 500 ms debounce, and each run three-way-merges against a snapshot of the last successful sync, so “changed on A,” “changed on B,” and “deleted on A” are distinguishable. Conflicts keep both copies — the newer wins, the loser survives as a .sync-conflict-* file. An edit on one side beats a delete on the other; suspicious mass deletions are blocked until approved; and on Synology the walker prunes @eaDir, #recycle, and #snapshot instead of faithfully replicating thumbnails across the Pacific.
None of these ideas is exotic on its own. The product is having all of them, wired together, behind a dialog with five settings.
What Synology gives you out of the box
Before reaching for anything third-party, know the native options — each is genuinely good at the job it was designed for, and I’ve run all of them across sites. The question that sorts them out is always the same: where does the source of truth live, and which way does data flow?
Shared Folder Sync: the one-way mirror
Shared Folder Sync is productized rsync: the source NAS owns a task, the destination only enables the rsync service, and data flows in exactly one direction over TCP 873 or SSH. The first run is a full copy; afterwards only changes move, and deletions propagate. Synology’s own help page says it plainly: if you need two-way sync, use Drive ShareSync.
What it adds over raw rsync is operational polish. Triggers can be “on data modification” — driven by file-system events, so the mirror updates moments after a write — manual, or scheduled, and a scheduled run with no changes is skipped instead of executed empty. Transfers can be SSH-encrypted and compressed, and an optional block-level mode ships only the changed regions of big files. The destination protects itself, too: the synced folder is created automatically and locked down — administrators get read-only, everyone else no access — because anything written on the mirror would be silently overwritten by the next run.
The limits to know before committing: it syncs whole shared folders only (no subfolder selection), concurrent tasks are capped per model (2 on entry boxes, up to 32 on the big FS/SA machines), the account creating the task must be an administrator on the destination and can’t use 2FA, and the two machines must have different server names. And on the wire it’s still a single rsync TCP stream plus a full tree scan per run — cheap on a LAN, increasingly expensive with distance and with millions of files.
Free, built in, and excellent at LAN mirroring and one-to-many distribution. That’s its home turf, and inside it there’s no reason to pay for anything else.
Drive ShareSync: site-to-site collaboration
ShareSync is best understood as a Synology Drive client that happens to be a NAS. Install Synology Drive Server on both machines, enable the folders you care about as Team Folders, and one NAS subscribes to the other’s folders exactly the way a desktop Drive client would — same engine, same port (TCP 6690, TLS optional). One hub NAS can serve many spokes.
Its feature set is the richest of the built-ins. Direction is per folder: two-way, upload-only, or download-only. Sync is event-driven and near-real-time, and modified files move as block-level increments rather than whole files. Every synced file lands in Drive’s version store — up to 32 historical versions plus a recycle bin — and conflicts are survivable: when the same file changes on both ends, the newer copy wins and the losing copy is renamed and kept, tagged with its origin. You can sync selected subfolders and filter by size, type, or name pattern. If you need per-file version history at every site, this is the option that has it — WarpSend doesn’t (it keeps conflict copies, not a version store; pair it with snapshots or Hyper Backup for history).
The bill: a full Drive Server with its file-indexing database and RAM footprint on every site, admin pairing on both ends (insufficient permissions silently degrade two-way to one-way), and a port that must be reachable across sites — which in practice means port forwarding or a relayed QuickConnect path. And the sync engine, however featureful, rides a TCP design that was never meant to fill an intercontinental pipe. That’s the twelve-day number in the test above.
Hybrid Share: the cloud is the master copy
The two tools above copy data between machines. Hybrid Share inverts the model: the only full copy lives in Synology’s C2 Storage cloud, and every NAS mounts the same cloud folder, keeping just a local cache. To users and applications it looks like an ordinary shared folder — SMB, File Station, everything works as usual.
The mechanics are elegant. Writes land in the local cache at local-disk speed and upload to C2 in the background; reads hit the cache when they can, and a miss fetches from C2 on demand — which means cold data has first-open latency. A new site comes online by mounting the folder, not by replicating terabytes first, which makes this the obvious answer when several sites need a 100 TB dataset that none of them can store locally. Encryption is client-side and zero-knowledge: data is encrypted on the NAS before upload, with a password only you hold — the stern corollary being that a lost password means unrecoverable data, by design.
The trade-offs are structural: a C2 subscription, a Btrfs volume on DSM 7.0.1+, and the internet becomes a component of your storage — offline, anything uncached is unreachable, and there’s no DSM-side versioning. It’s a capacity product, and a good one. But if what you want is two complete local copies on two continents, it’s answering a different question.
The rsync service: the bedrock
Underneath Shared Folder Sync sits the service that started it all. rsync’s claim to fame is the delta-transfer algorithm: the receiver fingerprints the file it already has, the sender slides a window across the new version, and only the regions that don’t match cross the wire. On DSM it lives in Control Panel → File Services — a plaintext daemon on TCP 873, or rsync-over-SSH for encryption (DSM user accounts are required to take the SSH path), with custom modules via /etc/rsyncd.conf officially supported.
Know its personality and it will never surprise you: it scans (every run walks the entire tree, so with millions of files even a run that transfers nothing takes real time), it’s one-way per run, and it’s stateless — no database, nothing to corrupt, trivially scriptable from any Linux box or cron job. For heterogeneous gear pushing data at a NAS it remains the honest workhorse, with the same single-stream WAN physics as everything built on top of it.
The full comparison
Which one should you use?
- Both NAS on the same LAN, simple mirror or distribution → Shared Folder Sync. Built-in, free, done.
- Teams at multiple sites editing the same files, with per-file version history at every site → Drive ShareSync earns its keep.
- A dataset too big for any one site, extended into the cloud → Hybrid Share.
- Scripts, Linux servers, mixed hardware → the rsync service.
- Two sites far apart, real volume, and you want the transfer done in days, not weeks — with end-to-end encryption and no router surgery → this is the exact problem WarpSend was built for.
Closing
The recipe, one more time: install the agent on both NAS (a .spk in Package Center), sign in on each, create a sync pair, pick Tunnel and Continuous. From then on, a file written in Tokyo starts moving within seconds and arrives in California at whatever speed your line can carry — encrypted end to end, verified with BLAKE3, resumable mid-file if either side hiccups.
Ten minutes of setup, and 120 ms of ocean stops dictating how fresh your second copy is.
You can try it at warpsend.io — agents for Synology (DSM 7.0+, x86–64), macOS, and Windows.
Benchmark notes: figures are from a real-world deployment — 1 Gbps residential fiber on both ends, ~120 ms RTT, initial full replication of a 20 TB dataset in about 60 hours; your throughput will track your line quality and disk speed. Synology feature details are current as of DSM 7.x — see the Knowledge Center pages for Shared Folder Sync, rsync, Drive ShareSync, and Hybrid Share, and check your model’s specifications before deploying.
