Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 8 Oct 2008 20:31:39 +0700
From:      "Outback Dingo" <outbackdingo@gmail.com>
To:        freebsd-hackers@freebsd.org, "Zaphod Beeblebrox" <zbeeble@gmail.com>,  Volker <volker@vwsoft.com>, "Evren Yurtesen" <yurtesen@ispro.net>
Subject:   Re: continuous backup solution for FreeBSD
Message-ID:  <5635aa0d0810080631s41a43444hbfd1eed11f48f6c2@mail.gmail.com>
In-Reply-To: <200810081120.m98BK2fV043545@lurza.secnetix.de>
References:  <86iqs3sdtp.fsf@ds4.des.no> <200810081120.m98BK2fV043545@lurza.secnetix.de>

next in thread | previous in thread | raw e-mail | index | archive | help
one answer...  www.bakbone.com

On Wed, Oct 8, 2008 at 6:20 PM, Oliver Fromme <olli@lurza.secnetix.de>wrote=
:

> Dag-Erling Sm=F8rgrav wrote:
>  > "Zaphod Beeblebrox" <zbeeble@gmail.com> writes:
>  > > "Dag-Erling Sm=F8rgrav" <des@des.no> writes:
>  > > > 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 th=
ey
>  > > need to finish their replication design) and I hinted that the hamme=
r
>  > > approach may be graftable to ZFS.  Both reasonably large effort-wise
>  > > (but probably within the scope of a single developer with sufficient
>  > > time).
>  >
>  > No...  you're so far off the mark it's not even funny, especially when
>  > it's been repeatedly pointed out to you.  This is not a file system,
>  > it's a backup system.  It's not designed to survive a disk crash or an
>  > accidental file deletion, it's designed to survive a direct missile
>  > strike on your colo center.
>  >
>  > To quote Wikipedia, "CDP is a service that captures changes to data to=
 a
>  > separate storage location" - emphasis on "separate".
>
> FWIW, the HAMMER file system _does_ support replication to
> remote targets (thus "separate").  Unfortunately they call
> this feature "mirroring", which is misleading at best.
> It's really rather a replication mechanism, much like the
> binlog of MySQL.  It can be used for various purposes,
> including live mirroring, delayed mirroring, archiving,
> backup and point-in-time recovery.
>
> Well, of course, all of that doesn't help us at all because
> HAMMER doesn't exist on FreeBSD.
>
> However, ZFS does exist on FreeBSD, and I think it wouldn't
> be impossible to add similar features to ZFS.
>
> Another possibility would be to extend gjournal by adding
> time stamps to journal transactions and a possibility to
> feed the journal to a pipe, socket or whatever.  And of
> course a client-side implementation that does something
> useful with the journal stream.  This might even be a good
> SoC project.
>
> Best regards
>   Oliver
>
> --
> Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
> Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch=E4ftsfuehrun=
g:
> secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M=FC=
n-
> chen, HRB 125758,  Gesch=E4ftsf=FChrer: Maik Bachmann, Olaf Erb, Ralf Geb=
hart
>
> FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
>
> "File names are infinite in length, where infinity is set to 255
> characters."
>        -- Peter Collinson, "The Unix File System"
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org=
"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5635aa0d0810080631s41a43444hbfd1eed11f48f6c2>