Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 3 of 3 total |
Test-Database before Backup-Database |
Tue, Feb 19 2013 4:53 AM | Permanent 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 ... just restore a backup and everything will work again. 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 |
This web page was last updated on Monday, April 29, 2024 at 05:23 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |