Veeam Snapshot Not Getting Removed

[SamVan]

So the other day we had a major issue with snapshots created by Veeam in our VMware environment not being removed after the Veeam backup job finished.

We opened a ticket with Veeam Support and to our surprise we were told that this is a VMware issue and we were referred to VMware support!

This does not make?

I provide an analogy here:
A vehicle part manufacturer designs and builds a product. Thorough their vigorous testing they guarantee that they product works correctly with no issues. Now at one point the part stops working and on the top of that it crates more problems for the car. Is it fair to accept their claim to say it's the car manufacturer's fault? It was the part's manufacturer's responsibility to work correctly and any issues that is causing for the car, needs to be addressed and fixed by the part's manufacturer not the car maker. Does anyone follow my logic here? Am I right, in our Veeam case, in saying that it is Veeam Support who needs to be troubleshooting and fixing the issue not VMware?

I am certain that if we do call VMware they will not be assisting us since none of their original components were involved in taking the snapshot.

I would appreciate any feedback here.

Thank you.

SP

[veremin]

Can you please post your ticket number here, so that, we can take a look at the case and see whether the provided answer was correct? Thanks.

[foggy]

I am certain that if we do call VMware they will not be assisting us since none of their original components were involved in taking the snapshot.

Actually, Veeam B&R does not manage snapshot creation/removal tasks itself, but rather issues the API call to vSphere to do that. So this is kind of activity that is initiated and performed totally by VMware.

That said, I'm not saying that in this particular case the issue is on VMware side, there are too many things that could cause snapshot removal failure that is's hard to judge without knowing the details. Anyway, Veeam temporary snapshots should be cleaned up during the next job run - does it occur in your case?

[kgreen29]

They are correct. Failure to remove snapshot is not a Veeam issue. Veeam simply issues the call to vsphere and then just gets the status from there to display. If the snapshot fails to remove, its something in your vm structure. Either vsphere lost communication, high io on your disks causing timouts when trying to remove and consolidate the disks, or something else. Latency at time of removal as well as size of the deltas plays a big part. What you can do is manually remove the snapshot. If the snapshot does not show but you have delta disks still you will need to consolidate the disks. Vsphere 5.5 or later you can just choose snapshot consolidate or you can create a new snapshot then delete all. This may take a while depending on how big the chain is. With v8 it has the snapshot hunter built in where if you don't manually remove, it should see the failed removal and attempt to remove and consolidate before its next run. I had this issue when another admin was patching vsphere and rebooted vcenter while my backup was running.

[SamVan]

Vladimir,
This is the ticket number:
01078036
Thank you.

SP

[foggy]

I do not see any contradictory statements in the case. As stated above, this is not something Veeam B&R can control, so might be reasonable to involve VMware, if the issue persists.

[SamVan]

I still do believe the Veeam Tech Support should have gotten involved and offered to look at the settings and examine the Veeam log files (at least as a costumer courtesy) to find out what went wrong. I had expected this to be a normal operating procedure for a well-known, successful company like Veeam. I am truly shocked by type of response I got from the Tech Support with respect to the ticket.

Thank you all for you comments.

SP

[Ben Milligan]

Hi Sam!

Ben Milligan with Veeam Support. I apologize for this situation and want to see if I can help you here. The above is true, however I agree with you that my engineer could have certainly done a few checks, such as if you are using appliance mode, that the hot-added disks may still be attached, or another touch may have been present. It is accurate also that we do require VMware's assistance to truly understand root cause in almost all situations concerning these behaviors due to the fact it is vSphere-side operation failure.

I discussed this case with the engineer's lead as well, and are happy to reopen and continue working with you. Please let me know what you would prefer. Thanks!

[SamVan]

Ben,
Thank you for caring about your customers.
At this point I cannot duplicate the issue and therefore does make any sense to reopen the ticket.
Hopefully the issue will never recur for the same job or any current or future jobs. But if it does, I will refer to your post and the incident number if I need to to get assistance from Veeam.

Thanks again for being so considerate and for your excellent customer relations skills. I have been a big fan of Veeam for many years and have been constantly admiring the simplicity and efficiency of Veeam products on social media. I was the one who introduced Veeam B&R and sold the idea to my new company. I had to ran many tests and prove the concept but I knew it was worth it.
Actions, like what you just did here, make me an even stronger believer of the Veeam Magic.

Thank you and please keep up the good work!

Sam

[SamVan]

Hi Ben,
I have the same issue occurred on one of my VMs. Is your offer still on the table? Can the original ticket be reopened or a new ticket be opened for one of the Veeam Support Technicians to look at the issue?

Thanks

SP

[Gostev]

Hi, Sam. Sure, just contact our support and request your existing ticket reopened. Thanks!