Power Checklist: Disaster Recovery Plan

Power Checklist: Disaster Recovery Plan

Development of a disaster recovery plan is a must. Although there may never come a time when the plan must be implemented, it is always best to prepare for any circumstance. A successful disaster recovery plan is a living entity. It is carefully planned and constantly updated to ensure that if the need arises to use the plan, it will continue to be valid.


Prepare for fire related disaster recovery.

Disaster recovery: How to protect your systems from flood threats.

Disaster recovery: Earthquakes.

In this series of three articles, Mike Talon reviews the basic recovery processes for three different types of natural disasters: fire, flood, and earthquake.


Creating an environment in which a company can operate regardless of the disaster is the key to an effective disaster recovery plan. The Power Checklist: Disaster Recovery Plan will identify the main elements that should be included in any disaster recovery plan and provide links to additional resources.


Use the following checklist to ensure that your disaster recovery plan includes the basic elements. Keep in mind that it may contain additional elements depending on your recovery requirements.

Data Backups/Storage

To plan for disaster recovery, you need to determine how many days of data can be lost without the company feeling severe repercussions. This timeframe can determine how often data backups must be performed. You also need to determine how it will take to restore data when a disaster does occur. Once these decisions are made, you can then determine which backup strategy is best for you.


  • Regular Backups - The disaster recovery plan must include backups of all resources required to perform critical business functions including computers, network devices, telecommunication devices, applications, electronic records and any other IT resources applicable to your environment. The recommended backup schedule for critical data is to perform a Full backup weekly and Incremental backups daily.


A full backup is performed by small organizations that have less data to back up or larger corporations that can afford faster backup equipment. A full backup consists of copying all files to a backup device. When the full backup is done, each file backed up will have its Archive attribute turned off.


Note: The Archive attribute is a setting on each file that shows whether the file has been modified. When a file is created or modified, the Archive attribute is turned on. When some backup types are performed, files with the Archive attribute are backed up and then the attribute is turned back off. This allows only changed and new files to be backed up.


An incremental backup backs up files that have changed since they were last backed up or those with the Archive attribute turned on. Once a file is backed up, its Archive attribute is turned off, so it will not be backed up again unless it is changed or a full backup is performed.


Restoring from the full backup is a simple process because all files should be present on the full backup. However, if you are performing incremental backups, the process of restoring files changes.


Because an incremental backup backs up only some of the files, the process of restoring all the files is a follows:


  1. The last full backup must be restored.
  2. Every incremental backup must be restored that was done since the last full backup, in the order in which they were done.


This puts back all the files that were on the system when the full backup was done as well as every changed file since then. Any file that was changed more than once would be overwritten by a later restore of the file from later in the week. For example, if Monday's incremental backup included files 2 and 5, the media would have the updated versions of these files. However, there may be updates to these files included in Wednesday's incremental backup.


If any day is skipped by not restoring the incremental backup from that night, you may miss a file that is not backed up again. For example, by restoring all from every night's incremental backup, except Thursday's, you may not have the most up-to-date version of all files.


Therefore, when restoring from an incremental backup, you must restore the full backup and every incremental backup since the last full backup to the time of the system crash. This will allow you to completely recover all data or as close to it as possible.


  • Off-site Storage - Hard copies of data critical to business functions should be stored in an off-site location.


Your off-site storage locations can be as simple as a locked safe with your own home or as complex as a locking fireproof cabinet at a secure location. How simple or complex will depend on the level of safety that you require. The key is that the tapes do not stay in the building. If the building is destroyed due to fire or flood, you will still have all your critical data.


Four things you're missing in your backup strategy. Robert L. Bogue discusses four fundamentals for developing a backup strategy.

Maximizing off site data storage for disaster recovery with iSCSI. Brien M. Posey shows you how to have instant data recovery using iSCSI technology.

 

Inventory List

A disaster recovery plan should include an inventory of all the hardware and software along with guidelines outlining when the inventory lists must be updated. For example, you may choose to revisit any inventory lists semi-annually if new hardware and software is introduced to the network on a regular basis. Otherwise, an annual review of all inventories should be sufficient.


  • Hardware Inventory - Create an inventory list of all the hardware you are using. This should include client and server hardware, network devices, telecommunication devices, and so on. The inventory list should also include the criticality of each resource.

  • Software Inventory- Create an inventory list of all the software you are using. This should include operating systems, applications, service pack, and so on. The version all software as well as the criticality should be included in the list.


Prepare for disaster recovery problems associated with custom applications. Learn more about the most common setbacks for custom applications.

Hardware/Software

Having spare hardware on hand is important to disaster recovery. The hardware that you do require will be dependent on the criticality (refer to the inventory list). For example, if a network device such as a router is deemed as being critical, you will likely want to have a spare router on hand in the event of a disaster.


  • Spare Hardware - Having replacement components nearby for critical hardware resources is important for any disaster recovery plan. For those resources that are not critical, procedures should be in-place for obtaining replacement parts from vendors.


When creating a disaster recovery plan, many people remember to include spare hardware parts but forget about the software.


  • Copies of Critical Software - You should have copies of any software, including, service packs, operating systems, applications, device drivers, and so on, easily accessible. Be sure to include copies of licenses for all software.


When it comes to replacing failed hardware and reinstalling software, consider documenting the current configurations. It will be easier and much faster to restore to a previous state if the configuration information is readily available.


Don't overlook licensing issues when planning for disaster recovery. Learn more about licensing issues when creating a disaster recovery plan.

Tech Tip: Document your system with System Information utility. This article outlines how to use the System Information utility to document your system.

Plan Maintenance

Maintenance of the disaster recovery plan needs to be included in the plan itself. Maintenance usually involves revisiting the plan on a scheduled basis to update on newly identified disasters as well as changes within the business.


  • Disaster Recovery Plan Updates - A disaster recovery plan is useless if it is not updated as the business changes. The disaster recovery plan should outline what warrants an update and how often it will be reviewed.


Changes that warrant an update to the plan may include the introduction of new software and hardware to the network, expansion of the business, new staff, or new technology use. The frequency of the plan maintenance will be determined by the business. If there are no changes to the business or no foreseeable new disaster threats, then maintenance will be limited.


Tech Tip: Perform a regular review of your DR plan to keep it effective. Learn the importance of regularly reviewing your disaster recovery plan.

Disaster Recovery Procedures

Disaster recovery will only be effective if users know exactly what to do in the event of disaster. Disaster recovery training is often an element that is missed in the disaster recovery plan.


  • Disaster Recovery Training - All staff need to know what to do in when disaster strikes and how to do it. This is accomplished by training users in disaster recovery procedures.


Regular training ensures that staff is current on the role they will play in disaster recovery. It is imperative that you develop a plan for regular staff training that covers two main aspects: What is the plan and how is the plan executed.


Staff needs to understand the elements of disaster recovery, the scope of implementation, and their individual (as well as collective) roles. Staff also needs to understand what to do and when to do it. There will be logical steps that must occur within a set sequence in order for disaster recovery to be carried out. Training staff on the execution of disaster recovery procedures will minimize confusion.


Staff that is not directly involved in disaster recovery can also be made aware of the procedures through email notifications, announcements, newsletter articles, posters or other awareness methods at least annually.


Getting help: Training for new disaster recovery technologies. Mike Talon discusses some disaster recovery training alternatives.

Keep track of your disaster recovery planning process. Take a look at another article by Mike Talon describing how to keep track of the disaster recovery planning process and how to communicate clearly with those involved in the planning process.  

Do More with Less: The reasons to keep disaster recovery in the hands of trained staff. Mike Talon looks at the importance of  putting disaster recovery tasks in the hands of trained staff.

Documentation

A disaster recovery plan needs to be documented in as much detail as possible. Without clear documentation, chaos will occur.


  • Document all Disaster Recovery Procedures - Documentation should include detailed steps to carry out the plan, contact numbers, data storage locations, persons responsible for specific procedures, and so on.


An important point to remember is the make copies of all disaster recovery plan documentation. Your documentation will be useless if it is destroyed in a natural disaster along with everything else. Copies of the disaster recovery plan should include hard copies, digital copies, and backup copies located off-site.


Testing

A disaster recovery plan is useless if it does not work as it is supposed to. The only way to work out any kinks in your plan is to perform regular testing.


  • Test the Disaster Recovery Plan - Once your disaster recovery plan is complete, put it into action and test it. Regular testing of the plan will also ensure that staff is familiar with recovery procedures.


Tech tip: Continue testing DR plans on a regular basis. This article summarizes the importance of testing disaster recovery plans on a regular basis.

Article ID: 22, Created On: 3/30/2011, Modified: 3/30/2011

Feedback (0)