Business Recovery, Step 6: V2V
In the previous 5 steps, I’ve focused on ways to recover systems, applications, and data, each providing a benefit to both you and your customers. I’ve covered protecting physical servers with virtual disaster recovery to create a virtual copy lying in wait, and even continuous recovery for those servers that need to be up and running on a virtual copy as close to the moment they crashed as is possible. But in this article, I want instead to talk about a recovery method that involves providing an additional layer of protection to an already existing virtual infrastructure.
Virtual to virtual (V2V) recovery involves the backing up and recovering of virtual machines. So you may be thinking that your customer already has a virtual infrastructure, so why would they need V2V recovery services? Great question, right? But there’s one presumptive point in that question that may not be true when recovery is required.
When you consider your customers with a VMware or Hyper-V-based infrastructure, and think about the idea of offering V2V recovery, you probably aren’t thinking “What if the customer’s infrastructure is wiped out?” are you?
You see, the whole idea of recovering a virtual server is based on the customer’s ability to actually have an infrastructure to recover a virtual server to in the first place. So what you’re offering is as much about a backup to their virtual infrastructure as it is you’re offer of a way to recover virtual servers.
V2V: Virtual Recovery. Real profit.
In the wake of a disaster, even a virtual environment is susceptible to failure, damage, and destruction. That’s why there is legitimate opportunity to offer V2V recovery.
So do you need an entire virtual infrastructure somewhere in a data center to offer V2V recovery? The good news is the answer is no. Depending on your customer’s recovery needs, V2V can be accomplished with as little as a replacement physical server to host a base virtual environment.
Your V2V offering can be as comprehensive as every server, and as focused as a single server. It all depends on what your customer needs and what services you want to offer.
As always, I try to break this up into a few basic steps. In this case, the steps revolve around the two Vs in “V2V”:
- Identify the first V – To offer V2V, you need to identify those source virtual servers that are critical. You’ll need to, like nearly every other offering I’ve discuss in this series, establish RTOs and RPOs for each server to determine how often you’ll need to be taking snapshots, and the scope of recovery environment that will be needed for recovery.
- Establish the second V – The target virtual environment needs to be part of your offering. You’ll need to establish with your customers the scope of that environment – some of you may very well be hosting within a data center, while others of you may simply have a powerhouse physical server supporting either a VMware or Hyper-V environment lying in wait at your office. Either way, you’ll need an environment to recover your customers to.
What’s the benefit?
V2V provides your customer with the assurance that even their virtual servers will be back up and running after a disaster.
You should be charging for the V2V recovery planning, recovery testing, and for any actual recoveries – bringing you both one-time, and recurring revenue for this service.
In my next article, I’m going to take all the recovery methods I’ve covered over the last six articles, and discuss the methodology, frequency, and opportunities within recovery testing.