Methods for safe hard-linked push backup

[Matt McCutchen]

This is to continue my discussion with Carl from:

https://bugzilla.samba.org/show_bug.cgi?id=5448

on methods for hard-linked push backup where the client can't corrupt
old backups via attribute tweaking.

> > I don't know why one would use "cp -al".  I was thinking that the client would
> > upload to the module and then the post-xfer script would copy the module
> > contents to a backup set elsewhere using --link-dest, just as if the module
> > were the original source.
> 
> Because I think that one "rsync" run and one "cp -al" copy would be faster than
> two "rsync" runs.
> 
> > > The client may not not be able to write to the previous backup but a buggy or
> > > exploited forked daemon could. So I don't think this is a good a solution and
> > > is more complex.
> > 
> > As I said, if you do not want to trust a properly configured daemon with direct
> > access to the previous backup, your alternative is to use a second copy.  If
> > you have a better idea, I would like to hear it (preferably on the list or in a
> > separate enhancement request).
> 
> _This is_ my better idea! Fix rsync to not modify files in place without
> "--inplace" and never use "--link-dest" but use server side scripts intead.

Sorry, I still don't understand what you're proposing.  Could you please
give a more specific description of the sequence of steps performed when
a client pushes a backup?

Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/rsync/attachments/20080508/6c8d804c/attachment.bin