Part 1 - Overview and Architecture#

Before touching any commands, it helps to understand what we are building and why. This page covers the architecture, the problem it solves, and the two-phase approach this guide takes.


What We Are Building#

The goal is an offsite backup destination for Synology Hyper Backup using a Linux server running rsyncd.

Home network                          Offsite location
┌──────────────────┐                 ┌──────────────────────────────┐
│                  │                 │                              │
│  Synology NAS    │── VPN ────────► │  Linux server (rsyncd)       │
│  Hyper Backup    │                 │      │                       │
│                  │                 │      ▼                       │
└──────────────────┘                 │  USB hard drive              │
                                     │  /mnt/backup_hdd             │
                                     │                              │
                                     └──────────────────────────────┘

The Linux machine can be a dedicated server, a repurposed PC, or a virtual machine. It needs storage and network access. That is it.

Both machines need a way to reach each other across the internet without exposing rsyncd publicly. Any VPN will work. In this guide I am using Tailscale.

Getting there takes two phases.


Two Phases#

This guide is structured so you build and seed the backup locally first, then relocate the server offsite. There are two reasons for this.

The seeding problem. Most residential internet connections have limited upload speeds. A 4TB backup over a 20Mbps upload connection takes roughly 18 days under ideal conditions. In practice it takes longer. Seeding over gigabit LAN takes hours instead of weeks. Incremental backups after the initial seed are small and manageable.

DSM’s TCP stack. DSM’s TCP stack is slow on internet paths because of CUBIC. The full explanation is in DSM’s TCP Stack Is Limiting Your Speed. On a LAN this does not matter. Over the internet it does, and we will need a workaround. We will set that up in Phase 2, not now.

Phase 1 - Local Setup and Seed#

Everything lives on the home LAN. The NAS talks directly to the rsyncd server over gigabit (or faster depending on your home network). No VPN, no proxy, no TCP stack issues.

Home network
┌──────────────────┐       ┌──────────────────────────────┐
│                  │       │                              │
│  Synology NAS    │──────►│  Linux server (rsyncd)       │
│  Hyper Backup    │  LAN  │      │                       │
│                  │       │      ▼                       │
└──────────────────┘       │  USB hard drive              │
                           │  /mnt/backup_hdd             │
                           │                              │
                           └──────────────────────────────┘

Parts 2 through 4 cover this phase. By the end of Part 4, you will have a complete, fully seeded backup sitting on the LAN.

Phase 2 - Relocate Offsite#

Once the initial seed is complete, the rsyncd server moves offsite. This is where DSM’s TCP stack becomes a problem, so we introduce a proxy VM to work around it.

The proxy VM is a Linux VM on the home network running HAProxy with BBR enabled. The NAS sends its backup to the VM over the LAN. HAProxy terminates that connection and opens a new one to the offsite rsyncd. That outbound connection originates from the proxy VM, where BBR is available.

Home network                                       Offsite location
┌──────────────────┐    ┌─────────────────┐       ┌──────────────────┐
│                  │    │                 │       │                  │
│  Synology NAS    │───►│  Proxy VM       │──────►│  Linux server    │
│  Hyper Backup    │LAN │  HAProxy + BBR  │Tail-  │  (rsyncd)        │
│                  │    │                 │scale  │                  │
└──────────────────┘    └─────────────────┘       └──────────────────┘
        CUBIC                  BBR

This adds a third box to what should be a two-box setup. If Synology ever ships DSM with BBR, this goes away.

Part 5 covers this phase: building the proxy VM, installing Tailscale on both ends, physically relocating the rsyncd server, and updating Hyper Backup to point at the proxy VM instead of the rsyncd server directly.