On Wed, 2003-07-23 at 18:20, Scott Taylor wrote:

> At 14:09 07/23/03, you wrote:
> >Colin,
> >
> >C> If it is, we are going to have to have to have a policy of restoring
> >C> every backup to make sure all is well... And then do some serious
> >C> thinking!
> >
> >I don't see it as tragic a thing as you seem to do. Just assume that a
> >restore on a different file is part of your backup process, just as you
> >learned you had to use gbak instead of an operating system file copy.
>
> Exactly. Every morning at 08h00, while the database is at it's busiest, I
> take a backup and restore it to another file for use as a dev/test
> DB. Works slick, and I've never had any trouble restoring it for the two
> years I've been doing it. I think a database would have to be very damaged
> to not restore.

Actually it's simple to do, take a field that allows NULL fields, change
the system tables so that it no longer allows NULL fields, neglect to
check that there are no NULL fields in the database. First time you
restore, when it finds a NULL it will explode faster then a Ford Pinto
rear-ended by a Mack sized truck.

99% of the time a restore fails this is the reason why. A number of
solutions have been proposed, but I don't think any have been
implemented. The other 1% are when the backup file itself has been
damaged.