Creating a disaster recovery plan for business continuity — well, it’s not easy. There are way too many factors to even attempt a summary here. Right from enlisting all the risks to choosing the location to host your disaster recovery applications and systems — every decision will test you.
It’s probably because of this that many business organizations find it difficult to start or improve their disaster recovery plan. You won’t have to search much before bumping into case studies of organizations whose first attempts at disaster recovery came when the crises had struck.
We don’t want your organization to add to the list of such lamentable case studies. Yours must be the happy story, of the organization that let saw storm arrive, watched in confidence, let it pass, and resumed work with nonchalance. Here’s everything you need to know and do to make that scenario happen.
You can only recover what you know is disrupted. Disaster recovery consultants swear by the practice of taking stock — for hardware as well as software. It’s ideal that companies create self-defined categories to classify these assets and to organize them in an order of priority, such that the most important ones are secured first.
While you do this, it makes sense to mark technical support and contact information close at hand for each asset. Don’t risk a situation where you know something is wrong, but don’t know what all it might have taken down.
Of course, different kinds of businesses have different levels of tolerance for system downtime and data loss. If you’re a local cake delivery service, you can afford a few hours of downtime. If you’re a cab-hailing service, your app can’t afford to be down for more than a few seconds.
Recovery time objective (maximum time you can wait before resuming access to affected systems) and recovery point objective (maximum amount of data loss you can afford due to a disruption, expressed in units of time, going back from the moment of disruption) are the two pillars on which your disaster recovery plan will stand. Ideally, the answer to both questions would be — a few milliseconds. But then, the costs, viability, and achievability will determine the values you truly settle for.
Experts advise that businesses should organize systems and applications in three or four categories, from Tier 1 (applications that must be recovered immediately) to Tier 4 (applications that can be recovered conveniently in a few days). The success of every disaster recovery plan depends on this.
System uptime is one goal, and prevention of data loss is another. To achieve the latter, experts swear by the 3-2-1 rule. It says there should be three copies of your data, on at least two different media, and one copy must be located offsite. The logic is clear enough; the plan should achieve redundancy, geographic separation, and must avoid known risks associated with specific media. If data stored in a traditional medium (disk, drive, etc.) deteriorates, the offsite location (which is mostly a cloud-powered storage service, for modern businesses) will keep things secure. This also means that even in a situation as bad as a city-wide natural disaster, your offsite data (located in a server thousands of miles away) will be safe.
After you’ve decided the RTO and RPO for different applications, it’s time to write down the disaster recovery plan in detail. Rather than getting into aimless discussions about preparing a template for the plan, we recommend you make it as practical, clear, and crisp as possible. That’s because people who will refer to it won’t really have the time to pour themselves an espresso shot and recline on a rocking-chair to read it.
Focus, instead, on clearly answering the questions people will have at the time; such as:
Once done, make sure the plan is easily accessible to people responsible for dealing with disaster situations. Also, devise a mechanism for revisiting the plan every three or six months, based on the sensitivity of your business. Newer threats (ransomware, for instance) require alterations and additions in the master disaster recovery plan.
The key source of chaos in businesses when a disaster strikes the IT infrastructure is the lack of clarity on who communicates to whom, and in what language. This calls for businesses to add a clear and comprehensive communication plan in their disaster recovery plan. The key points to cover in the communication plan are:
It’s naïve to prepare a disaster recovery plan and then not test it to a reasonable degree of detail and practicality. It’s almost guaranteed that you will face surprises, and you will realize that you:
The more surprises you face at this moment, the better your disaster recovery plan will become (provided you draw insights from your testing and translate them into improvements).
Disaster recovery is hefty. It’s tiresome, and in most cases, it’s expensive. However, it’s only after putting a robust disaster recovery plan in place that the business leaders can afford to sleep with their mind at ease about being prepared to combat a volatile situation.
Featured image: Pixabay
IFA 2019, this year’s version of the annual consumer electronics trade show, did not disappoint. Is one of these smartphones…
IT professionals all dread getting this fevered message from employees and clients: “I’m having Outlook connectivity issues!” Here’s what you…
Here’s a script designed to start and stop virtual machines based on tags associated at the resource group level. It…
Traditional VPNs are showing their age in the modern cloud-powered workplace. That’s why software-defined perimeter solutions are in your future.
Should you disallow NUMA spanning in your Hyper-V architecture? There are two sides to this story, and you’ll get both…
Coding may not be the No. 1 job duty for cloud admins, but it is often a part of the…