The firewall -- has the "magic" box lost its mojo?
May 3, 2016
Disaster Recovery for the SMB - 7 Steps to Better Sleep
January 6, 2015
In my last entry, I discussed the lack of working DR plans in the SMB world. Since my educated guess is that many SMBs don't do a plan because of the perceived difficulty, this follow-up is intended to show that it can be relatively easy to develop one. It just takes a bit of focus and determination. If you have a successful SMB, you obviously already have these traits, meaning that you are half way home.
Those readers with sharp eyes will have already noticed that the word "working" in the above paragraph is in bold and italics. It is really easy to put together a DR plan, but not as easy to have one that works. Based on my experience, the dirty little secret in the corporate world is that many plans are generated as a check-off to satisfy auditors, but when needed, are not worth the fancy paper on which they are printed. If you are unconvinced, ask Sony how well theirs worked.
Those of us in the SMB world have an advantage in that we don't need a highly formal and detailed plan to satisfy an auditor from a big accounting firm - we just need something that defines what we need to do in the event of various possible disaster scenarios. As I said above, this is not as hard as it seems. Consider the following seven step DR planning process:
Take stock of your assets - think about what systems, documentation, personnel , facilities, and other elements that are key to conducting your business. Make a list of them, rank them by importance, and realistically indicate for each how long you could operate without them.
Form a Strategy. Think about what you could do if each of those items were unavailable for a longer period than you indicated you could do without them. This will form your recovery strategy. If you don't have time to work through the list all at once, start with the most important item, and work your way down.
Document and Estimate. As you figure out a recovery strategy for each item, write them down, along with an estimate of the cost to implement. Some will be no or low cost, while others might be expensive. For those with higher costs, consider what it would cost in a disaster not to do them. You can use that information to prioritize items.
Prepare. For any of your recovery strategies that require formal action, such as ordering a backup Internet circuit, complete those tasks based on how you prioritized them.
Communicate the Plan. Let your employees know what the plan is, and what their parts will be. Distribute contact information, so employees can talk to each other in the event the plan is needed.
Test. This is the most intimidating step for most, but is often not as hard as it seems. You simply need to try out whatever your strategy is for each exposure. As an example, assume one of the strategies employed was a redundant Internet circuit. To test the strategy, you simply need to pull the plug on your primary circuit at a convenient time, to verify that the backup circuit works. Write the test procedures down for each strategy, and put them on a calendar for regular rechecks.
Maintain. Since your business is constantly changing, you can't simply put your plan on the shelf and hope you never need it. You need to factor business changes into the plan, and adjust it as necessary. This should happen at least every 6 months, and more often as necessary if your business changes more frequently. While there are numerous software packages available to help you record your plan and testing details, they don't have to be that formal. A Word document or Excel spreadsheet with recovery details is fine. The key is to record it in some usable form.
As I said, the above 7 steps are not rocket science - they just require focus and determination. Depending on your availability, it might be wise to retain a consultant to help facilitate discussions and suggest recovery strategies. The simplified process described above is not so complicated however that you can't do it yourself, time permitting.
I will conclude with one of my own DR failures, since we all can learn more from failures that successes. I was working for an SMB software company in Atlanta, with most of its work force at customer sites in the field, requiring access to corporate systems to do their jobs. We had built considerable reliability and redundancy into the central data center, and had some resources in the cloud to ensure availability. During a major snow event, all systems stayed up and were available throughout the event. Unfortunately, with everyone working from home, we quickly ran out of VPN licenses on our high capacity firewall, preventing the field employees, otherwise unaffected by the weather, from doing their jobs. Fortunately, this problem was quickly resolved (via my iPad while sitting in traffic trying to get home). Not all are so quickly resolved however, so proper planning is essential.
Remember, a developing a DR plan is not very helpful when done after the disaster. Start on yours today, and make sure you are prepared for whatever 2015 brings.