Unable to perform a full restore after full backup - "No files found in archive"

Asked by Michael Leinartas

I'm trying to get what I think is a simple backup and restore tested and have been banging my head for hours trying to get the restore piece to work.

I'm using s3 as a store and am backing up a Graphite storage tree and attempting to restore to a second box. My backup looks like this:

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

On restore I'm expecting to just be able to reverse the source and dest parameters but no matter what I do I get "No files found in archive - nothing restored." Here's the restore command:
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.

If I do a list-current-files command instead of restore, I get the full list of backed up files just fine. I've played around with --file-to-restore with relative paths to see if I could at least get a file or two, but get the same error (<file> not found in archive..).

I've tested this with both 6.0.18 and 6.0.19 with the same result and am quite frustrated. This *has* to be something I'm misunderstanding, right? Please help me see the light

Question information

English Edit question
Duplicity Edit question
No assignee Edit question
Solved by:
Michael Leinartas
Last query:
Last reply:
Revision history for this message
edso (ed.so) said :

you should try to circle in the issue.

do a backup a small test set (one folder some small files)

try A:
 same settings but file:// backend to exclude s3 backend as faulty

try B:
 same settings to s3 but allow compression. --no-compression is relatively new and could have a bug.


Revision history for this message
Michael Leinartas (mleinartas) said :

Ah indeed, just did a small test with the file:// backend and had the same issue. Removing the --no-compression flag and it restores just fine.

I'll turn this into a bug.