Subject | Re: [firebird-support] What is this gbak error message mean? |
---|---|
Author | Ann W. Harrison |
Post date | 2008-12-23T23:23:32Z |
Gabor Boros wrote:
through a forest of byte values, hoping to find one it understands.
Possibly you've got a backup created by a newer gbak and are trying
to restore it with an older gbak - backup files are not backward
compatible. If you're trying to revert a database to an earlier
version, start the new server and run the older gbak image to create
the backup file, then stop the new server, start the old server,
and use the old gbak to restore the database.
If the file was created by the same version of gbak you're using
to restore it, then you've got some corruption in the backup file.
One way to proceed is to try a restore with -m (metadata only).
If that works, restore again, to a different file with -o (one
table at a time. If that works, you've got all your fancy metadata
in the first database and a second database with essentially just
table and field definitions, plus all the data. Now all you have
to do is merge the two, which can be done by extracting the metadata
from the first database (ISQL can do it) and applying the missing
definitions to the second database.
Or you could look at IBBackupSurgeon at IBPhoenix.com
Cheers,
Ann
>Unfortunately, the "continuing" means that gbak is stumbling blindly
> I want to restore a database and these messages appears.
>
> gbak: do not recognize Bad attribute for table constraint attribute 126
> -- continuing
> gbak: do not recognize Bad attribute for table constraint attribute 3 --
> continuing
> ...
> gbak: do not recognize Bad attribute for table constraint attribute 142
> -- continuing
>
> The "continuing" mean the database(backup) is not corrupted but
> have any inconsistency?
through a forest of byte values, hoping to find one it understands.
Possibly you've got a backup created by a newer gbak and are trying
to restore it with an older gbak - backup files are not backward
compatible. If you're trying to revert a database to an earlier
version, start the new server and run the older gbak image to create
the backup file, then stop the new server, start the old server,
and use the old gbak to restore the database.
If the file was created by the same version of gbak you're using
to restore it, then you've got some corruption in the backup file.
One way to proceed is to try a restore with -m (metadata only).
If that works, restore again, to a different file with -o (one
table at a time. If that works, you've got all your fancy metadata
in the first database and a second database with essentially just
table and field definitions, plus all the data. Now all you have
to do is merge the two, which can be done by extracting the metadata
from the first database (ISQL can do it) and applying the missing
definitions to the second database.
Or you could look at IBBackupSurgeon at IBPhoenix.com
Cheers,
Ann