Recovering a Deleted VVol VM within 24 Hours

In this example, a VVol VM will be deleted in vCenter. The workflow will be recovering the VM within 24 hours. The point here is that when a VVol VM is deleted in vCenter, the FlashArray Volume Group and Volumes are destroyed but not eradicated. After 24 hours the volumes and volume group will be eradicated. With each of these workflows the Volume Group and Volumes will need to be recovered.

>> Here is the Workflow followed to recover the FlashArray Volume Groups and Volumes: (click to expand)

Recover the Volume Groups:

Once the Volume Groups are Recovered, then recover their Volumes. There are a couple of ways to do this. One is to recover the volumes from the volume overview page.

With this example, VVol-VM-2's volumes will be recovered:

Select VVol-VM-2's Volumes and then Recover:

Once Recovered, the Volume Group for VVol-VM-2 will show the Config and two Data volumes as part of that Volume Group:

Another way to recover the Volumes would be to navigate to the Recovered Volume Group directly, in this example VVol-VM-1.

Then expand the Destroyed Volumes, click on the options and then select Recover:

Select all of the volumes and then recover:

Now the Volume Group will show that each of the destroyed Volumes are recovered:

This process was followed for the remaining VMs VVol-VM-3 and VVol-VM-4.

Now when browsing the VVol Datastore in vCenter, you will see that the VM Directories are there; however, they are empty since the Config Volume was cleaned up before the FlashArray was requested to destroy the Config Volume:

Now that the Volume Groups and Volumes have been recovered, let's walkthrough how to recover the VMs that were deleted in vCenter.

With vCenter Storage Policies (SPBM)

When using the Storage Policies, the Config and Data Volumes are added to the FlashArray protection group. This means that we have a backup of the Config Volume.

After the volume group and volumes have been recovered, the next step will be to navigate to the Config Volume and then recover the Config Volume from the snapshot that was taken before the VM was deleted.

There were two VMs with Storage Policies applied to them; this example will be using VVol-VM-3 as the recovery example. The volume group has already been recovered since it has the volumes currently. The next step is to recover the Config Volume and then register the recovered VM.

>> Here is the Workflow followed to recover the Config Volume and Register the Recovered VM: (click to expand)

Navigate to the Volume Group page:

Then Select the Config VVol:

Over in the Volume Snapshots for the snapshot you are restoring from (basically the one before the VM was destroyed), click the options button and then select Restore:

Keep in mind that doing the restore option here will overwrite the existing volume. The goal here is to restore the Config Volume to the point in time before the VM was deleted. Click on Restore then navigate back to vCenter:

Once in vCenter, navigate to the VVol Datastore, then Files and then to the VM that is being recovered; if you are already on that page, refresh the page. Now you will see all of the correlating files for that VM. Select the VMX file and then register the VM:

After the VM is registered, navigate to the VM page, select the recovered VM and then Power the VM on:

Before the VM is powered on, there will be a question asked if the VM was moved or copied. Answer the question that the VM was copied:

When the VM is powered on check that the files, application, etc all look good and the VM is accessible. In this example we can see all the VVol-VM-3 files are in place with the E drive:

There it is, when using SPBM with the VVol VMs recovering the deleted VM is a straightforward process as there is a backup of the Config Volume that can be recovered.

With vCenter Managed Snapshots

Sadly, with vCenter Managed Snapshots there is no snapshot taken of the Config Volume. This means we will need to create a new VVol VM (it can be empty) to get the correct mappings in place to then copy out the Data Volumes and then power on the recovered VM.

>> Here is the Workflow followed to create a new VVol VM: (click to expand)

From vCenter select the New Virtual Machine option

Create a new Virtual Machine:

Give it the name of the deleted VM and the location for the VM:

Choose the Compute Resource (match with what it was previously):

Select a storage policy and the VVol Datastore that the deleted VM was on:

Make sure the CPU and Memory are the same as what the VM had previously.

Then, match the Hard Disks size with what the size of the VMDKs were on the VM that was deleted. In this case, the C Drive is 200 GB and the E Drive was 40 GB:

Review all the information, make sure it looks right and then finish:

Now that there is a new VVol VM, on the FlashArray, there will be a new VVol-VM-1 Volume Group and associated Data Volumes that we will use as the copy out target.

>> Here is the Workflow followed to copy out the recovered volumes and overwrite the new VM's volumes: (click to expand)

From the FlashArray, we can see the new VM's Volume Group as well as the recovered Volume Group:

Then from the new VM's Volume Group, note the name of VMDK 1 and VMDK 2 Data Volumes (copy them down somewhere):

From the recovered Volume Group identify the Data Volumes for VMDK 1 and VMDK 2:

To recover VMDK 1, click on the volume for VMDK 1, confirm it's the correct size and volume name, then click on options and select copy:

Make sure that the Volume Group selected in the new Volume Group, for the volume name put in the exact name of the recovery data volume and select the overwrite option:

Again, confirm that the correct data volume is getting overwritten then proceed:

Then proceed to do the same thing for the Data volume for VMDK 2:

Confirm that the correct Volume Group and Data Volume name are being used:

Navigate to the New Volume Group and notice that the two Data volumes have an updated source volume:

Back in vCenter, select the VM that was created and power it on, VVol-VM-1 is used in this example:

After the VM is powered on, log in and confirm that the application and files look good:

There we have it, the above is the workflow for recovering a deleted VM from Managed Snapshots when there is no backup of the Config Volume.

With Array Protection Groups

The following example would be if SPBM was not in use, but the VM's volumes were manually put into a FlashArray Protection Group. The workflow will be similar to the one shown with SPBM in use if the Config Volume was in the protection group. If only the Data Volumes were put into the protection group then the example with manual snapshots will be used.

>> If there is a backup of the Config Volume: (click to expand)

Follow the process outlined in the SPBM example.

From the FlashArray, recover the Volume Group
From the FlashArray, recover the Volumes in the recovered Volume Group
From the FlashArray, navigate to the recovered Volume Groups Config Volume
From the FlashArray, select the snapshot to recover the Config volume from and then recover the Config Volume
From vCenter, refresh the VVol Datastore's files, then navigate to the Recovered VM
From vCenter, register the Recovered VM's vmx file
From vCenter, power on the Recovered VM and check that everything is running as expected

>> If there is no backup of the Config Volume: (click to expand)

Follow the Managed Snapshots Example.

From the FlashArray, recover the Volume Group
From the FlashArray, recover the Volumes in the recovered Volume Group
From vCenter, create a new VVol VM with the same configuration (CPU, Memory and VMDKs) as the deleted VM
From the FlashArray, navigate to the new Volume Group, get the Volume Name for each Data Volume
From the FlashArray, navigate to the recovered Volume Group, select the Data Volume for VMDK 1
From the FlashArray, copy the Data Volume for VMDK 1 to overwrite the Data Volume on the new Volume Group for VMDK 1
Repeat for any additional VMDKs as needed
From vCenter, select the new VM that was created and power on the VM
Access the VM after it's powered on (RDP or Console) and confirm the Application or Files are all there

With Manual Snapshots

There are two types of workflows here. First- if the the Config Volume has a manual snapshot. Second- if only the Data Volumes have a manual snapshot. If there is a snapshot of the Config Volume, then the workflow is the same as the one shown in the SPBM example. If only the Data Volumes have manual snapshots, then the workflow will be similar to the managed snapshots workflow or if array protection groups were used on just the Data Volumes.

>> If there is a backup of the Config volume: (click to expand)

Follow the process outlined in the SPBM example.

From the FlashArray, recover the Volume Group
From the FlashArray, recover the Volumes in the recovered Volume Group
From the FlashArray, navigate to the recovered Volume Groups Config Volume
From the FlashArray, select the snapshot to recover the Config volume from and then recover the Config Volume
From vCenter, refresh the VVol Datastore's files, then navigate to the Recovered VM
From vCenter, register the Recovered VM's vmx file
From vCenter, power on the Recovered VM and check that everything is running as expected

>> If there is no backup of the Config volume: (click to expand)

Follow the Managed Snapshots Example.

From the FlashArray, recover the Volume Group
From the FlashArray, recover the Volumes in the recovered Volume Group
From vCenter, create a new VVol VM with the same configuration (CPU, Memory and VMDKs) as the deleted VM
From the FlashArray, navigate to the new Volume Group, get the Volume Name for each Data Volume
From the FlashArray, navigate to the recovered Volume Group, select the Data Volume for VMDK 1
From the FlashArray, copy the Data Volume for VMDK 1 to overwrite the Data Volume on the new Volume Group for VMDK 1
Repeat for any additional VMDKs as needed
From vCenter, select the new VM that was created and power on the VM
Access the VM after it's powered on (RDP or Console) and confirm the Application or Files are all there

No Snapshots?

If there are no snapshots, then we are still okay. The process will actually be similar to how we would recover the manual snapshots and managed snapshots. The main thing here is without a Config Volume backup, we'll need to "recreate" the VVol VM and then copy out the recovered FlashArray data volumes.

>> Here is the Workflow followed to recover a deleted VM with no snapshots: (click to expand): Follow the Managed Snapshots Example to create a new VM and then to copy out the Data Volumes to overwrite the "new" volumes.

From the FlashArray, recover the Volume Group
From the FlashArray, recover the Volumes in the recovered Volume Group
From vCenter, create a new VVol VM with the same configuration (CPU, Memory and VMDKs) as deleted VM
From the FlashArray, navigate to the new Volume Group, get the Volume Name for each Data Volume
From the FlashArray, navigate to the recovered Volume Group, select the Data Volume for VMDK 1
From the FlashArray, copy the Data Volume for VMDK 1 to overwrite the Data Volume on the new Volume Group for VMDK 1
Repeat for any additional VMDKs as needed
From vCenter, select the new VM that was created and power on the VM
Access the VM after it's powered on (RDP or Console) and confirm the Application or Files are all there