safe snapshot removal

[Kevin_Day]

Hi,

I notice you have safe snapshot removal listed as one of your benefits to v4.

Would you be able to let me know or point me in the direction of what this actually does on top of normal snapshot removal?

I am reviewing to buy your product and am very impressed so far. But before I release it onto highly loaded SQL and Exchange servers I would prefer to see the benefits of this new technology to put my mind at rest. I have had snapshot removal problems in the past and wondered if this will now fix it?

Thanks,

Kevin

[donikatz]

The User Guide states that this option creates a second snapshot on top of the regular consolidation helper snapshot so that it doesn't take too long to commit the consolidation helper snapshot of heavy I/O VMs. Basically, it allows ongoing changes to be written to this second snapshot rather than the snapshot that is in the process of being removed, thereby eliminating possible freezes and/or very large committal times leading to timeouts. This is the same technique that I and many people have used for a long time to manually remove large snapshots. I love that Veeam has thought of adding this!

EDIT: We previously worked around such timeouts by using the VMware-documented hack to extend the client timeout from the default 15 minutes to the max of 25 minutes. Before that our Exchange server and two other db servers would have snapshot removal timeout issues with VCB/Veeam. Theoretically this new feature should eliminate such problems.

Question: The User Guide says this should only be considered for ESX 3.5 U1 and earlier hosts -- why is that? And are there any recommendations from Veeam engineers re MB settings for different scenarios? Thanks

[tsightler]

Question: The User Guide says this should only be considered for ESX 3.5 U1 and earlier hosts -- why is that? And are there any recommendations from Veeam engineers re MB settings for different scenarios? Thanks

I believe that VMware from ESX 3.5 U2 and later already does this internally, or pretty much this same thing, so it's really not an issue, although it will still timeout in the vCenter console.

[Gostev]

Correct, potential vCenter timeout issue is still there. This technique does not fix the time it required to delete large snapshot, but instead ensures that VM does not time out when it is freezed for last snapshot removal. Last snapshot can only be commited while VM is fully frozen to prevent any I/O to VMDK (as last snapshot is injected directly into VMDK). Large snapshot would then result 30-60 seс timeouts, and thus lead to VM application errors.

Presumably this issue is resolved in ESX 3.5 U2 because it creates consolidate helper snapshots iteratively (frankly, there is very little information about this functionality). We can only be 100% sure that many people are experiencing this issue with the previous ESX versions, and because we still have customers who locked on ESX 3.0.x, ESX 3.5 U1 and custom ESX 3.5 U1 builds (some large customers have those), we have decided to provide this functionality for them as an option as it was very simple to add.

This simplified diagram shows snapshot size changes during hot backup with and without safe snapshot removal. As you can see, VM freeze time is much shorter in case when safe snapshot removal is leveraged.