NAS-to-NAS Replication: Setting Up an Offsite Backup Between Two Devices

If you already own a NAS, you know that RAID protects you from a drive failure, not from a fire, flood, or theft. The practical, affordable solution for true offsite redundancy is NAS-to-NAS replication — syncing your primary NAS to a second unit at a different location. This guide walks you through the software options, network setup, and sync strategies to get a second NAS offsite backup setup running, whether your second device is in a friend’s basement or a family member’s home office.

Why NAS-to-NAS Replication Completes the 3-2-1 Rule for Homelabs

The 3-2-1 backup rule says you need three copies of your data, on two different media types, with one copy offsite. A second NAS in another location fills that offsite requirement better than cloud storage for many homelab users — no monthly subscription fees, no egress charges, and full control over your data. Replicating between two NAS devices gives you a local copy for fast restores and an offsite copy for disaster recovery, all under your own management.

For a deeper dive into the full backup strategy, read our guide on How to Back Up Your NAS: The 3-2-1 Rule in Practice. That article covers the complete picture — local, offsite, and cloud tiers — while this page focuses specifically on the NAS-to-NAS replication link.

One-Way Sync vs. True Two-Way Mirror: Which Fits Your Setup?

Most homelab setups use a primary NAS for daily access and a second NAS purely as a backup target. For that scenario, one-way sync is the correct choice. Changes flow only from source to destination — if you accidentally delete a file on the primary, the deletion replicates to the backup, but you still have versioning (snapshots) on the backup to recover from. True two-way mirroring (bidirectional sync) is for active-active setups where both NAS units serve data to different users and changes happen on both sides. That introduces conflict resolution complexity and is rarely needed for a backup scenario.

Bandwidth and Scheduling: Initial Full Sync vs. Ongoing Incremental Syncs

The first full sync is the bottleneck. If you have 4 TB of data and a 20 Mbps upload connection, the initial transfer will take roughly 22 days continuous. Realistically, plan for 2–4 weeks for the first sync on a typical residential connection. After that, incremental syncs (only changed blocks) run much faster — typically minutes to a few hours per day depending on change rate.

Schedule the initial sync during a period of low usage — overnight or over a weekend. Most replication tools let you set bandwidth limits to avoid saturating your connection during work hours. For ongoing syncs, a daily schedule at 2–4 AM works well for most home networks. If your data changes frequently (e.g., security camera footage), consider hourly or even continuous sync with a tool like Syncthing.

Software Options for NAS-to-NAS Replication Across Brands

You don’t need both NAS units to run the same OS. The following tools work across Synology, QNAP, TrueNAS, Unraid, and DIY Linux builds. Choose based on your technical comfort and the features you need.

rsync: The Universal Workhorse

rsync is available on virtually every NAS OS. It uses delta transfer — only the changed parts of files are sent — and can run over SSH for encryption. Setup requires SSH key authentication (passwordless login) between the two NAS units. A typical command looks like rsync -avz --delete /path/to/source/ user@remote-nas:/path/to/destination/. The --delete flag mirrors deletions from the source to the destination, which is what you want for a one-way backup.

Syncthing: Real-Time Sync Without Vendor Lock-In

Syncthing runs on Windows, Linux, macOS, and as a Docker container — perfect for mixing NAS brands. It provides a web UI for setup, supports encrypted transfers, and handles conflict resolution automatically by renaming conflicted copies. For a backup scenario, configure it as one-way sync (send-only on the primary, receive-only on the backup). Syncthing is ideal if you want continuous replication without scripting.

ZFS Replication: For Power Users with ZFS Pools

If both NAS units run ZFS (TrueNAS, Proxmox, or a custom Linux build), ZFS send/receive is the gold standard. It sends only the blocks that changed between snapshots, making incremental syncs extremely fast and efficient. The destination receives an exact copy of the ZFS snapshot, which can be rolled back independently. This is the most bandwidth-efficient option but requires CLI comfort and matching ZFS pool configurations.

Network Setup: Same LAN vs. True Offsite Over the Internet

If both NAS units are on the same local network, setup is trivial — just use the local IP address for the destination. For true offsite replication over the internet, you need a secure tunnel between the two sites. Exposing your NAS directly to the internet is dangerous and strongly discouraged.

VPN or Tailscale: The Two Practical Approaches

The most secure and easiest approach for homelab users is Tailscale. It creates a WireGuard-based mesh VPN with no open ports on your firewall. Install Tailscale on both NAS units (or on a Docker container), authenticate both to the same Tailscale network, and they can communicate over the encrypted tunnel using their Tailscale IP addresses. No port forwarding, no dynamic DNS needed.

If you prefer a traditional VPN, set up WireGuard or OpenVPN on one side (typically the primary NAS or a router) and connect the second NAS as a client. WireGuard is simpler and faster than OpenVPN for this use case. Ensure the VPN connection is set to auto-connect and restart on failure. Monitor the connection with a simple ping script or health check.

Bandwidth Considerations for Offsite Links

Your upload speed at the primary site determines the maximum replication throughput. Most residential ISPs offer 10–50 Mbps upload. At 20 Mbps, you can transfer roughly 8 GB per hour. For the initial sync, consider seeding the data physically — copy the data to a USB drive, ship it to the remote location, and attach it to the second NAS. Then run a delta sync to catch up on changes made during shipping. This approach cuts the initial sync from weeks to hours.

If you run Docker containers on your NAS, the Best Docker Server Build 2026: Hosting Dozens of Containers at Home guide covers hardware choices that also work well as a second NAS node. A low-power Intel N100 mini PC running TrueNAS Scale or a lightweight Linux distribution can serve as an excellent offsite replication target, drawing only 6–10W idle.

Monitoring and Testing Your Replication

Replication is only useful if it actually runs and produces valid backups. Set up email or push notifications (via Synology Notification, Uptime Kuma, or a simple script) to alert you if a sync fails. Test restores quarterly — pick a random file or folder, restore it from the offsite NAS, and verify integrity. Without testing, you have a backup that might not work when you need it.

• Schedule replication during off-peak hours (e.g., 2 AM daily).
• Enable snapshot retention on the destination NAS (e.g., 7 daily, 4 weekly).
• Monitor sync logs for errors (connection timeouts, permission issues).
• Test a restore from the offsite copy at least once per quarter.

Power consumption for the second NAS matters for long-term cost. A typical 4-bay NAS with spinning drives idles around 25–40W. Over a year, that adds up. Our guide on How to Reduce Your NAS’s Power Consumption (Without Losing Performance) offers practical tips like using SSD-only targets, enabling HDD spindown, and choosing low-power CPUs for the backup unit.

Which Should You Choose: One-Way rsync, Syncthing, or ZFS Replication?

For most homelab users with mixed-brand NAS setups, rsync over SSH is the most reliable and universal choice. It works on everything, requires no additional software, and is well-documented. If you want real-time sync with a web UI, Syncthing is the best alternative. If both NAS units run TrueNAS with ZFS, ZFS send/receive is the most efficient option but requires more upfront configuration.

Start with a small test folder (1–2 GB) to validate your network tunnel and sync settings. Once that works, scale up to your full data set. Remember that the second NAS is a backup target — you don’t need high performance for daily access. A low-power, single-CPU unit with adequate storage is perfectly sufficient. For a cost breakdown of running that second NAS 24/7, see How Much Does It Cost to Run a NAS? Calculate Your Annual Electricity Bill.