Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 3 of 3 total
Thread Test-Database before Backup-Database
Tue, Feb 19 2013 4:53 AMPermanent Link

gripsware

gripsware datentechnik gmbh

Hi there,

today we got a customer with a damaged database ... his external-harddrive just died .. but he made a backup every week and stored it on a another drive (via "BACKUP DATABASE ...) ..
So everything seams to be fine Smile... just restore a backup and everything will work again.

Frown

Nope .. the backups of the last 3 Months are Damaged too(we were able to restore them but unable to repair them .. everything crash's (Edbmanager) displaying wild ascii chars..). It looks like the "BACKUP DATABASE"-Command doesn't test the tables for consistency before adding them to the backup ...

Now we dicided that this situation is not that good and that we have to test the database to inform the user about a damaged database so actions can be taken immediately.

But! *g* You can make a Backup without exclusive access ... but you can't do a verify without exclusive access.

I am stuck here ... are there any sugesstions?!

Greetz
Tue, Feb 19 2013 5:35 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Volker


If you're concerned about backup integrity the only test is a restore <vbg>

How about a small app that will restore a backup (obviously into a different location) and then run verify. If it is OK then blow away the restored data.

Before you give up totally on the duff backups its probably worth an email to Tim to see if he can do anything.

Roy Lambert [Team Elevate]
Sat, Feb 23 2013 11:56 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Volker,

<< Nope .. the backups of the last 3 Months are Damaged too(we were able to
restore them but unable to repair them .. everything crash's (Edbmanager)
displaying wild ascii chars..). It looks like the "BACKUP DATABASE"-Command
doesn't test the tables for consistency before adding them to the backup ...
>>

Were you overwriting the same backup files each time ?  EDB doesn't test the
files for consistency because it does a "raw" backup of the files.  Same for
restoring.  Therefore, any corruption in the tables should be irrelevant to
the backups - as long as EDB can open the tables in both cases, it will be
able to backup/restore them.

The problem I'm having here is the idea that they were using these database
tables all along, yet the backups somehow contain a *more corrupted* version
of the same database tables.  That doesn't sound correct.

<< But! *g* You can make a Backup without exclusive access ... but you can't
do a verify without exclusive access. >>

Sure you can - you can do a verification while others are using the same
database table(s).  Just open a table using EDB Manager, open up another
copy of the EDB Manager, and then do a verification on that table.

It's the *repair* that you can't do while others are using the database
table(s) being repaired.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com
Image