This case study documents the professional restoration of an 11 GB Firebird 2.5 database that suffered critical structural failure due to an improper server shutdown. By bypassing internal GDS (Gateway Data Software) bugchecks and manually re-aligning pointer pages, the AS Data Recovery team achieved a 100% recovery rate.

Client & Data Information

• Client Name: Confidential
• Data Type: Firebird 2.5 (.FDB)
• Data Capacity: 11 GB
• Primary Issue: Server Power Failure / Corruption of Pointer Pages
• Specific Errors: * End of file reached (I/O Error)
  • internal gds software consistency check
  • invalid block type encountered (147)
  • Page 1560281088 wrong type (expected 5 encountered 6)

Incident Summary

The client’s Firebird server experienced a hard shutdown, causing the database engine to lose its place during an active write cycle. When the client attempted to restart the service, the engine triggered an internal GDS software consistency check, a fatal protection mechanism that prevents the database from opening to avoid further damage. The client’s attempt at a self-repair (likely using gfix) failed because the Pointer Pages—the structural links that tell Firebird where specific table data is located—were pointing to invalid or non-existent page types.

Technical Analysis

Upon forensic analysis of the 11 GB .FDB file, AS Data Recovery engineers identified:

• Invalid Page Sequences: The error expected 5 encountered 6 indicated a fundamental mismatch. Page type 5 (Data Page) was expected, but the engine found type 6 (Index B-Tree Page), meaning the database’s internal “address book” was pointing to the wrong locations.
• Orphaned Data Pages: The specific table AP_STORE_OT_DTLS was completely inaccessible because its pointer page was missing, leaving nearly 600,000 data sequences floating without a logical parent.
• Truncation/EOF Errors: The End of file reached error suggested that the file header thought the database was larger than the physical file on disk, a common result of a failed write during a crash.

Recovery Solution

The recovery strategy utilized Low-Level Binary Page Reconstruction. Since standard Firebird utilities could not “continue after bugcheck,” our engineers bypassed the Firebird kernel entirely. Using proprietary forensic tools, we manually rebuilt the corrupted pointer pages and corrected the page-type flags in the binary stream. By re-linking the orphaned data sequences back to their respective table headers, we restored the database’s logical integrity.

Recovery Process

• Forensic Mirroring: Created a bit-level clone of the 11 GB file to ensure a non-destructive repair environment.
• Binary Header Alignment: Manually corrected the file size metadata in the header to resolve the “End of file reached” I/O errors.
• Pointer Page Reconstruction: Utilized specialized tools to scan the raw data pages and rebuild the pointer map for the damaged table AP_STORE_OT_DTLS.
• GDS Check Bypass: Corrected the invalid block type errors at the binary level, allowing the database to pass the internal GDS consistency checks.
• Full Metadata Export: Once the file was stabilized, we performed a full gbak backup and restored it into a fresh Firebird 2.5 instance to ensure a clean, production-ready environment.

Recovery Results

• Recovery Integrity: 100% (All tables and records fully recovered)
• Recovered Volume: 11 GB
• System Status: Database fully operational; all ERP/Application functions restored.
• Customer Satisfaction: Extremely Satisfied.

Expert Reminder from AS Data Recovery: When Firebird reports an “internal gds software consistency check,” it means the core structure is broken. Repeated use of gfix -mend or gfix -full can actually overwrite the data you are trying to save. If the pointer pages are gone, the data is invisible but still there. Contact AS Data Recovery professionals immediately for binary-level reconstruction.