Methods for safe hard-linked push backup
matt at mattmccutchen.net
Fri May 9 01:42:28 GMT 2008
This is to continue my discussion with Carl from:
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/rsync/attachments/20080508/6c8d804c/attachment.bin
More information about the rsync