Subject Re: Backing up a db with users connected can crash it?
Author Adam
--- In, Helen Borrie <helebor@...> wrote:
> At 01:50 PM 10/04/2008, Adam wrote:
> >--- In, Helen Borrie <helebor@> wrote:
> >
> >>
> >> Adam, have you ever seen the engine crash when gbak happens to read
> >corrupt data? Gbak -backup itself can crash but I've never heard of
> >the server crashing in these circumstances...did you attempt to
> >reproduce it?
> >
> >Yes. In fact with the one I have seen you can duplicate with an
> >unrestricted select * query on the effected table. I tried it again to
> >make sure I am not mad:
> >
> >.
> >.
> >.
> >.
> >gbak: writing data for table [CORRUPTTABLE]
> >gbak: ERROR: internal gds software consistency check (wrong record
> >length (183))
> >
> >gbak: ERROR: gds_$receive failed
> >gbak: Exiting before completion due to errors
> >gbak: ERROR: internal gds software consistency check (can't continue
> >after bugcheck)
> >
> >In firebird.log
> >
> >LAPPY Thu Apr 10 13:32:58 2008
> > internal gds software consistency check (wrong record
length (183))
> >
> >I have also seen one other instance where gbak failed due to the
> >corruption but was successful with the -g switch (corruption must have
> >been in a back version).
> Cool. ;-) Are you able to report it in Tracker, along with engine
version number and a zipped copy of the database?


Unfortunately it was a customer's database. There is some sensitive
data inside (other) tables. Normally I could overwrite this data and
backup/restore it out, but obviously that can't work ;)

I know how the corruption occurred (sys admin mishandling files while
the server was running), and managed to use a data pump at the time to
recover pretty much all the data.

Is there any process I can sanitize this information, or
alternatively, is there any way to reliably cause such corruption so I
can duplicate it on a non-sensitive database?