Lost Data

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQLServerCentral.com » Editorials » Lost Data

Lost Data

Rate Topic

Display Mode

Topic Options

Author

Message

Steve Jones - SSC Editor

Posted Wednesday, June 30, 2010 8:34 PM

SSC-Dedicated

Group: Administrators
Last Login: Today @ 4:46 PM
Points: 31,433, Visits: 13,745

Comments posted to this topic are about the item Lost Data

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help

Post #945892

Dave Schutz

Posted Thursday, July 01, 2010 6:26 AM

SSCommitted

Group: General Forum Members
Last Login: Wednesday, April 17, 2013 12:02 PM
Points: 1,631, Visits: 566

Steve,

I agree, tape backup is still a requirement for us. We are a non-profit and disk backup is too expensive for more than a few days worth of data. I make daily, monthly, and annual backup tapes so there is a plan B if plan A backup fails. Tapes can fail so test restores often.
I'd rather be old-school (tape backups) than lose data and possibly my job.

Post #946123

kevin77

Posted Thursday, July 01, 2010 11:20 AM

SSCommitted

Group: General Forum Members
Last Login: 2 days ago @ 9:18 AM
Points: 1,727, Visits: 1,042

Ha. This is my exact situation right now:

http://www.sqlservercentral.com/Forums/Topic926228-266-1.aspx

I've known about the error for over a month now, but management doesn't care because "the application still works for them". So I can't get the time and necessary resources to fix it.

Post #946363

Steve Jones - SSC Editor

Posted Thursday, July 01, 2010 11:53 AM

SSC-Dedicated

Group: Administrators
Last Login: Today @ 4:46 PM
Points: 31,433, Visits: 13,745

Sorry to hear that, Kevin. Keep your fingers crossed and hopefully disaster doesn't strike.

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help

Post #946378

Tom Bakerman

Posted Thursday, July 01, 2010 2:08 PM

SSC Journeyman

Group: General Forum Members
Last Login: Friday, May 10, 2013 6:33 AM
Points: 76, Visits: 568

I once worked with a customer that had a finite number of tapes that they used for their database backups Crazy

. Their database was big enough to have to use slightly more than one tape for each backup. So, when the time came to actually have to restore the database (due to a bad disk causing corruption), they discovered that the only complete backup set was the latest, and it too had the corrupted data on it. They wanted me to "recover as much as you can from an earlier backup", which of course was impossible because parts of the backup had been overwritten by a later backup. Needless to say, they came up with a better strategy AFTER that.

Post #946456

SQLBill

Posted Thursday, July 01, 2010 4:33 PM

Hall of Fame

Group: General Forum Members
Last Login: 2 days ago @ 1:48 PM
Points: 3,223, Visits: 414

I worked at a job where we the database outgrew the room for being able to do a restore and have two copies of the same database at the same time.

Before that had happened, we were using a third party backup software provided by the vendor knowing exactly what equipment we had and how it was set up. We did a backup and restore with no problem. Some time goes by and now the database is too large for two copies of it and we don't have another server large enough to restore a backup tape to. We updated the software and unfortunately the vendor didn't notify us or anyone at the time that their software would fail if:

1. you were using SQL Server 2000 Enterprise Edition
2. you were using Windows 2000 (some service pack, can't remember now)
3. the server was clustered
4. you were using the vendor's SQL Server agent add-on to backup SQL Server and it was a specific build.

1, 2, 3, & 4 -yep to all.

If you answered yes to all four, their product would not be able to restore the databases from the backups. Guess what, they only notified us of the issue AFTER we had a server issue and needed to restore from tape. They ended up recovering the tapes for us so we could do the restore and they 'ate' the cost of doing so, since they couldn't prove they had informed us of the issue prior to it happening.

-SQLBill

Post #946530

Russell Fields-270604

Posted Thursday, July 08, 2010 9:07 AM

Valued Member

Group: General Forum Members
Last Login: Today @ 11:57 AM
Points: 50, Visits: 512

Get a RestoreTest server (a VM would be fine) and enough disk space to restore your biggest database (plus necessary overhead).

Then cycle through your servers, restoring the backups one at a time to your RestoreTest server. (You will need to harvest the necessary data on backups from msdb of each SQL Server.) The process:

1. Restore a database, report any errors.
2. Delete the restored database.
3. Repeat with the next database.

Also, don't just restore full and diff backups. Include your transaction log backups as well.

When you start doing this you will probably find more problems than you imagined would exist. But once these are all smoothed out, you will sleep better.

RLF

Post #949373

« Prev Topic | Next Topic »

Permissions