mjhjmtu

This evening, I had to hard shut down my computer after some kind of kernel panic.

When I rebooted, I noticed my ~/.ssh/id_rsa had been replaced with an empty file.

Rebooting to a USB and running fsck on my home partition reported that the filesystem was in good shape.

This alone is not a problem. I access to the original key. However, I am concerned that other files may have been similarly truncated.

My last backup, using deja-dup, was three days ago, so I could just do a full roll-back, but I would rather just ask deja-dup what files have changed since then and look for "suspicious" files.

This seems to be exactly the purpose of duplicity verify, so after some man page skimming, I tried:

duplicity verify --verbosity 4 --no-encryption file:///path/to/backup/ /home/$USER


which ran to completion without reporting changes. At a minimum, I expected my ~/.ssh/id_rsa to be detected, but I have added, removed, and changed other files

My next try was then the same, but with the --compare-data flag:

duplicity verify --verbosity 4 --no-encryption file:///path/to/backup/ /home/$USER


Which seems to report that every file in my home folder is new, starting like:

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

I have had Android Studio installed for months, so it was most certainly in my backup from three days ago, and ls reports that Default.xml still exists and is 108 bytes long

As a final effort, I changed the target directory to /, since that seemed to be the root when using duplicity list-current-files, which required adding some regular expressions to limit duplicity to only consider my home folder:

duplicity verify --verbosity 4 --compare-data --no-encryption --include-regexp ".*home/$USER/.ssh.*" --exclude-regexp ".*" file:///path/to/backup/ /

which had the interesting effect of reporting that my home folder doesn't exist:

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

At this point, I am certainly just misunderstanding how I should use duplicity. How can I verify a backup generated by deja-dup?

duplicity list-current-files has output starting:

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

@ede and I found the same solution at the same time, in my case on the duplicity mailing list

duplicity verify needs the --compare-data flag in order to verify the on-disk files, and it needs the --file-to-resore flag in order to look in the proper directory, so the final command that solved my problem is:

duplicity verify --verbosity 4 --compare-data --file-to-restore=/home/$USER --no-encryption file:///path/to/backup/ /home/$USER/

Unfortunately, this still does not detect that ~/.ssh/id_rsa was damaged. At the same time, trying to restore from the backup restored a 0-byte file... It's quite possible something happened to my file weeks ago.