Sincronizzare file fra macchine diverse senza affidarsi a un cloud di terzi è una di quelle abitudini che mi hanno cambiato il modo di lavorare. Sulla scrivania ho un portatile Linux, in salotto un Mac mini dedicato al multimedia, in un angolo un paio di Raspberry Pi e su un provider cloud un piccolo server ARM su tier gratuito. Tenere allineata la cartella ~/Documenti/note/ fra tutti questi posti, senza che nessuno legga i miei file, è il caso d’uso perfetto per Syncthing.
Installare
Su Debian e derivate, incluso Raspberry Pi OS, il pacchetto è nel repo ufficiale. Sul portatile uso fish come shell, sui server bash di default:
sudo apt update
sudo apt install syncthing
Su Mac via Homebrew:
brew install syncthing
brew services start syncthing
Sui sistemi headless lo abilito come servizio utente, sostituendo USERNAME con il mio utente di servizio:
sudo systemctl enable --now [email protected]
Il demone parte su 127.0.0.1:8384 per la web UI e su TCP/UDP 22000 per la sincronizzazione vera e propria. Se il server è remoto, faccio tunnel SSH per arrivare alla UI invece di esporla in rete:
ssh -L 8384:127.0.0.1:8384 utente@host-remoto
E apro http://127.0.0.1:8384 in locale. Esporre la web UI direttamente su internet è una pessima idea: l’autenticazione di default è basilare e da li si gestisce l’intera tailnet di file.
Aggiungere un dispositivo
Ogni nodo ha un Device ID lungo, generato alla prima esecuzione. Dalla web UI lo copio, sull’altro nodo apro “Add Remote Device” e lo incollo. Quando entrambi si vedono, posso condividere cartelle. Tre accortezze che applico sempre:
1. Folder Type “Send & Receive” sulla macchina principale, “Receive Only” sui Raspberry Pi: un errore su un Pi non torna a sporcarmi il master.
2. Versioning “Staggered” con retention a 30 giorni: salva snapshot a intervalli crescenti e mi permette di recuperare un file modificato per sbaglio anche tre settimane dopo.
3. Ignore patterns per .DS_Store, .git/, node_modules/ e cartelle di cache: senza, Syncthing si mangia banda dietro a robaccia.
Topologia e routing
Per ridurre il traffico relay e tenere la sincronizzazione veloce, configuro un nodo come “Introducer” e abilito il discovery globale solo dove serve. Sui server in cloud con IP pubblico aggiungo l’hint statico nel device address: invece di dynamic metto tcp://203.0.113.10:22000. In questo modo il NAT traversal è immediato e non serve passare dai relay pubblici Syncthing.
Le porte 22000/tcp e 22000/udp sui server vanno aperte nel security group o sull’host firewall:
sudo ufw allow 22000/tcp
sudo ufw allow 22000/udp
Un caso reale
Una mattina, intorno alle 9:30, stavo lavorando su un Raspberry Pi della stanza-studio quando ho dovuto spostarmi al portatile per un ticket urgente. Apro il laptop e in venti secondi la cartella note è già aggiornata con quello che avevo scritto sul Pi. Niente upload manuali, niente “lascia perdere, lo finisco poi”. Quattro ore dopo, al rientro, ho notato che un service di un host periferico aveva ricreato per errore qualche file dentro node_modules in una cartella condivisa per sbaglio: la Receive Only di quel nodo ha bloccato la propagazione, ho potuto fare cleanup centralmente senza rincorrere copie sporche su tre macchine.
Cosa funziona bene
La filosofia peer-to-peer mi piace: i file restano miei, cifrati in transito, e non c’è nessun servizio centrale che vede i metadati. Lo Staggered Versioning mi ha salvato almeno tre volte da rm sbagliati. La UI è chiara, lo stato di ogni cartella è leggibile a colpo d’occhio.
Limiti
Per cartelle con tantissimi file piccoli (un cache di build, una libreria con migliaia di assets) Syncthing fatica e il CPU sul Raspberry Pi schizza. Per quei casi continuo a usare rsync puntuale o uno share NFS. Il primo handshake fra device dietro NAT a volte richiede un paio di minuti, soprattutto se la rete del provider cloud blocca certi flussi UDP.
In pratica
Syncthing è diventato il livello di trasporto file dell’homelab: copre la mia esigenza di “stessi file, ovunque”, senza che nessuno si metta in mezzo. Lo accoppio con backup a freddo per il disaster recovery e con un object storage S3-compatibile per il versioning storico, ma per il quotidiano è lui che fa il lavoro.
Immagine generata con ComfyUI Mac M1 / RealVisXL V5 Lightning.