>> Yep! Had several requests already from people complaining their backup
>> file is corrupted. One infamous is, with databases having a lot of
>> trigger, procedures and interdependencies.
>>
>> A restore might fail with mismatched parameters (can't recall the exact
>> error message) for procedures ... Nasty! The only way out here is to
>> have a working database and re-compile all PSQL stuff on parameter list
>> changes etc ...
>>
>
> The problem isn't exactly a corrupt backup, but a database with undetected
> logical errors in the data or metadata. Having the backup check the
> validity of the whole database would significantly increase the backup time,
> but it is possible. At the moment, for example, gbak doesn't pay any
> attention to data constraints like unique and not null. It could recognize
> and test them ... at a cost. But the kind of problem you're describing
> could be caught by making and restoring a metadata backup - much cheaper
> than restoring 100G of data.

Right. While a metadata backup can catch such things, it's still only
the half way, because I still need a valid backup with all data, but
checking the validity of the metadata with a metadata backup/restore is
a good idea. AFAIR there will be an option for the gbak restore process
to restore only metadata, even if the backup contains data.

I still wonder why the mismatched error message is shown during the
restore, because, only the BLR is restored of procedures, triggers and
views and they don't get recompiled during the restore.




--
With regards,

Thomas Steinmaurer
Upscene Productions
http://www.upscene.com
http://blog.upscene.com/thomas/

Download LogManager Series, FB TraceManager today!
Continuous Database Monitoring Solutions supporting
Firebird, InterBase, Advantage Database, MS SQL Server
and NexusDB!