23_Syncthing

Dernière vérification complète : 2026-08-11. Syncthing assure la synchronisation de fichiers entre le VPS Jux (hub), les postes Windows et Ubuntu, le téléphone et la tablette.

Le container sur le VPS

Ports

Volumes

Plusieurs volumes sont montés mais un seul est réellement partagé (voir ci-dessous).

Le maillage

Un seul dossier partagé

Point d'attention fréquent : Jux_univers, komga-pdf, Jux_Obsidian, Ouvrages… ne sont pas des partages Syncthing distincts — ce sont des sous-dossiers de l'unique dossier afltj-njyuy. Il n'y a rien d'autre à configurer pour qu'ils se synchronisent.

Appareils (état au 2026-08-11)

Le VPS sert de hub : deux appareils qui ne se voient jamais directement restent synchronisés en passant par lui.

Le poste Windows « PC-Julien 08/2026 » (2026-08-10)

Trois pièges rencontrés

1. Ne pas prendre SyncTrayzor.SyncTrayzor (1.1.29). Ce paquet winget est le projet d'origine, abandonné depuis 2021 et antérieur à Syncthing 2.x. Le fork maintenu est GermanCoding.SyncTrayzor (2.2.0). Il embarque son propre syncthing.exe (v2.1.2) et le pilote.

2. Le home Syncthing ne doit pas être sous %LOCALAPPDATA% sur ce poste. Claude Code s'exécute dans un conteneur MSIX : ce qu'il écrit dans %LOCALAPPDATA% atterrit en réalité dans …\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\. Le profil créé depuis une session Claude était donc invisible pour SyncTrayzor, qui a démarré sur un profil vierge — le poste est resté déconnecté du maillage sans qu'aucun message ne le signale. Symptômes : API locale en 403, plus aucune ligne écrite dans syncthing.log, appareil vu hors ligne côté VPS. Correctif : profil déplacé dans D:\SyncthingHome et <SyncthingCustomHomePath> renseigné dans %APPDATA%\SyncTrayzor\config.xml.

Get-CimInstance Win32_Process -Filter "Name='syncthing.exe'" | Select-Object CommandLine
# doit afficher --home=D:\SyncthingHome

3. Ne jamais faire tourner deux instances sur le même home. Le binaire winget Syncthing.Syncthing avait d'abord été lancé par tâche planifiée ; il a fallu l'arrêter et supprimer la tâche avant d'installer SyncTrayzor, sous peine de verrouillage de la base.

Faire rejoindre le maillage à un poste dont la copie locale est périmée

Méthode à reproduire telle quelle. Un poste qui arrive avec des fichiers vieux de plusieurs jours peut, en sendreceive, ressusciter des fichiers supprimés ailleurs et générer des conflits en série sur toutes les machines.

1. Sauvegarder hors de l'arbre synchronisé tout fichier modifié localement (voir plus bas).
2. Ajouter le dossier en receiveonly : l'état du maillage fait autorité, les divergences locales sont retenues sans être poussées.
3. Attendre needFiles = 0 — ici 229 fichiers / 547 Mo rapatriés.
4. Basculer en sendreceive : PATCH /rest/config/folders/afltj-njyuy avec {"type":"sendreceive"}.

Constaté lors de cette bascule : la synchronisation a écrasé CLAUDE.md par la version du maillage et déposé les modifications locales dans CLAUDE.sync-conflict-20260810-230652-I4M5WXU.md. Rien n'est perdu, mais il faut penser à rouvrir le fichier de conflit. Contrôle : GET /rest/db/localchanged?folder=afltj-njyuy.

Identité perdue : « PC-Elio+Jux » (supprimé le 2026-08-11)

Ce même poste Windows préexistait dans le maillage sous le nom PC-Elio+Jux (I4M5WXU-…), vu pour la dernière fois le 2026-08-07 à 22:16.

Un device ID Syncthing est sa clé privée (cert.pem / key.pem, rangés dans le home sous le profil Windows). Le profil C:\Users\eliob ayant disparu, la clé a disparu avec lui : l'identité est irrécupérable, et l'appareil ne pouvait pas être « reconnecté » — seulement remplacé par un nouvel ID. Le disque D:, lui, a survécu intact mais figé au 2026-08-06.

Leçon : sauvegarder cert.pem et key.pem hors du profil Windows si l'on tient à conserver l'identité d'un appareil au travers d'une réinstallation.

L'entrée a été retirée du VPS (appareil + liste de partage du dossier) par PUT /rest/config, après sauvegarde de la configuration complète. Elle subsiste sur les autres appareils (Xiaomi, PCNexte, SM-T720, Jux_Ubuntu, NAS), où elle apparaît hors ligne : à retirer à la main sur chacun.

Piloter Syncthing depuis Claude

Il n'y a plus de MCP Syncthing. Le script mcp_syncthing.py ne vivait que dans C:\Users\eliob\.claude\, hors périmètre Syncthing — il a disparu avec le profil. Passer par l'API REST directe, qui couvre tout ce que faisait le MCP.

Authentification : en-tête X-API-Key. Base VPS : https://syncthing.juxjux.ovh/rest. Base locale Windows : http://127.0.0.1:8384/rest.

Appairer un appareil sans toucher à l'interface : ajouter l'entrée dans devices et dans la liste devices du dossier, puis PUT /rest/config. C'est ainsi que « PC-Julien 08/2026 » a rejoint le maillage. L'appareil distant doit toutefois accepter le nouveau venu de son côté, sauf si un appareil introducer s'en charge.

Points de vigilance

• Aucune alerte en cas de décrochage. Un appareil peut rester des jours hors du maillage sans que rien ne le signale — c'est ce qui s'est produit ici du 2026-08-07 au 2026-08-10. Le seul contrôle fiable est GET /stats/device sur le VPS.
• NAS SASNEXTE n'a plus donné signe de vie depuis le 2026-01-30. À diagnostiquer.
• L'interface web du poste Windows n'a ni utilisateur ni mot de passe. Sans danger tant qu'elle n'écoute que sur 127.0.0.1 ; à corriger si le port venait à être exposé.
• UPnP saturé sur la Livebox (PinholeSpaceExhausted dans les journaux) : sans conséquence, la connexion sortante TCP vers le VPS suffit.
• Ne pas confondre le nom du projet compose et celui du service : la stack s'appelle 33, pas syncthing. Pour un redéploiement : docker compose -p 33 -f /var/lib/docker/volumes/portainer_data/_data/compose/33/docker-compose.yml up -d.

⚠ Syncthing n'est pas une sauvegarde — corrigé le 2026-08-30

Constat de départ : le dossier afltj-njyuy est en sendreceive avec versioning = AUCUNE (vérifié par GET /rest/config/folders, aucun .stversions sur le VPS). Syncthing fait de la réplication : une suppression ou un écrasement sur l'un des 7 appareils se propage partout en quelques secondes, sans retour arrière possible. Sept copies d'un fichier effacé font zéro copie.

Ce n'était pas théorique — c'est arrivé deux fois : le CLAUDE.md écrasé par le maillage le 2026-08-10, et les 308 suppressions provoquées par un simple renommage de dossier le 2026-08-28. C'était le seul trou de l'architecture de sauvegarde : les 6 services sauvegardés chaque nuit sont des bases de données, et ~/Documents n'y figurait pas.

Ce qui a été mis en place

Un septième service dans /opt/backups/vps_backup.sh (cron 0 2 * * *), sur le modèle de backup_baikal : tar de ~/Documents → 7z -mx=1 → upload vers le dossier kDrive 1485489, rotation documents_day{1-7}.7z. Plus une copie mensuelle le 1er de chaque mois (documents_month{01-12}.7z, dossier kDrive 1486390), qui donne une année glissante de recul. Sauvegarde du script avant modification : /opt/backups/vps_backup.sh.bak-260830. Le bilan de fin de log passe de 6/6 à 7/7.

Deux garde-fous dans la fonction :

• Contrôle d'espace sur /tmp avant de commencer — l'incident du 2026-06-24 (disque à 100 %, tout le VPS à terre) est parti d'un fichier temporaire.
• tar renvoyant 1 est traité comme un avertissement, pas comme un échec : Syncthing peut écrire pendant la sauvegarde et tar signale alors « file changed as we read it ». Seul un code > 1 fait échouer le service.

Le périmètre, mesuré le 2026-08-30

Après le rangement fait par Julien le même jour (retrait de APK temp, des conflits de komga-pdf, et déplacement de Suretés vers le NAS), l'arbre est passé de 1,6 Go à 493 Mo. Maillage cohérent : 1 267 fichiers des deux côtés, needFiles = 0, aucun .stignore.

À retenir : 73 % de tout l'arbre Syncthing est le coffre Cryptomator « Vault 2603 » — 513 fichiers .c9r pour 359,5 Mo, à l'intérieur de Jux_univers. Le reste de Jux_univers (Jux-scripts, Claude-pcelio+jux, 2026, EMOA) ne pèse que 6,2 Mo. Trier cet arbre par taille ne donne donc plus rien : le seul arbitrage réel est de savoir si le coffre reste ou non dans l'arbre répliqué. Décision de Julien le 2026-08-30 : il reste, et il en existe par ailleurs une copie sur kDrive.

Seules exclusions du tar : .stfolder et .stversions, qui sont des métadonnées Syncthing. Tout le reste est sauvegardé, y compris les dossiers de transit komga-pdf et komga-compressed — un PDF qui y attend son traitement n'existe nulle part ailleurs.

Restauration — vérifiée, pas supposée

Une sauvegarde jamais restaurée n'est pas une sauvegarde. Test complet fait le jour même :

1. archive re-téléchargée depuis kDrive — attention, curl -L obligatoire, voir la page A_liens entre Claude et le KDRIVE ;
2. 7z t → Everything is Ok ;
3. tar extrait : 1 760 entrées, et surtout masterkey.cryptomator bien présent — sans lui le coffre serait irrécupérable ;
4. un fichier témoin (CLAUDE.md, 151 849 octets) extrait puis comparé à la source : identique à l'octet près.

Profondeur de rétention (2026-08-30)

Deux séries indépendantes, toutes deux sans purge — la suppression via l'API kDrive ne fonctionne pas, donc on se contente d'écraser un nom qui revient :

Le tar est produit par une fonction commune documents_tar(). Le 1er du mois il est construit deux fois (~33 s de plus) : les deux séries restent ainsi indépendantes, un échec de l'une n'empêchant pas l'autre. Les autres jours, la fonction mensuelle sort en succès sans rien faire, pour ne pas inscrire un faux échec au bilan.

Ce que cette sauvegarde ne couvre pas

• Entre deux copies mensuelles, le recul retombe à 7 jours. Un fichier créé le 5 puis supprimé le 20 n'apparaît dans aucune des deux séries : il n'a jamais existé un 1er du mois, et les 7 jours glissants l'ont déjà dépassé. C'est la limite structurelle d'une rotation par écrasement de nom, assumée ici.
• Le versioning Syncthing reste désactivé. Une corbeille (trashcan, 30 jours, via PATCH /rest/config/folders/afltj-njyuy) protégerait immédiatement contre une fausse manœuvre, là où la sauvegarde ne rattrape que ce qui existait à 2 h du matin. Non fait à ce jour.