Disaster Recovery: Understanding Key PrinciplesDisaster Recovery, business resumption and emergency preparedness are three...
Disaster Recovery: Defining Project ScopeHow to Stop Scope CreepxsOne of the most important steps in Disaster Recovery pro...
features. After the cutoff date if any changes happen in production, the application team has tocommunicate and implement ...
In general, DR solutions cost too much, requiring enormous investment in additional server andnetworking hardware to repli...
Disaster Recovery: Develop Efficient Critique for an Emergency
Upcoming SlideShare
Loading in …5

Disaster Recovery: Develop Efficient Critique for an Emergency


Published on

Disaster recovery will be the procedure, policies and procedures that are associated with getting yourself ready for recovery or continuation of technologies infrastructure that are vital for an organization following a natural or human-induced catastrophe. Disaster recovery is really a subset connected with business continuity. While business continuity entails planning for maintaining all facets of a company functioning in the midst of bothersome occasions, disaster recovery targets the IT or technology techniques that support company features.

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Disaster Recovery: Develop Efficient Critique for an Emergency

  1. 1. Disaster Recovery: Understanding Key PrinciplesDisaster Recovery, business resumption and emergency preparedness are three integratedcomponents of a business continuity management solution. Some organizations focus on any oneor part of the solution. It is possible to have a perfectly functioning redundant data center andstill business cannot continue. So it is important that all the below three components of businesscontinuity management are tightly coupled and integrated to ensure successful businesscontinuity.  Emergency preparedness  Business resumption  Disaster recoveryDisaster recovery addresses recovery of critical IT infrastructure such as hardware, software,telecom, network and data for bringing up the mission critical applications to support thebusiness.Business recovery involves the recovery of critical business functions and processes that relate orsupport the delivery of core products/services to customers. It focuses on products/services, non-IT employees, vital records and other stakeholders involved in supporting critical businessfunctions.Emergency preparedness is designed to enable an effective response to an event. It focuses onstabilizing the situation. Generally this is coordinated by a team responsible for health & safetyof the employees. The scope of emergency preparedness includes utility failures, non-availabilityof employees/pandemic preparedness and non-availability of facilities due to bomb threats, etc. Italso handles transportation and coordination with external agencies.
  2. 2. Disaster Recovery: Defining Project ScopeHow to Stop Scope CreepxsOne of the most important steps in Disaster Recovery project management is defining thedisaster scope. It will help the project team to maintain the control of the project. Clearlyunderstanding whats included in a project is the only way of guaranteeing its success.Disaster scope should include the nature of impact and timeline. For example, it may besomething like, “If the primary data center is down in the event of any major incident, howto survive the critical business processes and applications for 3-4 weeks until the primarydata center is brought up.”The clear disaster scope definition will help in setting up the expectations very clearly and ironout all issues in the scope.Another challenge is the ongoing upgrade and development changes in applications. There willbe a potential delay because of these changes and upgrades in completing the disaster recoveryproject. So the disaster recovery project team should ensure a mutually agreed cutoff date andcommunicate to the application team that the disaster recovery environment will be similar toproduction as of that cutoff date. If any changes or upgrades are required, first it should beimplemented in production before the cutoff date and the disaster recovery environment will beimplemented similar to production as on that date and it will not have any new or additional
  3. 3. features. After the cutoff date if any changes happen in production, the application team has tocommunicate and implement the same changes to the disaster recovery environment also. Thishelps to avoid any technical refresh or upgrade project merging with DR project.Also, we need to ensure disaster recovery is not confused with high availability. High availability(HA) is for local system or architecture failures and generally HA is a solution under the sameroof. But disaster recovery allows an application to be recovered at an alternate site away fromthe production site in case a higher level failure or disaster strikes.Hardware Resource PlanningHow to Handle Hardware PlanningOne of the other major challenges faced in resource planning is end of life (EOL) hardware. Thiswill be a common case if the application is older and has been in use for more than 10-15 years.If the production environment is in EOL hardware, then there will be a requirement to buy newequivalent hardware. The issue in new hardware is that it will not support older operating system(OS) versions. Sometime, the new M5000 server procured for disaster recovery will support onlySolaris 10 whereas the production environment is still running on Solaris 9. So it may benecessary to upgrade the production environment to Solaris 10 or procure hardware which willbe compatibleEffective BIA in Disaster RecoveryHow to Perform an Effective BIASometimes it may be necessary to conduct a BIA in a very short time and it may not be possibleto conduct a detailed BIA for all the applications in the organization. In those cases, it issuggested to first have a discussion with senior management of each business division to identifythe candidates for a detailed BIA. It is also necessary that the audit team and IT support team beinvolved in the discussion and short listing of the applications which are considered as verycritical by respective business units. Then a BIA questionnaire can be sent to the respectiveapplication owners to determine the impact, RTO/RPO and dependencies. One of the commonchallenges in conducting a BIA is explaining RTO and RPO to the business users and ensuringthat there is no duplication or overlap in any impacts among the upstream and downstreamapplications. It may be necessary to conduct several awareness sessions and meetings to ensureall the doubts are clarified. It is also necessary to ensure that BIAs should be signed off by theirrespective business finance team to avoid any errors in estimating the impact.Lesson Learned: Ensure that the BIA is clearly understood by the person filling it out, andvalidate the financial impact with respective finance teams to avoid any errors in impactestimation.Maximizing the Return on Investment in HardwareCan the Disaster Recovery Hardware be utilized economically?
  4. 4. In general, DR solutions cost too much, requiring enormous investment in additional server andnetworking hardware to replicate existing data centers – increasing infrastructure needsaccordingly. These expenditures inflate the cost of IT, while reducing average system utilization.These cost and complexity challenges have effectively restricted or degraded many IT disasterrecovery plans.It may be very difficult to convince management to purchase new hardware when it is known toeveryone that new hardware is going to be kept idle until a disaster strikes the primary site. Also,another issue is that when it is known that the performance in new hardware is going to be betterthan the existing old production hardware, there will be pressures to use the new hardware forproduction.One solution considered in those cases is to use the old hardware for DR and use the newhardware as production. Another solution may be to use repurposing software which can allowservers to be used as a staging or QA environment during normal circumstances and bring up thedisaster recovery environment quickly when disaster strikes. This way the hardware procured isnot kept idle and is used effectively in normal times.Also, it is mandatory to analyze the consolidation and virtualization options while planning anyhardware requirements for disaster recovery which can reduce the hardware requirementsconsiderably.Lesson Learned: Consolidation, Virtualization and Repurposing software will be very useful inoptimizing the cost of hardware.Improving the Disaster Recovery ProcedureHow to Improve the Response and Reduce the Recovery TimeIn a time of disaster, there is a tremendous amount of pressure and stress to get everything backup and running and available to users. In manual processes, mistakes will be made for a varietyof reasons. Thus, it is suggested to automate the recovery process as much as possible. Having asimplified and automated disaster recovery processes would eliminate the unnecessary timedelay and manual errors during the recovery.Also, traditional recovery procedures involve several groups such as operating system, database,etc. It is recommended to reduce these levels of dependency to a minimum level and create a firstresponder who can run all these procedures alone as an immediate step and contact the respectiveadministrators only when there is an issue in the procedure. Simple UNIX scripts can be used toautomate most of the steps in the recovery procedure which can simplify the steps and avoid anymanual error in syntax and reduce the recovery time. These steps are helpful to have a betterrecovery procedure to respond very quickly to any disaster incident.Lesson Learned: Simple UNIX scripts can make the recovery steps less complex, avoid manualerrors and reduce the recovery time substantially.