Part 5 - Relocating Offsite#

If you haven’t already, complete Part 4 - Hyper Backup Configuration and Local Seeding before continuing. With a full backup on the rsyncd server, this part covers moving the server offsite and routing Hyper Backup through a proxy VM.

What We Are Doing#

There are four pieces of work in this part:

  1. Install Tailscale on the rsyncd server.
  2. Physically move the rsyncd server to its offsite location.
  3. Build a proxy VM on the home network. Assign a static IP. Enable BBR. Install Tailscale. Configure HAProxy.
  4. Update the Hyper Backup task to point at the proxy VM instead of the rsyncd server directly.

This guide uses Tailscale MagicDNS so HAProxy can refer to the rsyncd server by hostname instead of IP. Make sure MagicDNS is enabled in your Tailscale admin console under DNS before continuing.

Step 1 - Install Tailscale on the rsyncd Server#

SSH into the rsyncd server and run:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Tailscale will print an authentication link. Open it in any browser and log in.

Confirm the machine registered under the expected hostname:

tailscale status

The hostname shown here is what HAProxy will use to reach this server later. It defaults to the system’s hostname. Note it down. If you want to change it, rename the node in the Tailscale admin console now.

Do not unplug the server until tailscale status shows it as registered. Once Tailscale is working, you have remote access if anything goes wrong after the move.

(Optional) Lock Down Access to Tailscale Only#

Limits SSH (22) and rsync (873) to your Tailscale network, blocking LAN and public access.

Find your Tailscale interface (usually tailscale0):

ip addr

Allow SSH and rsync only over Tailscale:

sudo ufw allow in on tailscale0 to any port 22
sudo ufw allow in on tailscale0 to any port 873

Double-check the rules, then enable the firewall:

sudo ufw show added
sudo ufw enable

Make sure you are connected over Tailscale before enabling, or you may lock yourself out.

Step 2 - Move the rsyncd Server Offsite#

Shut down the rsyncd server cleanly:

sudo shutdown now

Unplug it and move it to its offsite location along with the USB hard drive. Plug it in, connect it to the network, and power it on.

From any device on your tailnet (your workstation, laptop, phone), verify the server is back online:

tailscale status

You should see the rsyncd server listed. SSH into it over Tailscale and confirm rsyncd is running:

sudo systemctl status rsync

If anything is wrong, you have remote access to fix it.

Step 3 - Proxy VM Setup#

The proxy server can live anywhere on your LAN, physical or virtual. Out of convenience, I run mine as a VM on Synology’s Virtual Machine Manager. Install Ubuntu Server, then continue below.

Assign a Static IP#

Hyper Backup will be configured to point at the proxy VM’s LAN IP, so that IP must not change. Configure a static address with netplan.

SSH into the proxy VM and find the existing netplan config:

sudo ls /etc/netplan/

Edit the file (the filename will vary):

sudo nano /etc/netplan/50-cloud-init.yaml

Replace the contents with the following, adjusting the interface name, address, gateway, and DNS servers to match your network. Confirm the interface name with ip a if you are unsure:

network:
  version: 2
  ethernets:
    INTERFACE_NAME_HERE:
      dhcp4: no
      addresses:
        - 192.168.1.50/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 192.168.1.1
          - 1.1.1.1

Apply the configuration:

sudo netplan apply

If you were SSHed in over the old DHCP address, your session will drop. Reconnect on the new static address.

Enable BBR#

Run:

echo "net.ipv4.tcp_congestion_control=bbr" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Verify it is active:

sysctl net.ipv4.tcp_congestion_control
# Expected output: net.ipv4.tcp_congestion_control = bbr

Install Tailscale#

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Tailscale will print an authentication link. Open it in any browser and log in.

Configure HAProxy#

Install HAProxy:

sudo apt install haproxy -y
sudo nano /etc/haproxy/haproxy.cfg

Add the following. Replace rsync-server with the hostname of your rsyncd server as it appears in your Tailscale admin console:

frontend rsyncd_gate
    bind *:873
    mode tcp
    timeout client 1h
    default_backend rsyncd_offsite

backend rsyncd_offsite
    mode tcp
    timeout server 1h
    server offsite rsync-server:873 check

Enable on boot and restart HAProxy:

sudo systemctl restart haproxy
sudo systemctl enable haproxy

Confirm it is running:

sudo systemctl status haproxy

Configure HAProxy to Retry on Boot#

If the proxy VM reboots, HAProxy will fail to start. It tries to resolve the rsyncd server’s MagicDNS hostname before Tailscale is up, the lookup fails, and the service exits. Add a systemd override so HAProxy keeps retrying until Tailscale comes up and the name resolves.

Open the override editor:

sudo systemctl edit haproxy

This opens the override file in nano. Near the top you will see two comment markers. Place the override between them. Anything written below the second marker will be discarded. Everything is case sensitive. :

### Anything between here and the comment below will become the contents of the drop-in file
[Service]
Restart=on-failure
RestartSec=30s
StartLimitBurst=0
### Edits below this comment will be discarded

Save and exit. Reload systemd to pick up the change:

sudo systemctl daemon-reload

How This Works#

The NAS sends its Hyper Backup job to the proxy VM’s LAN IP on port 873. HAProxy accepts that connection and opens a new one outbound to the offsite rsyncd over Tailscale. Two separate TCP sessions stitched at layer 4. The long-haul leg to the offsite server originates from the proxy VM, not from DSM, so it benefits from BBR.

The NAS never crosses the internet. From Hyper Backup’s perspective, it is just talking to a local rsyncd server.

Verify End-to-End Connectivity#

Test that HAProxy is correctly forwarding to the offsite rsyncd server over Tailscale. The simplest way is to run the test from the proxy VM itself, hitting its own LAN IP. This looks recursive (the VM connecting to itself) but it works: the connection still goes through HAProxy, out over Tailscale to the offsite server, and back. Any other Linux machine on your LAN works too if you would rather test from there.

Replace <proxy-vm-lan-ip> with the proxy VM’s static IP from earlier in this step:

rsync rsync://synology@<proxy-vm-lan-ip>/backup

Enter the password when prompted. You should see backup folder synology created in Part 4. If you do, the full path works.

Step 4 - Update Hyper Backup#

The backup task from Part 4 is currently pointing at the rsyncd server’s old LAN IP. That server is no longer on your network. Update the task to point at the proxy VM’s static LAN IP instead.

Open Hyper Backup on the NAS and navigate to:

Rsync Backup Job > Edit > Target > LAN IP

Replace the old IP with the proxy VM’s static LAN IP. Leave every other setting alone.

Save the task. The target should say it’s on-line. Run the backup

Upload Speed Cap Now that the backup is running over your residential internet connection, consider setting an upload speed limit in Hyper Backup’s settings to prevent it from saturating your uplink.

Verify the First Incremental Backup#

The first run after relocation will be a normal incremental, not a full backup. It should be small and quick, transferring only changes since the seed.

Test a restore from the offsite destination. Before trusting this setup long term, confirm you can restore at least one file now that the server is offsite.

Local Restore Tip: If you need to restore a large amount of data, bring the rsync server back onto your local network and update your Hyper Backup job to point to its local IP address. This avoids the bandwidth and time constraints of restoring over the internet.