continuous backup solution for FreeBSD

[Zaphod Beeblebrox]

I wanted to respond to DES' email separately --- because he's right.

On Tue, Oct 7, 2008 at 5:56 AM, Dag-Erling Smørgrav <des at des.no> wrote:

> Evren Yurtesen <yurtesen at ispro.net> writes:
> > They actually do not think that it is an easy job to adapt their
> > software to support FreeBSD even. See this post:
> > http://forum.r1soft.com/showpost.php?p=4224&postcount=3
>
> All this shows is that they don't know anything about FreeBSD at all
> (plus they need a refresher course in OS design; Linux is also a
> monolithic kernel)


A very succinct way of making a similar poing :)


> What really annoys me with this thread is that nobody has provided any
> information at all that would allow someone to understand what needs to
> be done and estimate how hard it would be.


Well... I hinted that a hammer port would be sufficient (although they need
to finish their replication design) and I hinted that the hammer approach
may be graftable to ZFS.  Both reasonably large effort-wise (but probably
within the scope of a single developer with sufficient time).

My primary concern about hammer is it's floating history stuff.  It seems to
me that legal compliance might have some things to say about it.  It seems
(from the document --- I havn't read the source) that the tunability of the
"real deletion" of data are "goals" not absolutes.  This is a concern.

But as filesystems _are_ databases and as they grow database technology
(like transactions and B+tree indexes), we should look to database systems
for some of the solutions (ie: problems already solved).  Replication
replacing "mirroring" is just one of them.

Doing this at the block level was suggested by someone earlier (BTW).
Suggesting that a geom node could store a bit or two per bock (marking it
"dirty" prehaps) and shipping off the blocks.  That only solves the
replication.  You'd need something like a transaction ID per block stored on
the backup server to enable time travel.  Probably want a B+tree index there
too.  If you're not careful, you might find implementing the filesystem
solution much easier.  You could, however, implement this with hooks for
gjournal --- such that the filesystems you backup are always sane.