Last updated on Thursday 1st of September 2022 01:58:34 PM

Troubleshooting Windows Quiescing

 Please note that this post is relative to old deprecated software ©XSIBackup-Classic. Some facts herein contained may still be applicable to more recent versions though.

For new instalations please use new ©XSIBackup which is far more advanced than ©XSIBackup-Classic.

See also: Troubleshooting Windows snapshots

As we all know, quiescing Windows Operating Systems is something that can become quite of a problem if you are hosting real time busy I/O services, such as SQL Server, Exchange, or some other service that requires atomic I/O operation consistency. Although when hosting Linux or Unix operating systems in ©VMWare ©ESXi, quiescing is not a problem most of the times, performing this operation prior to a snapshot in Windows hosted OSs can become a nightmare.

All this techniques are equally applicable to any other OS which lacks ©VMWare Tools support.

We have already dedicated some posts to this topic, like: Troubleshooting Windows Snapshots where we covered the matter from a more general OS perspective. Still, in some cases, addressing the problem from a perspective focused on individual services might be required.

Windows OSs behave "different" in ©VMWare ©ESXi, when you delve into the matter you realize that, in the end, it's all just something relative to the commercial war between MS and ©VMWare, and how they utilize these matters to manipulate users.

Nevertheless, a sysadmin needs a way to workaround all this shitty things and be able to properly backup his servers. There are a number of different approaches to the matter: from cold/ warm backups, which implies at a minimum an OS stop of some seconds, to more sophisticated solutions, which are the ones we'll be treating in this post.

As stated, simply setting --backup-how=warm to the backup job will instruct ©XSIBackup to shutdown the operating system, create a snapshot and start the guest OS right after the snapshot creation. This approach is simple, yet powerful, as it makes sure the snapshot data is consistent. The only drawback is that the OS has to be stopped for some seconds, which is not possible on mission critical services.

A better solution to the problem is to use a database proxy that can hold user queries long enough for the snapshot to be taken without the need to quiesce it. Putting the database server in a paused state in the interim, will allow running queries to finish, the proxy will then cache new queries while the database is paused. Once the snapshot is taken after some seconds, you can just resume the database server operation and the proxy will start to execute any pendant queries.

For the above to be possible, you need a way to run some custom script that executes previous to the snapshot creation and another one once the snapshot creation process ends. ©VMWare Tools provide us with a mechanism that allows to execute some script previous to the snapshot creation operation and another one once the snapshot has been created. This facilitates the management of pre and post snapshot scripts.

You will find all the datails about how this scripted logic can be applied to different ©VMWare Tools versions in ©ESXi Snapshots, errors and solutions (Windows script).

Depending on the services you are hosting, you might need to create different scripts, many software vendors provide their own, although we are taking about one liners like the following to pause the SQL Server service per instance.

net pause MSSQLSERVER


And the following to resume it.

net continue MSSQLSERVER


If you don't count with a database proxy that can cache your queries when the database service is in a paused state, then don't take the burden to employ this mechanism, as there will be "nobody" there to collect your DB transactions and whatever service makes use of the database server will appear as down and will in turn issue the corresponding connectivity errors. In such cases it's better to just use the --backup-how=warm strategy, as all benefit you will achieve by employing this approach will be an application error thrown to clients, instead of the VM being unavailable during the seconds that a snapshot creation usually last.

Still, even in the case of not having a DB proxy, some Sysadmins, specially in big corporation environments, will probably take the time to script something, at least to let users know the service will be down for some seconds.

Daniel J. García Fidalgo
33HOPS