Subject | Re: [firebird-support] Database restore failure |
---|---|
Author | Ann Harrison |
Post date | 2012-05-09T20:49:12Z |
Rick,
A database restore failed. Does anyone know what these errors mean, and
"adjusting an invalid decompression length from 78 to 73" is an attempt to
correct the error, hoping that ignoring some minor problem will let the
rest of the restore succeed. No such luck. Elements in the backup file
are tagged with attribute numbers which determine how the element should be
expanded. There is no attribute zero.
I notice that you seem to have done a test restore, which is a very good
thing. What I would do next is backup the database again and retry the
restore. With any luck, that will succeed and you might look in the system
log for write errors on the previous backup file. If the second try also
fails, if I were you, I'd get a copy of IBBackupSurgeon and let it tell you
what went wrong. Of course, being me, what I'd actually do is build a
debugging gbak and get my answers from there, but you'll save a lot of time
with a good tool.
Good luck,
Ann
[Non-text portions of this message have been removed]
A database restore failed. Does anyone know what these errors mean, and
> what we can do to prevent this from happening again?What that means is that the gbak file is corrupt. The first message
>
> /* backup */
> gbak -GARBAGE_COLLECT -b rxsaccessdb:accessrxs
> /usr/backup/firebird/accessrxs.fbk
>
> /* test restore */
> gbak -v -se it-test:service_mgr -use_all_space -r
> /opt/firebird/db/accessrxs.fbk /opt/firebird/db/accessrxs_3.fdb
>
> gbak: 47330000 records restored
> gbak: adjusting an invalid decompression length from 78 to 73
> gbak: 47333043 records restored
> gbak: do not recognize table attribute 0 -- continuing
> ...
> gbak: do not recognize table attribute 0 -- continuing
> gbak: ERROR: string truncated
> gbak: Exiting before completion due to errors
>
>
"adjusting an invalid decompression length from 78 to 73" is an attempt to
correct the error, hoping that ignoring some minor problem will let the
rest of the restore succeed. No such luck. Elements in the backup file
are tagged with attribute numbers which determine how the element should be
expanded. There is no attribute zero.
I notice that you seem to have done a test restore, which is a very good
thing. What I would do next is backup the database again and retry the
restore. With any luck, that will succeed and you might look in the system
log for write errors on the previous backup file. If the second try also
fails, if I were you, I'd get a copy of IBBackupSurgeon and let it tell you
what went wrong. Of course, being me, what I'd actually do is build a
debugging gbak and get my answers from there, but you'll save a lot of time
with a good tool.
Good luck,
Ann
[Non-text portions of this message have been removed]