duplicity-team team mailing list archive

[edso <question677428@xxxxxxxxxxxxxxxxxxxxx>]

Question #677428 on Duplicity changed:
https://answers.launchpad.net/duplicity/+question/677428

    Status: Open => Answered

edso proposed the following answer:
On 22.01.2019 04:57, trevj wrote:
> Question #677428 on Duplicity changed:
> https://answers.launchpad.net/duplicity/+question/677428
>
>     Status: Needs information => Open
>
> trevj gave more information on the question:
>
> On 20/1/19 3:12 am, Kenneth Loafman wrote:
>> Your question #677428 on Duplicity changed:
>> https://answers.launchpad.net/duplicity/+question/677428 Status: Open
>> => Needs information Kenneth Loafman requested more information: Some
>> questions, - Are you running the same user as duplicity when testing
>> gzip? - Is your system up-to-date? - Is /media/trevorj a Linux
>> filesystem? Just shooting in the dark here.
>
>
> On 20/1/19 3:12 am, Kenneth Loafman wrote:
>>
>> Your question #677428 on Duplicity changed:
>> https://answers.launchpad.net/duplicity/+question/677428 Status: Open
>> => Needs information Kenneth Loafman requested more information: Some
>> questions, - Are you running the same user as duplicity when testing
>> gzip? Yes
>
>>
>> - Is your system up-to-date? Yes - Is /media/trevorj a Linux
>> filesystem? Yes
>
>>
>> Just shooting in the dark here.
> Desperate times call for desperate actions:
>
> 1    I copied all the files on backup to a temp directory on my main
> hard disk.
>
> 2    In the temp directory I ran
>
>      for t in duplicity-full.20181208T043900Z.*.difftar.gz; do tar xf
> $t; done
>
> that's just the files in the first back up on the disk (Dec 8th 2018)
>
> 3    That created two directories multivol_snapshot and snapshot.
> snapshot was mainly empty folders but multivol_snapshot held most of my
> data. Unfortunately. the files were in slices numbered 1, 2 3 etc. 
> "cat" worked to join test files together. But I cannot imagine going
> through all the folders "cat" ing all the files.
>
>
> I found this script
>
> |find multivol_snapshot/ -type f -printf '%h\0' | \| |||sort -uz | \|
> |||xargs -0 -n 1 sh -c 'cd "$1" ; cat $(ls | sort -n) > content' spacer |
> It lists the containing directory for every file, removes duplicates
> from the list, then goes to each directory and creates a |content |file
> from the fragments there. (|spacer |is just to make|$1 |work.)
>
>
> But it's still messy.
>

Trevj,

if you can manually extract _all_ files then duplicity should as well.
btw. the "official" disaster recovery document resides here
https://wiki.gnome.org/Apps/DejaDup/Help/Restore/WorstCase#Restoring_by_Hand
but you seem to have found it already.

1.
first of all, can you show a 'df -h' that show there is ample space in your /tmp folder?

2.
run duplicity w/ the backup data copied from another file system (just to rule out read errors)

3.
if the error persists run it w/ max. verbosity (-v9) and '--ignore-errors' and redirect the output to a log file. here's the description from the man page
"
Try to ignore certain errors if they happen. This option is only intended to allow the restoration of a backup in the face of certain problems that would otherwise cause the backup to fail. It is not ever recommended to use this option unless you have a situation where you are trying to restore from backup and it is failing because of an issue which you want duplicity to ignore. Even then, depending on the issue, this option may not have an effect.
Please note that while ignored errors will be logged, there will be no summary at the end of the operation to tell you what was ignored, if anything. If this is used for emergency restoration of data, it is recommended that you run the backup in such a way that you can revisit the backup log (look for lines containing the string IGNORED_ERROR).

If you ever have to use this option for reasons that are not understood or understood but not your own responsibility, please contact duplicity maintainers. The need to use this option under production circumstances would normally be considered a bug.
"

might be that just one volume is corrupted.

4.
possible but unlikely. we had a bug years ago where '--no-compression' didn't work.
  https://serverfault.com/questions/726525/cannot-restore-duplicity-backup
but your case looks different.

..ede/duply.net

-- 
You received this question notification because your team duplicity-team
is an answer contact for Duplicity.