Helen Borrie wrote:

>At 01:01 PM 13/09/2004 +0100, you wrote:
>
>
>
>>>Thanks Paul, I have just been searching for information on NBackup and
>>>could noit find anything other that a very brief mention in Niocalys
>>>Japan lectures. Is there a link or more info to NBackup?
>>>
>>>
>>Unfortunately at the moment, you will have to search the firebird
>>development list archives, to get
>>full details of the implementation.
>>
>>
>
>There are no "full details" in the devel archives. Nickolay originally
>thought he had posted some descriptions there but later remembered that
>they had only passed between himself and Sean Leyne in private email.
>
>He did post an outline a few months ago, at Jim's request, which I will
>place up in the devel area of the website shortly. Apart from that, it
>appears we have to wait until Nickolay produces the promised Readme for
>Firebird 2.
>
>
>

This is a very serious problem. The most difficult part of Vulcan is
the cache manager into which NBak has dozens of hooks. I have been
unable to find coherent information on what NBak does, how it does it,
how to use it, or how to test it. I've tried to maintain whatever it
used to do, but frankly, I don't have a clue whether I broke it or not.

My understanding is that NBak exists to allow an ordinary backup utility
to backup an active database. It does by quiesing the primary database
files for duration of backup, redirecting page updates an ad hoc file,
then migrating dirty pages back the primary files following the
conclusion of the backup.

I have a few problems with strategy. I think most shops would be better
off using a "clone database" feature using the shadow creation code.
This gives them a physical backup consistent with the instant the backup
finish (not started). The clone can be used to archival backup, a warm
backup, or both. A side benefit of this strategy is that it doesn't
cost anything if you're not actively using it.

I understand why some shops would prefer NBak and have no problem with
it. I do object to the overhead induced by NBak to users who don't use
it. I don't know the overhead of NBak when it isn't being used, and
this bothers me. I don't think that people who don't plan to use it
should have to pay its overhead. I also don't think other developers
should be forced to cope with it's complexity given that there is no
documentation available on how to use it, what it does, or how it does it.

And, no, NBak doesn't address incremental backup. As far as I know
(which may be wrong), it doesn't address this problem at all.

We will probably continue to have organization desirous of special
features willing to pay full freight for their implementation -- such is
the nature of an open source project. But there really should be
minimal standards for documentation and a decent respect for the well
being of people who can't or don't want to use the feature.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376



[Non-text portions of this message have been removed]