4 Questions for Disaster Recovery as a Service

One of the easiest ways to get into the cloud—and one of the best, most essential uses of cloud infrastructure in general—is disaster recovery. This can be a low-cost method that will give you peace of mind and keep your business technology afloat if you lose primary hosting.

Depending on the recovery service level, you can prop up anywhere from 25% to 100% of your infrastructure to keep business continuity without a second location or colocation. Before you start implementing a disaster recovery plan, here are the essential questions you need to ask yourself and your IT team. These four questions will help you tackle your virtual and physical technology—see our post from February for an overview of disaster recovery planning from a whole business perspective, including setting up teams, getting C-level endorsement, and more.

1) How will we move our data and applications?

This includes everything from “Where is my data physically located?” to “What type of virtualization do I use, if any?” and “What is the upload speed of my current environment?”

This will help you plan for data migration. You may need to increase bandwidth speeds, depending on the amount you plan to transfer, to avoid shipping hard drives. Other tools might be needed depending on the compatibility the disaster recovery software with your current environment. For example, if you were to move into a VMware cloud with Veeam DR tools from a Hyper-V environment, you’ll have to use the VMware converter tool.

2) What are my DR objectives?

In other words, why use disaster recovery at all? What parts of your infrastructure are absolutely critical to keep your business running? E-commerce? Enterprise Resource Planning software? Other critical apps?

You’ll have to make some choices including cold site vs. hot site recovery, data center location, and the Recovery Time Objective and Recovery Point Objective. This will determine the percentage of resources that will be recovered and in what time. Note any specific or custom technical solutions that your DR provider will have to replicate as well as a timeline to have all your DR set up.

3) What resources do I need?

How many virtual or physical machines need to be replicated? What are their operating systems? Make note of the server names, allocated RAM, CPU cores/speed, and storage. Different machines often use different IOPS storage performance, redundancy, or backups.

Your network requirements should also be recorded for replication, including number of public IPs, firewalls, VPN configuration, and load balancing. If possible, give your DR service provider a network topology diagram.

Depending on your current environment, you will have to decide whether to purchase software licensing, use existing licenses, or include them in your cloud contract.

4) What does a failover look like?

Some of this will be addressed in your DR objectives. Is there a pre-defined failover policy? What are your requirements for failover testing? Will you test disaster recovery or ask your cloud provider to do so? Your RPO and RTO will come into play here.

Decide how you want to access virtual machines in the recovery environment (VPN, console, or browser) as well as any additional services you may require once the failover is successful, like monitoring, backup, or anti-malware.

There are many details to keep track of in disaster recovery setup, and plenty of opportunity to save money depending on the level of risk you’re willing to accept. You can go without an anti-virus monitoring tool upon recovery, for example, and save the license costs, but if you ever need to failover you’ll be scrambling for protection. Ultimately a DR plan is about discovering the most critical aspects of your IT and guarding them in the most efficient way possible. The process might even help you discover inefficiencies in your current environment.

Posted By: Joe Kozlowicz