Échec de la sauvegarde Deja-Dup - Données non valides - SHA 1 non concordance de hachage pour le fichier
Lors de ma dernière sauvegarde hebdomadaire aujourd'hui, Deja-Dup m'a donné cette petite note d'amour:
Échec de la sauvegarde
Données non valides - Incompatibilité de hachage SHA1 pour le fichier:
duplicity-inc.20130124T230054Z.to.20130201T225108Z.vol1.difftar.gpgHash calculé: 7726f55012e1e26cc762c9982e7c6c54ca7bb303
Hash de manifeste: 205ecad0a91f8a11967b70d2d3fbc8e4d06231f5
J'utilise la version 12.10 et exécute des sauvegardes hebdomadaires deja-dup depuis que je l'ai installée.
D'après ce que j'ai lu en lisant d'autres threads, il s'agit d'un bogue logiciel connu qui se produit lorsque la duplicité est interrompue, mais la plupart de ces autres threads sont des personnes qui tentent de restaurer à partir de ces sauvegardes corrompues.
J'ai essayé de supprimer et de ré-essayer le fichier en question pour réessayer, mais un message d'erreur me dit que le fichier n'a pas été trouvé.
Ma question est la suivante: qu'est-ce que cela signifie pour mes sauvegardes à venir? La sauvegarde de cette semaine a-t-elle fonctionné? Will la semaine prochaine? Si non, comment puis-je résoudre cette erreur?
Les anciennes versions de mes fichiers ne m'inquiètent pas trop et même si j'en ai besoin à l'avenir, j'ai des images de disque sauvegardées que je pourrais restaurer. Devrais-je donc tout supprimer et commencer deja-dup à partir de zéro?
Tout conseil est apprécié.
J'ai eu ce problème récemment moi-même. Je n'ai pas trouvé de solution "idéale". L'option la plus sûre consiste à ignorer la sauvegarde défectueuse et à en démarrer une nouvelle, comme vous l'avez mentionné dans votre commentaire.
Autres réponses à des problèmes similaires suggère des solutions de contournement pour la restauration de fichiers en utilisant des sauvegardes précédentes ou en ignorant les fichiers du volume corrompu, mais ceci est clairement sous-optimal, pour ne pas dire fastidieux à réaliser en pratique. Toutefois, cela n’aide pas une sauvegarde ayant échoué.
Essayer de forcer une sauvegarde complète des fichiers du volume en échec est contre-productif, car la sauvegarde incrémentielle suivante est énorme et couvre tous les autres fichiers; vous pouvez également supprimer la sauvegarde ayant échoué et recommencer.
J'ai trouvé un moyen d'implémenter un correctif de la partie défaillante de la sauvegarde. Voici la recette:
- Recherchez les fichiers concernés en notant le numéro de volume, puis vérifiez le numéro de volume dans le fichier manifeste.
- Appuyez sur les fichiers concernés (
touch -m /name/of/file). - Faites une sauvegarde incrémentielle.
La sauvegarde incrémentielle contiendra le (s) fichier (s) affecté (s), ainsi que tous les autres fichiers modifiés entre-temps, et l'erreur SHA1 n'est plus signalée ... sauf par vérification (voir ci-dessous).
J'ai testé cela en utilisant la duplicité directement plutôt que deja-dup gui, car cela me permettait d'avoir un peu plus de contrôle et de faire d'autres tâches comme vérifier la sauvegarde (duplicity verify /target/directory url:///for/backup/archive). Il ne supprime pas le problème SHA1 d'origine, mais l'atténue en fournissant un moyen de restaurer les fichiers dans le (s) volume (s) de sauvegarde présumé (s) corrompu (s).
De même, je pense que si vous êtes sérieux au sujet des sauvegardes, vous devez oublier deja-dup et utiliser directement la duplicité, car les sauvegardes sans vérification ne valent rien. J'ai découvert cela à la dure, après avoir utilisé deja-dup pendant presque deux ans, avant qu'une sauvegarde échouée ne me fasse comprendre que mon planning de sauvegarde était en fait une maison construite sur du sable; Lorsque j'ai vérifié le lecteur externe que j'utilisais, environ 5% de tous les fichiers de sauvegarde étaient illisibles. Depuis lors, j'ai constaté que l'utilisation de scripts Shell avec duplicité n'était pas si difficile, et une fois qu'il est configuré, c'est très facile.