Comment 11 for bug 877631

I can confirm that I'm seeing a similar issue, but this was caused by voluntarily interrupting the backup by using the "continue later" button.

Here is the python backtrace :

Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1359, in <module>
  File "/usr/bin/duplicity", line 1342, in with_tempdir
  File "/usr/bin/duplicity", line 1222, in main
  File "/usr/lib/python2.7/dist-packages/duplicity/", line 684, in set_values
    self.get_backup_chains(partials + backend_filename_list)
  File "/usr/lib/python2.7/dist-packages/duplicity/", line 807, in get_backup_chains
    map(add_to_sets, filename_list)
  File "/usr/lib/python2.7/dist-packages/duplicity/", line 797, in add_to_sets
    if set.add_filename(filename):
  File "/usr/lib/python2.7/dist-packages/duplicity/", line 94, in add_filename
    (self.volume_name_dict, filename)
AssertionError: ({10: u'duplicity-full.20111020T125029Z.vol10.difftar.gpg', 11: u'duplicity-full.20111020T125029Z.vol11.difftar.gpg', 12: u'duplicity-full.20111020T125029Z.vol12.difftar.gpg', 13: u'duplicity-full.20111020T125029Z.vol13.difftar.gpg'}, u'duplicity-full.20111020T125029Z.vol13.difftar.gz')

This is easily reproducible using local file system storage by following those steps :
1) Define the storage as a directory on a local disk
2) Start the backup and provide a password for encryption
3) use 'watch ls /the/backup/directory' to see the backup files appearing. They should end in .gpg
4) Interrupt the backup using "continue later" button
5) Restart the backup
6) Wait for new files to be created in the directory. They will now end in .gz
7) Interrupt the backup again like in #4
8) Restart the backup a third time, it will fail with the backtrace cited above.

It looks like, when interrupted and then restarted, deja-dup restarts _without_ encryption, which explains why the .gz file appears. When looking at the .gz file using a simple 'tar tvzf *.gz', it is indeed not encrypted and completly readable.