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

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