In my last post, I covered how to recover using the more traditional methods like file restore and full VM and BMR recovery. There are two more options for recovery which helps companies to recover and these options can be used in a DR scenario on premise or even on a replicated site or cloud location. Both options can help you to have a very low recovery time objective as they are instantaneous. So, in this post I will focus on two methods that can help you to instantly recover using Instant Virtual Machine (IVM) and Virtual Standby (VSB).
IVM and VSB provides you a virtual machine that can start instantly from a recover point you select and both methods use a hyper-Visor as target, and this could be either VMware or Hyper-V.
But what is the difference I can hear you ask?
Good question, and I get this often asked.
First off all, VSB is part of a plan which means you will need to create a task in your plan upfront, where is an IVM can be created without using a task inside a plan.
IVM is using the backup image and is mounted via NFS (when using VMware from the Recover server). In Hyper-V the image is mounted inside a folder on the host.
VSB is a pre-provisioned virtual machine created by a plan on your hypervisor and injected with the last recovery point each time a backup is finished.
IVM and VSB can be started immediately when you need it in case of a disaster. The main difference is in the performance. As IVM is using the backup image which sits on your backup storage platform and uses deduplication, the performance of these backup storage units might not be sufficient for business-critical applications. VSB however, will be pre-provisioned on your storage (profile) that you choose and therefore might have much better performance.
Obviously, using VSB you will need to have the storage capacity allocated where is IVM using the backup storage and does not require any additional storage allocation.
Removing the IVM will remove the data created, as the backup image is read only. If you use the IVM in DR you can either storage vMotion the IVM to your production environment or setup a new server (physical or VM) and use BMR to recover from IVM. You can protect the IVM by adding it into an UDP backup plan.
Data stored in a VSB will remain in the VSB, and once in DR a VSB should be added into a backup plan so you are protected as the VSB is the new production server. To failback to the original source you can use BMR to set up the new machine. Also the VSB can be protected by UDP by adding the VM into a plan.
Another use case for VSB is migration, you can use this to migrate a physical server to a virtual server in minutes or from one hyper-Visor to another as VSB is supporting cross-hypervisor. One thing to bear in mind is that VSB supports only Windows machines.
So let me explain what an IVM and what a VSB is
Instant Virtual Machine
The IVM process creates a virtual machine on your hypervisor and runs the backup session inside this virtual machine. The advantage of IVM s that it provides an immediate access to data and applications present in Arcserve UDP and it eliminates the downtime associated with a traditional restore or conversion of the backup session to a physical or virtual machine.
When starting the IVM the process, the instant VM core module will invoke communicate with the hyper-Visor and starts the IVM process. This core module is already installed on a Hyper-V hosts as the host has an UDP agent installed. With VMware environments, you will need to select a Recovery Server which can be the RPS server itself. The core module communicates with either the vCenter or the ESXi Host. The recovery server will use NFS to mount the recovery point as a disk and the IVM will be started from this image.
How to start the IVM
An IVM can be created and started from the UDP console, when you go to the resources and select a node you can right click (or choose actions from the menu) to create an IVM.
A four step wizard will start to configure the IVM
First step is to select the recover point you would like to use for the IVM, in this case I use the latest recovery point taken during the last backup.
Next step is to select the hypervisor, you have three options in here;
- Amazon EC2
It does not matter what the source is, either physical or any virtual machine from any hyper-Visor as IVM will convert it automatically to the correct format for you. This is true cross hypervisor technology.
In my case the next step does not need any configuration for the Hyper-V host. In other scenario’s you will provide the proxy server you would like to use. You must select a Recovery Server only when the hypervisor is VMware vSphere. Please note when VMware vSphere is used, the Windows Network File System (NFS) role must be installed on the Recovery Point Server.
Lastly, configure the resources and network for the IVM. You can change the adapter and update DNS. Also, specify the VM files folder, all changes made by the running VM into a child virtual disk, please make sure you choose a folder with sufficient resource. The selected folder mounts as NFS Datastore to VMware. A shared icon appears on this folder in the local machine. If VMware is used, you can redirect virtual disks to a VMware datastore.
When done, you can click Finish to start the IVM
The IVM is now available and can be used for testing or recovery.
One of the cool things is that, when using VMware you can storage vMotion this IVM to a definite status so that won’t lose any data when removing the IVM. You can simply select the VM in the vCenter and migrate the IVM to a data store of your choice.
Another option is to use BMR to recover your machine and you can select the IVM as a recover point. This will than recover the server with all the changes inside the IVM.
To remove an IVM, simply click the IVM in the console and click Delete
Where IVM can be started from the UDP console directly without any planning, the VSB needs to be created upfront using a plan. The VSB converts the recovery points to virtual machine formats and prepares a snapshot to easily recover your data when needed. The VSB are located on your storage that is connected to the hypervisor, and this needs to be planned as it requires additional storage capacity.
The VSB feature also monitors the heartbeat of the source node so that when the source node is down, the virtual machine immediately takes over as the source node. A monitor server can be selected to monitor the heartbeat of the source machine. The monitor server can be the RPS server.
In your hypervisor, you can see the virtual standby as it is created upfront, and using the snapshot manager you can see the recovery points that are converted to hypervisor snapshots.
Setup a VSB task
To create a VSB you will need to add a new task to your plan.
The source is always the nodes that are protected in Task1.
In the next tab you set the destination for the VSB, you can choose either VMware or Hyper-V, in my case I have a vCenter cluster that I use as a target. The monitor server monitors the heartbeat of the source machine, you can define your own server in here, which requires to install an UDP agent on the server or you can use a RPS server. In larger environments, I always recommend to use a dedicated server that can be used for proxy and monitoring.
Next is to set the resources for the VSB, you can specify the memory, cpu and resource pool. Also you can select the datastore you would like to use. And lastly, specify the network adapter and what virtual switch you want to use for this VSB.
In the advanced section, you can set the heartbeat and frequency and the alerting. Personally, I like to set the timeout on a much higher value than 30 seconds. I would recommend to set it to 300 seconds (5 minutes) or even 600 seconds (10 minutes). In UDP you have the option to pause and resume the heartbeats. If the monitoring server does not detect a heartbeat after a specified length of time, the virtual standby feature provisions the virtual machine to function as the source node.
Once done, you can save the plan and run the plan.
The first time you will run, a virtual machine will be created on your hypervisor and injected with the last backup recovery points which will be converted to snapshots.
You can start the VSB manually by selecting the node and right click (or actions in the menu) and select standby VM.
Once selected you can choose the recover point, which is converted to snapshot, to boot from.
This will start the virtual machine from the snapshot on the hypervisor.
Once started you can access your virtual standby
This machine can now be used as production machine and you can add into a backup plan to protect this virtual machine. You can also use BMR to recover back to either physical or another VM if needed.
You can see the status of the VSB within the UDP console:
If you use the VSB purely for testing, you can easily shut it down from the console again. Select the node and right click (or actions in the menu) and select standby VM and choose shutdown VM
As you can see you have two great features within UDP to lower your recovery time objectives and quickly start virtual machines from the UDP solution.