Introduction: The Imperative of Multi-Cloud Disaster Recovery

In the modern digital economy, data is the ultimate enterprise asset. While cloud giants like Amazon Web Services (AWS) offer unparalleled scalability and global infrastructure, relying solely on a single cloud provider introduces a critical point of failure known as vendor lock-in. Outages, compliance shifts, or sudden billing anomalies can disrupt business continuity. To mitigate these risks, forward-thinking enterprises are adopting multi-cloud strategies.

This technical guide details how to architect and build a self-hosted, real-time Disaster Recovery (DR) Hub between AWS and Hetzner Online—a highly cost-effective European infrastructure provider. By leveraging an advanced configuration of Syncthing, an open-source peer-to-peer file synchronization tool, businesses can achieve continuous, secure data replication without the exorbitant egress fees typically associated with traditional cloud providers.

Architectural Overview: AWS to Hetzner Blueprint

A resilient DR strategy requires geographic and infrastructural separation. In this blueprint, AWS serves as the primary production environment, hosting active application workloads and hot data storage. Hetzner acts as the secondary disaster recovery site, maintaining a real-time mirror of critical data volumes.

Unlike traditional master-slave replication setups, Syncthing utilizes a peer-to-peer architecture powered by the Block Exchange Protocol (BEP). This ensures that data modification is tracked via cryptographic hashes, and only modified blocks are transmitted across the network, significantly optimizing bandwidth utilization.

Key Infrastructure Components:

Primary Node (AWS EC2): An instance situated within a secure VPC, housing production databases, media assets, or configuration files requiring continuous replication.
DR Node (Hetzner Cloud or Dedicated Server): A high-storage, cost-efficient instance configured to ingest real-time data blocks.
Network Overlay / Secure Tunnel: While Syncthing natively encrypts data using TLS 1.3, an additional WireGuard VPN or strict security group policies can be implemented to isolate synchronization traffic.

Step-by-Step Deployment: Setting Up the DR Hub

Implementing this multi-cloud replication framework involves preparing the hosts, installing Syncthing, configuring secure connectivity, and optimization for production workloads. Below is the technical execution path.

Step 1: Installing Syncthing on AWS and Hetzner

First, ensure the latest stable release of Syncthing is installed on both systems. Avoid outdated default distribution packages by utilizing the official Syncthing repository. Execute the following commands on both your Ubuntu-based AWS and Hetzner instances:

# Add the release PGP keys:
sudo mkdir -p /usr/share/keyrings
sudo curl -fsSL [https://syncthing.net/release-key.txt](https://syncthing.net/release-key.txt) -o /usr/share/keyrings/syncthing-archive-keyring.gpg

# Add the official stable repository:
echo "deb [signed-by=/usr/share/keyrings/syncthing-archive-keyring.gpg] [https://apt.syncthing.net/](https://apt.syncthing.net/) syncthing stable" | sudo tee /etc/apt/sources.list.d/syncthing.list

# Update and install:
sudo apt-get update
sudo apt-get install syncthing -y

Step 2: Configuring Network Security and Firewalls

Syncthing relies on specific ports for communication and discovery. For a hardened enterprise architecture, disable global discovery and relaying to prevent data tracking over public announcement servers. Instead, explicitly declare the peer IP addresses.

Configure your AWS Security Groups and Hetzner Firewall to allow traffic exclusively between the two nodes on the following ports:

Port 22000/TCP: For the Block Exchange Protocol (BEP) sync traffic.
Port 22000/UDP: For QUIC-based sync traffic (highly recommended for high-latency cross-continent links).

Step 3: Initializing and Binding the Web GUI

By default, Syncthing binds its web management interface to 127.0.0.1:8384. To access the GUI securely, it is best practice to keep this binding local and tunnel into it via SSH, or modify the configuration file to bind to a private network interface if a VPN is present.

To access the GUI via an SSH tunnel from your local workstation, run:

ssh -L 9090:127.0.0.1:8384 user@aws-instance-ip

Navigate to http://localhost:9090 in your browser to access the AWS Syncthing console. Repeat the process for the Hetzner node on a different local port (e.g., 9091).

Advanced Syncthing Configurations for Enterprise DR

A standard file-sync setup is insufficient for a rigorous disaster recovery framework. To ensure data integrity, performance, and legal compliance, several advanced features must be tailored within Syncthing.

1. One-Way Replication (Send-Only vs. Receive-Only)

To protect the primary production data on AWS from accidental deletion or corruption originating on the DR node, folder types must be explicitly defined:

Set the AWS source folder to Send Only. This ensures AWS dictates the source of truth.
Set the Hetzner target folder to Receive Only. Any accidental modifications or local file injections on the Hetzner side will be automatically flagged as overrides and ignored during sync cycles.

2. Advanced File Versioning Strategies

Disaster recovery must account for ransomware attacks and data corruption, not just hardware failure. If an application writes corrupted data to AWS, Syncthing will instantly replicate it to Hetzner. To counteract this, enable Staggered File Versioning or External File Versioning on the Hetzner node.

Staggered versioning automatically retains deleted or modified files in a hidden .stversions folder, keeping hourly versions for the first day, daily versions for the past month, and weekly versions prior, up to a user-defined age limit. This creates an immutable historical timeline of your data fabric.

3. Performance Tuning for High-Throughput Workloads

When handling massive datasets or high frequencies of small file changes, default parameters can bottleneck system resources. Modify the following advanced options in the Syncthing configuration:

Max Folder Concurrency: Increase the number of concurrent file transfers (default is 4) to match the available CPU cores of your instances.
Puller Rub In Intervals: Tune the scanning interval. Instead of frequent disk scanning, use filesystem notifications (fswatcher) to trigger replication instantly upon file closure.
Hashers: Adjust the number of hashing routines to maximize CPU-bound processing power during intensive block calculations.

Verifying Recovery Point Objective (RPO) and Recovery Time Objective (RTO)

An untested backup is not a backup. Organizations must continually audit their DR metrics using Syncthing’s REST API or integrated metrics exporters.

Achieving Near-Zero RPO: Because Syncthing utilizes real-time filesystem monitoring, the Recovery Point Objective (the maximum acceptable age of data before an outage) is reduced to seconds, assuming stable network transit.
Optimizing RTO: In a total AWS failure scenario, system administrators can rapidly adjust the Hetzner folder state from Receive Only to Send/Receive, update DNS routes via an automated script, and spin up active application containers pointing to the local mirrored storage volume, minimizing the Recovery Time Objective.

Conclusion: Resiliency Achieved at Fractured Cost

Constructing a self-managed Disaster Recovery Hub between AWS and Hetzner using advanced Syncthing capabilities bridges the gap between premium enterprise availability and open-source cost optimization. By bypassing the proprietary replication lock-ins of major public clouds, enterprises regain absolute control over their data topology, ensure cross-cloud business continuity, and guarantee that their services remain online no matter where the infrastructure landscape shifts.

Building a Multi-Cloud Disaster Recovery Hub: Real-Time Data Replication Between AWS and Hetzner Using Advanced Syncthing