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>
index | next in thread | previous in thread | raw e-mail
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@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=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.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5f67a8c40810070937r5ba89773ncee407ace25fa0dd>