Date: Tue, 07 Oct 2008 09:40:15 -0700 From: Bakul Shah <bakul@bitblocks.com> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> Cc: Volker <volker@vwsoft.com>, Evren Yurtesen <yurtesen@ispro.net>, hackers@freebsd.org Subject: Re: continuous backup solution for FreeBSD Message-ID: <20081007164015.2E3085B29@mail.bitblocks.com> In-Reply-To: Your message of "Tue, 07 Oct 2008 11:56:09 %2B0200." <861vysiv9i.fsf@ds4.des.no> References: <48E9E1BB.6020908@ispro.net> <48EA56BB.6040702@vwsoft.com> <48EA8B3A.3090609@ispro.net> <861vysiv9i.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 07 Oct 2008 11:56:09 +0200 =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> wrote: > Evren Yurtesen <yurtesen@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.]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081007164015.2E3085B29>