Is it normal to not be able to do a file level restore if a snapshot exists?

[adidasnmotion]

I've been updating our windows VM's from Windows 2012 to Windows 2022 in these last few weeks.  Before updating I've been creating snapshots of the VMs and figured I'd delete the snapshots after a 1-3 weeks to make sure I didn't need to roll back the upgrade for any reason.  I recently had to restore a file and discovered that if I tried to do a file level restore I could not browse to the file location because I would get the error: "Error getting partition list."  It wasn't all VMs that had this problem but the ones that did had a filename that ended in "-000001.vmdk".  I finally realized that those are the VM's that had snapshots.  I deleted the snapshot for one as a test and had the same issue when I tried to do a FLR from an existing backup but if I created a new backup (after deleting the snapshot) I could finally browse to restore a file on that new backup. 

I now have 1-3 weeks of backups on all the VM's that had snapshots that are basically gone since they are inaccessible because of this issue.  Is this expected behavior that I just wasn't aware of or is this a bug?

[Sanika]

Hi adidasnmotion,

It looks like you are facing an issue with File Level Restore from the backup you created before upgrading the Windows OS.

This can be caused because of the presence of VMware snapshots on the Virtual Machine.

The administrator guide for the release you are on should list the supported partition types, if you have not tried FLR prior, it's worth checking if the filesystem is supported.

As the server is Windows OS, open disk management if the impacted disk is dynamic instead of basic you will not be able to perform a file-level restore from the plug-in tool. For Windows operating systems, it is required to use FLR with basic disks instead of dynamic disks.

You always have the option to fully restore the Virtual Machine and get the files that way if it is critical.

Also sometimes it might be caused when CTK option is enabled for the Virtual Machines. Try to disable CBT for the virtual machine by setting the ctkEnabled value to false to see if it helps.

To investigate further and resolve the issue, I recommend reaching out to HPE SimpliVity support as they can provide specific guidance and assistance in troubleshooting and addressing this problem.

Hope this helps.

Regards,
Sanika.

[adidasnmotion]

Looks like the issue is because we had snapshots on for the VM's we were backing up.  Our current process when making major changes to a VM is to take a snapshot of the VM before the change and keep that snapshot for about a week to make sure there's no need to roll back the changes.  Obviously this means backups that happen during that week are useless and essentially lost to us.  Is there a best practice on how we should handle major changes to a VM so that we can roll back the changes in case of an issue? 

It seems to me like we have two choices, either get a snapshot and not be able to get any backups while the snapshot exists or don't rely on snapshots at all and instead lock a Simplivity backup prior to the change and rely on that in case we need to roll back changes.  Is this second scenario how HP recommends we handle this situation?