Issue Details (XML | Word | Printable)

Key: CORE-3492
Type: Bug Bug
Status: Open Open
Priority: Critical Critical
Assignee: Unassigned
Reporter: FrantiĊĦek Jahoda
Votes: 0
Watchers: 3

If you were logged in you would be able to see more operations.
Firebird Core

gbak: ERROR:BLOB not found

Created: 24/May/11 09:49 AM   Updated: 25/May/11 07:40 AM
Component/s: Engine, GBAK
Affects Version/s: 2.1.3
Fix Version/s: None

Environment: amd64, Debian Squeeze

 Description  « Hide
Regular backups with "gbak -b" failed at these error

gbak: ERROR:BLOB not found
gbak: ERROR:gds_$receive failed
gbak:Exiting before completion due to errors

content of /var/log/firebird.log (all times are in UTC):
our_database (Server) Tue May 17 03:34:51 2011
        Database: /srv/firebird/our_database.fdb
        internal gds software consistency check (error during savepoint backout (290), file: exe.cpp line: 4043)

our_database (Server) Tue May 17 03:36:39 2011
        Database: /srv/firebird/our_database.fdb

our_database (Server) Tue May 17 03:36:44 2011
        Database: /srv/firebird/our_database.fdb

our_database (Server) Wed May 18 06:15:25 2011
        Fatal lock manager error: invalid lock id (21688), errno: 22

Last successful backup started at 2011-05-17T22:00Z and ended at 2011-05-18T04:53Z

after that error we have been unable to backup database, gfix binary copy of it trough --mend or --validate --full
we were able to backup database with gbak -b --ignore but unable to restore (gbak restored the file but ended on bad page type error and quit)
but the gfix was able to find a lot of following types of errors:

 Database: /mnt/tmp/our_database.fdb
        Index 1 is corrupt on page 8136665 level 1. File: ../src/jrd/validation.cpp, line: 1649
         in table DEVICE_PIM_DATA (133)

our_database (Server) Fri May 20 16:24:02 2011
        Database: /mnt/tmp/our_database.fdb
        Page 22655159 is an orphan

We were able to finally backup the database after manually scanning all blobs and removing records with missing blobs (cca 8 records).
Our database have 89GB file size (cca 70% of content are blobs). After gbak failed we upgraded to 2.1.4 and solved the problem with this version. We provide free service for users all around the world so we do not want any downtime. (but the database itegrity is still a priority).

Should we do anything about reported errors?

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
There are no subversion log entries for this issue yet.