Hello,

I believe there is a bug in firebird which causes gbak to fail (or perhaps a bug in gbak) when backing up large databases. Here's the problem:

we have a database that is about 25GB in size. When running gbak I notice that the second db backup file (tedb.bk1) is not growing past 106,633KB. I leave gbak running for days as it takes up zero CPU cycles. Finally, about 3 or 4 days later I go back to the machine I'm running the gbak on and I see the following in the DOS Window:

gbak: 12060000 records written
gbak: 12080000 records written
gbak: 12100000 records written
gbak: 12120000 records written
gbak: 12140000 records written
gbak: 12160000 records written
gbak: 12180000 records written
gbak: 12200000 records written

Gbak seems to be stopping at this point... or perhaps running so slowly as to be of no use.

Using this same database I've been able to reproduce this problem on 3 different machines using Firebird 1.0 and 1.5. At the same time, I have been unable to reproduce this bug using an independent database that I built which contains more than 14 million records and which takes up 34GB of disk space. In those attempts gbak ran successfully. In addition, I've backed up many databases larger than this without running into this issue so the problem seems to be isolated to this particular firebird DB.

Is there a known limitation to gbak? Is gbak known to slow to a complete crawl when it gets over 10million records?

Some things I've tried:
gfix validation with all sort of options (lots of corruption found)
gfix mend with various options (just reports the same corruption as -v)
gfix -v again reports the same errors (-mend seems useless)
gbak and restore (gbak fails so restore is impossible)

Could this just be a case of a database that is corrupted beyond repair? Other than this gbak problem, the application which attaches to this DB is running fine.

Any ideas? Any help would be appreciated.

Jake Evans
Software QA Engineer


---------------------------------

What are the most popular cars? Find out at Yahoo! Autos

[Non-text portions of this message have been removed]