T-SQL Tuesday #19 – Disasters & Recovery

When I first read this article, I thought to myself “I have no clue on this one. What could I write that would be unique or interesting?”

My Disasters

Have you heard that old axiom that bad things come in sets of three? For me, I have three such tales and two of them have a correlation to SQL Server (at least in some degree).

Disaster the First – You Can see it Coming

This one is a slow, ongoing process. We are in a state of watch and wait. But it at least gives us a chance to prepare and thus be prepared. We live in an area where a flood plain exists but once every 20-25 years. It just so happens that this is one of those years. Our neighborhood is preparing by digging ditches, building dykes and sandbagging the most likely flow areas. We see it coming and we are making plans.

Disaster the Second – Efforts Didn’t Go According to Plan

Last Friday I was applying a software patch. As you would have guessed, the patch did not go according to plan. The patch actually corrupted windows files and caused windows to fail reboots. I tried to repair the corrupted files (default action with Win7). I also tried to restore to a previous checkpoint. Last effort was to re-install Windows. You know that means I had to re-install all of my apps as well. Any settings in the apps (such as SSMS) would be lost.

In this case, I should have imaged my machine immediately prior to installing the patch. In this case, I wanted to retrieve all of my SSMS registered servers. In order to do that (even though I did not export the registered servers) I needed to locate the prior RegSvr.XML from the backup that the Windows Installation makes of an existing windows install. In some cases this prior install will be relocated to windows.Old. Search in that directory for the RegSvr.XML file and copy it to %username%\AppData\Roaming\Microsoft\Microsoft SQL Server\100\Tools\Shell. This will RECOVER the registered servers in SSMS that you had there prior to the reinstall. Of course you would first need to reinstall SQL Server Tools prior to attempting this.

Disaster the Third – UnPlanned

After successfully recovering from that minor disaster, I encountered a new disaster only after two days of laptop use. Upon arriving on-site yesterday morning (and mind you the laptop worked at the hotel) in Chicago (which is out of state for me), my laptop froze, rebooted and came back to “No Boot Disk.” Well, I was completely unprepared for this midlevel disaster. I didn’t have my reinstall discs with me. I did not have my laptop backed up from the Friday disaster – I was still trying to get everything back to normal. I had but one option – buy a new laptop and try to recover the hard drive later.

In trying to make sure it was not going to boot, I booted the system to a Boot CD (UBCD and a couple others) to be certain. I was getting Int13h errors trying to find the drive. I checked CMOS and CMOS did not see the drive. I bought the new laptop and first tried to boot the new laptop from that HDD. It too did not recognize it. The drive was not even spinning up at that time.

Today, I have attached that drive to an external cage and connected via USB. It’s alive!! The data is still there but some clusters are corrupt. That is fine so long as I get the data. In this case, I don’t normally take daily backups of my laptop drives. In the future, I will be taking more frequent backups of the laptop drives. And now I have a backup laptop for cases just like this.

And once this last disaster is recovered, I will be copying settings from apps on that laptop to the new laptop – might save a little time.