How to recover a Linux VM in Amazon EC2 using Arcserve UDP “Instant VM” Recovery
InstantVM Recovery was one of the great new features introduced in Arcserve UDP v6.0 & has been improved further in Arcserve UDP v6.5. The concept of InstantVM may be familiar to anyone used to other backup vendors such as Veeam. Instant VM Recovery essentially creates an “empty VM” on a supported Hypervisor & then boots the VM from the Backup Repository.
InstantVM provides a Recovery Time Objective of a matter of minutes. The actual RTO depends on the speed of the infrastructure, the Recovery Point Server, the Hypervisor and the network.
There are some considerations when thinking about using InstantVM as your recovery strategy.
- Supported Hypervisors – InstantVM supports Hyper-V, VMWare and now Amazon EC2 (Linux Recovery only – UDP version 6.5). Microsoft Azure support is surely coming in the future (we hope).
- Performance of an InstantVM “Recovered” VM will initially run slower then the original production server as data is being pull out of the de-duplicated datastore and re-hydrated on the fly.
- Limited simultaneous InstantVM’s. Although there is no hard limit to the number of InstantVM’s that can be run from an RPS Server, clearly performance is going to become a limiting factor. An RPS could be the destination for hundreds or thousands of servers. Clearly it would not be possible or practical to run an InstantVM for so many recovered servers.
- Long Term Disaster Recovery considerations. InstantVM’s should not be considered as a long term DR solution. Once the VM’s are up & running & you have achieved the necessary RPO, the InstantVM’s should be “converted” to VM’s that are not reliant on the Recovery Point Server. For Windows VM’s, this involved performing a “Storage Migration” of the VM’s but for Linux this process is automated by Arcserve UDP as it completes a background restore of the backup to the InstantVM’s disks.
When should you use InstantVM as opposed to Virtual Standby?
This is a common question that is best answered by firstly considering some of the limitations of both solutions.
There are some occasions when InstantVM can’t be used and when Virtual Standby can’t be used. It can depend on the Operating System protected and the target Hypervisor.
- Source Server is running Linux – Virtual Standby not available – use InstantVM
- Target Hypervisor is Amazon EC2 – InstantVM is currently the only option for Linux, Virtual Standby is currently the only option for Windows.
Then you need to consider the environment and the end users requirement.
- Virtual Standby will consume storage on the DR platform – It will actually create “thin” disks on the target hypervisor (if supported) that will be equal to the size of the data on the production server.
- InstantVM won’t consume additional disk space on the target Hypervisor – however that space should be available to enable a full recovery.
- InstantVM lends itself well to “cloud” style pricing for storage, where there is plenty of storage available, but you only pay for what you consume.
- Virtual Standby is pre-configured as part of a backup plan. To invoke recovery, the administrator only needs to power on the VM (using the Arcserve console). This means that many VM’s can be online and available in just minutes.
- InstantVM is not configured as part of a backup Plan (although Assured Recovery Testing does leverage the InstantVM methodology). An InstantVM can be created from any “Recovery Point”, it is even possible to import a datastore from another RPS and perform InstantVM on any of the recovery points.
- InstantVM requires the administrator to complete a short wizard for each VM to be recovered. This increases the admin effort and time to recover when compared to InstantVM.
A combination of InstantVM and Virtual Standby can be the best approach. Critical “must be up first” servers or particularly large could be configured to use Virtual Standby, whilst less critical servers can be recovered using InstantVM.
How to recover a server using InstantVM.
- Select your server you wish to recover. This can either be by selecting a server from the UDP console or by browsing a Datastore in the UDP console.
- Select “create an instant VM” from the drop down menu
- Choose the recovery point that you wish
- to restore.
- Choose the Hypervisor or Cloud platform (Amazon EC2 currently the only supported Cloud Platform).
- Configure CPU, RAM & Network settings.
- Select if you want the “restore” process to complete automatically after boot (for Linux only).
- Choose to Boot the VM Now, or later. The Boot process will take longer than usual, but will speed up as more data is pulled out of the backup set.
You have now completed an InstantVM recovery. The recovered VM’s are now available and operational. Windows VM’s running on Hyper-V or VMware can be “detached” from the backup by completing a storage migration to the hypervisors datastore. Linux Servers are detached once the “restore” process has been completed.