{"id":33520,"date":"2019-06-21T18:13:44","date_gmt":"2019-06-21T14:13:44","guid":{"rendered":"https:\/\/www.msp360.com\/resources\/?p=33520"},"modified":"2021-03-24T16:10:10","modified_gmt":"2021-03-24T12:10:10","slug":"disaster-recovery-plan-checklist","status":"publish","type":"post","link":"https:\/\/www.msp360.com\/resources\/blog\/disaster-recovery-plan-checklist\/","title":{"rendered":"Disaster Recovery Planning Checklist"},"content":{"rendered":"

Being prepared for a disaster starts with a plan. Creating a disaster recovery plan<\/strong> (DRP) is a documented set of procedures to execute to recover a business IT infrastructure in the event of a disaster.<\/p>\n

In this guide, we\u2019ll explain how a disaster recovery plan differs from a business continuity plan, discuss its key elements and provide a checklist of what you have to keep in mind when creating such a plan.<\/p>\n

Introduction<\/h2>\n

It seems that not a week goes by without news of another organization that has had all of its files encrypted by ransomware, a data center hit by a natural disaster, or a cloud application that becomes suddenly unavailable. These businesses range from one-person shops to city governments, to one of the largest shipping concerns in the world.<\/p>\n

The amounts of money involved grow dramatically with the size of the company, but the chances of the company surviving without their data are worse for smaller businesses that may lack the funds to go 30 days or more without revenue if a disaster occurs.<\/p>\n

If your business cannot do without all of its files, apps, and computing capacity, there is a critical need in a disaster recovery plan, no matter what size your company is or where your files are located.<\/p>\n

\n
\n
FREE whitepaper<\/div>\n
Backup and Disaster Recovery on AWS<\/div>\n
Every minute of downtime means money lost.
\nPlan your perfect disaster recovery strategy on AWS:<\/div>\n\"CTA\"<\/a><\/span><\/span>\n<\/div>\n
\"whitepaper<\/div>\n<\/div>\n

Disaster Recovery Plan vs Business Continuity Plan<\/h2>\n

Recovering from a disaster will have two parts \u2013 finding a place to put files back, and then actually putting them back. If a disaster such as a fire, hurricane, or flood destroys your data center, you\u2019ll need new servers to restore files to.<\/p>\n

Even if there is a backup that\u2019s effective and complete, where will the files go? <\/p><\/blockquote><\/div>\n

If the problem is ransomware, or a service provider losing your files, it may be possible to restore them to their original locations, but the servers themselves may have to be re-configured with different network addresses, or your workstations may have also been encrypted and will need to be restored before users can resume their work.<\/p>\n

Further reading<\/span> Disaster Recovery FAQ: Essential Definitions for IT Pros and MSPs<\/a><\/p>\n

BCP+DRP=BCDR<\/h3>\n

Both parts of the plan, the plan to ensure users can continue to work, and the plan to get files back are critical. This is why the BCP (business continuity plan) and DRP (disaster recovery plan) are often merged into a single plan.<\/p>\n

Learn the difference between disaster recovery and business continuity in more detail and check how to ensure that the disaster recovery solution meets the requirements of a given business continuity plan:<\/p>\n

Further reading<\/span>\u00a0Business Continuity vs Disaster Recovery vs BCDR<\/a><\/p>\n

\n
\n
FREE ASSETS<\/div>\n
MSP Business Continuity Plan<\/div>\n
Build an efficient business continuity plan and increase your safety and security<\/div>\n\"CTA\"<\/a><\/span><\/span>\n<\/div>\n
\"WP<\/div>\n<\/div>\n

Disaster Recovery Plan Checklist<\/h2>\n

\"Prepare1. Prepare your end-users<\/strong><\/p>\n

You can start the process of creating a plan by educating your end-users. A quick search on the web will uncover a wide variety of disasters that have recently befallen companies like yours. Share these with your employees and ask for their help in figuring out ways to get around the problems.<\/p>\n

\"Identify2. Identify business processes<\/strong><\/p>\n

The first step in creating a BCDR plan is to identify all of your business processes. This includes not only what data is stored where, but can include individuals with critical knowledge that is not written down anywhere.<\/p>\n

For example, a company recently found that the only person with access to $190 million in company funds stored in a cryptocurrency account had died or disappeared. Another company found that the only user with a key to their account had forgotten the code, which cost them $30,000. What if there is only one user who knows how to create an invoice through the accounting system, and they are hit by a bus on the way to work?<\/p>\n

\"Prepare3. Prepare for coming disasters if you are warned<\/strong><\/p>\n

If you have sufficient warning of an oncoming disaster, and your employees haven\u2019t left to take care of their homes, there are steps you can take to protect your site before disaster arrives.<\/p>\n

If you know an extended lightning storm is coming, shut down and unplug major systems. Make sure you can recover them after the storm. If a flood is coming, shut down systems and get equipment up above expected flood levels. If a hurricane is coming, nail plywood over the windows.<\/p>\n

\"Make4. Make use of available tools<\/strong><\/p>\n

There are procedural methods such as ISO 9001 that can help to identify and document all business processes. It isn\u2019t necessary to adopt ISO 9001 to make use of the techniques, just to ensure that you look at all the steps in your customer\u2019s business processes and make sure they can survive a disaster.<\/p>\n

You may find that some employees are reluctant to document their day-to-day activities, whether because of a sense of turf or so that they remain irreplaceable. One simple way that some organizations have used to motivate employees to cover their bases is to point out that vacations can\u2019t be taken if they have information the company can\u2019t do without.
\nAgain, this doesn\u2019t have to be complex and include every possible step \u2013 it\u2019s only necessary to identify potential sticking points and document them.<\/p>\n

\"Locate5. Locate data and create a backup plan<\/strong><\/p>\n

After identifying all the processes and what information is stored where, it\u2019s time to begin creating a plan to find and back up all that data. At one time, this would have involved backing up the mainframe. Today, with data on individual users\u2019 PC\u2019s, servers in the data center, in one or more public clouds, and stored in private clouds as well, just finding all the data your organization might be using could take a while, and you might find that some users have added to the pile after your plan was completed. This is why testing and regularly revisiting the plan is also a necessity.<\/p>\n

Further reading<\/span> Backup Plan: The Ultimate Guide to Saving Your Data<\/a><\/p>\n

\"DR6. Test, test, test<\/strong><\/p>\n

The plan needs to be tested. Regularly tested. No, you should test a lot. The annals of IT are full of stories of backups that completed without a hitch for years, until someone tried to restore, at which point it was found that the backups weren\u2019t complete or that they\u2019d been failing silently for months or years, and that there was no way to recover lost files. So test. You don\u2019t have to test the whole system every day, or a week, or even a month.<\/p>\n

\u00a0<\/a>\"CTA\"<\/a><\/span><\/span><\/div>\n

A useful schedule might be to test the whole system once it\u2019s first built, then a different directory every week, a full server once a quarter, and the whole data center once a year.
\nIt\u2019s perfectly feasible to make most tests non-disruptive \u2013 restore files to an alternate location, and make sure they\u2019re all up to date, then delete the copies once they\u2019ve been verified.<\/p>\n

However, some tests may need to be disruptive \u2013 for instance, to test a backup that includes moving servers from one location to another, it\u2019s necessary to test the steps necessary to allow users to access the new servers in their different locations \u2013 this could be done over a long weekend while most users were off-line and out of the office.<\/p>\n

Some backups can serve two purposes \u2013 for instance, a backup copy of the company\u2019s customer database can be used by application developers to test against. It\u2019s simply necessary to ensure that private data such as users\u2019 SSN or other personal information is properly encrypted or redacted.<\/p>\n

Further reading<\/span>\u00a0Disaster Recovery Testing: Scenarios, Best Practices, Methods<\/a><\/p>\n

How much is too much?<\/strong><\/p>\n

It\u2019s possible to have a plan that can ensure that vital operations are back up and running in almost no time, regardless of the level of disaster. For instance, some Navy operations resumed the day after the Pentagon was hit on 9\/11. All files had been mirrored off-site, and users were able to deploy to an alternate location and continue work almost immediately, using PCs and other systems that had been deployed in advance. Most businesses can\u2019t afford this level of preparation, but it certainly is possible. The key here is to identify a\u00a0recovery time objective (RTO)<\/a> that your business can afford to be without its data or equipment, and set the response based on that. For instance, a system that allows for 24 hours of downtime will be much less expensive than one that only allows 15 minutes.<\/p>\n

\n
\n
Minimize Business Downtime with These Recovery Essentials<\/div>\n
\n