There are pros and cons for different cloud disaster recovery service scenarios. People often think of DR as a technical decision, but it is actually more of a business decision with business implications.
Private cloud
The company owns the entire infrastructure and has to pay for everything, whether it is used or not. While it may seem expensive, you get to control everything and can use your resources as you see fit. It gives a huge degree of flexibility that is often not available in public clouds.
Unlike public clouds, private clouds are not a shared resource. There is no contention or slowdown as they are company-owned resources (assuming everything has been correctly specified beforehand).
While it may be a rarity, a natural disaster could mean a lot of companies want to fail over to their cloud disaster recovery service at the same time. Knowing that your resources are guaranteed is a benefit not to be ignored.
The administrator and business control what comes up, when and how. It does come with a relatively high cost, though. You are not a number at the mercy of the cloud provider. (This scenario is separate and distinct from a cloud provider failing over its data center, which is a whole different ball game.)
The major downside to a private cloud approach is that it is limited to those who can afford it. It comes at a very steep price, so it’s not for everyone.
Public cloud
Smaller companies can use the public cloud for DR failover. It allows them to have a DR capability that wasn’t available previously within their budget. Those resources are not guaranteed, however, so a natural disaster could result in some contention when everyone tries to fail over to the cloud disaster recovery service.
Hybrid approach
Going in another direction, a hybrid approach is, by far, the most popular solution with companies, irrespective of size. There are many reasons, but the main factor is that it is cheaper to use someone else’s cloud and not have to pay the additional costs for cooling, rent, depreciation and so on. Shared resources equal lower costs. With this approach, you keep the key applications on site and put the rest into a backup provider of choice.
It is also possible to take the hybrid approach and have key applications and infrastructure fail over to private cloud resources and then have the tier-two applications fail over to the public cloud.
At the end of the day, it is more the level of risk the company is willing to bear versus the cost of the cloud disaster recovery service. Crucial “must-have” and “nice-to-have” resources can be divided among the cloud environments, effectively managing an organization’s risk.
Virtualized Disaster Recovery
The recent wave of malware spreading over the internet has provided an excellent opportunity to showcase how dynamic and flexible virtual infrastructure can be and how organizations can avert issues using a virtualized environment.
The crown jewel of virtualized disaster recovery (DR) infrastructure is the point-in-time copy feature. Point-in-time copies are very similar to classic virtual machine snapshots but less weighty; they don’t keep copies of the VM memory and other less important items. These copies allow an administrator to roll a virtualized system back to a point in time prior to when the malware hit.
The snapshot process in a virtualized disaster recovery environment is automated and keeps hundreds or thousands of point-in-time copies of the data that can span days and even weeks. While this may sound very inefficient, it is actually the opposite. Each copy just keeps track of the changes from how the block in question looked prior to the change written to it. Multiple changes to that block are not an issue. Essentially, this means that large amounts of changes can be represented by a tiny amount of copied block data. It is possible to go back to almost the exact minute prior to any infection.
Virtual vs. physical DR
The snapshot process in a virtualized disaster recovery environment is automated and keeps hundreds or thousands of point-in-time copies of the data that can span days and even weeks.
This type of functionality isn’t available on physical hosts. While physical hosts may have restore points provided by the inbuilt OS functionality (i.e., Windows restore points), modern malware removes the restore point protection. Because the restore functionality and point-in-time copies are isolated from the VM, the restore functionality can’t be subverted from inside the VM. (That is assuming the underlying DR system is still available and not impacted.)
Compare this virtualized disaster recovery to a physical environment. There are tools such as Dell EMC’s Symmetrix Remote Data Facility that allow replication, but they can be a bit cumbersome to use and require more in-depth support. These products also require dedicated storage LUNs to work correctly. There are manual tasks that need to be completed, such as breaking replication, mounting disks and reconfiguring the application. This is problematic enough with one server, but when there are dozens or more compromised machines, it becomes a huge task. The manual labor involved alone would be huge. Any DR failover should have as few steps and different groups as possible. Complexity adds risk, which is not something you want when trying to perform a failover.
Lastly, virtualized disaster recovery offers massive time savings. Top-flight DR products advertise the fact that a failover can be completed in less than 15 minutes.
An all-virtualized disaster recovery environment provides functionality that helps companies fight malware and ransomware attacks. Anyone not using it is missing a massive tactical advantage that is easy to use and implement.
GINDSINGH 