On August 2nd 2016, Veritas released Feature Pack 5 for Backup Exec 15.
So, what’s new here and is it worth the effort to upgrade?
Support for New or Updated Platforms and Applications
- SQL 2016
- SQL 2014 SP2
- Exchange 2016 CU2
- Exchange 2013 CU13
- SharePoint CUs 2013, 2010
- SharePoint 2013 with SQL 2016 instance
- Customizable S3 Cloud Connector
New Feature – Instant Recovery
The most important feature within this new feature pack is called “Instant Recovery” (IR).
This feature allows you to stand up a virtual machine you backed up on a hypervisor within seconds without having to restore any data.
Let me explain this in more detail:
Traditionally, restore concepts require companies to define two different values: the “Recovery Point Objective” (RPO) and the “Recovery Time Objective” (RTO).
The first one (RPO) defines, how often backups are performed, or in other words, how much data can be lost without bringing the company into real trouble in cases where a data restore is required. If no data loss is acceptable, the RPO is zero.
The RTO defines, how long a system may be down in case of an outage. In case of a restore, how much time is allowed between the point of time, where the system crashed and the moment when it was brought up again after a restore.
When using classic backup technology, the RTO heavily depends on the size of the system, because in case of a lost server, the whole system needed to be recovered.
Of course, we always tried to shorten the RTO, i.e. by recovering only the system drive in case of an operating system error. Nevertheless, the RTO always was always dependent on the amount of data that needed to be restored.
With Backup Exec FP 5, Veritas released a technology that completely changes this picture.
Instant Recovery allows admins, to stand up a virtual machine directly from the backup without having to restore it in the first place.
So what happens under the hood here:
At any point of time, an administrator logged in to the Backup Exec console can click on a backed up virtual machine and select “Recover Virtual Machine”. Backup Exec then rises a wizard prompting the admin for information where (on which hypervisor) the machine shall be started.
It then creates a (read-only) share for the folder where the backup image is located and mounts this share on the selected hypervisor.
Afterwards, it creates a new “empty” virtual machine on the hypervisor and mounts the backed up virtual hard drives from the share on the backup server into the new VM.
At last, Backup Exec instructs the hypervisor to create a snapshot of the new VM on the hypervisor’s storage that was selected within the “Recover Virtual Machine” wizard in Backup Exec and optionally start the virtual machine.
This way of recovering virtual machines has many advantages over classic restores:
- Since we’re not (or nearly not) restoring any data to the hypervisor, the time it takes to recover a virtual machine is independent on the size of the virtual machine. Instead it’s only the performance of the backup server that influences the time it needs to recover a VM by Instant Recovery.
- The data movement from the backup server to the virtual environment is done, when the VM is already running by vMotion in a VMware environment or by LiveMigration when using Hyper-V.
Data lifecycle management (DLM) is postponed for the backup set that was
used to create the instantly recovered virtual machine until you remove the virtual
machine. The next cycle of DLM expires the backup set.
Requirements for Instant Recovery
In order to be able to use Instant Recovery, your environment has to meet the following requirements:
- The Backup Exec Server has to be updated to Backup Exec 15, Feature Pack 5
- The server role “Server for NFS” must be enabled on the backup server if you want to use Instant Recovery with VMware ESX.
- The machine you want to recover must be backed up with GRT enabled.
Instant Recovery in Real Life
You can watch the video recorded for this post on YouTube:
Things to Keep in Mind
Even though Instant Recovery will improve the way we do restores in the future, there are some things to keep in mind when using this technology:
- The NFS share is visible from the network
SInce the NFS implementation on Windows servers is not secure, the shares Backup Exec creates are visible from the network.
- Don’t reboot the backup server
Rebooting the backup server will make the share unavailable, where the virtual hard drive of the running VM is located. This will almost sure result in a crash of the VM.
- Keep an eye on the performance of your backup server
Even though Backup Exec can run multiple IR machines in parallel, you should keep in mind that all these VMs are running on the local storage of the backup server, which obviously creates some load on the disks.
- Be careful when modifying IR VMs before thy have been moved
After a successful Instant Recovery of a VM, you can configure its properties with your hypervisor’s management tools. But please, be careful to do so, before the VM was moved back to the hypervisor’s storage.
Just think, what will happen, if you add additional hard drives to the VM and move data to them. Since these new hard drives are located on the hypervisor, but the original disks are still located on the backup server, you could run into several problems: Someone reboots the backup server, a migration of the virtual disks from the backup server to the hypervisor is no longer possible, because the disks on the hypervisor are full and so on.
- Don’t try to update your backup server
The installer routine will be blocked until you have removed all IR VMs from the backup server.
Download the Feature Pack
Download Feature Pack 5 for Backup Exec 15 here.
Thank you for reading this post and I hope, you found some interesting stuff here.