Synchroniser des fichiers entre deux serveurs distants. Le besoin trivial qui finit par générer une stack disproportionnée : Dropbox Business, OneDrive, ownCloud, S3 + sync, NFS sur VPN, rsync en cron... La plupart des solutions soit dépendent d'un cloud central, soit nécessitent une infrastructure lourde, soit se cassent à la moindre interruption réseau.
Syncthing résout ce problème depuis 2014. Open source GPL, écrit en Go, peer-to-peer, chiffrement bout en bout. Pas de serveur central, pas de cloud, pas de comptes à gérer. Chaque noeud s'authentifie par clé cryptographique, et on synchronise des dossiers entre noeuds avec une granularité fine.
Pour une infrastructure distribuée multi-site, des sauvegardes répliquées entre DC, ou simplement deux serveurs qui doivent rester cohérents, Syncthing est sous-estimé.
Plan de l'article
- Cas d'usage où Syncthing gagne
- Architecture P2P et protocole BEP
- Déploiement Syncthing sur Linux
- Découverte et NAT traversal
- Versioning et conflits
- Hardening : auth, TLS, isolation
- Comparaison avec rsync, Resilio, Unison
- Limites et signaux d'alerte
Cas d'usage où Syncthing gagne
Quatre profils de besoin où Syncthing est le bon outil.
Backup secondaire entre sites. Un site principal génère des dossiers de backup (DB dumps, archives), un site distant doit en avoir une copie. Avec Syncthing, dès qu'un fichier est créé localement, il est répliqué sur le distant en quelques secondes. Pas de fenêtre cron, pas de delta-sync à scripter.
Distribution de fichiers config entre serveurs. Un fichier inventory.yml mis à jour sur un orchestrateur, propagé automatiquement à 10 hôtes. Syncthing remplace rsync + cron par un push event-driven.
Sync entre poste utilisateur et serveur. Un dev qui veut accéder à son code source depuis plusieurs machines sans passer par un cloud central, ou un photographe qui veut que ses raw soient répliqués depuis le NAS vers un serveur de sauvegarde dans une autre ville.
Sync multi-site sur lien instable. Syncthing tolère des coupures réseau de plusieurs heures ou jours. Quand le lien revient, il reprend là où il en était. Les solutions cloud centrales nécessitent souvent une intervention manuelle après une longue déconnexion.
Pas pour : les bases de données live (utiliser de la replication native), les fichiers très volatiles (>1000 modifications par seconde), les workloads HFT.
Architecture P2P et protocole BEP
Syncthing implémente le protocole Block Exchange Protocol (BEP), spécifié et publié par l'équipe Syncthing.
Principe :
- Chaque noeud a une device ID dérivée de sa clé publique TLS (un identifiant unique cryptographique).
- Chaque dossier partagé a un folder ID propre.
- Les noeuds sont reliés deux à deux par accord mutuel (Alice ajoute Bob, Bob accepte Alice).
- Pour un dossier donné, chaque fichier est découpé en blocs (typiquement 128 KiB).
- Les noeuds s'échangent les hashs de blocs et identifient les blocs manquants.
- Les blocs manquants sont demandés et transférés en parallèle.
Pas de serveur central. Les noeuds se découvrent via :
- Local discovery : multicast UDP sur le LAN.
- Global discovery : serveurs publics opérés par Syncthing (et auto-hébergeables) qui maintiennent une carte device-id → IP.
- Manual : on saisit directement IP et port d'un noeud.
Pour le NAT traversal entre noeuds derrière des routeurs :
- Direct UPnP/NAT-PMP quand possible.
- Relay : si direct impossible, le trafic transite chiffré bout-en-bout par un relay public (ou self-hosté).
Tout le trafic est chiffré TLS 1.3, mutual auth. Aucune donnée en clair sur le wire, même via relay.
Déploiement Syncthing sur Linux
Paquet Debian/Ubuntu disponible :
sudo curl -o /usr/share/keyrings/syncthing-archive-keyring.gpg \
https://syncthing.net/release-key.gpg.asc
echo "deb [signed-by=/usr/share/keyrings/syncthing-archive-keyring.gpg] \
https://apt.syncthing.net/ syncthing stable" | sudo tee /etc/apt/sources.list.d/syncthing.list
sudo apt update && sudo apt install syncthing
Démarrage en service systemd :
sudo systemctl enable --now syncthing@user
Le démon écoute par défaut sur :
- Port 22000 TCP/UDP (sync)
- Port 21027 UDP (local discovery)
- Port 8384 (UI web, écoute par défaut sur 127.0.0.1)
Pour exposer l'UI sur un réseau privé, modifier ~/.config/syncthing/config.xml ou faire un reverse proxy nginx local. Le pattern classique : SSH tunnel pour accéder à l'UI sans l'exposer.
ssh -L 8384:localhost:8384 user@server
# Ouvrir http://localhost:8384 dans son navigateur
L'UI permet d'ajouter des devices (clé publique) et des folders (chemin local + paramétrage versioning). Tout est sauvegardé dans le config.xml.
Découverte et NAT traversal
Sur des serveurs avec IPs publiques fixes, on peut désactiver les serveurs de découverte publics et utiliser les adresses statiques.
<device id="ABCDEF...">
<address>tcp://203.0.113.42:22000</address>
</device>
Pour des sites derrière NAT, deux options :
Option 1 : VPN intersites. WireGuard ou IPsec entre les sites, Syncthing tourne sur les IPs privées routées via VPN. Pattern propre mais demande l'infra VPN. Voir wireguard-vpn.
Option 2 : Relay. Plus simple opérationnellement. Le trafic transite chiffré via les relays Syncthing publics. Latence ajoutée, débit plafonné par la capacité du relay (typiquement 1-5 MB/s par flux). Pour des syncs occasionnelles, suffit. Pour de gros volumes, self-hoster un relay (strelaysrv).
Option 3 : Self-hosted relay. On opère son propre relay sur un serveur public, fait tourner strelaysrv. Trafic privé, débit selon la machine.
Pour des architectures multi-DC, on combine VPN entre les DC (WireGuard sur du backbone) avec sync direct, et relay public pour les noeuds clients mobiles (laptops développeurs).
Versioning et conflits
Syncthing gère plusieurs stratégies de versioning par dossier :
- No versioning : si un fichier est supprimé sur un peer, il est supprimé partout.
- Trash can : version mise dans
.stversions/, conservée X jours. - Simple file versioning : N versions conservées par fichier.
- Staggered versioning : rétention dégressive (1 par minute pendant 1h, 1 par heure pendant 1j, etc.).
- External : exécution d'un script custom (par exemple push vers Restic).
Conflits : si deux peers modifient le même fichier hors connexion, Syncthing crée un fichier filename.sync-conflict-<date>-<id>.ext à la reconnexion. À l'utilisateur de décider.
Pour des dossiers avec des conflits fréquents, configurer un seul peer en "Send Only" (master), les autres en "Receive Only" (slaves). Pattern unidirectionnel.
Hardening : auth, TLS, isolation
UI auth : activer un mot de passe sur l'UI dès le déploiement. Sans ça, n'importe qui sur le LAN peut piloter Syncthing.
TLS UI : activer HTTPS sur l'UI avec certificat Let's Encrypt ou auto-signé. Évite les credentials en clair.
Folder GUID : chaque folder partagé a un GUID. Syncthing refuse de partager un folder vers un peer qui n'a pas le bon GUID. Pas de "ah il a deviné le folder ID".
Auto-accept folders : désactiver. Si un peer compromis envoie un nouveau folder, le user humain doit l'accepter.
Pause / Disable : prévoir un kill switch. Si une compromission est suspectée sur un peer, le retirer immédiatement de la liste devices. Tous les autres peers cessent de partager.
Audit logs : Syncthing logge chaque modification. Pour un audit trail complet, monter .stversions/ sur un FS append-only ou rsync vers du restic immutable.
Isolation conteneur : sur des noeuds non dédiés, faire tourner Syncthing dans un conteneur Docker ou une VM. Évite l'escalade en cas de bug Syncthing.
Comparaison avec rsync, Resilio, Unison
| Outil | Modèle | Bidirectionnel | Chiffrement | UI |
| Syncthing | P2P, event-driven | Oui | TLS bout-en-bout | Web |
| rsync | One-shot via SSH | Non (par script) | SSH | CLI |
| Resilio Sync | P2P, propriétaire | Oui | AES | Web (gratuit limité) |
| Unison | One-shot, batch | Oui | SSH | CLI / GUI Tk |
| Mutagen | Synchro dev-oriented | Oui | SSH | CLI |
rsync reste le standard pour des sauvegardes ponctuelles ou des syncs unidirectionnelles cron. Syncthing remplace les usages "sync continu bidirectionnel" pour lesquels rsync demande beaucoup de glue. Resilio est l'équivalent commercial de Syncthing, à éviter sur du neuf (propriétaire, modèle freemium fragmenté).
Limites et signaux d'alerte
Pas pour les très gros datasets. Au-delà de 50 To synchronisés sur un peer, Syncthing devient lent au démarrage (scan complet des hashs). Pour ces volumes, préférer une replication block-level (DRBD, Ceph) ou un object storage avec replication native.
Pas pour les BDD live. Un fichier de base ouvert et modifié constamment générera des transferts permanents et des conflits. Utiliser la replication native PostgreSQL / MariaDB / MongoDB.
Charge CPU sur le hash initial. Le scan d'un dossier de 1 To prend plusieurs heures sur SSD. Pendant ce temps, CPU à 100% sur un coeur. Lancer en heure creuse.
Versioning consomme l'espace. Le .stversions/ peut tripler la taille du dossier si rétention longue. Surveiller.
UI accessible côté Internet. Plusieurs CVE historiques de XSS ou RCE via UI. Ne pas exposer publiquement, toujours derrière VPN ou SSH tunnel.
Découverte publique. Les serveurs de discovery Syncthing voient les device IDs en ligne. Pour une organisation paranoïaque, désactiver la découverte globale et utiliser uniquement IPs statiques ou VPN.
Bande passante. Syncthing peut saturer un lien si on ne limite pas. Configurer --global-rate-limit-up et --global-rate-limit-down pour les liens partagés.
Syncthing prend une niche précise mais utile : remplacer du rsync+cron sur des sync intersites continus, ou propager des dossiers config entre noeuds. Le déploiement initial est mécanique. Le travail réel est dans la définition des stratégies de versioning et de gestion des conflits. Pour des architectures multi-DC qui veulent répliquer des données spécifiques sans payer du stockage cloud, c'est une option solide à condition de définir un runbook de restauration testé. Surveiller ces flux de synchro sort vite du périmètre d'une équipe produit ; cette veille se sous-traite sans drame.
Sources
- Syncthing documentation officielle : référence install, config, troubleshooting.
- GitHub syncthing/syncthing : code, releases, communauté.
- Block Exchange Protocol specification : spécification technique du protocole P2P.
- Local Discovery Protocol specification : spécification de la découverte LAN.
- Syncthing Forum : retours utilisateurs et patterns avancés.
- TLS 1.3 RFC 8446 : référence du transport sous-jacent.
