Duplicity

restore fails for file listed in list-current-files?

Asked by Ted

I'm trying to restore a file that appears in the list when I run list-collection-status, but every time I attempt to restore it, I get the message:

<file> not found in archive, no files restored.

Duplicity was crashing on .21, so I upgraded to the last stable version in the PPA, and now I get this message:

python2.7: ERROR: (rs_file_copy_cb) unexpected eof on fd94
python2.7: ERROR: (rs_job_complete) patch job failed: unexpected end of input
Error 'librsync error 103 while in patch cycle' patching .

Is this the cause for the file being unrestorable? Is there any way to mitigate this? I upgraded to trunk after reading the bug report related to this error message, but that bug report said the data loss error was fixed in trunk.

Is it possible that duplicity is erroneously reporting the file's presence in the archive? The file is a gpg public keyring, and it's continually refreshed by parcimonie, so it's possible that there's no good backup if the file was changed while a backup was running, correct?

Question information

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

On 26.03.2014 16:16, Ted wrote:
> New question #246088 on Duplicity:
> https://answers.launchpad.net/duplicity/+question/246088
>
> I'm trying to restore a file that appears in the list when I run list-collection-status, but every time I attempt to restore it, I get the message:
>
> <file> not found in archive, no files restored.
>
> Duplicity was crashing on .21, so I upgraded to the last stable version in the PPA, and now I get this message:
>
>
> python2.7: ERROR: (rs_file_copy_cb) unexpected eof on fd94
> python2.7: ERROR: (rs_job_complete) patch job failed: unexpected end of input
> Error 'librsync error 103 while in patch cycle' patching .
>
> Is this the cause for the file being unrestorable? Is there any way to mitigate this? I upgraded to trunk after reading the bug report related to this error message, but that bug report said the data loss error was fixed in trunk.
>
> Is it possible that duplicity is erroneously reporting the file's presence in the archive? The file is a gpg public keyring, and it's continually refreshed by parcimonie, so it's possible that there's no good backup if the file was changed while a backup was running, correct?
>

try to restore an older state (backup).

the initial error was fixed yes, but erroneous backups like your's will stay of cause as they are.

..ede/duply.net

Revision history for this message
Ted (tedks) said : 		#2

How should I do this? Passing --time yyyy-mm-dd on the command line causes the same failure.

Revision history for this message
Ted (tedks) said : 		#3

I should add -- passing the earliest backup date for that chain on the command line causes that failure.

Thank you for the prompt help as well!

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

On 26.03.2014 21:16, Ted wrote:
> Question #246088 on Duplicity changed:
> https://answers.launchpad.net/duplicity/+question/246088
>
> Ted gave more information on the question:
> I should add -- passing the earliest backup date for that chain on the
> command line causes that failure.
>
> Thank you for the prompt help as well!
>

it shouldn't .. patching is only done in case of restoring incremental backups afaik.
Ken, Mike: right?

run the restore with max. verbosity '-v9', check & obfuscate private strings in the terminal output and pastebin or upload it to a free filehoster and post the link here.
this way i can see what's going on.

..ede/duply.net

Revision history for this message
Michael Terry (mterry) said : 		#5

What duplicity calls "patching" still happens on restoring a full backup. (It still patches chunks of large files together etc.)

Can you help with this problem?

Provide an answer of your own, or ask Ted for more information if necessary.

To post a message you must log in.