IBSurgeon FirstAID 7.5

Purchase & Download

Licensing

Download

Documentation

IBSurgeon FirstAID is the tool that can automatically diagnose and repair corrupted Firebird or InterBase databases - it can recover corruptions that neither gbak nor gfix can fix. Supported versions: Firebird 1.0, 2.0, 2.1, 2.5, 3.0, 4.0, InterBase from 4.0 to 2020.

Download FirstAID to repair Firebird and InterBase databases

It uses its layer for low-level database access without using the InterBase or Firebird engine, so it can perform real "surgical" operations and repair your database when all other standard mechanisms (gfix and gbak) cannot. 

Now you are in 5 minutes from the recovery of your corrupted Firebird or InterBase database!

How to repair Firebird database:

  1. Download FirstAID - no registration required.
  2. Open the corrupted database with FirstAID and double click on the table name, then browse through the table's data pages.
  3. If you decide to recover the data you see in FirstAID, purchase the license (you'll get your password in 15 minutes after completing the purchase). What you see is what you will recover with FirstAID.
  4. Make sure to read FirstAID (Firebird and InterBase) Recovery Guide before recovery actions!

What is database corruption and how FirstAID repairs it?

Usually, database corruption means that some links between internal structures of Firebird (or InterBase) database are broken. When the database engine sees a broken reference to the missed record or database page, it stops working with a message like this:

Internal gds software consistency check ()
Or, for recent Firebird versions:
Internal Firebird software consistency check ()

Such error messages are reported by gbak tool, by gfix (it writes them into firebird.log), and by end-users applications (you can see the full list of "software consistency check" errors here).
The first part of this error is a common prefix for bugcheck (i.e., serious error), and in the parentheses, there are details of the error. 

Usually, such error prevents normal work with the database, and the recovery procedure should be executed. If it was not possible to fix a corrupted Firebird (or InterBase) database with standard means (gfix.exe and gbak.exe), it is time for IBSurgeon FirstAID.

IBSurgeon FirstAID is designed to work with the database directly, on a very low level – it allows bypassing erroneous places where the engine crashes and either fix broken links or exporting all users' data to the new database.

Firebird database recovery preview in IBSurgeon FirstAID 5.0:

Two options to recover Firebird or InterBase database with FirstAID

IBSurgeon FirstAID can perform 2 kinds of recovery operations: direct recovery and data extraction. The direct recovery is intended to fix the original corrupted database in place. This is a very fast and efficient method: after fixing the broken links database usually becomes readable, and it is possible to perform backup and restore. There are detailed instructions in FirstAID Recovery Guide on how to use the direct fix in FirstAID and then perform final steps with gfix and gbak tools.

The data extraction is designed to view and export data from the corrupted database to the database with the same structure (usually it should be empty).

FirstAID data extraction is applied in the case of heavy corruptions or metadata losses: it uses only a few system tables to decrypt users' data and export all available data to the new database.

Important! You can download the free version of FirstAID, open the corrupted database and preview all available data – and if you can see these data, they can be saved and exported to the new empty database. FirstAID scans corrupted database, then shows the list of tables, so a user can browse them.

With IBSurgeon FirstAID it is possible to repair corrupted Firebird/InterBase databases in more than 95% of cases.
See the video below how to repair the Firebird database with IBSurgeon FirstAID:

Recovery service

Important! If you cannot see data with FirstAID in your corrupted database, please contact our support: support@ib-aid.com. Please send the diagnostic log and relevant details (full error text, screenshots, etc) to our support, and get recovery estimation for free.

You will receive an exact free answer on whether your database is recoverable or not, is it recoverable by FirstAID directly, or some manual work is needed. We will also try to estimate how much of your data can be recovered if there is a serious problem that will not allow 100% recovery.

For serious problems we offer Firebird (and InterBase) database recovery service - see more details here.

Common Firebird corruptions and their error codes

There are many possible corruptions that IBSurgeon FirstAID has been designed to repair and correct. These are listed below:

  1. Internal gds software consistency check (cannot find tip page (165)) The required Transaction Inventory Page is corrupt and the database cannot be opened. Firebird error code (bugcheck number) is 165. It is expected in this instance that neither gbak nor gfix will be able to repair your database (except in the case of a Read-Only database). IBFirstAID will repair the missing pages and recover the database. It should be fixed with FirstAID Direct.
  2. Database file appears corrupt (). bad checksum. checksum error on database page. gds_$receive failed This error is reported by gbak, it indicates corruption caused by lost or zeroed pages: Firebird cannot find checksum placeholder (it is 12345 since InterBase 5.x) and reports any other value of as "bad". It can be fixed with Direct Fix or, in the case of heavy corruption, with extraction. 
  3. Internal gds software consistency check (decompression overran buffer (178)....) One or more records are damaged. Data should be exported from the corrupted database with FirstAID extraction.
  4. Internal gds software consistency check (wrong record length (183)...) One or more records are damaged: the actual length of the record is different from declared one. The data from the corrupted database should be exported with FirstAID extraction. Bugcheck number (error code for this error) is 183.
  5. Unknown database I/O error for file "*.gdb". Error while trying to read from the database file. This usually indicates that many database pages have probably been lost at the end of the database file (power failure?). In this case, the database cannot be opened. Gfix cannot repair this. IBFirstAID will recreate the missing system pages and deletes the wrong pointers.
  6. Database file appears corrupt. Wrong page type. Page NNN is of wrong type (expected X, found Y).  Or, another variant of this error: Page ... is of wrong type (expected ..., found purposely undefined) This error can indicate several problems. But typically there are missing pages in the database or the page that is being accessed is not the expected page type. For example, if the expected page type is 5, it can mean that some data may have been corrupted within a table. Such corruption may prevent a successful backup or may make the table unavailable to the database. IBFirstAID fixes the wrong page pointers and repairs the database.
  7. Fragmented record NNN is corrupt in table TABLE(NNN) One or more fragmented records lost their fragments, so the whole record cannot be assembled from fragments. In this case, data should be exported from the corrupted database with FirstAID extraction.
  8. Wrong record length. Cannot find backversion. IBFirstAID will check every record in a database and will try to repair these record-level errors.
  9. internal gds software consistency check (pointer page vanished from mark_full (256), file: dpm.cpp line: 3240) Serious corruption, data export with FirstAID is recommended.
  10. Invalid request BLR at offset NNN. This error occurs in a case of corrupted or incompatible BLR (Binary Language Representation) of some stored procedure, trigger, or view in the database. Ideally, this error should be fixed with the recompilation of appropriate database objects, but in the case of the persisting problem, the full export to the new good database is required. The peculiarity of this error that backup/restore with gbak does not fix it since BLR is not recompiled automatically during backup/restore.
  11. Incremental backup (nbackup) merge errors, like this:
    [
    PROBLEM ON "end backup".
    unsuccessful metadata update
    -ALTER DATABASE failed
    -Database is not in the physical backup mode
    SQLCODE:-607
    ]
  12. Other database corruptions can be caused by lost pages, corrupted records, metadata problems, etc. The full list of Firebird errors and their codes are here.

How to avoid further corruption?

For those who don't want to experience corruption again, we recommend HQbird Enterprise, with the option to create a mirror (warm-standby) for the database or even a fail-safe cluster. 

 

Licensing 

FirstAID is licensed per database – “database” means database file which can be recovered. The most popular license is for 3 databases, it is enough for the majority of clients.

If you are ISV (Independent Software Vendor, i.e., your company produces business software that uses Firebird or InterBase) or you have many databases, 50 databases license should be a perfect choice.

For those who need the complete recovery solution, there is HQbird Professional – it includes FirstAID for 50 databases, IBBackupSurgeon for recovering corrupted backups and IBUndelete to undelete occasionally deleted records.

HQbird Enterprise is our flagship product, it includes the following features: high availability and replication, recovery toolset for 100 databases, GUI for database development, backups' automation, transaction and queries monitoring, database structure analysis, optimized configurations and more.

Upgrades

Also, it is possible to buy the upgrade for 5 and 50 databases. The upgrade can be done for any version of FirstAID or any previous Pack.

Tips to recover Firebird with gbak and gfix

gfix

Gfix is a tool designed to fix a corrupted database, it is included in each Firebird or InterBase distribution (located in Firebird\Bin folder in versions 1.x-2.x and in Firebird root folder in 3.0 and 4.0).

Gfix scans the database, checks data structures and records for corruption, and fixes them.
Please note: It is necessary to run gfix after FirstAID Direct Fix, and it can be skipped in case of extraction since the database for export is not corrupted.

The recommended combination of gfix switches and commands after FirstAID direct fix is the following:

gfix -v -full -ig -user SYSDBA -pass your_pass Path_to_database
gfix -mend -ig -user SYSDBA -pass your_pass Path_to_database

In a case of successful execution, gfix returns nothing. In a case of errors, gfix writes about all found problems into firebird.log (so firebird.log can be very large after gfix) and to output it prints only "Summary of errors" where quantities of found errors are shown:
  • Number of record level errors - the number of corrupted records found during gfix work. These records are not correct - essentially, lost.
  • Number of index page errors - the number of index pages in bad indices. When even the only key is incorrect in the index, gfix marks the whole index as bad, so the number of pages usually is high. However, since it does not affect user's data, and because corrupted indices will be recreated during backup/restore, this can be considered as for your information only.
  • Number of transaction page errors - the number of transaction pages which were fixed by gfix. Usually, if you see this message it means that gfix did its job and now transactions are Ok.
  • Number of BLOB errors - the number of bad BLOB pages, it indicates the number of bad BLOBs.
  • Number of database page errors - this is the overall number of database pages, which were visited and changed/marked as bad by gfix. Again, this is mostly for your information.

If gfix reports such errors or even if it fails with various error messages, it is necessary to proceed with gbak! There is a good chance that gbak will be successful.

gbak

Gbak is a tool included in the standard installation of Firebird and InterBase (it is located near gfix). Originally gbak is designed to create verified backups of the databases: it reads the whole database from the beginning to the end, table by table, record by record, and stores metadata and data into the special backup format.
Since gbak reads the whole database as a normal client (it uses snapshot transaction to see the consistent state of the database), the creation of database's backup by gbak means that the database is not corrupted (with pretty high chances, around 99,9% - we saw very few unrestorable backups).

So, the goal of using gbak during the recovery is to create a healthy database backup, and then restore from it to the new uncorrupted database.
Here are some tips on how to achieve it.

The recommended combination of gbak switches for the corrupted database is the following:
gbak -b -g -ig -user SYSDBA -pass your_pass Path_to_database Path_to_backup

 After the successful gbak, the restore must be done to create a fresh database from the backup. The command is the following:
gbak -c  -user SYSDBA -pass your_pass Path_to_backup Path_to_database 

More details about gfix and gbak can be found in FirstAID Recovery Guide.