Heute Abend musste ich meinen Computer nach einer Art Kernel-Panic herunterfahren.
Als ich neu startete, bemerkte ich meinen ~/.ssh/id_rsa wurde durch eine leere Datei ersetzt.
Neustart auf USB und Ausführen von fsck auf meiner Home-Partition hat gemeldet, dass das Dateisystem in gutem Zustand ist.
Dies allein ist kein Problem. Ich greife auf den Originalschlüssel zu. Ich befürchte jedoch, dass andere Dateien möglicherweise ähnlich abgeschnitten wurden.
Mein letztes Backup mit deja-dup , war vor drei Tagen, also könnte ich einfach ein vollständiges Rollback durchführen, aber ich würde lieber einfach deja-dup fragen welche Dateien sich seitdem geändert haben und suchen Sie nach „verdächtigen“ Dateien.
Dies scheint genau der Zweck der duplicity verify zu sein , also habe ich nach einigem Überfliegen der Manpage Folgendes versucht:
duplicity verify --verbosity 4 --no-encryption file:///path/to/backup/ /home/${USER}
die bis zum Abschluss lief, ohne Änderungen zu melden. Ich habe mindestens meinen ~/.ssh/id_rsa erwartet erkannt werden, aber ich habe andere Dateien hinzugefügt, entfernt und geändert.
Mein nächster Versuch war dann derselbe, aber mit dem --compare-data Flagge:
duplicity verify --verbosity 4 --no-encryption file:///path/to/backup/ /home/${USER}
Was zu melden scheint, dass jede Datei in meinem Home-Ordner neu ist, beginnend wie folgt:
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
Ich habe Android Studio seit Monaten installiert, also war es höchstwahrscheinlich in meinem Backup von vor drei Tagen und ls meldet, dass Default.xml existiert noch und ist 108 Bytes lang.
Als letzten Versuch habe ich das Zielverzeichnis auf / geändert , da dies der Stamm zu sein schien, wenn duplicity list-current-files verwendet wurde , was das Hinzufügen einiger regulärer Ausdrücke erforderte, um die Duplizität zu begrenzen und nur meinen Home-Ordner zu berücksichtigen:
duplicity verify --verbosity 4 --compare-data --no-encryption --include-regexp ".*home/${USER}/.ssh.*" --exclude-regexp ".*" file:///path/to/backup/ /
Was den interessanten Effekt hatte, zu melden, dass mein Home-Ordner nicht existiert:
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
An diesem Punkt missverstehe ich sicherlich nur, wie ich Duplizität verwenden soll. Wie kann ich ein von deja-dup erstelltes Backup verifizieren ?
duplicity list-current-files hat die Ausgabe ab:
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
Akzeptierte Antwort:
@ede und ich haben zur gleichen Zeit dieselbe Lösung gefunden, in meinem Fall auf der Duplicity-Mailingliste
Verwandt:Seltsames Sicherungs- und Warnproblem?
Duplizitätsprüfung benötigt den --compare-data Flag, um die Dateien auf der Festplatte zu überprüfen, und es benötigt den --file-to-restore Flag, um im richtigen Verzeichnis zu suchen, also lautet der letzte Befehl, der mein Problem gelöst hat:
duplicity verify --verbosity 4 --compare-data --file-to-restore=/home/${USER} --no-encryption file:///path/to/backup/ /home/${USER}/
Leider wird dieser ~/.ssh/id_rsa immer noch nicht erkannt war beschädigt. Gleichzeitig wurde beim Versuch, aus dem Backup wiederherzustellen, eine 0-Byte-Datei wiederhergestellt … Es ist durchaus möglich, dass vor Wochen etwas mit meiner Datei passiert ist.