Back in the pre-digital era, only a disgruntled employee or an unforeseen physical disaster like a fire, a flood, a hurricane, or an earthquake could destroy all of your business records without warning. The threat from these harms hasn't diminished, but we've now invited a whole new class of disaster by entrusting business operations to the fragile vessels of silicon we call computers. The set of things that can render a hard drive unusable includes the same set of things that can destroy a filing cabinet — plus a lot more. It's not a question of whether a digital medium will fail, but when it will fail. IT consultants need to prepare their businesses and their clients for this inevitability. These disaster preparedness tips apply to your IT consultancy and to clients' businesses.
Data and work product backups
If you suddenly lost everything, you'd eventually be able to replace your office, your hardware, and all the software you use — but one thing you can't replace unless you've copied it somewhere else is your data, which includes the work you produce for clients as well as the information that tracks your business. Your work product may benefit from one additional form of backup: your client's copy — but be wary of relying on that as your only backup; your client may be relying on you to back them up.
When considering how frequently to back up, you should ask yourself "how much work am I willing to lose?" I'm okay with one day's work, but no more. I have a task scheduled for cron to create daily archives of all important drives. These archives get placed on a server, which gets backed up daily to a physical medium that is then transported off-site. That way, if the building burns down I still have a copy. You could instead use one of the various online backup services or simply copy files to an off-site web host, but I prefer having a tangible copy that I can put my hands around when I need it. Maybe I'm old-fashioned.
It's important that backups become routine, and automation helps with that, but you also need to monitor these automated processes regularly to insure they are working. Years ago, I spent a few months on-site with a client, developing a new product on a system that was supposedly backed up every night automatically. When the hard drive failed, imagine the bottomless pit that opened in my stomach when we learned that the backups had been failing for the previous two months due to a permissions problem. Nobody had bothered to read the logs.
Some IT consultants make image backups of their entire drive: O/S, programs, and data. That's a good idea for client sites, but for myself, I prefer just to do regular backups of data and work products. I view a system failure as an opportunity to finally upgrade that operating system, or at least clean out all the cobwebs with a full reinstall, which almost always helps (especially on Windows). However, that means that I need to stay prepared for reinstallation: I need to know exactly what I need to install, and where to find the disks. I'd better be able to place my hands on the activation keys and serial numbers that the installation requires — they had better exist somewhere other than on the disk I just lost. I also must keep detailed records — I was reminded of this point the other day when I got caught reinstalling Adobe Acrobat. I had the disk and the serial number, but it was the upgrade from a previous version for which I also needed the serial number. I no longer had that number, so I had to call Adobe.
Make a checklist of the reinstallation steps required for each of your systems, and keep it up to date.
How long can you afford to be out of business if your system dies? Wouldn't it be good if you had zero downtime? Redundancy is your friend. Not just RAID or some other disk redundancy (though those are essential), but also keep another system you can use in place of every critical system you have. If your tower fails, make sure you can move operations to your laptop without a hitch. If your server goes down, have another system that can stand in. I've found that virtualization helps keep the cost of this kind of redundancy down. If my server fails, I have a VM I can bring up in VirtualBox that will do the same job (only slower) until I can get the real beast resuscitated.
How dependent is your business on your physical location? If your office went up in flames, could you carry on? Thanks to mobile computing, some of us could make do — but it's always good to have a plan. Where could you set up shop? What restrictions would that impose, and how would you deal with them?
Any recovery effort, no matter how well-planned, will require some time to execute. That's time you can't devote to your clients, unless you have other people who can help you. Make a list of the people you could call in an emergency, and then make sure they agree to respond in such a situation (remember to offer to reciprocate). Don't abuse the relationship.
Most people never think about how they'd cope with disaster until it happens and then it's too late to do much about it. The details of your recovery plan may differ from mine, but the important thing, as Tom Lehrer so aptly put it, is to be prepared.
Disaster recovery resources on TechRepublic
- Download the TechRepublic Resource Guide: Disaster Planning and Recovery
- Download: Disaster recovery plan template
- Download: Focus your DR planning by using these five levels of disaster classification
- Members share why planning, and more planning, is key to disaster recovery
- What BP can teach us about IT
- 10 items for your disaster recovery wish list
- Understand the impact of Sarbanes-Oxley compliance on your disaster recovery plan
- HIPAA compliance and disaster recovery
- Build human accountability into your disaster recovery plan
- Don't overlook licensing issues when planning for disaster recovery
- Service level agreements and disaster recovery
- Don't rely solely on remote availability
- Why you can't rely on tape backups alone
- TechRepublic Real World Guide: Creating a Disaster Plan (TechRepublic Pro premium content)
Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant blog, he also contributes to [Geeks Are Sexy] Technology News and his two personal blogs, Chip's Quips and Chip's Tips for Developers.