@Gostev mentioned some data loss issues in conjunction with VMware Tools quiescence in his current “the word from Gostev”. This method is used, when Veeam application-aware processing is not enabled ...

… but “VMware Tools quiescence” is.

Also because of such issues, Veeam recommends using their application-aware backup.

So I want to ask the community, which backup method for application awareness do you use for Windows vSphere-VMs:

• Veeam application-aware processing
• VMware Tools quiescence.

I personally try to implement Veeam processing whenever possible (security, network,...). At least for AD, SQL-based applications, Exchange, ...

 

 

For me it’s either Veeam’s Application aware processing as default and only revert to VMware Tools where it’s unsupported to use Veeam.

We are using the VMWare Tools quiescence with application unsupported by Veeam only, too.

With all supported applications by Veaam we are using the application aware backup.

For windows really only VSS is the deal. I always tell people to check and see if their application is VSS aware, i.e. it has a VSS writer, otherwise the application should have some dumping method, or freeze/thaw script.

Vmware quiescing was using for some linux vms.

Application aware processing is the default for all jobs and we enable VMware Tools quiescing for non-VSS systems.

For future reference this is what Gostev Said:
@Gostev 
Last week our Support saw two different data loss issues in conjunction with the VMware Tools quiescence usage. Obviously this is not something we recommend using for application servers and our own proprietary application-aware image processing (AAIP) is there for a reason since Veeam Backup & Replication v2. Nevertheless some customers do still use it – so be aware that apparently, there are some new issues with its Microsoft VSS integration. The first issue is data corruption in backups, and it is easy to detect because you will have the corresponding Windows Event log warnings on protected machines saying in plain text that some data has been lost (event ID 50). Restoring such backups results in chkdsk prompt and possible application issues, depending on how well a particular application is designed to handle data loss.

The second issue is production data loss due to restoring an Active Directory (AD) domain controller (DC) from backup, which is basically a well-known USN rollback issue. The first white paper I wrote after joining Veeam 13 years ago was about this very issue! Now, experienced AD admins know that about half-way through since then, Microsoft implemented a change in Windows to combat the impact of reverting DC VMs to a snapshot by introducing so-called VM Generation ID feature. And while it should protect your Active Directory in such scenarios, apparently VMware Tools quiescence prevents it from working correctly (or something along these lines). This results in a VM snapshot containing the DC state that you really don't want to be backing up and later restoring! So basically, the recommendation remains the same as 13 years ago: use AAIP!
 

What I was not aware of for some time: Using “just” VMware Tools quiescence does also trigger a VSS snapshot in Windows. You can even restore - for example - SQL server with corresponding Veeam Explorer when you did a VMware Tools quiesced snapshot. While testing this works great. 

I always use Application Aware backups for Windows machines. Only exceptions is without application aware backups, so copy-only (crash-consistent backup). For Linux machines I don’t use yet application aware backups but vmware tools quescence or just crash-consistent backups.

I also did not know that vmware tools quiescence is a trigger to a VSS snaphost, as you can see, we learn every day :-)

I use Application aware coc AD & SQL, Exchange, but I disable quiescence.
i use quiescence only for non App aware.

Actually we do not use it for sql server, but for ad and exchange. (Both with Agent)

With Exchange and ad its working fine.

We were always in discussion with the database administrator. They only trust the backup from the sql manager. So if you force them, to use veeam, you will lose anyway. If its working - fine. If not, in any case, you are lost . So the database administrator is responsible for backup and restore there databases. With Veeam, we do backup the hole server including the sql backup files. So on an issue, we are able to restore the hole sql server in once. If the sql database are not working probably, we can restore them from sql backup. So it´s a kind of double protection. 

After this we do offlaoding to S3IA immutable + Archive due to our retention. 

Interesting I thought only Oracle DBA’s were so tough with their love of RMAN but it seems there are MS SQL folks like this too .

I had such a discussion with a customer last week. I would never try to bring SQL folks to Veeam-Only backup. I also see a lot of advantages, if they backup their DBs with native SQL tools. So they can backup and restore without a Veeam admin. And if everything goes wrong with SQL, Veeam admin can save their day.

I’m happy to use application aware backup for Windows Servers and Linux Agent.

I’ve never used VMWare Tools quiescence, I prefer to use pre-post freeze scripts!