A disaster recovery plan (DRP) is a document you need to keep handy to handle unexpected incidents that could shut down your company’s IT systems and hinder its overall operation. A DRP aims to get your business up and running as quickly as possible during a disaster or data breach. With an effective DRP, there is less chance of you losing out on profits for too long. A
Does Your Business Have a Disaster Recovery Plan?
Data loss, downtime, and tech outrages are some of the new horror stories that even the top companies come across nowadays. Whenever a disaster strikes in a company, the engineering teams rush to repair the damage, and on the other hand, PR teams work overtime to restore customer confidence.
Disasters come uninvited with loads of complex challenges, which organizations might take months or years to overcome. Cyber attacks, tornadoes, terrorist attacks, hurricanes, and floods are some of the disasters that can cause data breaches. A disaster plan is a long-term assurance of business operability as it is designed in such a way that it enables businesses to reduce damages of unpredicted outages.
Do you have a disaster recovery plan, or are you just beginning the process of creating one for your organization? In either of these cases, the disaster recovery plan checklist below will help you add all the crucial components in your plan.
1. Analyze Potential Threats and Possible Reactions
The first thing is to take time and analyze all the possible factors that can disturb your flow of business. Once you are done with the research, it’s time to create a different recovery plan for each of those scenarios. For instance, cyber attacks are becoming more prevalent and likely to occur, and unfortunately, the average firewall is not that strong enough to protect from most of them.
Thus look at the possibility of a cyber attack more intensely than you would, say, a tsunami. You might opt for encrypting data and securing hardware. Try to understand the vulnerabilities that are within your systems, as these are the points of entry a hacker will use to gain access.
2. Fix the Disaster Recovery Objectives
Disaster recovery helps you keep your business operating as usual, constantly, so you need to fix on IT services that are most critical to run your organization. Also, the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) required for these services/ machines. But are you aware of RTO and RPO?
RPO: The amount of time required to recover from a disaster after notification of business disruption. In case of any disaster, if your business is not able to withstand at least an hour of downtime without losing customers to your competitors, then it’s crucial. You need a reliable disaster recovery plan that comprises of a clearly-stated allowed RTO.
RPO: A window of time in which data is acceptable. After a disaster strike, if your business can only survive a data loss for four hours after a full day of business, this can lead to a catastrophic loss of important data, so your RPO would be four hours.
An organization’s RTO and RPO are sure to affect its recovery strategy and associated expenses. In order to reduce the total cost of the disaster recovery strategy, it is better to divide the applications into tiers. The highest tier reserved for mission-critical applications would require a disaster recovery technology based on real-time continuous data replication. The mid-level tier might require a snapshot-based application, and finally, the lowest tier may get by with a simple file-level backup system.
3. Recognize the Stakeholders in Your Disaster Recovery Plan
The next and crucial step is to identify those who need to be updated once disaster strikes. Engineers, support, executives, etc. will be involved in performing the actual disaster recovery. Still, you need to identify others too like vendors, members of the PR and marketing team, third party suppliers, and key customers. Most of the companies maintain a register of stakeholders in their project office documentation to notify in the case of a disaster.
4. Create a disaster recovery site
There are high chances that a disaster will severely damage your production center, thus making it impossible for you to resume operations at the primary site and thus migrating critical workloads to another location. According to the disaster recovery plan, the checklist you need to build a DR site to use in case of emergency relocation of critical data, staff, physical resources, ad applications. Also, you should equip the site with enough hardware and software to take on the essential workloads.
5. Gather Entire Infrastructure Documentation
When a disaster occurs everything goes for a toss, everyone is under pressure. Indeed, you have your engineering teams with the required skills and knowledge to activate disaster recovery procedures, but infrastructure documentation is mandatory. Even the highly proficient engineers while performing disaster recovery would prefer to go command by command from infrastructure documentation.
So what does this documentation comprise of? The entire setup of systems and their usage (installation, recovery procedures, applications running, OS and configuration), cloud templates, storage and databases (how and where the data is saved, how backups are restored, how the data is verified for accuracy) and all your mapped network connections (with functioning devices and their configuration).
6. Cherry-pick the Precise Technology
Disaster Recovery as a Service (DRaaS) and on-premise disaster recovery is not just the feasible solutions available for business continuity. The next option is to make use of cloud-based disaster recovery in order to spin up your disaster recovery site on a public cloud-like Microsoft Azure, AWS and Google Cloud in minutes using an automated disaster recovery solution.
Before you make a choice of solution, ensure to consider the total cost of ownership, maintenance requirements, scalability, recovery to the previous point in time, and ease of testing. Choices are many when it comes to disaster recovery solution, thus do you thorough research and choose wisely.
7. Launch Communication Channels
No one knows when disaster can knock your door, so being an organization, you must keep a list of teams (along with their roles and contact information) for disaster recovery. Try to establish a comprehensive chain of command which includes accountable individuals from each of the engineering teams (e.g., database, systems, network, storage) and relevant executive leadership. Also, set up dedicated communication channels and hubs, or an online information-sharing tool to use for instant messaging.
8. Outline an Incident Response Procedure
If you have a disaster recovery plan, then an “incident response procedure” is a must. Herein the companies will define in detail which events have to be declared as a disaster. For instance, if your system goes down, will you consider that as a disaster? Also, the plan should also indicate how to verify the disaster and how it will be reported— by an automatic monitoring system, raised by calls from site reliability engineering (SRE) teams, or reported by customers?
In order to verify that a disaster is really happening, you need to check the status of critical network devices, application logs, server hardware, or any other critical components in your production system, that you monitor proactively. If something is odd or not working, then for sure you have a disaster on your hands.
9. Outline an Action Response Procedure
Once disaster strikes, a disaster recovery environment needs to be activated as soon as possible. An action response procedure will outline how to failover to the disaster recovery site with all the required steps. No matter whether your recovery process is using DRaaS or a disaster recovery tool to launch your disaster site automatically, you need to prepare the action response procedure in writing to ensure how the necessary services will be started, verified, and controlled.
Additionally, spinning up production services in another location is not sufficient, ensuring that all the required data is in place, and all the required business applications are functioning properly, is also equally critical.
10. Get Ready for Failback to Primary Infrastructure
Failback is restoring operations at the primary production center once they have been transferred to a DR site during failover. DR sites are not designed to run daily operations; instead, they can be used only for emergency purposes. DR sites are built for a very short period (until the primary site is restored or until a new production center is built).
Once the disaster is over, a lot of effort is required to implement the moving of data and business services back to the primary location—plan for a potential partial disruption of your business during the revert process. Fortunately, there exists disaster recovery solutions that provide unified failback to the primary location, activated automatically or manually once you complete the verification of the primary IT location.
11. Report the incident to stakeholders
Once a disaster occurs, first notify not only those who are responsible for executing DR activities but also key stakeholders such as vendors, customers, members of the PR and marketing team, and third-party suppliers. Also, consider informing each of these groups and formulate answers for addressing their concerns. It is better to write a press release in advance to waste no time during an actual disaster and have it ready for publication.
12. Do the Extensive Tests
Testing your disaster recovery plan is mandatory but usually neglected. Failover tests are usually complex and lead to data loss and disruption of product services. Thus most companies don’t test their disaster recovery plan on a regular basis.
In order to understand how well your disaster recovery plan will work, you must schedule regular failover tests. Ignoring the disaster recovery plan tests can put your entire business at risk during a disaster strike, ending up either unable to recover in time or no recovery at all. Performance tests also help you to assess whether or not your secondary location is sufficient to withstand the business load.
13. Keep your Disaster Recovery Plan Updated
Last but not least, as disaster recovery plan testing is mandatory, so is keeping all the disaster recovery documents updated. At the end of each test, review what happened, how your teams handle the test, and document your findings.
Comments