Hello. Did you try early creating the DB structure and changing "field1 INTEGER Not Null" to "field1 INTEGER " and after that restore with -REP option?
One or more records could be writing, in someway, in the FBK with a null value. It happens when a NOT NULL column is created when a table has records. Atenciosamente, Em sex., 29 de mai. de 2020 às 11:59, Rodrigo Gonçalves (JIRA) < trac...@firebirdsql.org> escreveu: > GBAK can't restore database due to 'do not recognize table attribute' > --------------------------------------------------------------------- > > Key: CORE-6321 > URL: http://tracker.firebirdsql.org/browse/CORE-6321 > Project: Firebird Core > Issue Type: Bug > Components: GBAK > Affects Versions: 3.0.5, 2.5.9 > Environment: Both Linux (CentOS 6.8 64bit) and Windows > Reporter: Rodrigo Gonçalves > > > 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? > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: > http://tracker.firebirdsql.org/secure/Administrators.jspa > - > For more information on JIRA, see: http://www.atlassian.com/software/jira > > > > > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel >
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel