Jim,

> Gbak is a logical database backup ... and is incapable of
> propogating database corruption.

...

> A GBak can always be restored
> (though you may have to turn off constraints).

Not true!

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.

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!!

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)!

> NBak, at best, requires the original environment

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.

> Personally, I'd also like a simple database clone operation to make a
> faithful image copy while the database is running.

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


But a clone would have the exact issues which you held up GBak as the
solution to.

So which is it?

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?

As we both agree, each has its purpose/use.

But you seem to be holding up one as the ideal but pining for the other
(which is NBackup).


Sean

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.