Today we’re sharing insight from guest blogger, Chad Orlikowski, Vice President of Operations for ENS Group. We hope you enjoy Chad’s wisdom and perspective.
I often see companies implement technology first without truly understanding how their disaster recovery procedures will be executed. As a result, the recovery tends to be chaotic and less effective than it should be. How can this best be avoided? I recommend looking at the following key areas when developing your business continuity plan and technology strategy:
What are the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) requirements of your business? RTO refers to how much downtime you can realistically endure. Everyone of course wants instant recovery, but often the means to develop this level of response aren’t available. And RPO is how much data you can lose in the event of a complete failure. Can you tolerate losing 12 hours of data? Or 24 hours?
It is important to identify both RTO and RPO upfront so you can build your plan and technology solution to meet those expectations.
Who will lead your disaster recovery efforts during an outage? Ideally, you’ll have representation from all critical business areas. This team should be predefined and communicated so everyone knows who they will need to look to for further direction.
It is also important to consider locations in this discussion as your team could be geographically diverse. Locations may also be critical when initiating a failover and determining how to reroute IP traffic from remote locations to a new data center.
3. Third Party Contacts & Contracts
In most cases when you experience a disaster recovery event, third parties will be involved. All parties who need to be leveraged during this time must be clearly documented and communicated to your team so they can take action as soon as needed.
As many tasks and directions as possible need to be defined ahead of time so your disaster recovery team can effectively delegate and direct the activities to failover/recover.
The technology stack should be designed to enable each of the requirements identified and documented in the other key areas. Each level of the stack will support and reinforce the disaster recovery strategy within the means of the organization.
- Compute: What redundancy needs to be in place to mitigate localized failures such as a server or host failure? Virtualization often plays a key role here as it will allow you to separate the server needs from the actual hardware. Redundant hosts allow for local failure that is rapid and results with very little downtime.
- Storage: Storage for Compute needs to be protected on multiple levels - from redundant controllers, to backups, to offsite replication.
- Backups: Local rapid recovery backups need to be in place for day-to-day needs. At a minimum, offsite backups should be in place. However, a better design would include the ability for offsite replication that allows the Compute and Storage environments to be turned up quickly. This could be a second location owned by your organization, a colocation facility, or a disaster recovery as a service (DRaaS) option. They all have pros and cons that you and your team should vet.
- Network: If the headquarter site is completely down, with little to no options for recovery, how will you minimize downtime to switch over to an alternate location? Network diagrams, ISP connections, firewalls, and load balancing technologies will play into this consideration.
- Critical Communications: What phone system failover will be required? Can mobile phones be utilized due to their ubiquity? If so, do you have a current mobile phone list for all critical business functions and personnel?
After each of these items have been analyzed and implemented, the most important task is to test the plan. When was the last time you attempted to recover from a mock failure? Almost everyone says “never.” By testing you find the holes in the plan, which allows you to remove as many variables as possible that could interfere with a successful recovery.
Before implementing new technology solutions for business continuity, take time to consider these 6 elements in order to create a more effective and comprehensive disaster recovery plan.
This content was written and shared by guest blogger, Chad Orlikowski.
Chad Orlikowski is an I.T. professional with years of progressive experience in network technologies, Windows Server architecture, virtualization platforms, disaster recovery and business continuity planning and consulting. As Vice President of Operations of ENS Group in Fort Wayne, Indiana, Chad oversees their four major practice areas: Security, Network Technologies, Data Center, and Managed Services. He also works directly with clients to understand their business processes and needs. His experience and approach allow him to easily discuss complex I.T. issues to both technical and non-technical customers at all levels of corporate hierarchy.