--- In [email protected], 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. To fix this, I had to have the database itself. So I could alter the procedure and add the 'suspend' statement. The restore of the gbk file resulted in a half restored database with no procedures or triggers. Todd
