Disaster Recovery Plan

Disaster Recovery is the process, policies and procedures of restoring operations critical to the resumption of business, including regaining access to data (records, hardware, software, etc.), communications (incoming, outgoing) workspace, and other business processes after a natural or human-induced disaster.



Here are some common aspects of designing a Disaster Recovery environment for a business application:



1. DR Server

The server-that you intend to use in case of disaster-should contain the same version/patch of the Operating System as the primary server. You have to ensure that the disk allocation is similar to that of primary. You need not allocate identical server resources on the DR site, but you may need them when you intend to run the DR site as primary in the event of a disaster.



2. Standby Database

Most of the database vendors provide you with an option to install and maintain a standby database, which keeps itself cloned with the primary database. Ex: Oracle provides DataGuard. You may also explore and use third-party software if you are not happy with the existing solution.



The most common methods of keeping a cloned database are:

a. Log shipping from primary to DR database

In this method, the redo logs that are created in the primary database are copied and applied to the DR database. These logs may be applied immediately (synchronous) or in with a delay/independently (asynchronous).

b. Storage level replication

In this method, the changes made to the files are written to the primary storage and the DR storage. The database transaction complete only when the write operations are successful on both storage devices.

3. Synchronizing File Systems

Ensure that the file systems are synchronized, so that the application data files, profiles, scripts, logs, software and user environment is cloned at the DR site. Don't forget OS configuration files such as service and host files in the sync list. The server OS usually come with utilities to help synchronize data remotely.



4. DNS/Firewall

When the DR server replaces the primary, the IP address for the host name changes. The DNS server and FIrewall rules should be updated with the new IP and the users/application accessing via IP address or maintaining a host file should be informed of the change.



5. License Aspects

Some software vendors provide licenses based on the hardware used. For any hardware change, you have to apply a new license. In case of a DR, from license perspective, you are essentially changing your hardware.



6. The Plan

When a disaster takes place, you will not have the peace of mind to take sound decisions. Everyone will be confused as to what to do to get the business application back to functional state. You can minimize the chaos, by documenting and testing the procedure to get the cloned server and application to work as your primary. Take into account of the safety procedures, management approval process and communication process into these documents.