Duplicity fails to restore with --no-compression enabled: "No files found in archive"

[Michael Leinartas]

I'm unable to complete a restore using the --no-compression option in 0.6.18 and 0.6.19:

duplicity full /opt/graphite/storage s3+http://graphite_backup/graphite1 --no-encryption --no-compression

The backup completes successfully:
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: none
--------------[ Backup Statistics ]--------------
StartTime 1343269272.86 (Wed Jul 25 21:21:12 2012)
EndTime 1343278162.25 (Wed Jul 25 23:49:22 2012)
ElapsedTime 8889.40 (2 hours 28 minutes 9.40 seconds)
SourceFiles 31128
SourceFileSize 173292409215 (161 GB)
NewFiles 31128
NewFileSize 173292409215 (161 GB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 31128
RawDeltaSize 173291150126 (161 GB)
TotalDestinationSizeChange 4687715680 (4.37 GB)
Errors 0
-------------------------------------------------

And the restore:

duplicity restore s3+http://graphite_backup/graphite1 /opt/graphite/storage/ --no-encryption --no-compression

and result with -vinfo:
Using archive dir: /root/.cache/duplicity/9042287f5ee10d690f1bc95d44d10cb6
Using backup name: 9042287f5ee10d690f1bc95d44d10cb6
Import of duplicity.backends.giobackend Succeeded
Import of duplicity.backends.u1backend Succeeded
Import of duplicity.backends.botobackend Succeeded
Import of duplicity.backends.localbackend Succeeded
Import of duplicity.backends.webdavbackend Succeeded
Import of duplicity.backends.ftpbackend Succeeded
Import of duplicity.backends.imapbackend Succeeded
Import of duplicity.backends.rsyncbackend Succeeded
Import of duplicity.backends.hsibackend Succeeded
Import of duplicity.backends.tahoebackend Succeeded
Import of duplicity.backends.ftpsbackend Succeeded
Import of duplicity.backends.sshbackend Failed: No module named paramiko
Import of duplicity.backends.cloudfilesbackend Succeeded
Import of duplicity.backends.gdocsbackend Succeeded
Main action: restore
================================================================================
duplicity 0.6.18 (February 29, 2012)
Args: /usr/bin/duplicity restore s3+http://graphite_backup/graphite1 /opt/graphite/storage/ --no-encryption --no-compression -vinfo
Linux graphite1 3.2.22-35.60.amzn1.x86_64 #1 SMP Thu Jul 5 14:07:24 UTC 2012 x86_64 x86_64
/usr/bin/python 2.6.8 (unknown, Jun 29 2012, 06:50:56)
[GCC 4.4.6 20110731 (Red Hat 4.4.6-3)]
================================================================================
Using temporary directory /tmp/duplicity-H5q0ZU-tempdir
Temp has 4699389952 available, backup will use approx 34078720.
Listing s3+http://graphite_backup/graphite1/
Local and Remote metadata are synchronized, no sync needed.
Listing s3+http://graphite_backup/graphite1/
Last full backup date: Wed Jul 25 21:21:12 2012
Downloading s3+http://graphite_backup/graphite1/duplicity-full.20120726T022112Z.vol1.difftar
Deleting /tmp/duplicity-H5q0ZU-tempdir/mktemp-WYjACi-2
Processed volume 1 of 179
Downloading s3+http://graphite_backup/graphite1/duplicity-full.20120726T022112Z.vol2.difftar
No files found in archive - nothing restored.

I'm able to reproduce this with the file:// backend as well. The same backup/restore procedure performed without the --no-compression option works fine

[Hector (hectcastro)]

I'm seeing the same behavior with 0.6.20.

[Dalton (dboutte)]

I have also seen this behavior on 0.6.20 with a backup to NFS share mounted on the same server. I am able to list the contents of the backups, but any attempt to restore single files, directories, or entire backups fail.

[Cory Coager (ccoager)]

Same issue with 0.6.21 also. I believe I know what the problem is. The backup with --no-compression is actually compressed even though the file extension doesn't reflect it. If you run a 'file' against the backup set, it says they are gzipped max compression.

If someone fixes the backup, it may fix the restore issue as well.