continuous backup solution for FreeBSD

[Bakul Shah]

On Tue, 07 Oct 2008 11:56:09 +0200 =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <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=3D4224&postcount=3D3
> 
> 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)
> 
> 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.

>From their http://forum.r1soft.com/CDP.html page:

    R1Soft's Continuous Data Protection solution is a
==>>near-Continuous Backups system capable of providing <<==
    hundreds of recovery points per day scheduled as little
    as 5 or 10 minutes apart.
	...
    CDP Server works by reading your hard disk volumes at the
    sector level, bypassing the file system for the ultimate
    in performance and recovery.  This disk sector
    synchronization is performed while the server is online
    and provides no interruption to other I/O requests even
    on a busy server.

Clearly "near-Continuous" is *not* the same as "continuous"
but never mind -- truthiness in business is so last century!
But this could be the cause of some confusion.  What they do
is backups, not mirroring.  A remote mirror would essentially
require a continuous "backup" -- every disk write must be
sent right away but in pure mirroring there is no access
previous snapshots.  In a true backup solution you can
restore disk state to some number of previous backup points,
regardless of whether you have *online* access to them.

My guess is they have a driver that keeps track of disk
writes.  Something like set bit N of a bitmap when sector N
is to be written.  Then once every 10 minutes (or whatever
snapshot interval you have selected) a client app scans the
bitmap and sends these sectors to the backup server.

If they did *just* this, there'd be consistency issues --
between the time a snapshot is taken and some sector N is
actually backed up, there may be new writes to N by the OS.
To deal with this, the new write must be delayed until N has
been backed up.  Another alternative is to "slide" forward
the snapshot point.  That is, if the snapshot was taken at
time T1 and the backup finished by T2, and there were
conflicting writes during [T1..T2), backup these writes as
well and slide forward this snapshot time from T1 to T2.
Repeat until there are no conflicting writes.  This latter
method won't block any writes from the OS.

So my guess is they need an interface where they get notified
for every disk write and optionally a way to delay a write.

[To respond to an earlier point raised by others, I believe
 OS X Time Machine does a filesystem level backup and not
 at the disk level.]