By Steve Swiecichowski, Director of Service Delivery
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 that nearly 80 percent of small businesses have experienced an IT incident that resulted in downtime which cost them between $137 and $427 per minute – and because we’re talking about small businesses, those numbers are on the low end.1 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.2 Research firm Gartner cites even higher figures, offering an average cost of $5,600 per minute.3 And with more than half of IT respondents in a Channel Partners survey indicating that their companies lack effective BC/DR plans,4 the importance of disaster recovery planning becomes crystal clear.
Six Key Elements of a Good Disaster Recovery Plan
While it may be clear that you need a good disaster recovery plan, not everyone knows what that plan should include. To help, we’ve put together a checklist for you that includes the top six elements that every disaster recovery plan should have.
- Establish a Backup Plan: While ensuring data is backed up and stored in a secure off-site facility is certainly an important first step, it’s only one step out of several. I can’t tell you how many clients have told us they’re ready for a disaster because they have a backup plan in place, but they haven’t tested their restore capabilities or determined specific responsibilities -- who will do what -- when disaster strikes. 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.
- 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 as I mentioned in my first point above. In disaster recovery, there need 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. Create a list of each of these people, what their roles will be, and how you can best reach them both during and after business hours. Include backup personnel in case a team member is on vacation or out of the country. 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.
- 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?
- 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.
- 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. Remember that there will be steps along the way that have to be enacted to give the testers permissions and access that will be required, so be sure to give your testers a way to communicate with administrators who can help them with this and to allot enough time for the testers to work through these hurdles while doing their job thoroughly.
- Create a Report: 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. One of our clients, for example, needed a key code from a vendor in order to run a test of a business-critical application; they had not thought about that until SRC tested their restore process, and now obtaining that key code is a step built into the client’s disaster recovery (and DR testing) plan.
One final thought: It’s also important to update your disaster recovery plan anytime you make significant changes to your IT environment. Even if your environment doesn’t change, at a minimum, meet with your disaster recovery team and ask what needs to be updated in your disaster recovery plan – don’t just create it and tuck it away for a year or two. If you do that, chances are it won’t work when you need it. Testing is also an important part of the process. I know it’s hard to spend the time and man-hours to do that when things seem to be going well, but people rarely know when something is about to go wrong. 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.
Want to learn more about backup and disaster recovery? We’ve got a couple of two-part blogs that are a great place to start. Read “Answer Truthfully: Are You Confident in Your Backup Solution,” then follow that with part 2 of that series: “Eight Data Protection Questions Every SMB Needs to Answer.” You may also enjoy a two-part blog entitled: “Backup Testing May Be the Most Important Thing Your IT Team Ever Does” – you can read Part 1 here, and Part 2 here. You may also want to explore SRC’s data protection and recovery services, then contact us to find out what SRC Technologies can do for you.
1 Carbonite: Downtime Costs Small Businesses Up To $427 Per Minute
2 Forbes: Why CTOs and CIOs Should Care More About the Cost of Downtime and DevOps.com: The Real Cost of Downtime
3 ZDNet: The Astonishing Hidden and Personal Costs of IT Downtime and Gartner: The Cost of Downtime
4Channel Partners 2017 BC/DR Survey: 5 Disaster Disconnects: Survey Shows Partners Must Educate Customers on BC/DR