VMWare Data Recovery Snapshot Removal

I have an urgent question.  Last night during backups, the RAID 5 deduplication store that my VMWare DR appliance backs up to failed.  When I found the problem this morning, there were two jobs that had been running for a number of hours, and continued to show as Busy in the interface.  I attempted to Stop each of the jobs a number of times in the Reports tab of the interface, but they would not respond.  I therefore opted to shut down the DR appliance.  After some time, the appliance did finally shut down.  I am currently working on correcting the hardware problem with the deduplication store.  I now have a relatively small (< 30 KB) snapshot file listed for each of the two servers whose backup jobs were stuck.  My question is, is it safe to delete these snapshot files?  Or, once the deduplication store hardware issue is resolved and the DR appliance is restarted, will it automatically manage and delete the snapshot files?  VMWare support is not available on the weekends for DR appliance issues, so I am hoping someone can help me out here.
Thanks in advance,
rdillionSystems AdministratorAsked:
Who is Participating?
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
Do not DELETE the snapshot file.

When you restart the vDR applicance, vDR will handle the removal of snapshot file, and possibly dismount the virtual disks currently connected to the vDR appliance.

You may also want to test and re-run the backups, and check why the Backup Jobs failed.

Also check your Restore Repository for broken restores, and delete them, and re-index the store again manually.

This can take some time to comeplete.
rdillionSystems AdministratorAuthor Commented:
Thanks hanccocka, I appreciate your help and quick response.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.