Re: Recommended Linux Backup correction
s/would fault/would not fault/
On 20091030_192015, Paul E Condon wrote:
> On 20091030_010001, lrhorer wrote:
> > Alex Samad wrote:
> >
> > > On Fri, Oct 30, 2009 at 01:37:51AM +0000, Paulo A.B. wrote:
> > >> It's based on Rsync, but has a different flavor.
> > >>
> > >> Try ribs <http://www.rustyparts.com/ribs.php>.
> > >
> > > Or have a look at rdiff-backup
> > This doesn't sound to me as if it fits the bill, either. It sounds
> > closer than rsync, but I didn't read anything about changing drives or
> > maintaining an index. Rather, it sounds to me as if it merely creates
> > directories with diff files on them on a single remote target. This
> > strategy won't work when one's targets are much smaller than the array
> > being backed up. I haven't seen any 20 TB drives for sale, so this
> > backup and restore has to span multiple target drives, all but one of
> > which are offline at any given time.
> >
>
> I can't remember the details of your original post, but I remember
> reading it. Given your responses to several suggestions, I suggest
> that you should reconsider rsync, but not in the way that you seem to
> have been doing. I use rsync as for the core functionality of a backup
> system that I have implemented with a few dozens lines of bash
> scripts. My backup system is very compact and does exactly what I want
> for a cluster of four hosts. I didn't offer it, because it doesn't do
> what you want, and, frankly, I remembered your specifications as being
> poorly thought out.
>
> I think there are a lot of different ideas as to what a backup system
> should do. It was a useful learning experience for me to write my own.
> My reading of your responses is that it might also be a useful
> learning experience for you to write your own. If you embark on such a
> project, I think you should not start from scratch with a C++
> compiler, only. Rather you should take rsync as a functioning,
> debugged module that you can incorporate into your system to handle
> the great bulk of the low level detail work. But I would fault rdiff or
> tar, or some other well known software as a starting point.
>
> HTH
> --
> Paul E Condon
> pecondon@mesanetworks.net
>
>
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
Paul E Condon
pecondon@mesanetworks.net
Reply to: