A disaster recovery (DR) plan is something that needs to be tested and revised regularly to evolve with the changing threat landscape. Along with protecting your company from natural disasters and major equipment failure, your DR plan must help you recover from significant breaches.
Ask yourself if your organization’s DR plan is robust enough to recover from a ransomware attack. Just before Thanksgiving, a county school system near a major city in the Mid-Atlantic was hit by a ransomware attack that derailed online learning for 150,000 students.
Don’t wait for an attack to happen before you beef up your DR plan. Here’s an overview of what you need in a DR plan and how to get there.
Business Decisions Come First
Before you begin drafting the plan, keep in mind that RPO (Recovery Point Objective) and RTO (Recovery Time Objective) are actually business decisions, not technology ones. Leadership at all levels of the organization should know and be comfortable with how much downtime can be planned for and how much data loss could be acceptable. If a business leader says “we cannot afford downtime or any data loss,” then the next logical step is to begin planning for a technology and process that supports that objective. Having the business discussion also has the side benefit of making non-technical leaders a part of the process. More importantly, it can help gain advocates that may be essential in getting the budget approved for the right technology to support the agreed upon RPO/RTO.
How to Create a DR Plan for Your Business
To get started on your DR plan, you need to compile a list of the applications and services in your IT environment. After you have this list, perform a business impact analysis (BIA) to determine how you will recover your applications. This BIA will determine the ideal recovery point objective (RPO) and recovery time objective (RTO) for every application or service in your environment.
For each application and service, you must determine:
- Constituent components or servers
- Interdependencies
- How to meet your RPO and RTO
- How to verify that components have been restored correctly
- How to protect the data in your disaster recovery site
- How to fail back to production after the disaster
Throughout this DR process, remember the human factor. Recovering from a disaster is stressful, so having a unified approach to each application is important. Find a tool that will make the creation, testing, and execution of your plan easy for your staff to perform.
DR Plan Template
One of the most important parts of your plan is your DR plan template, which is often overlooked in the planning process.
During a disaster, emotions can run high. A template ensures that each DR plan is uniform, containing the same information in the same format so key stakeholders can quickly review documentation and get an understanding of what is in each plan.
Key Steps of a DR Plan
A DR plan comes down to bringing the application back online and making sure it works correctly. To do so, key steps must be followed, including:
- Declaring the disaster
- Beginning recovery of components
- Testing components as they are recovered
- Testing applications to ensure they are working correctly
- Protecting the data in the DR location
- Notifying application owners and key stakeholders as the plan progresses
There are more steps to a DR plan, but if your plan can’t bring the failed application back online and make it work again, you haven’t successfully recovered.
What You Need to Include in a DR Plan
Each plan should have a distinct name so it’s easy to reference, such as “XYZ Application Disaster Recovery Plan.” It should also clearly list the application owner, as well as their contact information.
The plan should also list every asset, the steps that must be taken to recover each of them, and any specific order that applications or components need to be recovered in. If the applications recovered require any sort of verification or validation, these instructions should be included in the plan.
Recovery Plan Considerations
As you create recovery plans, keep in mind that they need to be easy to read and use. You can ensure this by making sure that your recovery plan is reviewed by others during the creation of the plan.
Besides checking things such as spelling and grammar, having another set of eyes on the plan will make sure it flows correctly. Make sure someone who does not know that particular application reviews the DR plan because you won’t know who may be executing the recovery.
If you’re validating your application before you bring all components online, this could cause problems from both an audit and an application functionality perspective.
Part 2
Next week we’ll discuss additional considerations such as building a team, formalizing a process, and of course, testing.
FirstLight offers disaster recovery as a service (DRaaS), providing companies with a faster and easier route to reliable and robust disaster recovery. Cloud-based DR frees your business from needing to create a secondary environment for data protection.
Our DRaaS solution is powered by Veeam, combining award-winning replication and recovery software and robust cloud computing infrastructure with our ultra-low latency network for optimal RTOs and RPOs.
