Question about the VSS consistency..

[verre]

Could someone help me to understand which are the differences between the two methods: Veeam VS VMware Tools.
I've already searched and read a lot of blogs and documents, but still to not understand.
What I've (hope to have) understood:
- VMware snapshots are crash consistent also without VSS
- If I want a OS File System and Application consistent I need to invoke the Microsoft VSS
- Microsoft VSS Provider asks the OS (OS writer) and Applications (Application writer) to freeze all IO operations in order to dump the RAM data to disk
- if I proceed to collect the data directly from Guest OS, the Microsoft VSS Provider sends the data to the VSS requestor (the Backup Software) and all data are consistent becouse Provider knows which data are been modified during the data collection
- if I proceed to prelevate the vmdk I cannot ask to VSS provider, BUT (now what I don't understand) I NEEDN'T TO ask to provider the data, becouse the vmdk doesn't change since the snapshot and all data in ram has been dumped before taking the snapshot!
- I know that with VMware Tools the OS File System is consistent thanks to VSS but the Applications are not consistent: which are the differences betweeb OS and Applications? What exactly do Veeam agent inside the vm?
Thank you a lot!

[Vitaliy S.]

- VMware snapshots are crash consistent also without VSS

Yes, if you don't enable either of the options (VMware Tools/Veeam AAIP), these VM snapshots are created in crash-consistent mode.

- If I want a OS File System and Application consistent I need to invoke the Microsoft VSS

Correct, you need to invoke file system VSS provider and application specific VSS provider.

- Microsoft VSS Provider asks the OS (OS writer) and Applications (Application writer) to freeze all IO operations in order to dump the RAM data to disk

Correct. These providers instruct applications to commit all operations/transactions and prepare themselves for hot backup.

- if I proceed to collect the data directly from Guest OS, the Microsoft VSS Provider sends the data to the VSS requestor (the Backup Software) and all data are consistent becouse Provider knows which data are been modified during the data collection
if I proceed to prelevate the vmdk I cannot ask to VSS provider, BUT (now what I don't understand) I NEEDN'T TO ask to provider the data, becouse the vmdk doesn't change since the snapshot and all data in ram has been dumped before taking the snapshot!

Not sure I fully understand you here, but when VMware takes a snapshot of the running VM, there might be some transactions still happening in the applications, and the end result of these transactions will not be reflected in the VM backup file.

- I know that with VMware Tools the OS File System is consistent thanks to VSS but the Applications are not consistent: which are the differences betweeb OS and Applications? What exactly do Veeam agent inside the vm?

There are many differences between Veeam application-aware image processing and VMware Tools VSS. For example, Veeam will truncate Exchange transaction logs upon successful backup, prepare DCs to start in DSRM mode upon first boot up after restore, and so on. You can review our sticky F.A.Q. (if you haven't done that already) for more information on this.

[verre]

Ok thank you. I have read all the FAQ I found around google but still not understand
I imagine that an application writes informations to disk through the ram memory. If I could have a snapshot and a backup of both disk and ram in the same instant, I needn't to request the vss help. Is it so? Both OS and APP change data in ram and disk.
I don't understand why OS and APP aren't managed both in the same way by vmware tools: maybe because APP changes the informations faster then OS?
Ok...then... step1: VMware Tools ask VSS to quiesce OS and APP; step2: VSS says to VMware Tools that all is ready to backup and VSS Provider makes a snapshot inside Windows to track the changes of applications; step3: VMware Tools say to ESX to proceed with snapshot; step4: ESX makes the snapshot; step5: ESX through the VMware Tools inform the VSS Provider that he has finished to take the snapshot (or whatever he made); step6: VSS provider unmount its snapshot.
ESX doesn't read the VSS snapshot therefore the only VSS use that he does is to ascertain that there aren't pending data from ram to disk before taking snapshot.
Now: between step2 and step5 the APP still write to disk rely on the VSS snapshot inside the OS (wich tracks all changes made by the APP), therefore the VMware snapshot is not (or could not be) consistent.
If all I have write are correct, I don't understand how the AAIP can resolve this trouble without freezing the APP.

[Vitaliy S.]

I don't understand why OS and APP aren't managed both in the same way by vmware tools.

Simply because VMware Tools do not implement application-specific processing logic for applications requiring such. It's not about the speed or other factors, please check out this topic for more info > VMWare Tools VSS

P.S. please be aware that memory state is not snapshotted while using VMware Tools quiescence. This parameter is optional and is not used to create backup files.

Let me know if that helps!

[Gostev]

One example of essential application-specific processing logic is transaction logs pruning during Microsoft Exchange backup. If the backup solution does not do this, transaction logs will overfill your Exchange server, causing an outage.

VMware Tools do not do this, but it is important to realize that this is not a bug or bad design on VMware side. This is simply because they are not a backup solution! Their quiescence is meant to facilitate creation of application-consistent snapshots, and nothing more than that. They cannot just randomly truncate logs each time the snapshot is done, because Microsoft requires the logs are truncated after successful backup only. VMware Tools cannot know if the snapshot is created for the purposes of backup, and if the backup will be successful eventually.

[verre]

Simply because VMware Tools do not implement application-specific processing logic for applications requiring such. It's not about the speed or other factors, please check out this topic for more info > VMWare Tools VSS

P.S. please be aware that memory state is not snapshotted while using VMware Tools quiescence. This parameter is optional and is not used to create backup files.

Let me know if that helps!

Thank you, I've read that post. I know very well how vmware snapshots work and I also know very well how VSS works. I know also the process of truncation logs but still not understand what exactly does the AAIP. I assume that:
- the AAIP are useless if I had to make the backup directly inside the OS becouse I can use the VSS snapshot
- the VSS snapshot wasn't designed to promote the backup using vmware snapshot
- vmware tools invoke the vss before taking vmware snapshot, but the application aren't consistent (I understand why!)
- veeam AAIP prepare the application before vmware snapshot (I don't understand how)

I understand that is not so important to know (the most important thing to know is that AAIP are better than Vmware Tools).... my doubts are only for curiosity. I hope to not bother you

[Vitaliy S.]

- the AAIP are useless if I had to make the backup directly inside the OS becouse I can use the VSS snapshot

If you're referring to backup solutions that have agents inside the Guest OS, then AAIP might not be required in some cases, that's correct. Please note that backup vendors that require agents inside the guest OS, usually also have different agents for different applications installed in the system.

- veeam AAIP prepare the application before vmware snapshot (I don't understand how)

Depending on the application we apply its specific settings required for application-level quiescence, and then VSS-aware restore. Due to competitive reasons we do not disclose exact steps for each applications that we use in our unique technology. In my post above, however, I have highlighted a couple of things we perform:

Veeam will truncate Exchange transaction logs upon successful backup, prepare DCs to start in DSRM mode upon first boot up after restore, and so on