Issue Details (XML | Word | Printable)

Key: CORE-424
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: ironman-lok
Votes: 11
Watchers: 4

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

GBAK should validate data during backup, not restore

Created: 14/Dec/03 12:00 AM   Updated: 04/Feb/09 02:35 PM
Component/s: GBAK
Affects Version/s: None
Fix Version/s: None

SF_ID: 859615

 Description  « Hide
SFID: 859615#
Submitted By: ironman-lok

GBAK detects some validation errors (like NOT NULL
fields with null values) during the restore, but no errors
occurs during backup.

Example: create a table, insert some rows, then use
alter table to add a NOT NULL field. Then you make a
backup, and GBAK won't detect any error, but when you
try to restore that backup (even with -n), a validation
error will occur.

I'm not sure if it's a bug or a feature request, however,
IMHO that validation should be done during BACKUP, as
an unrestoreable backup isn't a backup.

PS: Sorry if I've made any mistake in my spelling or
something, my english isn't perfect.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alice F. Bird added a comment - 14/Jun/06 09:39 AM
Date: 2005-04-06 04:33
Sender: ironman-lok
Logged In: YES

As I said before, unrestorable backups aren't backups. The
problem is that you can't even imagine if a .gbk file you've
made can be restored when you need it.

Just imagine this scenario: I've got a daily backup tool
that catches GBAK errors and send them through email. Then I
make a change in a production DB adding a NOT NULL field,
and, unfortunally, forget to fill that field for old records
(OK, I must be careful, but this surely could happen with
anyone). GBAK doesn't report any error for the next 6
months, so far so good. Someday, the production DB becomes
corrupt and when I try to restore yesterday's backup, BINGO!

If GBAK generated an error during backup six months ago,
nice, I'd have corrected the mistake, and everybody would be

In fact, I'm not exactly asking for an integrity checker. If
you say that GBAK is for moving data, then it should move
data, whatever it happens. If it can't move data for any
reason, then it should warn the user (and the apropriate
time is when backing up, not restoring).

By the way, if GBAK is intended for moving data only, then
it should not be documented as a backup utility, but as a
dump utility.

Alice F. Bird added a comment - 14/Jun/06 09:39 AM
Date: 2005-04-05 22:49
Sender: seanleyne
Logged In: YES

I disagree, GBAK not should be responsible for checking
data integrity. GBAK is only responsible for moving the data
records; nothing more, nothing less.

There is the need to have a integrity checker, but this should
be a separate tool/utility/function. (Heck, it could be written
as an SP)

Given the design of the GBAK utility, I wonder if we should be
designing the backup/restore streams such that it does
absolutely/positively no data integrity checking (by having
NOT NULL settings added to the schema/column definitions
after the data has been restored).


Alice F. Bird added a comment - 14/Jun/06 09:39 AM
Date: 2004-05-25 17:54
Sender: fgm
Logged In: YES

Maybe simpler would be a way for GBAK to ignore this NOT
NULL problem (already documented on BDN) when -N is

Or, more generally, provide a flag to restore only data without
touching the metadata in the DB. It would be a complement to
the -M flag on backups: one only backs up metadata, the
other would just restore data.

It would allow one to correct the DB structure (like redefining
the offending field), restore, and only then apply the DB
structure modifications.

I'm stuck in this situation currently from a precious table GBAK
can't restore, and all I've found to do is pick up values by hand
from a hexdump of the backup and rekey them in. Not what
you'd expect. I'd more gladly have rewritten something to
restore from the .gbk, but couldn't find a spec for the .gbk
format, only the C(++) source, which is a bit too much.

Cosmin Apreutesei added a comment - 04/Feb/09 02:35 PM
I happily made lots of useless backups myslef with gbak, never knowing they were useless, because of this. CORE-1030 is a related request.