Lumo Syncthing Kopia Setup for Admins Part 2 - Building a Syncnet with SyncThing

Below is a practical guide that walks you through building a “digital phone‑tree” style sync network with Syncthing’s Introducer feature, and then layering Kopia on top to create scheduled, encrypted backups that are pushed to a remote WebDAV store.
I’ll split the workflow into three sections:

Setting up the Syncthing introducer network – how to get a one‑way‑sync hierarchy that behaves like a phone tree.
Configuring Kopia to back up the synced folders – snapshotting, compression, encryption, and retention.
Automating periodic uploads to a WebDAV endpoint – scheduling, error handling, and a few advanced patterns.

Feel free to pick the pieces that match your environment; each step includes optional tweaks for tighter security or higher reliability.

1️⃣ Build the Syncthing “phone‑tree” with the Introducer Feature

1.1 Core Concepts

Concept	What it does	Typical role in a phone‑tree
Folder	A directory that Syncthing watches and syncs.	The data you want to propagate (e.g., `~/shared`).
Device	An instance of Syncthing identified by its Device ID.	Each node in the tree (leaf, branch, root).
Introducer	When enabled on a device, it advertises all of its known peers to any new device that connects to it.	Acts like the “central switchboard” that hands out contacts downstream.
One‑way sync	Set a folder’s Folder Type to Send Only on the source and Receive Only on the target.	Guarantees data flows outward only, preventing accidental edits upstream.

1.2 Topology Design

Root (introducer, send‑only) ──► Branch‑A (introducer, receive‑only)
                                 │
                                 └─► Leaf‑A1 (receive‑only)
                                 └─► Leaf‑A2 (receive‑only)

Root (introducer, send‑only) ──► Branch‑B (introducer, receive‑only)
                                 │
                                 └─► Leaf‑B1 …

The Root holds the master copy and is the only device that can edit the source folder.
Branch nodes also run as introducers, so any leaf that joins a branch automatically learns about its sibling leaves (useful if you later want peer‑to‑peer sharing).
All downstream nodes are receive‑only, ensuring a strict one‑direction flow.

1.3 Step‑by‑step Deployment

Install Syncthing on every machine (Linux, macOS, Windows, Raspberry Pi, etc.).
```
# Debian/Ubuntu example
sudo apt install syncthing
```
Create the shared folder on the Root device:
- Open the Syncthing UI (http://localhost:8384).
- Click Add Folder → Folder Path → choose e.g. ~/phone-tree-data.
- Set Folder Type = Send Only.
- Tick Introducer under Advanced → Folder Settings.
Add the first Branch device:
- On the Root UI, click Add Device → paste the Branch’s Device ID.
- In the dialog that appears, select the folder you just created and set the Branch’s Folder Type = Receive Only.
- Enable Introducer on the Branch as well (so it can pass the contact list further down).
Propagate to leaves:
- On a Branch device, repeat the “Add Device” step for each leaf, using the leaf’s Device ID.
- Because the Branch is an introducer, any leaf that later connects directly to the Root will automatically learn about the other leaves (and vice‑versa) without manual entry.
Verify one‑way flow:
- Create a test file on the Root. It should appear on all branches/leaves within seconds.
- Try editing the same file on a leaf – Syncthing will reject the change (or, if you allowed “receive‑only”, it will simply ignore the modification).
Optional hardening:
- TLS certificates: Syncthing already encrypts traffic end‑to‑end, but you can pin certificates for extra assurance.
- Firewall rules: Restrict inbound ports (default 22000/TCP) to known subnets.
- Device authentication: Keep the Device IDs secret; treat them like SSH keys.

2️⃣ Back up the Synced Folders with Kopia

Kopia is a fast, deduplicating backup tool that works well with constantly changing source directories. Below is a minimal yet robust configuration.

2.1 Install Kopia

# Linux (deb)
curl -sSL https://kopia.io/install.sh | sudo bash
# macOS (brew)
brew install kopia
# Windows (chocolatey)
choco install kopia

2.2 Initialise a Repository (local or remote)

For a WebDAV‑backed repo you can skip this step and point directly to the remote URL later, but having a local cache speeds up incremental snapshots.

# Create a local cache directory
mkdir -p ~/.kopia-cache
kopia repository create filesystem --path ~/.kopia-cache

Why a local cache?
Kopia stores metadata (snapshots, indexes) locally; the actual blob data can still be streamed to WebDAV. This reduces latency when creating many small snapshots.

2.3 Define a Backup Policy for Each Syncthing Folder

Assume the Root’s folder path is /home/user/phone-tree-data.

# Create a snapshot (snapshot name is optional)
kopia snapshot create /home/user/phone-tree-data \
    --policy="{
        \"RetentionPolicy\": {
            \"KeepLatest\": 30,
            \"KeepHourly\": 24,
            \"KeepDaily\": 14,
            \"KeepWeekly\": 8,
            \"KeepMonthly\": 12,
            \"KeepAnnual\": 3
        },
        \"CompressionPolicy\": { \"Algorithm\": \"zstd\", \"Level\": 3 },
        \"EncryptionPolicy\": { \"Algorithm\": \"AES256-GCM\" }
    }"

Retention: Keeps the most recent 30 snapshots plus a rolling window of hourly/daily/weekly/monthly/annual backups. Adjust numbers to match storage budget.
Compression: zstd gives good speed/compression trade‑off.
Encryption: AES‑256‑GCM ensures the backup blobs are unreadable without the repository password.

2.4 Automate Snapshot Creation

On Linux/macOS you can use systemd timers or cron; on Windows, Task Scheduler.

Example Systemd Timer (Linux)

Create /etc/systemd/system/kopia-backup.service:

[Unit]
Description=Kopia backup of Syncthing folder
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/kopia snapshot create /home/user/phone-tree-data

Create /etc/systemd/system/kopia-backup.timer:

[Unit]
Description=Run Kopia backup every hour

[Timer]
OnCalendar=hourly
Persistent=true

[Install]
WantedBy=timers.target

Enable and start:

sudo systemctl enable --now kopia-backup.timer

Windows Task Scheduler (quick outline)

Action: Program/script → C:\Program Files\Kopia\kopia.exe
Add arguments: snapshot create "C:\PhoneTreeData"
Trigger: Daily → Repeat task every 1 hour for a duration of 24 hours.

2.5 Verify Backups

kopia snapshot list /home/user/phone-tree-data
kopia repository status

You should see a series of snapshots with timestamps matching your schedule.

3️⃣ Push Snapshots to a Remote WebDAV Store

Kopia can stream each snapshot’s blobs directly to a WebDAV endpoint, treating it as a “blob storage” backend.

3.1 Prepare the WebDAV Destination

Obtain the URL (e.g., https://webdav.example.com/backups/kopia/)
Ensure you have a dedicated username/password with write permission only (read‑only is fine for restores).
Test connectivity with a simple curl command:

curl -u user:pass -T test.txt https://webdav.example.com/backups/kopia/

3.2 Connect Kopia to WebDAV

kopia repository connect webdav \
    --url https://webdav.example.com/backups/kopia/ \
    --username yourUser \
    --password yourPassword \
    --cache-dir ~/.kopia-cache

The --cache-dir argument points to the same local cache we used earlier, so Kopia reuses existing metadata.

3.3 Automatic Upload during Snapshot Creation

When you run kopia snapshot create … against a repository that is already connected to WebDAV, Kopia streams the new blobs to the remote store automatically. No extra step is required.
Tip: If you want to keep a local repository for quick restores and push to WebDAV for off‑site safety, you can configure multiple repositories and use kopia snapshot push:

# Assuming you have a local repo at ~/.kopia-local
kopia repository connect filesystem --path ~/.kopia-local
kopia snapshot create /home/user/phone-tree-data

# Push the latest snapshot to the remote WebDAV repo
kopia snapshot push \
    --source-repo ~/.kopia-local \
    --target-repo webdav \
    --snapshot-id <latest-snapshot-id>

3.4 Advanced Use Cases

Use case	How to implement	Why it matters
Multi‑region redundancy	Configure two separate WebDAV endpoints (e.g., one in Europe, one in North America) and push each snapshot to both using `kopia snapshot push` twice.	Protects against regional outages or ISP blocks.
Retention policy per endpoint	Create two distinct repositories (`webdav-eu`, `webdav-us`) with different `RetentionPolicy` settings (e.g., longer retention in the cheaper region).	Optimizes cost while keeping a long‑term archive.
Chunk‑level dedup across devices	Run Kopia on each Branch device independently but point all of them to the same WebDAV repo. Since Kopia deduplicates globally, identical files from different branches occupy only one set of blobs.	Saves bandwidth and storage when many branches share common assets (e.g., installers, media).
Encrypted per‑device keys	Use `--encryption-key` flag to supply a unique key per device, then store the key in a secure password manager.	Even if the WebDAV server is compromised, an attacker cannot reconstruct any single device’s data without the corresponding key.
Backup verification	Schedule a nightly `kopia check` against the remote repo: `kopia check --full`. Pair it with a notification script (email, Slack webhook) that alerts on failures.	Guarantees integrity of the off‑site archive.

3.5 Monitoring & Alerting

Kopia logs are written to ~/.kopia/logs. Tail them or forward to a syslog collector.
Systemd can be configured to send email on failure (OnFailure=mail@...).
For a lightweight dashboard, run kopia server start and browse http://localhost:51515/ – it shows recent snapshots, storage usage, and health checks.

📌 Quick Recap & next Steps

Syncthing – set up a root → branch → leaf hierarchy, enable the Introducer on every upstream node, and enforce send‑only / receive‑only folder types for true one‑way propagation.
Kopia – create a repository (local cache + WebDAV remote), define a retention/compression/encryption policy, and schedule hourly snapshots.
WebDAV upload – connect Kopia to the remote endpoint; snapshots are streamed automatically. Extend the setup with multi‑region pushes, per‑device encryption, or dedup across branches for efficiency.

With this stack you get:

Real‑time distribution of files across a controlled tree (Syncthing).
Immutable, encrypted backups that survive device loss or ransomware (Kopia).
Off‑site durability via any standard WebDAV service (ownCloud, Nextcloud, commercial cloud storage, etc.).

Let me know which part you’d like to dive deeper into—e.g., scripting the kopia snapshot push for multiple endpoints, fine‑tuning Syncthing firewall rules, or setting up monitoring dashboards—and I can provide concrete config snippets or sample scripts.

Syncthing – Common Attack Surfaces & How to Harden Them

Below is a concise threat model that covers the most frequently‑encountered weak points in a typical Syncthing deployment, followed by concrete mitigations you can apply right away. The goal is to keep the peer‑to‑peer mesh encrypted end‑to‑end while reducing the risk of accidental exposure, man‑in‑the‑middle (MITM) attacks, or abuse of the discovery mechanisms.

1️⃣ Network‑level Exposure

Weakness	Why it matters	Mitigation
Default listening port (22000/TCP) open to the Internet	Anyone who can reach the port can attempt a connection handshake. If the attacker knows a valid Device ID, they could try to join the mesh.	• Restrict inbound traffic to known IP ranges (firewall/NAT). • Use a port‑forwarding rule only for the specific peers that truly need remote access.
Global discovery service (default `discovery.syncthing.net`)	Allows strangers to learn that a given Device ID exists, which can be leveraged for enumeration or denial‑of‑service attempts.	• Disable global discovery (`Settings → Advanced → Global Discovery = false`). • Rely exclusively on local discovery (multicast) and/or manual device addition.
Relay servers (used when direct NAT traversal fails)	Relays forward encrypted traffic, but the relay operator can see metadata such as connection timing and volume.	• Turn off relays unless you truly need them (`Settings → Advanced → Relaying = false`). • If you must use relays, host your own trusted relay server.

2️⃣ Authentication & Authorization

Weakness	Why it matters	Mitigation
Device ID is the sole authenticator	If an attacker obtains a legitimate Device ID (e.g., from a log file, screenshot, or compromised machine) they can impersonate that node.	• Treat Device IDs like SSH keys: keep them secret. • Rotate Device IDs periodically (remove old IDs from peers, generate new ones).
No granular ACLs – any accepted device can read/write any folder it’s granted.	A compromised node gains full access to every shared folder.	• Use folder‑level “Read‑Only” or “Send‑Only” modes wherever possible. • Split sensitive data into separate folders with a minimal set of trusted devices.
Introducer auto‑propagation	When a device is marked as an introducer, it automatically shares all its known peers with newcomers, potentially spreading a compromised Device ID.	• Enable Introducer only on highly‑trusted nodes (e.g., the root of a phone‑tree). • Periodically audit the peer list on each introducer.

3️⃣ Encryption & Data Integrity

Weakness	Why it matters	Mitigation
Transport encryption only – Syncthing encrypts traffic but does not encrypt data at rest.	If a device’s disk is stolen, the attacker can read the synced files directly.	• Store synced folders on encrypted volumes (e.g., LUKS, BitLocker, FileVault). • Combine with a second‑layer backup solution that adds at‑rest encryption (e.g., Kopia).
Version‑specific cipher defaults	Older releases used ChaCha20‑Poly1305; newer versions default to AES‑256‑GCM. If you’re running a legacy binary, you might be stuck with a weaker cipher suite.	• Keep Syncthing up‑to‑date (auto‑update or regular package upgrades). • Verify the negotiated cipher in the UI (`Actions → Show Log → TLS`).
Missing integrity verification after a crash	If a device crashes mid‑transfer, corrupted blocks could be persisted.	• Enable “Automatic Folder Rescan” (default) and run a manual “Repair” (`Actions → Repair Folder`) after unexpected shutdowns.

4️⃣ Configuration & Operational Mistakes

Weakness	Why it matters	Mitigation
Running Syncthing as root	Grants the process unrestricted access to the whole filesystem, magnifying the impact of any compromise.	• Run Syncthing under a dedicated, non‑privileged user account (e.g., `syncthing`). • Use systemd’s `User=` directive or a Docker container with limited capabilities.
Exposing the GUI without authentication	The web UI (default `127.0.0.1:8384`) can be proxied or tunneled inadvertently, allowing an attacker to alter settings.	• Enable GUI authentication (`Settings → GUI → Authentication`). • Bind the GUI to `127.0.0.1` only, or put it behind a reverse proxy with TLS and strong auth.
Leaving default folder names/paths	Predictable paths make it easier for an attacker to locate the data once they have host access.	• Choose non‑obvious folder names and store them in locations that are not world‑readable.
Insufficient logging	Without proper logs you may miss unauthorized connection attempts.	• Increase log level (`Settings → Advanced → Log Level = debug`) temporarily during audits. • Forward logs to a central syslog server for long‑term retention.

5️⃣ Supply‑Chain & Update Risks

Weakness	Why it matters	Mitigation
Binary tampering	If an attacker replaces the downloaded installer with a malicious build, the entire mesh can be compromised.	• Verify SHA‑256 signatures of official releases (published on the Syncthing website). • Prefer distribution via trusted package managers (e.g., Debian/Ubuntu repos, Homebrew) that provide GPG verification.
Automatic update hijacking	The built‑in updater fetches binaries over HTTPS; a compromised CA could serve a fake binary.	• Pin the update URL to a known-good mirror or disable auto‑updates and manage upgrades manually.

6️⃣ Practical Hardening Checklist

Network
- Block inbound 22000/TCP except from known peer IPs.
- Disable global discovery & relaying unless required.
- Use a VPN (e.g., Proton VPN) to encapsulate traffic when traversing untrusted networks.
Authentication
- Keep Device IDs secret; rotate them annually.
- Enable GUI password and bind UI to localhost only.
Encryption at Rest
- Encrypt the underlying filesystem where Syncthing stores data.
- Consider double‑encrypting with a backup tool (Kopia, Restic).
Least‑Privilege Execution
- Run Syncthing as a dedicated, non‑root user.
- Use systemd sandboxing options (ProtectSystem=full, PrivateTmp=yes).
Monitoring & Auditing
- Forward Syncthing logs to a SIEM or centralized syslog.
- Schedule daily kopia check (if you back up with Kopia) and weekly syncthing repair.
Update Discipline
- Verify signatures on every new release.
- Keep the client up‑to‑date within a month of each stable release.