If you are busy, just look at these 2 images for the gist of this article...
1. Overview of using Veeam to provide Disaster-Recovery-as-a-Service. Click here for full size image (opens a new tab).
2. This is a multi-tenant solution. Click here for full size image (opens a new tab).
Action:
1. Decide how our Hyper-V servers should be configured to provide the service. It can be
i. Standalone hosts
ii. Cluster
iii. SCVMM
2. Build the Hyper-V servers.
3. Build Veeam Backup Infrastructure.
In this article, we are talking about using Veeam to provide Disaster-Recovery-as-a-Service for client's Hyper-V servers. (Veeam also supports VMware servers.) Veeam basically replicates the client's VMs from the client's Hyper-V server to our Hyper-V server.
First, we need to think about the hardware, especially where the VMs' data will be ultimately. Veeam in itself does not really care where that data is. It only cares what Hyper-V server we tell it to use. It is up to us to build a Hyper-V server / cluster that is fault-tolerant. (Yes, we can tell Veeam to use a Hyper-V cluster too.) In this article, the example uses a single Hyper-V server.
We need to build the Veeam backup infrastructure. The image below gives an overview. Basically, it is building (almost) everything that we need in order to do regular Veeam backups.
 |
| The Veeam backup infrastructure for regular backups. Click here for full size image (opens a new tab). |
Then we add Hyper-V servers to our Veeam backup infrastructure.
 |
| Adding Hyper-V server / cluster to our Veeam backup infrastructure. Click here for full size image (opens a new tab). |
After that, we add the client (called a "Tenant" in Veeam), create the "hardware plan" (which controls the CPU, RAM, storage, network, etc the client can use), etc.
When we get that all done up, we can send the credentials to the client. At a minimum, 3 things: Service Provider (i.e. us, seen in this example as "VeeamBackup.quek.tech), username (seen as "Tring1987" in this example), password.
We will need to build a Veeam backup server in client's office too. That Veeam backup server will talk to client's Hyper-V server and our Veeam backup server, and do the replication. Veeam will create a VM called "Network Extension Appliance" in client's Hyper-V server, and install a "Transport Service".
 |
| Client tells his Veeam backup server to replicate his VMs to our Veeam backup infrastructure. Click here for full size image (opens a new tab). |
Side point: Veeam is a multi-tenant solution, i.e. one set of hardware can support more than 1 client.
 |
| Veeam is a multi-tenant solution. Click here for full size image (opens a new tab). |
Client can perform a partial site failover, i.e. failover some VMs, not all the VMs. Veeam will use the "Network Extension Application" to establish a VPN tunnel between the 2 locations, so that the VMs in the 2 locations can communicate with each other.
 |
| Partial site failover. Veeam will set up VPN automatically, so that VMs in both locations can reach each other. Click here for full size image (opens a new tab). |
In the event that client's office is down, client can perform a full site failover, using the web-based GUI (called "Cloud Connect Portal") provided by our Veeam backup infrastructure. It makes sense to have this, because if the client's location is down completely, he cannot use the Veeam backup server in his office to start the failover process.
 |
| Performing a full site failover using "Cloud Connect Portal". Click here for full size image (opens a new tab). |
Veeam can do more than what is mentioned here. I think it is a software that can be used to provide Disaster-Recovery-as-a-Service.
Most of the planning and work should be done at setting up the fault-tolerant Hyper-V cluster (with growable space to store VMs' data) that will run clients' replicated VMs. In the screenshot below, we are choosing the Hyper-V host / cluster for the "hardware plan", which is then assigned to the client. Client's VMs will then be replicated into the Hyper-V host / cluster specified the "hardware plan" that client is assigned to.
 |
| Choosing the Hyper-V host or cluster for the hardware plan. This Hyper-V host or cluster should be fault-tolerant and have growable space. Click here for full size image (opens a new tab). |
In the screenshot below, we are choosing the location to put the VMs' data. The list of locations available is read from the the Hyper-V host / cluster that we have selected earlier. We should use a location that is growable in terms of space.
 |
| Selecting to location to put clients' VMs. Ideally, this location's space should be growable. Click here for full size image (opens a new tab). |
Of course, it is also possible to keep things simple by using standalone Hyper-V hosts, and then carefully use "hardware plans" to manage how much of CPU, RAM and storage the client can use. Using standalone Hyper-V hosts might actually be better because we have to ensure that a single client's VMs should all be in the same Hyper-V host, so that the "partial site failover" can work properly.
