Creating a disaster-recovery application inventory
- 18 June, 2008 19:17
The continuing advancement in the numbers and kinds of options available to assist with disaster recovery is encouraging growing numbers of organizations to look at ways in which to enhance their disaster recovery capabilities. Storage vendors are enhancing their replication capabilities, tools for rapid recovery for databases and core applications like Exchange are finding their way into organizations of all sizes, and, of course, virtualization has opened new disaster recovery opportunities to a wide range of organizations.
However, before placing the technology cart before the horse, a critical phase in any form of disaster recovery planning and design is to establish a solid understanding of applications and their interdependencies. A good initial step in this process is the establishment of a DR application inventory.
What should a disaster recovery application inventory include? While requirements can vary depending on the organization, a basic listing should include the following:
Application name and description
- Business function - the business unit or functional area the application supports
- Business process - the specific business process supported
- Recovery objectives - stated RTO and RPO targets for the application
- Known related applications - this includes both applications that act as sources and targets in the business process
- Server details - a list of the actual servers both physical and virtual on which the application resides along with configuration details
- Storage details - the actual storage devices and LUNs allocated to the servers
- Software requirements - specific information about the software
In mature organizations, this information would likely reside within a configuration management database (CMDB) and could be readily obtained. However, in many environments, the data is not centrally consolidated, particularly if significant attention has not been paid to disaster recovery previously.
Such an inventory can form the basis for developing a multi-tiered suite of DR services and a recovery plan that can move an IT organization closer to that non-trivial goal of meeting business recovery requirements.