Duplicity

file not found in archive from full backup

Asked by ubuaverill

I am attempting to restore a single file from a full backup done with Duplicity 6.08b to an external hard drive. My computer runs Ubuntu 10.04 (lucid lynx) 64 bit. There are 429 30MB volumes. On the advice of a mail list I increased the number of open files ( ulimit )to 4096 files from 1024.
This did not solve the problem. I have tried unsuccessfully to restore other files which are seen in the list produced by 'list current files' option.
I don't fully understand the log file (verbose = 9) - all 'seems' OK except for this message:
DEBUG 1
. File duplicity-full.20110120T092445Z.vol133.difftar.gpg is not part of a known set; creating new set followed by

many messages like so:
DEBUG 1
. File duplicity-full.20110120T092445Z.vol213.difftar.gpg is part of known set

DEBUG 1
. File duplicity-full.20110120T092445Z.vol423.difftar.gpg is part of known set ... and so on

Then: ERROR 19
. MyDir/myfileDec.pdf not found in archive, no files restored.

My preference is to do a full restore, but I will settle for 1 file at a time. If someone wants to see the log file I can send it. I just need to know where.

I sure hope someone can help me resolve this. Thanks --brian

Question information

Language:
English Edit question
Status:
Solved
For:
Duplicity Edit question
Assignee:
No assignee Edit question
Solved by:
ubuaverill
Solved:
Last query:
Last reply:
Revision history for this message
edso (ed.so) said : 		#1

please create a bug report from this question and attach

1. the complete debug output, obfuscate private data in there
2. a list-current-files run output

ede/duply.net

Revision history for this message
ubuaverill (brian-averill) said : 		#2

On 10/09/2011 02:35 PM, edso wrote:
> Your question #173724 on Duplicity changed:
> https://answers.launchpad.net/duplicity/+question/173724
>
> Status: Open => Needs information
>
> edso requested more information:
> please create a bug report from this question and attach
>
> 1. the complete debug output, obfuscate private data in there
> 2. a list-current-files run output
>
> ede/duply.net
>

Please see errlog file and FileList file in attached tar.gz as requested
above.

Thank you kindly for looking into this restore problem.

--brian

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

>
> Please see errlog file and FileList file in attached tar.gz as requested
> above.
>

where exactly did you attach it to?

ede/duply.net

Revision history for this message
ubuaverill (brian-averill) said : 		#4

On 10/09/2011 10:45 PM, edso wrote:
> Your question #173724 on Duplicity changed:
> https://answers.launchpad.net/duplicity/+question/173724
>
> Status: Open => Answered
>
> edso proposed the following answer:
>> Please see errlog file and FileList file in attached tar.gz as requested
>> above.
>>
> where exactly did you attach it to?
>
> ede/duply.net
>
> I thought I attached it to the reply email. I will attach it again to this email. If that doesn't work is there another way to send it to you? The file is named duplicityErr.tar.gz. My Thunderbird email client shows that the file is attached so hopefully delivery will succeed. --brian

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

>>>
>> where exactly did you attach it to?
>>
>> ede/duply.net
>>
>> I thought I attached it to the reply email. I will attach it again to this email. If that doesn't work is there another way to send it to you? The file is named duplicityErr.tar.gz. My Thunderbird email client shows that the file is attached so hopefully delivery will succeed. --brian
>

The list might filter big attachements.
Please open a bug ticket. You'll find it on the launchpad answer page in the bottom where you can write a comment. Unfortunately you _can_ attach files to bugs only, not to questio0ns on launchpad. Please do not compress the files when attaching them there.

ede/duply.net

Revision history for this message
ubuaverill (brian-averill) said : 		#6

Solution to problem was to use, for example, the full path in "file-to-restore": /home/meUser/mydata.dat rather than just mydata.dat.

The documentation is somewhat unclear, at least to me, about the how much of the path to use for file restoring.

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

On 23.10.2011 15:10, ubuaverill wrote:
> Question #173724 on Duplicity changed:
> https://answers.launchpad.net/duplicity/+question/173724
>
> Status: Answered => Solved
>
> ubuaverill confirmed that the question is solved:
> Solution to problem was to use, for example, the full path in "file-to-
> restore": /home/meUser/mydata.dat rather than just mydata.dat.
>
> The documentation is somewhat unclear, at least to me, about the how
> much of the path to use for file restoring.
>

could you point to the unclear docs for improvement?

to be clear, the relative path of the file to your backup src root is needed. how else would you identify a file in the backup?

..ede/duply.net

Revision history for this message
ubuaverill (brian-averill) said : 		#8

On 10/23/2011 05:15 PM, edso wrote:
> Your question #173724 on Duplicity changed:
> https://answers.launchpad.net/duplicity/+question/173724
>
> edso posted a new comment:
> On 23.10.2011 15:10, ubuaverill wrote:
>> Question #173724 on Duplicity changed:
>> https://answers.launchpad.net/duplicity/+question/173724
>>
>> Status: Answered => Solved
>>
>> ubuaverill confirmed that the question is solved:
>> Solution to problem was to use, for example, the full path in "file-to-
>> restore": /home/meUser/mydata.dat rather than just mydata.dat.
>>
>> The documentation is somewhat unclear, at least to me, about the how
>> much of the path to use for file restoring.
>>
> could you point to the unclear docs for improvement?
>
> to be clear, the relative path of the file to your backup src root is
> needed. how else would you identify a file in the backup?
>
> ..ede/duply.net
>
 Hi,

Thank you again for your help to solve my restore problem. Now that I
know what 'path' means I feel somewhat stupid. However, below is from
the duplicity man page:

--file-to-restore path
               This option may be given in restore mode, causing only
_path_ to be
               restored instead of the entire contents of the backup
archive.
_path_ should be given relative to the root of the directory backed
               up.

My interpretation of this was this: since I backed my home directory (eg
/home/myHomeDir) it seemed to me that path meant any directories under
/home/MyHomeDir (eg .thunderbird, myData, etc.) would all that is
necessary with the 'restore file' option because the top of the 'current
file listing' begins with /home/myHomeDir, hence assuming duplicity
would 'know' where to start. I see know that was a foolish assumption.

Generally the duplicity man pages are understandable; it does help
greatly novice or advanced beginners of Linux to have examples to work
from, at least for the more commonly used functions.

Regards --brian

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

On 27.10.2011 13:41, ubuaverill wrote:
> Question #173724 on Duplicity changed:
> https://answers.launchpad.net/duplicity/+question/173724
>
> ubuaverill posted a new comment:
> On 10/23/2011 05:15 PM, edso wrote:
>> Your question #173724 on Duplicity changed:
>> https://answers.launchpad.net/duplicity/+question/173724
>>
>> edso posted a new comment:
>> On 23.10.2011 15:10, ubuaverill wrote:
>>> Question #173724 on Duplicity changed:
>>> https://answers.launchpad.net/duplicity/+question/173724
>>>
>>> Status: Answered => Solved
>>>
>>> ubuaverill confirmed that the question is solved:
>>> Solution to problem was to use, for example, the full path in "file-to-
>>> restore": /home/meUser/mydata.dat rather than just mydata.dat.
>>>
>>> The documentation is somewhat unclear, at least to me, about the how
>>> much of the path to use for file restoring.
>>>
>> could you point to the unclear docs for improvement?
>>
>> to be clear, the relative path of the file to your backup src root is
>> needed. how else would you identify a file in the backup?
>>
>> ..ede/duply.net
>>
> Hi,
>
> Thank you again for your help to solve my restore problem. Now that I
> know what 'path' means I feel somewhat stupid.

your welcome

>However, below is from
> the duplicity man page:
>
> --file-to-restore path
> This option may be given in restore mode, causing only
> _path_ to be
> restored instead of the entire contents of the backup
> archive.
> _path_ should be given relative to the root of the directory backed
> up.
>
> My interpretation of this was this: since I backed my home directory (eg
> /home/myHomeDir) it seemed to me that path meant any directories under
> /home/MyHomeDir (eg .thunderbird, myData, etc.) would all that is
> necessary with the 'restore file' option because the top of the 'current
> file listing' begins with /home/myHomeDir, hence assuming duplicity
> would 'know' where to start. I see know that was a foolish assumption.

what do you mean, could you give an example on how you thought it works?

>
> Generally the duplicity man pages are understandable; it does help
> greatly novice or advanced beginners of Linux to have examples to work
> from, at least for the more commonly used functions.
>

i will add a note that the path is usually the relative path (it has no slash in the beginning) listed when doing a list-current-files. btw: you can deliver a time to list-current-files to search for older backups of the files.

..ede