Using Ubuntu 14.04 LTS, deja-dup 30.0, duplicity 0.6.23, I have accidentally deleted a directory's content for which I made a backup just 5 days ago.

The data arrangement is the following:

  1. The data deleted are in /home/dir/subdir/subsubdir
    • that directory is still there (empty)
  2. The directory /home/dir/ is a mounted partition
    • user accesses it with a symlink /home/user/dir
  3. The backed-up data are stored in an external drive
    • in deja-dup (System Settings > Backups) the directory /home/user/dir is among the 'folders to save' and home/user/dir/subdir not on the 'folders to ignore'.

I have read in https://askubuntu.com/a/181276/446253 that symbolic links can confuse the handling, so I put this factor to the test as well. It does not appear to be crucial though.


A1) If I use nautilus and go into the directory with deleted content via the symlink path #2, the menu show the option 'Restore missing files...'.

The dialogue 'Restore' with a big heading 'Restore which File?' pops up and scans the back-up data from up to a day ago, one week, one month ago, and so on. It does not find anything. I see this happening also for healthy non-empty directories. Weird.

A2) For the sake of completeness, in nautilus I also used the full path to the directory #1. There, unlike A1, the menu does not show any option 'Restore missing files...' at all

B) If I use the deja-dup front-end (System Settings>Backup) and launch the Restore... action for the stored data in full, the dialogue with a big heading 'Restore From Where?' pops up.

There I have the choice of the Date (5 days ago is there), move forward, chose to restore files to original locations, move forward, acknowledge the summary of operations (backup location, restore date, restore folder), launch the restore, authenticate as super user, and move on.

The issue there is that the restore date seems to fail there: I see cumbersome files showing up that I had deleted way way long before 5 days ago, and they take up all space left on the partition /home/dir. This effectively prevents the completion of the restore because of no space left. And, if this understanding of mine is correct, I could delete the most conspicuous files as long as I spot them and avoid a full partition. However, it creates the chore of spotting the all other sparse clutter emerging again and clearing it again after so much time.

The good thing is that the progress report shows that the stored data are there. Existing files are "restored" at least nominally (I guess it is a check on existing copies), and deja-dup appears to deal with the symbolic link smoothly after all. So symlinks are not a trouble for me.

C) In the same conditions, restoring a single file that had not been deleted but was corrupted went well as expected. I could choose the back-up date and the restored file had the content it was supposed to at that point in time. So I guess that the issues are related to directories (which are empty after accidental deletion of the files in them, more specifically)


Using nautilus and deja-dup I lack the fine-grained control on how to restore the files in a single directory with an accurate date-control. The date control is only available for the full restore and is not reliable.

I was thinking of using the command line, but I am hesitant to engage in experimentation with data that could be lost for good. Would someone suggest a fool-proof work around these glitches?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.