Disaster Recovery Can Be An On-Ramp to the Cloud

Written by Joe Kozlowicz on Thursday, October 6th 2016 — Categories: Disaster Recovery

The road to the cloud is easier with disaster recoveryDisaster recovery and DRaaS solutions are intended as a method to keep a constant, or near-constant copy of your IT infrastructure in the cloud, ready to turn on a moment’s notice in the case of downtime at your primary data center site. But DR tools can also be used for your initial cloud migration, providing an on-ramp to the cloud that is cost-effective and relatively fast. You also get the bonus of a ready-to-go DR plan, if you continue to maintain the DR environment after your production servers turn on.

You generally have a few options when migrating to the cloud. One is to set up totally new servers, with new versions of your applications, new server OS licensing, and so on. Sometimes this makes sense as you don’t need to adjust or re-architect any applications for the cloud platform. Existing data can be transferred via network (slow and often expensive for large amounts of information) or by shipping hard drives – a process that many administrators find a bit harrowing. If you’re already virtualized, however, you can migrate workloads more directly.

At Green House Data, we’ve had a number of customers start with disaster recovery before moving more and more applications onto cloud servers. If you already have an investment in DR, it makes an initial migration fairly simple.

Migrating via DR ensures that you don’t encounter downtime when you cut over to the cloud servers, as your DR environment should already be tested and functional. Most mission-critical business applications cannot endure downtime or data loss. Datasets and VM application servers are synchronized without using snapshots and with minimal performance impact to your current production servers, then kept continuously updated as defined by your Recovery Point Objective (RPO). Testing failover (or migration, in this case) is as simple as a single click.

After your data is copied, your planned migration mostly involves changing DNS settings and reconfiguring networking or storage.

DR products like Zerto allow different hypervisors and storage to be used even from different data center facilities, combining migration and/or failover in a DR event with hybrid IT infrastructure and enabling you to migrate even very large datasets. It supports Hyper-V as well as VMware virtualization; and can even put workloads into AWS.

There are other methods to migrate, like snapshots and individual VM migration. Limitations can slow you down when migrating individually, as testing is slower, risk is higher, the amount of VMs that can be migrated in one go is lower, and data transfer can be sluggish.

Using DR allows you to move large VM sets, even in the hundreds, with a single automated click — and you can pull them back quickly thanks to commit policies, which validate all configurations and functionality before commiting the migration. During this process the original production VMs are turned off after the most recent changes to the environment are replicated to the destination. Boot ordering and network configurations are reconfigured and any scripts you wrote ahead of time are executed. Many of these steps would be manual if migrating via snapshot.

While Zerto is far from the only DR product on the market, we’ve found it to be highly reliable, easy to use, and functional across a wide range of source and destination environments. If you need assistance crafting a DR or migration plan, our experienced engineers are ready to help.

Chat Now