Date: Mon, 6 Oct 2008 20:00:26 +0200 From: Mel <fbsd.questions@rachie.is-a-geek.net> To: freebsd-questions@freebsd.org Cc: Jeremy Chadwick <koitsu@freebsd.org>, Evren Yurtesen <yurtesen@ispro.net.tr> Subject: Re: continuous backup solution for freebsd? Message-ID: <200810062000.26501.fbsd.questions@rachie.is-a-geek.net> In-Reply-To: <48EA45D2.70502@ispro.net.tr> References: <48E9E146.9040308@ispro.net.tr> <20081006152430.GA23608@icarus.home.lan> <48EA45D2.70502@ispro.net.tr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 06 October 2008 19:07:30 Evren Yurtesen wrote:
> First of all, I am not an r1soft advocate, but they seem to be making a
> software which is popular and affordable and interested in giving
> FreeBSD support... r1soft is not the issue here, the problem is that
> there is no way to do near continuous backups on FreeBSD servers.
>
> Jeremy Chadwick wrote:
> > That said, I'd like to know exactly how "low-level" R1Soft's software
> > truly is. dump(8), AFAIK, is "block-level" -- and that's a userland
> > program. Does R1Soft's software *truly* require kernel-land? I have
> > more to say on that issue (not against R1Soft, but speaking with regards
> > to the current state of FreeBSD's developer count) if it truly does.
>
> I think you might not have understood the concept of near continuous
> backups. The R1Soft backup monitors the filesystem operations
So does ggate. But read on.
> So it has to know what is written and when to be able
> to back it up. The dump command simply reads/writes the blocks. It cant
> only read changed blocks. It has to read the whole thing (inefficient).
But Jeremy's point being, dump(8) does not need /dev/special_device to
read/write at block level.
> >> Continuous backups as well as bare-metal-restore seem to be a key
> >> feature for many hosters.
> >
> > Regarding continuous backups: the GEOM gate class could be used for
> > this. Meaning, I think it could be used as an alternate to R1Soft's
> > software.
>
> The GEOM gate allows mirroring to a remote machine, am I not right? That
> would be more or less same as same as using RAID. The continuous backup
> (or near continuous) means that you can restore the filesystem to a
> point like 15 minutes ago, or 1 hour ago. Besides, I hear geom might
> have network delay problems and it is much more complicated setup to
> build two machines in mirror configuration just for backup purposes as
> well as you cant restore to a point in the past.
I think once you and R1soft step out of the "I need a block level device"
paradigm, you will see that modifying ggate with a "copy and fall through"
mode, as well as a mechanism to block writes to the local provider, when the
remote provider wants to write is the best solution all around and your best
bet to get support for it.
Right now, ggate does "intercept and redirect", but the concept of copy and
fall through is not that far away. Bringing the R1soft devs in contact with
the FreeBSD geom list and having them browse the sys/geom/ggate sources to
see how trivial it is to hook into filesystem operations would be the course
of action I'd recommend.
--
Mel
Problem with today's modular software: they start with the modules
and never get to the software part.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200810062000.26501.fbsd.questions>