GBAK should validate data during backup, not restore [CORE424]

[firebird-automations]

Submitted by: ironman-lok (ironman-lok)

Votes: 11

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.

[firebird-automations]

Commented by: Alice F. Bird (firebirds)

Date: 2005-04-06 04:33 Sender: ironman-lok Logged In: YES user_id=929747

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 happy.

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.

[firebird-automations]

Commented by: Alice F. Bird (firebirds)

Date: 2005-04-05 22:49 Sender: seanleyne Logged In: YES user_id=71163

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).

Comments?

[firebird-automations]

Commented by: Alice F. Bird (firebirds)

Date: 2004-05-25 17:54 Sender: fgm Logged In: YES user_id=4775

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

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.

[firebird-automations]

Modified by: @pcisar

Workflow: jira \[ 10448 \] =\> Firebird \[ 14736 \]

[firebird-automations]

Commented by: Cosmin Apreutesei (cosmin_ap2)

I happily made lots of useless backups myslef with gbak, never knowing they were useless, because of this. CORE1030 is a related request.