rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] rdiff-backup vs. rsync(d) at the remote end


From: devzero
Subject: Re: [rdiff-backup-users] rdiff-backup vs. rsync(d) at the remote end
Date: Fri, 30 Jun 2006 23:30:32 +0200

hey - nobody finding this useful, too ?

i think this idea is something "new" - at least i didn`t find any reference on 
this list about someone doing it this way!

:)

roland


> -----Ursprüngliche Nachricht-----
> Von: address@hidden
> Gesendet: 24.06.06 22:10:35
> An: address@hidden
> CC: address@hidden,
> Betreff: Re: [rdiff-backup-users] rdiff-backup vs. rsync(d) at the remote end


> Hello again, 
> 
> i have probably found an intersting solution for doing rdiff-backups via 
> rsync with local mirror and without needing twice the space as usual.
> 
> i`d like to discuss this solution and getting some feedback. 
> 
> if it`s a good and reliable solution, maybe it`s useful for others, too.
> 
> the trick for saving the diskspace for rsync mirror is using the rsync option 
> "--link-dest",whis is set to the rdiff-backup repositroy. --link-dest means, 
> that rsync can store data space-efficiently by creating hardlinks. hardlinks 
> are created whenever the rsynced file already is at another destination. so 
> if the rdiff-backup directory contains exactly the same file which is being 
> rsynced, then rsync can detect this and create a hardlink instead. files 
> which changed or which are new are just rsynced as usual. for me this saves 
> most of the space the rsync directory normally needs.
> 
> 
> this is my current backup script (i simplified it just to show the essential) 
> :
> 
> ------------
> cd /backup
> 
> rm -rf hostA_rsync
> 
> mkdir hostA_rsync
> 
> rsync -az -H --link-dest=./hostA_rdiff  hostA:/ ./hostA_rsync
> 
> rdiff-backup --no-hard-links ./hostA_rsync ./hostA_rdiff
> ------------
> 
> 
> for my curiousity i needed to add --no-hard-links to rdiff-backup, otherwise 
> rdiff-backup behaved strange with this.
> 
> see the difference:
> 
> before:
> 
> du -s -k hostA*
> 
> 30014511  hostA_rdiff
> 24219719  hostA_rsync
> 
> after (made a second hostA_rdiff for testing - this is why it is smaller):
> 
> du -s -k hostA*
> 
> 24243554  hostA_rdiff
> 219719      hostA_rsync
> 
> 
> since i just have found this solution and didnŽt test in depth (maybe there 
> are problems?) , i`d glad to hear some comments about this.
> 
> regards
> roland
> 
> 
> 
> ------------------------------------------
> 
> 
>         Betreff:       Re: [rdiff-backup-users] rdiff-backup vs. rsync(d) at 
> the remote end
>       Von:     "roland" <address@hidden>  ins Adressbuch
>       An:      "Gerard van Dijnsen" <address@hidden>
>       Cc:      address@hidden
>       Datum:   24.06.06 16:03:31
> 
> 
> hi!
> 
> mhhh - still wondering here and spending thoughts over and over again...
> 
> > As far as I can see, there are a lot of reasons for using a server on
> > the receiving side.
> 
> yes - but why does this need rdiff-backup as server? rsync can run as a
> server, too.
> 
> >One of them is storage of metadata, the most
> > important however is keeping a history using 'reverse' diffs.
> 
> mhh - but metadata is only stored on the backup-machine within the
> rdiff-backup repository.
> nothing on the client side. rdiff-backup just pulls the data and metadata
> from the backup client.
> whatever data/metadata rdiff-backup needs on the receiving side for storing
> this - an rsync
> daemon on the remote site should be able to "deliver" this (imho - in
> theory).
> 
> does somebody have a clue what's different "on the wire" between rsync and
> rdiff-backup ?
> 
> itŽs gets a bigger problem for me, because i cannot install rdiff-backup on
> many remote machines and
> so i need to create a local copy via rsync and rdiff-backup'ing it
> afterwards.
> this doubles storage and isn`t very optimal.
> 
> ok, i know that i can convert a rsync mirror with "-b --force" into a
> rdiff-backup repository - but
> i`m not allowed to rsync afterwards.
> 
> >Actually, take a look at Duplicity and you will see a nice example of what
> >you are looking for.
> thanks. maybe , fusessh is also worth looking at....
> 
> regards
> roland
> 
> 
> ----- Original Message -----
> From: "Gerard van Dijnsen" <address@hidden>
> Cc: <address@hidden>
> Sent: Saturday, May 27, 2006 6:45 PM
> Subject: Re: [rdiff-backup-users] rdiff-backup vs. rsync(d) at the remote
> end
> 
> 
> > As far as I can see, there are a lot of reasons for using a server on
> > the receiving side. One of them is storage of metadata, the most
> > important however is keeping a history using 'reverse' diffs. This might
> > be implemented differently using rsync perhaps, I am not sure. Actually,
> > take a look at Duplicity and you will see a nice example of what you are
> > looking for. You only need ssh on the receiving side for this to work...
> >
> > Gerard
> >
> > On Sat, 2006-05-27 at 13:24 +0200, roland wrote:
> >> Hello !
> >>
> >> while thinking about (and digging into) how rdiff-backup is working
> >> internally, i wonder a little bit about rdiff-backup being needed at the
> >> remote end.
> >>
> >> wouldn`t rsync(d) be sufficient for this (in theory) ?
> >>
> >> i`m asking this, because it's a lot easier and more "lightweight" to
> >> install
> >> rsync(d) on the clients you need to backup.
> >>
> >> regarding "what's being transferred over the wire or being done at the
> >> remote end" - can someone explain the difference between rdiff-backup and
> >> rsync and give a comment about possible replacement of rdiff-backup with
> >> rsync(d) ?
> >>
> >> regards
> >> roland
> >>
> >> ps:
> >> actually, i even have one machine i need to rsync first to a local
> >> directory
> >> and rdiff-backup from that, because i'm not allowed to install python on
> >> that machine. so this takes twice the space on my backup machine.
> >>
> >>
> 
> 


__________________________________________________________________________
Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!        
        
Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131





reply via email to

[Prev in Thread] Current Thread [Next in Thread]