A virtual machine within a VMware ESXi 5.x or 6.x environment has been accidently deleted, become inaccessible, or having other issues that require the virtual machine to be restored from a Pure Storage FlashArray snapshot.
This article is for restoring a virtual machine from a Pure Storage FlashArray snapshot only. This does not apply to other third party snapshot recovery processes or a Pure Storage FlashBlade.
Please follow the steps outlined below to successfully restore a virtual machine from a Pure Storage FlashArray snapshot:
1. Identify the VMware datastore that contained the problematic VM before the issue was identified.
2. Follow the steps in the VMware vSphere: ESXi Host Troubleshooting wiki under 'Identifying Pure LUNs' to determine which volume the restore will need to be completed on within the FlashArray.
3. Determine the snapshot on the FlashArray that you would like to perform the restore from:
root@slc-405-ct1:/# purevol list slc-production --snap Name Size Source Created Serial slc-production.4674 500G slc-production 2017-01-17 11:26:18 MST 309582CAEE2411F900011242
4. After the snapshot has been identified create a new volume from the snapshot:
root@slc-405-ct1:/# purevol copy slc-production.4674 slc-production-recovery Name Size Source Created Serial slc-production-recovery 500G slc-production 2017-01-17 11:26:56 MST 309582CAEE2411F900011243
5. Confirm the new volume has been created based off of the snapshot listed:
root@slc-405-ct1:/# purevol list |grep -e Name -e recover Name Size Source Created Serial slc-production-recovery 500G slc-production 2017-01-17 11:26:18 MST 309582CAEE2411F900011243
The 'Created' date & time should match the timestamp of when the snapshot was created on the newly created volume.
6. Map the newly created volume to the ESXi host you would like to deploy the virtual machine you are restoring:
root@slc-405-ct1:/# purevol connect --hgroup ESXi-HG slc-production-recovery Name Host Group Host LUN slc-production-recovery ESXi-HG slc-esx-1 253
7. Perform a rescan on the ESXi host that the newly created volume was presented to complete presentation of the LUN.
8. Add the recovery LUN as a datastore to the ESXi host(s) you plan on performing the recovery on:
Note in the output above that the recovery LUN is identified as a snapshot to our 'slc-production' datastore we will be recovering.
9. While creating the datastore ensure you choose the: 'Assign a new signature' option.
It is not uncommon for the resignature process to take several minutes to complete. If this task does not complete after 10 minutes, engage additional resources for assistance.
10. Once the datastore creation has completed you will note that the datastore name will be in the following format: 'snap-hexNumbers-originalDatastoreName'. The image below is an example of what this specific restore datastore looks like:
11. With the recovery datastore highlighted locate the 'Actions' wheel and click on 'Register VM...' to locate our VM that needs to be restored.
12. After you have located the VM in need of restoration step through the VMware prompts to add the VM to the ESXi host inventory.
While registering the recovery virtual machine to the ESXi host, and the original VM is still live on the ESXi host, ensure you rename the recovery VM. If you do not you will have two VMs with the same name and need to look at the underlying datastore properties to determine which VM is the recovery and which is the original.
13. Once the recovery VM is listed in the ESXi host inventory proceed with powering on the VM and ensuring it contains the required data and is accessible as expected. If the original VM is still in the ESXi host inventory ensure it is powered off to ensure no conflicts encountered.
When powering on the recovery VM you may be asked if the VM has been 'Copied' or 'Moved'. If the original VM is already destroyed and no longer in inventory you can safely choose 'I moved it'. If the original VM is not deleted and going to be around for additional time then you will need to select the: 'I copied it' option so that there is not a conflict in UUIDs between VMs.
14. Once the recovery VM has been powered on and data integrity is confirmed, you can now storage vMotion the VM from the 'snap-hexNumber-OriginalDatastoreName' to the original datastore (if the original datastore will still be used). Otherwise, if the customer is going to destroy the old datastore you can simply rename the recovery datastore and use it as needed.
15. If the customer decides to keep the original datastore, and the storage vmotion of the recovery VM has been completed, you can now safely unmap and clean-up the recovery volume as needed. If they are going to keep the newly created recovery datastore no clean-up is required and you can simply rename the LUN as needed.