Ce soir, j'ai dû éteindre mon ordinateur après une sorte de panique du noyau.
Lorsque j'ai redémarré, j'ai remarqué mon ~/.ssh/id_rsa avait été remplacé par un fichier vide.
Redémarrage sur une clé USB et exécution de fsck sur ma partition personnelle a signalé que le système de fichiers était en bon état.
Cela seul n'est pas un problème. J'accède à la clé d'origine. Cependant, je crains que d'autres fichiers n'aient été tronqués de la même manière.
Ma dernière sauvegarde, en utilisant deja-dup , c'était il y a trois jours, je pouvais donc faire une restauration complète, mais je préférerais simplement demander deja-dup quels fichiers ont changé depuis et recherchez les fichiers "suspects".
Cela semble être exactement le but de la duplicity verify , donc après avoir parcouru quelques pages de manuel, j'ai essayé :
duplicity verify --verbosity 4 --no-encryption file:///path/to/backup/ /home/${USER}
qui s'est déroulé jusqu'à son terme sans signaler de modifications. Au minimum, j'attendais mon ~/.ssh/id_rsa à détecter, mais j'ai ajouté, supprimé et modifié d'autres fichiers.
Mon essai suivant était alors le même, mais avec le --compare-data drapeau :
duplicity verify --verbosity 4 --no-encryption file:///path/to/backup/ /home/${USER}
Ce qui semble indiquer que chaque fichier de mon dossier personnel est nouveau, commençant par :
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Fri Dec 15 11:43:22 2017
Difference found: File . has permissions 1000:1001 700, expected 0:0 555
Difference found: New file .AndroidStudio2.3
Difference found: New file .AndroidStudio2.3/config
Difference found: New file .AndroidStudio2.3/config/inspection
Difference found: New file .AndroidStudio2.3/config/inspection/Default.xml
J'ai installé Android Studio pendant des mois, donc c'était très certainement dans ma sauvegarde d'il y a trois jours, et ls signale que Default.xml existe toujours et fait 108 octets de long.
Dans un dernier effort, j'ai changé le répertoire cible en / , car cela semblait être la racine lors de l'utilisation de duplicity list-current-files , ce qui nécessitait d'ajouter quelques expressions régulières pour limiter la duplicité afin de ne considérer que mon dossier personnel :
duplicity verify --verbosity 4 --compare-data --no-encryption --include-regexp ".*home/${USER}/.ssh.*" --exclude-regexp ".*" file:///path/to/backup/ /
Ce qui a eu l'effet intéressant de signaler que mon dossier personnel n'existe pas :
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Fri Dec 15 11:43:22 2017
Difference found: File home is missing
Difference found: File home/${USER} is missing
Difference found: File home/${USER}/.AndroidStudio2.3 is missing
Difference found: File home/${USER}/.AndroidStudio2.3/config is missing
Difference found: File home/${USER}/.AndroidStudio2.3/config/inspection is missing
Difference found: File home/${USER}/.AndroidStudio2.3/config/inspection/Default.xml is missing
À ce stade, je ne comprends certainement pas comment je devrais utiliser la duplicité. Comment puis-je vérifier une sauvegarde générée par deja-dup ?
duplicity list-current-files a une sortie commençant :
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Fri Dec 15 11:43:22 2017
Tue Feb 6 19:36:56 2018 .
Wed Aug 2 17:32:09 2017 home
Tue Feb 6 00:38:20 2018 home/${USER}
Sat May 13 18:49:24 2017 home/${USER}/.AndroidStudio2.3
Thu Jun 22 19:42:14 2017 home/${USER}/.AndroidStudio2.3/config
Sat May 13 18:57:45 2017 home/${USER}/.AndroidStudio2.3/config/inspection
Sat May 13 18:57:45 2017 home/${USER}/.AndroidStudio2.3/config/inspection/Default.xml
Réponse acceptée :
@ede et moi avons trouvé la même solution en même temps, dans mon cas sur la liste de diffusion de duplicité
En relation :Problème de sauvegarde et d'alerte étrange ?
la vérification de duplicité nécessite le --compare-data flag afin de vérifier les fichiers sur le disque, et il a besoin du --file-to-restore flag afin de regarder dans le bon répertoire, donc la commande finale qui a résolu mon problème est :
duplicity verify --verbosity 4 --compare-data --file-to-restore=/home/${USER} --no-encryption file:///path/to/backup/ /home/${USER}/
Malheureusement, cela ne détecte toujours pas que ~/.ssh/id_rsa a été endommagé. En même temps, essayer de restaurer à partir de la sauvegarde a restauré un fichier de 0 octet… Il est tout à fait possible que quelque chose soit arrivé à mon fichier il y a des semaines.