Web Guide: vSphere Virtual Volume VM Recovery and Snapshot Workflows

Before beginning let's review the setup and environment that will be used in the example workflows to follow.

>> Here is an Overview of the Environment and Virtual Machines used for the workflows in the KB (click to expand)

Here are 4 VVol VMs- two VMs per vCenter and each will have a different snapshot method. Each VM is a Windows Server 2016 VM with a 200 GB VMDK and 40 GB VMDK. The 200 GB is the OS volume and the 40 GB is the E Drive:

VVol VM 1 will be using Managed snapshots: The option to snapshot memory or quiesce the file system are not checked: Now, looking at the FlashArray for this VVol VM, the two Data Volumes have an additional volume with a -snap suffix: However, that is just for the Data Volumes. Take note that there is no snapshot or copy of the Config Volume: This is a key difference between storage policies and manual protection group snapshots. Without a backup of the Config volume, recovering a VM that was deleted or recovering a deleted VMDK gets a little bit more tricky. More on that to come.

On to VVol VM 2. Here a Storage Policy with Replication will be applied: Here the storage policy "1 hour replication" is applied to the VM Home (config volume) and the two VMDKs (data volumes): There is a specific replication group (flasharray protection group) that is selected for all volumes: The policy has been applied and is compliant: Looking at the FlashArray for VVol VM 2, notice that there are not any -snap volume copies and there are no volume snapshots found: However, look at the individual volumes (Config and Data) and you will see that the volume is part of a Protection Group as expected: The key part here is that we have a backup of the Config Volume. This is important as we have a point at which we can recover a deleted VM or VMDK in some cases.

Here is VVol-VM-3, which is much like VVol-VM-2 except it's a local snapshot storage policy and not a replication policy. The setup and configuration is similar to VVol-VM-2, just a different policy and replication group: Again, very similar to VVol-VM-2, no volume snapshot for the VVol VM: And here we see that the Config Volume is part of a protection group and there is a snapshot of the Config Volume:

With VVol-VM-4 we will be doing some manual snapshots (using the Pure web client plugin): We will take a manual snapshot of both the boot volume and the second vmdk: On the FlashArray we can see that there are snapshots for both Data volumes: However, there are no snapshots for the Config Volume: So VVol-VM-4 and VVol-VM-1 both have a "backup" of the two data volumes, but there is no backup of the config volume in either.

Let's review the FlashArray Protection Groups and see what they look like. With VVol-pgroup-rep-1 we see that VVol-VM-2 has the Config and both Data Volumes as members. This is expected as this VM had the storage policy for this pgroup applied: Then looking at the VVol-pgroup-snap-1 Protection Group we see that VVol-VM-3 has the Config and both Data Volumes as members as well: In addition to the two pgroups above, I created a manual snapshot pgroup that does not have a snapshot or replication schedule. Only the two Data Volumes for VVol-VM-4 were added as well as a manual snapshot for this pgroup:

Let's take a look at the VVol VMs and files that are there. With VVol-VM-1 there is the E drive labeled as VM-1-Volume and there are three files of varying sizes in that volume: With VVol-VM-2 there is the E drive labeled as VM-2-Volume and there are three files that are the same size: With VVol-VM-3 there is the E drive labeled as VM-3-Volume and there are three files that are the same size: With VVol-VM-4 there is the E drive labeled as VM-4-Volume and there are three files that are the same size: Now that we have a view what VVol VMs and what everything looks like on the array we can start to look at some of these scenarios.