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