Pourquoi la synchronisation à distance recopie-t-elle un dossier entier après la reconnexion ?

La synchronisation à distance recopie un dossier entier lorsque le client ne peut plus prouver que les fichiers locaux et distants sont identiques.

Après la reconnexion d’un ordinateur portable, d’un NAS, d’un partage monté ou d’un pair distant, le moteur de synchronisation peut reconstruire son index, voir une identité de système de fichiers différente, perdre les hachages stockés, détecter des horodatages modifiés, traiter des fichiers renommés comme de nouveaux objets ou comparer avec une base de données obsolète. Le bon diagnostic protège d’abord les deux copies, puis détermine si le client est en train de rescanner, recalculer les hachages, retélécharger ou réellement retransférer des données avant de réinitialiser une bibliothèque.

Confirmer si le client est en train de scanner, hacher ou transférer

Enregistrez le débit réseau, les lectures disque, l’utilisation du CPU, le statut du client et les messages de journal pendant la recopie apparente. Un scan complet ou un passage de somme de contrôle peut sembler actif pendant des heures sans envoyer le dossier complet sur Internet.

Une discussion sur rclone décrit comment le mode somme de contrôle peut répéter le traitement des sommes de contrôle à chaque exécution. Ce comportement consomme du stockage et du CPU mais diffère d’une véritable retransmission réseau.

Utilisez les compteurs de transfert par fichier ou les totaux de paquets pour classer l’événement. Si seules les métadonnées et les hachages sont lus, optimisez l’état du scan ; si les octets de charge utile complète circulent à nouveau, poursuivez avec les tests d’identité, d’index, d’horodatage et de renommage.

Vérifier si la base de données ou l’index de synchronisation a été reconstruit

Inspectez les journaux du client autour de la reconnexion pour des messages de migration de base de données, corruption, index manquant, réinitialisation, rescannage ou première exécution. Comparez le répertoire de configuration du client et l’horodatage de la base de données avec la dernière synchronisation réussie.

Un cas de support Syncthing explique qu’une base de données d’index corrompue peut nécessiter une reconstruction, faisant que l’appareil se comporte comme si les dossiers étaient nouvellement ajoutés et pouvant provoquer un grand rescannage initial.

Sauvegardez la base de données avant de la supprimer ou de la réinitialiser. Si la recopie a commencé immédiatement après une réinstallation de l’application, une recréation de conteneur, une réinitialisation de profil ou une perte de base de données, conservez les bonnes données et utilisez le flux de travail de reconnexion vers un dossier existant pris en charge par le client.

Comparer l’identité des fichiers au-delà du nom de fichier

Sélectionnez plusieurs fichiers que le client souhaite recopier et comparez la taille, l’heure de modification, la somme de contrôle, les permissions, la propriété, la casse, les attributs étendus et le chemin des deux côtés. Notez quel champ diffère.

Les utilisateurs de FreeFileSync discutent du stockage des sommes de contrôle car la taille et les horodatages seuls ne prouvent pas toujours que les fichiers appariés restent identiques, tandis que les bases de données de sommes de contrôle ajoutent leurs propres exigences d’état. Cela illustre pourquoi les métadonnées de comparaison de fichiers sont importantes après une reconnexion.

Si les hachages de contenu correspondent mais que les horodatages ou permissions diffèrent, corrigez les réglages d’horloge, de préservation des métadonnées ou de comparaison plutôt que de retransférer le contenu. Si les hachages diffèrent, identifiez quel côté est autoritaire avant d’autoriser une écriture automatique.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Vérifier si le dossier s’est reconnecté sous une identité différente

Comparez le chemin monté, l’UUID du système de fichiers, le nom du partage réseau, la lettre de lecteur, l’identifiant de volume, le montage de conteneur lié et la sensibilité à la casse avant et après la déconnexion. Un chemin de dossier familier peut pointer vers un montage différent ou un répertoire local vide.

Les outils de synchronisation stockent souvent l’identité du dossier dans une base de données locale plutôt que de se fier uniquement au chemin affiché. Un partage NAS remonté, un disque USB remplacé, un volume Docker modifié ou un profil client recréé peut donc sembler être une nouvelle cible.

Arrêtez la synchronisation si le montage attendu est absent ou si le dossier pointe vers un stockage local de secours. Restaurez le montage original et vérifiez des fichiers d’exemple avant de reconnecter la bibliothèque pour éviter suppressions ou téléchargements en double.

Tester si les déplacements et renommages sont détectés

Choisissez un petit dossier, renommez-le pendant que les deux pairs sont connectés, et observez si le client effectue un déplacement de métadonnées ou télécharge chaque fichier comme nouveau contenu. Répétez après une déconnexion et reconnexion.

Une discussion sur une fonctionnalité Syncthing note que les déplacements ou renommages peuvent être traités comme de nouveaux transferts lorsque l’outil ne peut pas faire correspondre les chemins modifiés via son index existant, produisant un comportement de suppression et rechargement.

Si la recopie suit un renommage de dossier de haut niveau, laissez le client terminer son échange d’index avant de faire d’autres modifications. Pour les grandes bibliothèques, évitez les renommages massifs simultanés sur plusieurs pairs et maintenez la versionnage ou la protection de sauvegarde activée.

Reconnecter en toute sécurité sans réinitialiser la bonne copie

Créez une sauvegarde ou un instantané du côté autoritaire, mettez la synchronisation en pause, et testez un petit sous-dossier en utilisant la fonction de dossier existant ou de reliaison du client. Ne cliquez pas sur un bouton générique de réinitialisation ou de resynchronisation avant de comprendre sa direction.

Le guide ZimaSpace pour restaurer un dossier partagé en toute sécurité fournit le même principe de confinement pour protéger les données non affectées.

Le problème est résolu uniquement lorsque la reconnexion préserve l’index, compare les fichiers existants sans transfert de charge utile, applique uniquement les changements réels et survit à une nouvelle déconnexion. Si la base de données se corrompt ou disparaît à répétition, réparez le stockage, l’arrêt, la persistance du conteneur ou le problème d’installation du client plutôt que d’accepter des synchronisations complètes récurrentes.