From Microsoft Windows 7 to Hurricanes: Dealing With IT Disasters

By Wayne Rash  |  Posted 2011-09-14

From Microsoft Windows 7 to Hurricanes: Dealing With IT Disasters

During the course of the last month, those of us in the Washington, D.C., area have dealt with our share of natural disasters. We had an earthquake that was relatively mild by West Coast standards, but it shut down a nuclear power plant that remains closed, it toppled the tops of the spires on National Cathedral, collapsed several school buildings and brought about an overloaded wireless network. If that wasn't enough, we were hit a few days later by Hurricane Irene, and then a few days after that by Tropical Storm Lee.

You'd think that would be enough disasters for a three-week period of time. But then there were the unnatural disasters. For example, a utility worker accidentally caused a blackout in parts of Arizona, California and Mexico when something went wrong during a maintenance procedure, and then automatic safeguards didn't function as expected. The result is that a number of areas had to wait days for power to be restored, and that in turn meant that computers and data centers were down. Hopefully, they were protected by uninterruptible power supplies (UPS) so that they didn't lose anything, but that doesn't help with conducting business.

Of course, unnatural disasters can be smaller, and closer to home. I found myself doing disaster recovery of sorts starting Sept. 10, after I had to reinstall Microsoft Windows 7 on my primary workstation. This was caused by the kind of individual disaster that's not any larger than a single business. But it still caused days of downtime while I restored computing power to my business.

The cause of this one-business disaster was a desire to tune up my primary computer. It's a machine with a pair of dual-core Intel Xeon processors, 64-bit Windows and a lot of memory. But it was getting slow, so I installed a new copy of System Mechanic from Iolo Technologies, a product that I'd reviewed before, and that has generally rated well. This time, something went horribly wrong, and my registry was corrupted. I was eventually able to get the computer to start, but it couldn't do anything useful.

Since I'd discovered the damage over the weekend, I had to wait until Monday for the proper level of tech support. I used my laptop for doing work, so all was not lost, but then I spent hours on the phone with Iolo's tech support. There was no solution other to perform a clean install of Windows. I did that Monday.

From Microsoft Windows 7 to Hurricanes: Dealing With IT Disasters

title=Eating Up Lots of Time} 

Fortunately, I'd followed the advice of eWEEK's storage guru, Chris Preimesburger, and had signed up for Carbonite's cloud based backup. While the Windows installer creates an "" directory, that doesn't do much to save your settings for things like Outlook. So I started Carbonite's full system restore. Once that was running, I went to see my newly-born granddaughter. When I got back, the restore was finished.

But I found out a few things that would have helped me, and had the need to do the restore been for more data, would have made a huge difference. The first is that even with a fairly fast Internet connection, downloading the data for a full restoration can take a long time - about 15 hours for just this one computer. The second is that you have to make sure you back up absolutely everything you need - I'm still looking for my old email files, and I'm not certain that I had them in the back-up set. And I found out that I could have saved a lot of time if I'd created an image of my system on one of the servers.

You should try a restore process before you actually need it. While Carbonite is seriously easy to use, it still took a little while before I was certain that I knew what to do. And, of course, you need to have some idea how long it will take so that you can plan for it.

Normally, I would also suggest that you should test software before you use it for something that you need for a critical business function. But in this case, I had already tested it. Nobody knows why it chose this moment to run amok.

But there were things that I did right. First of all, I have a laptop that can do most of the functions that my primary workstation can do. I also have spare workstations that could be pressed into service if necessary, although they're normally doing other things. So my business wasn't down, it just lost productivity because I was occupied trying to restore my system rather than doing actual productive work.

And that's probably the last lesson that I learned from this not-so-big unnatural disaster. The one thing that you can't replace when you're doing recovery is time. No matter how you plan it, the process will eat up time from someone in your organization, and you'll effectively lose the services of that person or those people involved in it until the restore process is completed, and the recovery tested and confirmed. Unnatural or not, that can be its own disaster.


Rocket Fuel