continuous backup solution for freebsd?

[Mel]

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.