July 1, 2010 at 6:26 am
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.
July 1, 2010 at 11:20 am
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.
July 1, 2010 at 11:53 am
Sorry to hear that, Kevin. Keep your fingers crossed and hopefully disaster doesn't strike.
July 1, 2010 at 2:08 pm
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.
July 1, 2010 at 4:33 pm
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
July 8, 2010 at 9:07 am
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
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply