What Are Remote Servers
A remote server is storage sitting in one location that users in another location need to reach. Think remote offices, distributed teams, and a branch pulling from HQ.
The reason people care about where the server sits comes down to LAN vs WAN access. On a LAN, latency is sub-millisecond, and bandwidth is cheap. Users hit a file share, and it feels instant. Over a WAN, latency jumps to 50-150ms+ depending on distance, and every round trip pays that tax. Protocols like SMB are chatty — a single file open can require dozens of round-trips — so WAN latency can turn a fast operation into a slow one.
So the instinct is to put a server in every office and keep access local. But that creates its own pain. Now you’re managing hardware in every location — the TCO stacks up fast with hardware refresh cycles, upgrades, maintenance, and the config overhead of keeping each box consistent. Every office becomes a site you have to babysit.
Accessing Remote Files
Two situations come up.
Office with a server. You can install a box locally, so people use SMB/NFS and get LAN-speed access to data in that office. The catch: that office’s data needs to stay in sync with other locations over the WAN. So now you’re moving data across the WAN to keep local servers current, and that sync becomes the hard part.
Remote employee, no server. You can’t drop hardware at someone’s home office. So they go VPN + SMB and access files over the WAN directly. This is where it falls apart:
- WAN latency + chatty SMB = every operation drags.
- Any connection drop throws errors — often cryptic, unknown errors that don’t tell you what actually happened.
- It’s not self-healing. Something breaks mid-operation, and you’re left debugging an error message that doesn’t map to a clear cause.
Copying Files to Remote Servers
The other approach is to just copy the data over. Common tools: robocopy on Windows, rsync on Linux/Unix. Both work fine on a small scale. At real scale over a WAN, problems show up:
- Millions of files. Scan and comparison time dominate. rsync building its file list on huge trees eats memory and time before a single byte moves.
- WAN throughput. These tools don’t do much to overcome latency — TCP throughput collapses over high-latency, lossy links.
- Error recovery. A dropped transfer mid-run means restarting or babysitting retries. Recovery isn’t clean.
- File locking. Open/locked files get skipped or fail. Handling in-use files during a copy is messy.
The Resilio Approach
Keep your remote servers, sync the data. If you want servers in each office, Resilio syncs data between them and overcomes WAN latency by using a custom UDP protocol rather than fighting TCP’s behavior over high-latency links. It’s not periodic/scheduled — it’s real-time, and it scales to 100M+ files.
Or skip the servers — use a Gateway (GW). Instead of standing up and syncing full servers across offices, a Gateway caches hot files on demand in a specific office. Rather than copying all the data to every site, users get a LAN experience for just the files they actually need, pulled on demand. All transfers are WAN-optimized, with proper cache management to prevent local storage from being overrun.
Or install Resilio on end-user machines. Users get local performance without installing hardware in the office. No boxes to buy, no upgrade cycles — a similar or better experience for people, without the need to maintain the site.
