Introduction - Enterprise Application Services



<Project Name>Disaster Recovery PlanTable of Contents TOC \o "1-3" \h \z \u 1.Introduction PAGEREF _Toc309026582 \h 21.1.Purpose PAGEREF _Toc309026583 \h 21.2.Assumptions PAGEREF _Toc309026584 \h 21.3.Business Continuity PAGEREF _Toc309026585 \h 21.3.1Critical Business Functions PAGEREF _Toc309026586 \h 21.3.2Recovery Point Objective PAGEREF _Toc309026587 \h 21.3.3Recovery Time Objective PAGEREF _Toc309026588 \h 32.Version Control PAGEREF _Toc309026589 \h 53.Overview PAGEREF _Toc309026590 \h 63.1 Application Overview PAGEREF _Toc309026591 \h 63.2 Hardware Overview PAGEREF _Toc309026592 \h 74.Architecture PAGEREF _Toc309026593 \h 84.1 Software: PAGEREF _Toc309026594 \h 84.2 Hardware PAGEREF _Toc309026595 \h munications PAGEREF _Toc309026596 \h 95.1 Communication Plan PAGEREF _Toc309026597 \h 95.2 Contact Profile PAGEREF _Toc309026598 \h 96.Recovery Procedures PAGEREF _Toc309026599 \h 107.Testing PAGEREF _Toc309026600 \h 118.Approval PAGEREF _Toc309026601 \h 12Dictionary of Terms PAGEREF _Toc309026602 \h 13IntroductionPurposeOne of the objectives of this document is to provide key Disaster Recovery personnel with all pertinent information in order to have the <Insert System Name> added to the University Disaster Recovery plan (if applicable). This plan will outline the functionality of the system, hardware, software, and provide an overview of the business need to allow the Disaster Recovery design team to make an informed decision on how to implement the best recovery model in the event of a disaster affecting the hardware, software, connectivity, or other unforeseen event that will prevent access, operation, or use of said system.AssumptionsThe disaster recovery of this System and/or application relies on the following critical assumptions. If any of these assumptions are not true at the time of the disaster, then the user facility must remain in downtime procedure mode until all such assumptions are true.<Insert assumption><Insert assumption><Insert assumption>Business Continuity Critical Business FunctionsIdentify the suspected organizational functions and/or activities that will be dependent on the application and/or system being implemented. Analyze the identified functions, and then determine only critical functions. Recovery Point ObjectiveOnce the critical functions of the application and/or system have been identified, each one must have a Recovery Point Objective documented. This describes the acceptable amount of data loss measured in time. Generally, this is the definition of what an organization determines is an "acceptable loss" in a disaster situation. Example: If there is a complete replication at 10:00am and the system dies at 11:59am without a new replication, the data written between 10:00am and 11:59am will not be recovered from the replica. This amount of lost time data has been deemed acceptable because of the 2 hour RPO. This is the case even if it takes an additional 3 hours to get the site back into production. The production will continue from the point in time of 10:00am. All data in between will have to be manually recovered through other means.Recovery Time ObjectiveDocument the Recovery Time Objective which will determine the duration of time for and a service level that a critical business process must be restored to after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity.This document provides an outline listed in the order of importance of the suspected “Critical Business Functions” that are reliant on the <Insert System Name>, Recovery Point Objective, and the Recovery Time Objective will be considered in the development of the Business Continuity plan of the afore mentioned system. Since the system is not fully implemented the anticipated Critical Functions, Recovery Point and Recovery Time Objective’s must be re-evaluated prior to the finalization of the Business Continuity plan.Business Continuity OverviewCritical Business FunctionRecovery Point ObjectiveRecovery Time ObjectiveCritical Business FunctionRecovery Point ObjectiveRecovery Time ObjectiveCritical Business FunctionRecovery Point ObjectiveRecovery Time ObjectiveVersion ControlVersionDatePersonChange1.0Initial Document CreationOverviewApplication OverviewOutline all components and overall use of application. Please include vendor documentation as an attachment, if applicable.Application/Software OverviewApplication Name:Application Description:Application Type:Version at Install:Current Version:Delivery MethodFinancial ImpactY/NIf yes Explain:Account Management of UsersMedical System ImpactY/NIf yes Explain:Access method:Port:User LocationUsed By Department(s)Install MediaReinstall Media Location:Application/Software BackupApplication ComponentData Size GBFrequencyMethodStorageHardware OverviewOutline all components of the hardware required or used for the implementation. Please include vendor documentation as an attachment, if applicable. Hardware/ServerServer TypeServer brand:Server topology:Server model #:Server serial #:Disk InformationNumber of DisksSize of each diskDisk TypeDisk InterfaceRaid NumberTotal Available Space Operating SystemOS:Service Pack/Version:Physical LocationStreet AddressSuiteCityStateZip CodeServer Access InformationServer(s) name:IP Address(s):xxx.xxx.xxx.xxxxxx.xxx.xxx.xxxxxx.xxx.xxx.xxxxxx.xxx.xxx.xxxMac Address(s):xx-xx-xx-xx-xx-xxxx-xx-xx-xx-xx-xxxx-xx-xx-xx-xx-xxxx-xx-xx-xx-xx-xxActive Directory OU:Warranty InformationLength of WarrantyWarranty Start DateWarranty End DateLaborPartsSystem and/or Application InterfaceInterface Engine:Interfaces – Inbound:Interfaces – Outbound:Other Comments:ArchitectureSoftware:Refer to the Architecture Design document.HardwareRefer to the Architecture Design Plan document. CommunicationsCommunication PlanRefer to the Communication Plan for unscheduled downtime procedures, processes and the order in which the contacts below will be notified of said downtime. Contact ProfileSupport PersonnelHardware Administrator(s)Contact TypeNameE-MailOfficeEXT.Cell/PagerAdministratorSecondary AdminBack/Restore AdminNetwork AdministratorsContact TypeNameE-MailOfficeEXT.Cell/PagerAdministratorSecondary AdminBack/Restore AdminApplication AdminContact TypeNameE-MailOfficeEXT.Cell/PagerAdministratorSecondary AdminBack/Restore AdminVendorsContact TypeNameE-MailOfficeEXTCell/PagerVendor ContactTechnical Contact:Alt Technical ContactVendor SupportTechnical Support LinksUniversity Support Link(s)Vendor Support Link(s)Offsite Backup Storage Link(s)Recovery ProceduresThis section describes the recovery strategies identified for equipment and services.Items that may be included:Server Recovery Procedures: (include server restoration priorities)Application Recovery ProceduresApplication Functionality and Data Integrity Validation ProceduresComplete Restore needsSecurity Procedures: (If warranted)System Restoration ChecklistThis may also just be a reference to the current Disaster Recovery Plan. Identify which schedule the system and/or application will belong to.TestingIdentify where this system and/or application will fall into the current Disaster Recovery Plan testing phases. If it does not fall into the university current disaster recovery testing, outline the testing for this system or application.ApprovalThe individuals below agree that they have reviewed and approved the requirements outlined in this Support Documentation.APPROVED BY:Function RoleName and TitleSignatureDateAppendix ADictionary of TermsAssumptions - an assertion about some characteristic of the future that underlies the current operations or plans of an organization.Business Continuity - an extension of disaster recovery, aimed at allowing an organization to continue functioning after (and ideally, during) a disaster, rather than simply being able to recover following a catastrophic event.Critical Business Function - A function may be considered critical if the implication for stakeholders of damage to the organization is the halt of day to day business. A function may also be considered critical if dictated by law. Perceptions of the acceptability of disruption may be modified by the cost of establishing and maintaining appropriate business or technical recovery solutions.Recovery Point Objective - This describes the acceptable amount of data loss measured in time. Generally this is the definition of what an organization determines is an "acceptable loss" in a disaster situation. Recovery Time Objective (RTO) is the duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download