Agentless protection Rapid Recovery 6.0.1

As I mentioned here in the upgrading to Rapid Recovery 6.0.1 post, one of the most anticipated features for me of Rapid Recovery was the agentless backup.  Having to maintain agents of any kind is not fun for the administrator.  However, they are a necessary evil in some cases.  With RR 6.0.1 however, utilizing changed block tracking for VMs enables us to do away with the agents for backing up VMs in vCenter.  Let’s take a look at agentless protection Rapid Recovery 6.0.1.

Agentless protection Rapid Recovery 6.0.1

In order to perform the agentless protection, you have to go to the Protect >> Protect Multiple Machines option in the console which is a bit non intuitive.  After clicking the “Protect Multiple Machines” option, you are presented with the “Protect Multiple Machines Wizard.”

On the Connection screen, you need to enter the connection details of your vCenter/ESXi server and be sure to select the Protect selected VMs Agentlessly.

Here you select the VMs in your vCenter listing that you want to protect.  As the wizard denotes, you can select multiple VMs here.

You receive a warning that “The CBT VMware feature needs to be enabled (all ESXi snapshots will be removed)” and it references VMware KB 1020128 which explains what changed block tracking does as well as how to manually enable it.

Next, you can set your default protection settings or choose custom protection.

Here we specify a location for storing the protected data.

Finally, you can choose whether or not to enable encryption.

After you protect a VM agentlessly with your connection to vCenter, the protected machine will be listed under your vCenter server in the rapid recovery console.  This through me the first time looking for the machine, as you normall y see them in alphabetical order in the console, however, it will appear under your vCenter server whatever name it is listed as.

UPDATE 3.18.2016 – A few Gotchas with Agenless protection

In working with RR 6.0.1 agentless protection a few days now, I wanted to add a few thoughts to help everyone understand a few of the limitations of agentless protection that I was a little disappointed in.  One of the features of agentless protection that I assumed would work great would be protection for older OS’es that the fat RR agent couldn’t protect such as old Windows 2000 VMs (yes hard to believe but a few clients are still running one off VMs with older OS’es).  Since agentless uses CBT, I figured the agentless approach would fill in the gaps of where the agent could not.

In placing my first old OS into agentless protection, the snapshot worked great and recovery points started to be gathered.  However, after setting up a virtual standby to have this particular VM exported continuously in a backup core environment, I noticed the standby was failing with the error “Operating System version is unknown.”  After contacting support about this issue, I was given the response that the agent-less deployment works with Win 2008 and above. The Core may not recognize any OS lower than 2008 and with older OS’es, it cannot read the OS metadata.  So this was a true bummer.  I can backup the OS, but I can’t really export or restore it using Rapid Recovery exports.

Another issue by design is that if you are thinking about protecting a SQL or Exchange VM using the agentless method to perhaps avoid a reboot installing the agent, think again:  “Agentless protection does not collect Microsoft SQL or Microsoft Exchange metadata.”  Take a look at the KB here: https://i.dell.com/sites/csdocuments/Shared-Content_campaigns_Documents/en/Alder_Spec_Sheet_v3.pdf

Final Thoughts

As I spend more time with the agentless backups, I will update this post or create another post noting my observations with how well things flow with the agentless protection and backup.  All in all so far the agentless backup option seems to work very well.  There are the above mentioned limitations however that may place a damper on the enthusiasm for the agentless backup especially for older OS’es as well as database specific VMs that may be in an environment.