When it comes to your IT responsibilities, being able to recover data and maintain business continuity is among the most critical. But, there’s tradeoffs to factor in between cost, convenience and the benefit.
That’s why “DR tests” become much maligned – they require too much work, time, and effort to properly execute. Fortunately, technologies like disaster recovery as a service (DRaaS) and CloudBoot Orchestration can alleviate the time, cost and complexity required to perform system recoveries.
01. Why are some DR tasks dreaded?
It truly comes down to a classic cost-benefit analysis. Dreaded tasks are the ones with high costs and moderate-to-high benefits, especially when those benefits are not immediate—think about how often most people floss. When you look at a routine IT task like ‘run a site-wide recovery test,’ it’s obviously valuable, albeit not immediate, but requires a lot of upfront work and time – two commodities in increasingly short supply.
At Infrascale, we’re trying to make the process of scheduling and conducting DR tests simple. Brain-dead simple. And our new drag and drop orchestration is the next step in that evolution.
|DRaaS + Orchestration||VERY HIGH||VERY LOW||VERY HIGH||MONTHLY|
02. Simplifying Recovery
Recovery of a full network can be a complicated affair. The administrator needs to be aware of the dependencies of all the applications and machines in use to get a business back and in production.
Usually, this knowledge is shared tribally among the techs or the expertise assumed to be in place when disaster strikes. But, this requires the system admin to deduce the recovery steps (and the system dependencies) by looking at what’s going on the network. That’s a pretty tall order, especially when the disaster is highly visible, stressful, and revenue-impacting. This is not a good recovery plan and leaves too many opportunities for human error to creep into the equation. A recovery plan should mean that steps to recover your systems are second nature, no learning needed.
With DRaaS-based orchestration, the administrator can predefine the order in which machines are recovered, and can add time-delays between specific machines or groups of machines to allow for additional tasks to be performed or to accommodate application/database load times.
This means that any technician tasked to recover a full site will be able reduce many steps that require pre-existing knowledge to a single series of documented steps that is simple, straight forward, and transferrable.
03. Audits, SLAs and Trust
When recoveries and test recoveries become a convenient and high value task, it also means that the pain normally associated with audits fall by the wayside.
Easier testing means you can test more granular scenarios and ensure that your dependencies have all been mapped out and tested successfully. For example, you can simulate a ransomware attack that has infected all of your end users, the local backup files, mission critical databases and your file servers. You can even simulate a RAID failure on the hardware running vSphere or recover a CEO’s laptop that was crushed by TSA and you need to restore an important presentation in one hour. Now, you have the time – before an actual disaster strikes — to play out these scenarios to ensure that you can uncover any ‘gotchas’ and maintain your service agreements.
Regular testing and role playing translates into a smoother and more confident approach to real-life disaster scenarios. Click here to see how our Drag & Drop Orchestration simplifies your disaster recovery plans and system recoveries.