What We Have To Say

July 12, 2018
Column by Steve Swiecichowski,
SRC Technologies Director of Service Delivery

Backing up data is not enough when planning for disaster recovery

Without sufficient preparation and protocol, the downtime for businesses – big and small – impacted by IT disruption can be costly for even a minute.

GREEN BAY, Wis. — When it comes to disaster recovery, complacency is the biggest hurdle most organizations face. Who wants to think about, spend money on and plan for a disaster that might never occur – especially when everything is working just fine? Nobody.

But if you ask those same people when disaster will strike, or what kind of disaster they think may happen to their data, they realize that disaster-recovery solutions are really an insurance policy for their business. Most people understand the need to back up their data and to store a copy off site, and while that is important, backing up data is just the first step in a disaster-recovery plan.

Let’s say you have your data backed up, and it’s stored safely off site. Now, what happens if your server room catches fire and all the equipment is ruined? On what equipment will you restore your data? Who is responsible for managing that restore process? How long will this process take – and what will it cost you in the meantime?

According to market research firm IDC, studies indicate nearly 80 percent of small businesses have experienced an IT incident that resulted in downtime which cost them between $137 and $427 per minute. In larger businesses, depending on how they operate and how IT-dependent they are, the cost of downtime can be significantly higher; for the Fortune 1000, that hourly cost can be closer to $1,667 per minute – or $100,000 per hour. And with more than half of IT respondents in a Channel Partners survey indicating their companies lack effective BC/DR plans, the importance of disaster-recovery planning becomes crystal clear.

Six Key Elements of a Good Disaster-Recovery Plan

Here’s a checklist that includes the top six elements every disaster-recovery plan should have.

1. Establish a Backup Plan: Building a disaster-recovery plan – and testing it on a regular basis – is critical to the timely, accurate recovery of data that may have otherwise been lost in the event of an IT failure. Start by establishing a backup plan and, by all means, keep a copy of it off site, but don’t stop there.
2. Identify Recovery Participants: Whether you’re in an actual emergency situation or completing periodic tests, you need to be able to work the plan you’ve already created – and that means everyone must know who is responsible for performing each task. In disaster recovery, there needs to be several different teams of people established up front. The first is a team that conducts the assessment and reports to the decision makers, so they can decide if they need to declare the incident an actual disaster or not. A second team performs the restore, and a third team tests it. There should be a recovery coordinator and a list of specialists, each with an assigned role during the recovery process. And determine who the project manager will be – you need one overall point person calling the shots once a disaster-recovery plan is set in motion.

5. Establish Communication Protocols: You need a way to communicate with the team members throughout the recovery process. Everyone will need regular status updates – how will those be delivered? What will you do if your email system is down, for example?
6. Determine the Sequence of Events: Now that you’ve established who will do what and how you will communicate, turn your attention to prioritizing your technical tasks. Clearly, giving technicians network access will be high on the list so they can actually perform the restore. If your equipment is damaged or destroyed, everyone needs to know what alternative infrastructure to tap into. Next, consider mission-critical apps – if you have a particular application that runs your business, it may be the first one you want to restore. Assign priority levels to each task and develop a sequence of events that should be followed.
7. Test the Restore: Once you have your data restored, it’s time to call on your restore testing team to verify content. Identify what their testing criteria should be – are they just testing one or two apps or running through a sequence of functions that would be required to add a new customer or complete a sale? Determine what the verification process looks like and what criteria are required to declare the restore a success. Testing your restore process is the only way to ensure it actually works, and it’s the only way to fix the issues you identify along the way – before disaster strikes.
8. Create a Scorecard: When you complete a restore – or even just a test of your disaster-recovery plan – be sure to create a report that includes the actual time each stage of the process took to complete and notes about any issues that were identified.

Steve Swiecichowski is the Director of Service Delivery for SRC Technologies in Green Bay, Wisconsin.

About SRC: Located in Green Bay, Wisconsin, SRC Technologies is a managed service provider that offers IT infrastructure and data-security consulting and management to enterprise and midmarket organizations, enabling their IT to enhance business performance. For more information, visit srctechnologies.com.