Issue Details (XML | Word | Printable)

Key: CORE-6321
Type: Bug Bug
Status: Closed Closed
Resolution: Won't Fix
Priority: Major Major
Assignee: Unassigned
Reporter: Rodrigo Gonçalves
Votes: 0
Watchers: 3
Operations

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

GBAK can't restore database due to 'do not recognize table attribute'

Created: 29/May/20 02:56 PM   Updated: 01/Jun/20 08:46 AM
Component/s: GBAK
Affects Version/s: None
Fix Version/s: None

Environment: Both Linux (CentOS 6.8 64bit) and Windows

QA Status: No test


 Description  « Hide
Dear all,

one of our clients has a large database (around 196GB) and the disk where it was hosted has crashed (without change of recovery).

Thankfully they had a backup (made with with gbak) but did not perform a restore to check the integrity of the backup, thus we have only the FBK file.

Now they are trying to restore the database but the following error appears at about 80GB of data restored:

gbak:do not recognize table attribute 0 -- continuing
gbak:do not recognize table attribute 0 -- continuing
gbak:do not recognize table attribute 0 -- continuing

Trying to restore just the metadata, for testing, results in the same error.

This happens at a table with the following structure:

SQL> show table table_name;
field1 INTEGER Not Null
field2 INTEGER Nullable DEFAULT NULL
field3 INTEGER Nullable DEFAULT NULL
field4 CHAR(40) Nullable DEFAULT NULL
field5 BLOB segment 80, subtype BINARY CHARACTER SET NONE Nullable DEFAULT NULL
field6 BLOB segment 80, subtype BINARY CHARACTER SET NONE Nullable DEFAULT NULL
field7 INTEGER Nullable
field8 INTEGER Nullable
field9 INTEGER Nullable
field10 INTEGER Nullable

After trying all gbak standard options, while looking at its source code I've found the "SKIP_BAD_DATA" option to try. I've tried it using both a large number (16384) and a small number (1) with no success. Is there a way to find out the possible numbers to try?

The command used was:

/opt/firebird/bin/gbak -REP -K -N -I -r -v -p 16384 backup.GBK database.FDB -user sysdba -pass masterkey

Also, I've tried finding some documentation regarding the FBK/GBK file format, so that we could build a tool to extract the data manually and pump it to a clean database. But did not find any documentation. Is it available online somewhere?

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dimitry Sibiryakov added a comment - 29/May/20 03:11 PM
It is usual error if you try to restore Interbase backup on Firebird server thus not a bug. Next time use support list for support questions.

Sean Leyne added a comment - 29/May/20 04:11 PM
Further to Dimitry, how did you confirm which database engine (Firebird vs. Interbase) and version # the client was using?

Sean Leyne added a comment - 29/May/20 04:12 PM
Issue is not confirmed to be with Firebird release

Rodrigo Gonçalves added a comment - 29/May/20 06:31 PM
Dear Dimitry and Sean,

the database was running in the same Firebird version in which the restore is being tried: ISQL Version: LI-V2.5.8.27089 Firebird 2.5

Only the disk with the database crashed. The OS disk did not suffer a failure, thus it is the same installation.


Alexander Peshkov added a comment - 01/Jun/20 08:25 AM
That's definitely not firebird bug. Most of your questions should be asked at support list.

What about format of gbak file. I do not know any source of documentation about it. Format is in many aspects simple:

attribute value, data length, data

Known attributes may be found in src/burp/burp.h. The main trickery is data length - depending upon attribute it can be one, two or fours bytes. I'm afraid that teh only way to study where what format is used is to read gbak sources.