Garbage collection error causing backup to fail [CORE3954]

[firebird-automations]

Submitted by: Brenden Walker (braindead)

Attempt to backup with garbage collection using the following:

"c:\program files\firebird\bin\gbak" -y d:\testxnet.log -se service_mgr -v -nt -user sysdba -password masterkey d:\mp9.fdb d:\testxnet.fbk

Fails with the following error:

gbak: ERROR:internal Firebird consistency check (applied differences will not fit in record (177), file: sqz.cpp line: 64) gbak: ERROR: gds_$receive failed gbak:Exiting before completion due to errors

However if I add -G to the above gbak command it completes without a problem. Restoring the backup to a new database allows subsequent backup with garbage collection to function properly effectively fixing the problem.

I could be off base on this, but it seems to me that any errors in garbage collection should report the errors but allow the gbak to finish.

I have a copy of the DB in question, it's rather large (18gig) and contains our customer data however if it's needed I'm sure we can figure out something.

[firebird-automations]

Commented by: @AlexPeshkoff

Switch -g exists not only to make backup process faster, but also to help backup damaged databases. BTW, what does gfix say for that database?

[firebird-automations]

Commented by: Brenden Walker (braindead)

gfix -v returned nothing. gfix -v -full: Number of record level errors : 20

Is that what you were looking for?

[firebird-automations]

Commented by: @paulbeach

If you have a garbage collection problem using gbak - then I suggest you read this: http://www.ibphoenix.com/resources/documents/how_to/doc_5 Specifically the section below.

Clean and recover the database.

Whether you skipped steps 2 and 3 or not, now do a full backup and restore using gbak, even if errors are still being reported. Include the -v[erify] switch to watch progress. In its simplest form, the backup command would be (all in one command):

gbak -b -v -i copy1.fdb [pathto]copy1.fbk

The following should help to resolve some of the complications that might show up during gbak:

Garbage collection problems might cause gbak to fail\. If this happens, run it again, adding the \-g switch to signify "no garbage collection":

gbak \-b \-v \-i \-g copy1\.fdb\{path\}copy1a\.fbk

Corruption in limbo transactions If there is corruption in record versions associated with a limbo transaction, you may need to include the \-l\[imbo\] switch:

gbak \-b \-v \-i \-g \-l \{path\}copy1a\.fbk

[firebird-automations]

Commented by: Brenden Walker (braindead)

I already found that -g allows a proper backup, and restoring that backup results in a clean database. I simply entered this to make sure the behaviour was intended. Sounds like it is.

[firebird-automations]

Commented by: @AlexPeshkoff

Gbak behavior is really as designed.

What about gfix - yes, I just wanted to make sure that all tools are 'in sync' for your DB. And for damaged DB use of -g switch for gbak is really very good idea. Moreover, it's good to use that switch in any case when you do not plan to use original database after backup - it just saves your time.

[firebird-automations]

Modified by: @AlexPeshkoff

status: Open \[ 1 \] =\> Resolved \[ 5 \] resolution: Won't Fix \[ 2 \]

[firebird-automations]

Modified by: @pcisar

status: Resolved \[ 5 \] =\> Closed \[ 6 \]