Date: Tue, 7 Oct 2008 12:37:37 -0400 From: "Zaphod Beeblebrox" <zbeeble@gmail.com> To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" <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: <5f67a8c40810070937r5ba89773ncee407ace25fa0dd@mail.gmail.com> In-Reply-To: <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
I wanted to respond to DES' email separately --- because he's right. On Tue, Oct 7, 2008 at 5:56 AM, Dag-Erling Sm=F8rgrav <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) 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 t= o 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 o= n the backup server to enable time travel. Probably want a B+tree index ther= e 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5f67a8c40810070937r5ba89773ncee407ace25fa0dd>