{"id":3,"date":"2026-01-15T20:47:00","date_gmt":"2026-01-15T20:47:00","guid":{"rendered":"https:\/\/rpi.temporiti.net\/wordpress\/blog\/sincronizzazione-file-decentralizzata-p2p\/"},"modified":"2026-05-30T14:05:19","modified_gmt":"2026-05-30T12:05:19","slug":"sincronizzazione-file-decentralizzata-p2p","status":"publish","type":"post","link":"https:\/\/rpi.temporiti.net\/wordpress\/?p=3","title":{"rendered":"Sincronizzazione file decentralizzata con Syncthing"},"content":{"rendered":"

Sincronizzare file fra macchine diverse senza affidarsi a un cloud di terzi \u00e8 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\/<\/code> fra tutti questi posti, senza che nessuno legga i miei file, \u00e8 il caso d’uso perfetto per Syncthing<\/a>.<\/p>\n

Installare<\/h2>\n

Su Debian e derivate, incluso Raspberry Pi OS, il pacchetto \u00e8 nel repo ufficiale. Sul portatile uso fish come shell, sui server bash di default:<\/p>\n

\nsudo apt update\nsudo apt install syncthing\n<\/code><\/pre>\n
Su Mac via Homebrew:<\/p>\n
\nbrew install syncthing\nbrew services start syncthing\n<\/code><\/pre>\n
Sui sistemi headless lo abilito come servizio utente, sostituendo USERNAME<\/code> con il mio utente di servizio:<\/p>\n
\nsudo systemctl enable --now syncthing@USERNAME.service\n<\/code><\/pre>\n
Il demone parte su 127.0.0.1:8384<\/code> per la web UI e su TCP\/UDP 22000 per la sincronizzazione vera e propria. Se il server \u00e8 remoto, faccio tunnel SSH per arrivare alla UI invece di esporla in rete:<\/p>\n
\nssh -L 8384:127.0.0.1:8384 utente@host-remoto\n<\/code><\/pre>\n
E apro http:\/\/127.0.0.1:8384<\/code> in locale. Esporre la web UI direttamente su internet \u00e8 una pessima idea: l’autenticazione di default \u00e8 basilare e da li si gestisce l’intera tailnet di file.<\/p>\n
Aggiungere un dispositivo<\/h2>\n
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:<\/p>\n
1. Folder Type “Send & Receive”<\/strong> sulla macchina principale, “Receive Only”<\/strong> sui Raspberry Pi: un errore su un Pi non torna a sporcarmi il master.<\/p>\n
2. Versioning “Staggered”<\/strong> con retention a 30 giorni: salva snapshot a intervalli crescenti e mi permette di recuperare un file modificato per sbaglio anche tre settimane dopo.<\/p>\n
3. Ignore patterns<\/strong> per .DS_Store<\/code>, .git\/<\/code>, node_modules\/<\/code> e cartelle di cache: senza, Syncthing si mangia banda dietro a robaccia.<\/p>\n
Topologia e routing<\/h2>\n
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<\/code> metto tcp:\/\/203.0.113.10:22000<\/code>. In questo modo il NAT traversal \u00e8 immediato e non serve passare dai relay pubblici Syncthing.<\/p>\n
Le porte 22000\/tcp e 22000\/udp sui server vanno aperte nel security group o sull’host firewall:<\/p>\n
\nsudo ufw allow 22000\/tcp\nsudo ufw allow 22000\/udp\n<\/code><\/pre>\n
Un caso reale<\/h2>\n
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 \u00e8 gi\u00e0 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<\/code> in una cartella condivisa per sbaglio: la Receive Only<\/code> di quel nodo ha bloccato la propagazione, ho potuto fare cleanup centralmente senza rincorrere copie sporche su tre macchine.<\/p>\n
Cosa funziona bene<\/h2>\n
La filosofia peer-to-peer mi piace: i file restano miei, cifrati in transito, e non c’\u00e8 nessun servizio centrale che vede i metadati. Lo Staggered Versioning mi ha salvato almeno tre volte da rm sbagliati. La UI \u00e8 chiara, lo stato di ogni cartella \u00e8 leggibile a colpo d’occhio.<\/p>\n
Limiti<\/h2>\n
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<\/code> 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.<\/p>\n
In pratica<\/h2>\n
Syncthing \u00e8 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 \u00e8 lui che fa il lavoro.<\/p>\n
\n
\n
Immagine generata con ComfyUI Mac M1 \/ RealVisXL V5 Lightning.<\/p>\n<\/blockquote>\n","protected":false},"excerpt":{"rendered":"
Sincronizzare file fra macchine diverse senza affidarsi a un cloud di terzi \u00e8 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 […]<\/p>\n","protected":false},"author":1,"featured_media":186,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-3","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-self-hosting"],"_links":{"self":[{"href":"https:\/\/rpi.temporiti.net\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/3","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rpi.temporiti.net\/wordpress\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rpi.temporiti.net\/wordpress\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rpi.temporiti.net\/wordpress\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rpi.temporiti.net\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3"}],"version-history":[{"count":10,"href":"https:\/\/rpi.temporiti.net\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/3\/revisions"}],"predecessor-version":[{"id":353,"href":"https:\/\/rpi.temporiti.net\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/3\/revisions\/353"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rpi.temporiti.net\/wordpress\/index.php?rest_route=\/wp\/v2\/media\/186"}],"wp:attachment":[{"href":"https:\/\/rpi.temporiti.net\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rpi.temporiti.net\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rpi.temporiti.net\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}