Pourquoi une tâche de synchronisation cloud téléverse-t-elle à nouveau des fichiers précédemment supprimés après la restauration de sa base de données d’état ?
Une base de données de synchronisation restaurée peut téléverser à nouveau des fichiers supprimés lorsqu’elle ne contient plus les enregistrements de suppression qui distinguaient une suppression intentionnelle de nouvelles données locales découvertes.
La synchronisation bidirectionnelle repose sur davantage que les fichiers actuellement visibles. Elle conserve un index ou une base de données des chemins précédents, des versions, des identifiants d’appareils, des marqueurs de suppression et de l’état de synchronisation. Restaurer une ancienne base de données tout en conservant des fichiers locaux plus récents ou l’état du cloud crée un décalage temporel : le client peut analyser une copie locale subsistante comme un nouveau fichier, ou interpréter la suppression distante comme un conflit. Mettez en pause tous les participants à la synchronisation avant de déterminer quelle chronologie fait autorité.
Confirmer quelle base de données et quelle arborescence de fichiers ont été restaurées
Notez l’heure de la sauvegarde de la base de données, l’heure de l’arborescence locale, l’état du cloud, la configuration du client, l’identité de l’appareil et le premier événement de nouveau téléversement. Vérifiez si la base de données et les fichiers proviennent du même point de restauration.
La procédure de restauration de Nextcloud exige de restaurer la base de données et le répertoire de données comme un système cohérent, car restaurer une seule couche crée des métadonnées qui ne correspondent plus aux fichiers stockés.
Si la base de données est antérieure à la suppression, mais que l’arborescence locale contient une ancienne copie subsistante, un nouveau téléversement est prévisible. Préservez les trois états avant d’autoriser une nouvelle passe de synchronisation automatique.
Vérifier si les marqueurs de suppression ont été restaurés à un état antérieur
Déterminez si l’état restauré contient l’événement de suppression, la version du fichier, l’identifiant de l’élément distant et l’appareil qui a initialement supprimé le fichier. Comparez les journaux juste avant et juste après la suppression.
Syncthing conserve une base de données d’index locale et avertit qu’une réinitialisation de la base de données force une nouvelle analyse complète et une resynchronisation ; si une ancienne arborescence montée apparaît ensuite, des versions incohérentes peuvent en résulter.
Une suppression qui n’existait que dans la base de données la plus récente est absente après la restauration à un état antérieur. L’analyse suivante voit le fichier restant, mais ne dispose plus des éléments historiques indiquant qu’il doit rester supprimé.
Examiner les fichiers d’état de Bisync ou les listes de synchronisation bidirectionnelle
Pour des outils tels que Rclone Bisync, localisez les deux listes précédentes, le répertoire de travail, l’état du verrou et la dernière exécution réussie. Ne considérez pas une nouvelle resynchronisation comme équivalente à la poursuite d’une synchronisation à partir d’un état valide.
Rclone indique que Bisync conserve son état d’une exécution à l’autre et stocke les données de travail séparément des dossiers synchronisés.
Restaurer ou supprimer ces listes peut effacer la distinction entre « supprimé depuis la dernière exécution » et « existe uniquement de ce côté ». Effectuez une simulation et enregistrez les deux listes avant de reconstruire l’état.
Mettre à jour l’empreinte du serveur après la restauration d’une base de données
Vérifiez si la plateforme serveur fournit un marqueur de restauration indiquant aux clients que la base de données a été restaurée. Appliquez-le avant de reconnecter les clients.
OwnCloud demande aux administrateurs d’exécuter maintenance:data-fingerprint après la restauration afin que les clients de bureau et mobiles puissent reconnaître l’état restauré du serveur.
En l’absence de modification de l’empreinte de restauration, les clients peuvent continuer à partir d’hypothèses établies avec la base de données plus récente. Cela peut provoquer des conflits, de nouveaux téléversements ou des tentatives de suppression d’objets restaurés sur le serveur.
Identifier les copies locales ayant survécu à la suppression dans le cloud
Recherchez, sur chaque appareil synchronisé, dans les dossiers hors ligne, les chemins exclus, la corbeille, les répertoires de conflits et les dossiers temporaires de récupération, des copies du fichier supprimé.
Dropbox explique que la suppression d’un élément peut le supprimer sur les appareils synchronisés, mais que des copies appartenant à un autre emplacement ou ne participant plus au même état synchronisé peuvent subsister.
Un fichier local subsistant devient candidat au téléversement lorsque la base de données restaurée ne le reconnaît plus comme l’ancien objet supprimé. Calculez son empreinte et placez-le en quarantaine en dehors de la racine de synchronisation avant la réconciliation.
Mettre les clients en pause avant de réinitialiser ou de reconstruire l’état de synchronisation
Arrêtez les processus de synchronisation du serveur et mettez en pause tous les clients de synchronisation de bureau, mobiles, conteneurisés et planifiés. Reconnectez d’abord un seul point de terminaison faisant autorité.
La procédure de réinitialisation de OneDrive de Microsoft indique que le client reconstruit son fichier DAT local, ce qui montre pourquoi une réinitialisation modifie l’état du client sans déterminer quelle version historique du fichier doit faire autorité.
La réinitialisation ne remplace pas le choix de la bonne chronologie. Si plusieurs clients analysent les données simultanément, l’un peut téléverser une ancienne copie locale tandis qu’un autre propage la suppression.
Réconcilier un dossier avec une simulation et une sauvegarde indépendante
Exportez la base de données restaurée, copiez tous les fichiers locaux en conflit en dehors des racines de synchronisation, choisissez l’état faisant autorité et testez un petit dossier avant de reprendre la synchronisation de toute la bibliothèque.
Le guide de sauvegarde 3-2-1 de ZimaSpace fournit la limite complémentaire : l’état de synchronisation n’est pas une copie de récupération indépendante lorsqu’il peut reproduire une suppression ou téléverser à nouveau des données obsolètes.
Le problème est résolu lorsque les fichiers supprimés restent supprimés, que les fichiers devant subsister sont téléversés une seule fois, que les conflits sont documentés et qu’une seconde synchronisation contrôlée ne produit aucune réapparition inattendue.
Foire aux questions
La restauration de la base de données restaure-t-elle aussi l’historique des suppressions ?
Seulement jusqu’à la date de la sauvegarde de la base de données. Les suppressions enregistrées après cette date sont absentes, sauf si un autre journal ou point de terminaison les conserve.
Faut-il laisser tous les clients de synchronisation connectés pendant la récupération ?
Non. Mettez-les en pause et reconnectez d’abord un seul point de terminaison faisant autorité afin que les anciens clients ne puissent pas réintroduire immédiatement des fichiers obsolètes.
Une nouvelle analyse complète résoudra-t-elle le problème en toute sécurité ?
Une nouvelle analyse reconstruit l’état de ce qui existe actuellement, mais ne peut pas déduire l’intention historique manquante. Elle peut téléverser à nouveau les fichiers subsistants, sauf si l’état faisant autorité est choisi au préalable.
Produits recommandés
Assistance et conseils
Plus à lire
Pourquoi la restauration d’un volume Docker recrée-t-elle le contenu des fichiers, mais supprime-t-elle les attributs étendus ?
Un diagnostic de restauration de volume couvrant l’inventaire des xattr, les options de tar et de Rsync, les espaces de noms, la prise en...
Pourquoi un conteneur en cours d’exécution conserve-t-il son ancienne limite de mémoire après la modification du fichier Compose ?
Un diagnostic des limites mémoire couvrant les cgroups actifs, le redémarrage par rapport à la recréation, les champs Compose, les limites strictes et souples,...
Pourquoi le redémarrage d’un proxy inverse invalide-t-il toutes les sessions d’une application auto-hébergée ?
Un diagnostic de perte de session couvrant la portée des redémarrages, la propriété des cookies, la rotation des secrets, les sessions adossées au cache,...
