Issue link: https://cp.revolio.com/i/1012043
12 | THE DATA CENTER JOURNAL www.datacenterjournal.com DUE DILIGENCE OF AN EFFECTIVE DISASTER- RECOVERY STRATEGY When it's time to activate their disaster-recovery (DR) strategy, the challenge too many organizations face is employing a plan that's been sitting untouched for a year or longer, while nothing with the outage seems to be going as expected—nor should it be. Indeed, every disaster will have a variety of uncontrol- lable variables. Although numerous circumstances trigger these events, three common yet avoidable factors cause a DR strategy to fail. ey are the lack of the following: • Testing • Updated documentation • DR scenario training In addition, a common scenario is that many IT-oper- ations staff members are functionally constrained because they were absent during the initial design of a DR plan, and they're unfamiliar with the processes. How do organizations validate and implement a DR strategy that incorporates the three crucial elements of a successful DR plan without hindering production and disrupting users or business operations? e following multiphase approach will help minimize downtime as well as save costs and, in turn, minimize the impact of poten- tially disastrous events. • Preplanning phase • Phase 1: Assessment • Phase 2: Documentation • Phase 3: Test • Phase 4: Tabletop PREPLANNING PHASE e preplanning phase requires answering numerous questions about the organization's business operations, po- tential financial impact and customer experience with re- spect to tolerance. A careful analysis and ranking of critical importance for each application empowers a fundamental understanding of what's critical to the business. is step helps the enterprise determine what the financial conse- quences may be, not only to the business but to customers as well. In the event of a failover, determining the tolerance level of each application is critical. It's then possible to define and evaluate an acceptable recovery-point objec- tive (RPO) and recovery-time objective (RTO) for each application. e financial damage a business suffers during downtime, with each hour spent to bring an application back, will continue to increase spending (and potential revenue loss). In addition, understanding what and how much data could be lost since the last scheduled backup is critical. Doing so will facilitate more-accurate knowledge of the costs associated with each application and help manage these costs more effectively. Once you have a solid understanding of the business impact of each application, you can place each one into its appropriate group: Tier 1, 2 or 3. is step provides a more cost-effective basis for how much you invest in each application. PHASE 1: ASSESSMENT An initial assessment of the current environment and planned architecture for replication and failover is essential to ensuring a DR strategy's effectiveness. is assessment requires the full attention of the infrastructure and applica- tion teams. ey must work together to gather information pertaining to all applications and their documentation. e teams should obtain an accurate list of all servers associated to each application and determine the appro- priate replication/data-protection tool required for the server types. is phase is critical to provide the necessary information to start the disaster-recovery process without unanticipated roadblocks. An assessment document should be created for each application, separated into two sections and including the following: Business • Application leads • Infrastructure leads • User base • Criticality rating • Operating hours needed Technical • Authentication information • Backup strategy • Application interdependencies • Interface requirements • Server information • Required database features • Application-delivery method PHASE 2: DOCUMENTATION In addition to the assessment document from Phase 1, other documentation that needs creation or updating may include the following: • DR failover-process flow diagram—is document contains swim lanes providing a workflow between each departmental and technical component. • Architecture diagram/infrastructure—To create a comprehensive architecture diagram, the DR-plan- ning team must identify these items: