Content-Type: multipart/signed; micalg=pgp-sha1;

Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF=EF=BB=BFThis 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 clien=

t would
> > upload to the module and then the post-xfer script would copy the modul=

> > contents to a backup set elsewhere using --link-dest, just as if the mo=

> > were the original source.

> Because I think that one "rsync" run and one "cp -al" copy would be faste=

r 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 solu=

tion and
> > > is more complex.

> >=20
> > As I said, if you do not want to trust a properly configured daemon wit=

h 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 intea=


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?


Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

Version: GnuPG v1.4.7 (GNU/Linux)



Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html