In this post I though it might be useful to share some information about VSAN interoperability with VMware’s flagship backup and restore product, vSphere Data Protection also known as VDP. First a note about versions – that you will need to use the March 2014 release of VDP (version 5.5.6), not just to backup VMs running on VSAN, but to back up VMs running on vSphere 5.5U1. Here is a comment taken from the release notes for ESXi 5.5 U1:
- vSphere Data Protection. vSphere Data Protection 5.1 is not compatible with vSphere 5.5 because of a change in the way vSphere Web Client operates. vSphere Data Protection 5.1 users who upgrade to vSphere 5.5 must also update vSphere Data Protection to continue using vSphere Data Protection.
So if you wish to deploy VSAN and backup virtual machines on the VSAN datastore, you will need to deploy a new 5.5.6 VDPA to back up those virtual machines since VSAN is only supported with ESXi 5.5U1.
Without getting into all the details of what VDP (or VDP Advanced) can and cannot do for you, suffice to say that we are interested in backing up virtual machines residing on the VSAN datastore and restoring virtual machines to the VSAN datastore. But before we do that however, I also wanted to point out that the VDP appliance can also be deployed on VSAN and that the storage disks used by VDP for saving backup data may also reside on the VSAN datastore (this in fact is one of the use cases identified for VSAN by the product team). During the VDP install, you are asked to allocate three x 250GB devices for storing the backups, and you can select the VSAN datastore for that purpose, as shown in this screen shot.
Disclaimer – I would not recommend reducing the Number Of Failures To Tolerate (FTT) from 1 which is part of the default policy. However, for some customers who have other replication techniques at their disposal, you could consider saving disk space on the VSAN datastore by setting FTT to 0. The other replication techniques that I am referring to leverage the backup replication facility built-in to VDP Advanced which allows you to replicate the backup data to another VDPA appliance, or indeed replicate to an Avamar grid, either on-premise or off-premise.
Again, I would seriously ask you to consider keeping the FTT=1. Whilst an FTT=0 may save you some disk space overall, a single disk failure with an FTT=0 policy may require you to reinstall your VDP/VDPA appliance and then restore your backup data. Using FTT=1 and replicating your backup data can be considered as a “belt and braces” approach to saving your backups. Think very carefully about changing from this approach. I would strongly urge you to only consider this approach if you have an alternate copy of your backed up data. Don’t set the Number of Failures to Tolerate to 0 if you have no other protection strategy, and then complain that you’ve lost all your backup data.
So what about the actual backups and restores of virtual machines on the VSAN datastore? Yep, no problems. Backup is done in just the same way as you would backup virtual machines on traditional datastores and restore in the same way. You can still do restores to the original location, overwriting the existing VM if it still exists, or you can restore the VM to a new location.
One thing to keep in mind is that the VM Storage Policy is not backed up with the VM. This isn’t a problem is you are restoring to the original location and overwriting the existing VM – you maintain the VM Storage Policy when you restore using that method.
However, if you restore to an original location and the original VM no longer exists, or if you restore to a new location, the VM will be restored with a default VM Storage Policy (which has Number Of Failures To Tolerate = 1). Therefore you will need to reapply the VM Storage Policy to this virtual machine after it has been restored.
Other than that, it does exactly what it says on the tin.