Leyne, Sean wrote:

>There are plenty of examples of DBAs performing direct system tables
>updates, which are not detected during backup and result in a backup
>which can't be restored, even with constraints disabled.
>
>

I've been arguing that we should deprecate direct update of system
tables for well over a year now. NBak isn't really a solution, however,
since there is no way to move these to a new ODS version.

>So, you're left with a backup, which you thought was fine (no errors
>were generated during the backup) but isn't worth the cost of the disk
>space it occupies. There is a REAL CRIME!!
>
>

This requires a system solution. Neither GBak nor NBak addresses how
unconventional system table updates are propogated.

>Further, there is a list of a half-dozen cases in the SF tracker where
>simple schema definitions result in databases which can't be restored by
>GBAK (I am working on fixes for a number of them)!
>
>

These are bugs that are correctly being addressed. Surely you aren't
arguing any piece of software with a less than perfect implementation
should be dropped.

>
>
>Again not true!
>
>It requires a **compatible environment**.
>
>A NBak file produced on Intel 32 bit Linux would work directly and be
>restorable on a 32 bit Windows platform, just like you can you can move
>a database file between those platforms today.
>
>

It won't go to an incompatible ODS version. Firebird has had to live
within the constraints of upwards compatible only changes because
Borland screwed up the architecture. Vulcan is perfectly happy to
support any number of incompatible ODS versions seamlessly (I hate that
word). NBak can't (and shouldn't) span ODS versions.

>That is what NBackup does! A Level 0 NBackup is a clone/copy of the
>database file.
>
>

Good. Since I was never able to get any documentation on NBak, I've
always been a little fuzzy on what it did. I presume the Firebid 2
release notes have a full set of docs?

>
>Do you want a logical backup which can be moved (better word = migrated)
>to another platform as your backup?
>
>Or, a clone/image backup which requires an appropriate environment to
>accessible?
>
>

Both.

>P.S. Jim you seem to have your blinders on when it comes to NBackup.
>You haven't really bothered to investigate what it does or how it works,
>but are prepared to pass judgment on it.
>
>

Sean, my friend, I asked for NBak documentation any number of times
during Vulcan development only to be told "look it up in the archive".
I did my best to convert it to Vulcan without knowing what it did or how
it did it. I haven't passed judgement against it because I'm still
don't know what it does or how it does it. But in the best of worlds, a
physical backup has limitations.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376