Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
firebird-automations opened this issue Dec 14, 2003 · 5 comments
Open

Comments

@firebird-automations
Copy link
Collaborator

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

Modified by: @pcisar

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

@firebird-automations
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant