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

[Matthew Twomey]

Ken,

Yes this is exactly the case. I'm using openssh (scp/sftp) on both the
client and the remote host. In my experience, openssh (and possibly
ssh2) always leaves a truncated file with the actual destination
filename (not a temporary filename) if the transfer is interrupted.

I'm not sure what the correct solutions is, but people may believe their
resumed backups are complete when in reality they may be unable to fully
restore from them.

I'm digging around a bit in the openssh man pages but I don't see an
option for using temporary filenames (which I assume would solve the
problem). SFTP does support renaming of remote filenames, so it could be
done within the Duplicity code (e.g. upload each volume to a temp
filename and then rename upon completion), however I won't presume
that's a direction you'd want to take.

Thanks,

-Matt


On Thu, 2009-11-26 at 05:19 -0600, Kenneth Loafman wrote:
> 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
> > 
> 
> 
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/duplicity-talk