Issue Details (XML | Word | Printable)

Key: CORE-2338
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Don Young
Votes: 4
Watchers: 4

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

More robust gbak

Created: 24/Feb/09 03:10 AM   Updated: 08/Oct/09 11:42 PM
Component/s: GBAK
Affects Version/s: None
Fix Version/s: None

Environment: Windows

 Description  « Hide
I've ever developed a database system, based on FireBird 2.04. This system has a very high frequency for data inserting and updating. The size of the db file growed rapidly, however, this is not the real trouble. I backup and resore the database periodically, using gbak, which would keep the database at a high speed. Till one day, during restoring, gbak reported that it found duplicated primary keys, and refuse to work, all the data in the table was lost. We've tried all kind of methods, still cannot get back the data, only because it has duplicated keys. Why not make gbak more fault-tolerance? I think it would be much better that gbak should port the problematic data into a external log file when met errors, than just stop there and refuse to do anything rest.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alexander Peshkov added a comment - 24/Feb/09 07:33 AM
Did you try -I (deactivate indexes during restore) switch?

Carlos H. Cantu added a comment - 24/Feb/09 09:32 AM
IB BackupSurgeon utility, from IBSurgeon, can help with this too.

Sean Leyne added a comment - 24/Feb/09 02:17 PM
In normal operation it is not possible for a duplicate primary key to be added to a database.

This suggests that you are not performing your backup/restore cycle correctly, and allowing the restore database to be accessed while the restore process is running. This is the only way for duplicate primary keys to be created within the database (the constraint must be disabled, and a primary key constraint is only disabled during a restore cycle).

This case seems to be a "won't fix" case, as you are not following reasonable processes.

Alexander Peshkov added a comment - 24/Feb/09 02:35 PM
Sean, you are almost correct - except cases called
1. new bug in firebird,
2. hardware fault.
And it's good idea to have restorable backup even in this rare cases.

Cosmin Apreutesei added a comment - 26/Feb/09 12:50 PM
there's another request somewhere around here to make gbak validate data on backup, not restore -- you may want to vote for that :) i got my fair share of trash backups myself -- learned my lesson and now I only do SQL dumps with firebird. nothing beats plain text data.

Claudio Valderrama C. added a comment - 10/Mar/09 08:15 AM
Did you try the -ONE switch in gbak when restoring?

Philippe Makowski added a comment - 08/Oct/09 11:42 PM
I agree with Alex
it could be a good option to choose if you wanted to restore all, or without Indexes, without SP, without Triggers or with Triggers non actives , etc ..

For example if you are using PLAN referencing indexes into SP, you can't use the -I switch :(