> --- In firebird-support@yahoogroups.com, Doug Chamberlin<chamberlin.doug@...> > wrote: >> >> On 2/29/12 2:50 PM, todderamaa wrote: >>> Maybe with the possibility of corruption, I should tell him to exclude >>> the database files from backup entirely and only backup the gbk files >>> that are created in the evening. >> This is the usual way to backup Firebird databases in situations like >> your clients have. Operating on the live database files is a quick way >> to corrupted backup copies. If you have not experienced corruption >> either you have been lucky or have not actually tried restoring from >> many of those backup copies. >> >> The client network admins should be aware of this special case when >> databases are being used. For this reason some database vendors have an >> API that backup software can use to ensure the database activity does >> not interfere with the backup operation. The vendors of backup systems >> usually charge extra for these modules that handle various databases. >> Firebird, however, does not have such an API. >> >> Steps for a safe, reliable Firebird backup: >> 1) Run GBAK >> 2) Copy the GBAK output to your backup media >> 3) Periodically restore from the GBAK output to a test database to >> ensure there are no errors. >> > > I agree. > > But with this latest issue, we needed the database file and not the backup. > The restore of the backup failed, because we had a stored procedure that was > selectable that didn't include a 'suspend' statement. I think this must be > something that was allowed in Firebird 2.0 but not with 2.1.
This is another reason to perform a backup/restore cycle when upgrading to a newer server version. A sanity check and upgrading the ODS to activate all good new stuff. ;-) Regards, Thomas
