Re: [Duplicity-talk] Issues with restoring restarted backups

[Kenneth Loafman]

The presence of an incomplete remote volume could cause confusion to
duplicity.  Most protocols do not keep incomplete transfers, or keep
them with a distinct file name that duplicity would not recognize.  Is
that the case here?  Is duplicity seeing the partial volume as one of
its own?  That would explain the behavior you are seeing.

...Ken

Matthew Twomey wrote:
> Ok - after a little more testing it appears that when a full backup is
> disrupted in the middle of transferring and then restarted - duplicity
> starts on the next volume number *without* finishing the files that were
> supposed to be in the previous volume. 
> 
> That is to say:
> 
> *Normal non-disrupted backup*
> 
> Volume 1 = files 01 - 10
> Volume 2 = files 11 - 20
> Volume 3 = files 21 - 30
> 
> *Backup which was disrupted during network transfer of Volume 2 and then
> restarted (Restarting after volume 2" was the message in the log)*
> 
> Volume 1 = files 01 - 10
> Volume 2 = files 11 - 13 (or wherever it was disrupted)
> Volume 3 = files 21 - 30
> 
> I've noticed that after a disruption, if I go in and delete the last
> volume file (the one which was disrupted) on the remote location and
> then restart the backup - it picks up with that volume, producing a
> usable backup.
> 
> Thought on this?
> 
> Thanks,
> 
> -Matt
> 
> On Wed, 2009-11-25 at 15:43 -0600, Matthew Twomey wrote:
>> It does sound similar yes, I had seen that bug. I've tried several
>> controlled experiments with restarted backups now and in no case can I
>> get them to restore properly. I'll dig into the manifest files a little
>> bit to see if I can see anything there.
>>
>> Thanks,
>>
>> -Matt
> 
> 
> 
> 
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/duplicity-talk
>

signature.asc
Description: OpenPGP digital signature