AssertionError in add_filename - backup folder corrupted?

Asked by Kakurady Drakenar

deja-dup 37.1-2fakesync1
duplicity 0.7.17-0ubuntu1

My deja-dup backups have started to fail with "Failed with an unknown error.", accompanied by this traceback:

Traceback (innermost last):
  File "/usr/bin/duplicity", line 1555, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1541, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1393, in main
    do_backup(action)
  File "/usr/bin/duplicity", line 1419, in do_backup
    action).set_values()
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 710, in set_values
    self.get_backup_chains(partials + backend_filename_list)
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 836, in get_backup_chains
    add_to_sets(f)
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 824, in add_to_sets
    if set.add_filename(filename):
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 105, in add_filename
    (self.volume_name_dict, filename)
 AssertionError: ({1: 'duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol1.difftar.gz'}, 'duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol1.difftar.gz')

It looks like Bug #1652410, where an uncompressed backup volume sits next to its compressed counterpart, but then I ran ls in the backup storage directory, which is on an NTFS formatted disk volume:

    kakurady@nanairo:/media/kakurady/Seagate Backup Plus Drive/Backup/nanairo$ ls duplicity-inc.20180614*
    ls: cannot access 'duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol2.difftar.gz': No such file or directory
    duplicity-inc.20180614T072154Z.to.20180615T072208Z.manifest
    duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol1.difftar.gz
    duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol1.difftar.gz
    kakurady@nanairo:/media/kakurady/Seagate Backup Plus Drive/Backup/nanairo$ ls | grep "duplicity-inc\.20180614"
    duplicity-inc.20180614T072154Z.to.20180615T072208Z.manifest
    duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol1.difftar.gz
    duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol1.difftar.gz
    duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol2.difftar.gz
    kakurady@nanairo:/media/kakurady/Seagate Backup Plus Drive/Backup/nanairo$ ls -i | grep "duplicity-inc\.20180614"
    ls: cannot access 'duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol2.difftar.gz': No such file or directory
    ls: cannot access 'duplicity-inc.20180615T072208Z.to.20180616T072156Z.manifest': No such file or directory
    ls: cannot access 'duplicity-inc.20180615T072208Z.to.20180616T072156Z.vol1.difftar.gz': No such file or directory
    ls: cannot access 'duplicity-inc.20180615T072208Z.to.20180616T072156Z.vol2.difftar.gz': No such file or directory
    ls: cannot access 'duplicity-inc.20180616T072156Z.to.20180617T112221Z.manifest': No such file or directory
    ls: cannot access 'duplicity-inc.20180616T072156Z.to.20180617T112221Z.vol1.difftar.gz': No such file or directory
    ls: cannot access 'duplicity-inc.20180617T112221Z.to.20180618T111612Z.manifest': No such file or directory
    ls: cannot access 'duplicity-inc.20180617T112221Z.to.20180618T111612Z.vol1.difftar.gz': No such file or directory
    ls: cannot access 'duplicity-inc.20180618T111612Z.to.20180619T072208Z.vol1.difftar.gz': No such file or directory
    354308 duplicity-inc.20180614T072154Z.to.20180615T072208Z.manifest
    354305 duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol1.difftar.gz
    354305 duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol1.difftar.gz
        ? duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol2.difftar.gz

As you can see, there are two files with the same file name, and there are directory listings whose corresponding files can't be accessed.

I'm not sure if I should report it to Bug #1652410, or create a new bug. I could try fixing the problem myself, starting with running chkdsk on the volume, but I also feel duplicity could do more to make diagnosing this situation easier, and fixing up the directory that way would mean I can't give more information on this. What should I do next?

Question information

Revision history for this message
edso (ed.so) said :
#1

sounds exactly like Bug #1652410 therefor i linked it. should probably at lest turned into a meaningful error message.

wrt. your problem, i'd suggest
- clone the full drive, to have an untouched copy
- try to repair/chkdsk either one drive
- see if a verify runs through

..ede/duply.net

Revision history for this message
Kenneth Loafman (kenneth-loafman) said :
#2

You will also need to remove the non-encrypted duplicate in the folder to get duplicity to work properly.

Revision history for this message
edso (ed.so) said :
#3

Ken,

looks more like

"
AssertionError: ({1: 'duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol1.difftar.gz'}, 'duplicity-inc.20180614T072154Z.to.20180615T072208Z.vol1.difftar.gz')
"

this unencrypted compressed file is listed _two_ times bey the file system because of the corruption and that is why duplicity chokes.. ede/duply.net

Revision history for this message
Kenneth Loafman (kenneth-loafman) said :
#4

That's corrupted! I've not seen duplicate file names in Linux before this. I hope fsck and friends can help.

Revision history for this message
Kakurady Drakenar (kakurady) said :
#5

It's unusual for sure. The volume being NTFS formatted might have something to do about it.

I don't have enough space to clone the drive, but I'll see if I can get a copy of that particular directory.

Revision history for this message
Kakurady Drakenar (kakurady) said :
#6

I ran chkdsk and it gave up with read errors (I've never seen that happen before). That convinced me the hard drive has failed, so I bought a new one and cloned the contents with ddrescue, which copied everything successfully. Another chkdsk later and my backups are going fine again.

Revision history for this message
edso (ed.so) said :
#7

hey Kakurady,

just want to reemphasize the necessity of a verify(s) if you really want to be sure that your restored chain(s) are truely proper!

..ede/duply.net

Revision history for this message
Kakurady Drakenar (kakurady) said :
#8

I did. Deja-dup doesn't have a UI for it, so I had to reach for the command
line, but the verify finished without any problems. (Wish I could say the
same for the rest of the data on disk. )

On Sun, Jul 29, 2018, 18:03 edso, <email address hidden>
wrote:

> Your question #670964 on Duplicity changed:
> https://answers.launchpad.net/duplicity/+question/670964
>
> edso posted a new comment:
> hey Kakurady,
>
> just want to reemphasize the necessity of a verify(s) if you really want
> to be sure that your restored chain(s) are truely proper!
>
> ..ede/duply.net
>
> --
> You received this question notification because you asked the question.
>