Well, to be honest enabling the Guest Queiscing after removing the sync drive make no sense usually. As the guest Quescing is usually handled by the sync driver. I can understand your worry of getting a crash consistant image when running without the sync driver, but getting a crash consistent OS image is better than having the sync driver crash your active DC when flushing all memory data to disk . Though I would not worry about a crash consisten windows as much as making sure VSS is handling my DC correctly. I believe your setting shall be OK, but remember even you had enabled guest Quescing that will do nothing without the Sync drive, though you really don’t want Quescing to happen any way.

A good thing to mention that vReplicator has a failover test functionality, which I recommend you test several time after you had finalized your setting & make sure your DC is coming up on the other site. Unfortunately, vReplicator still not the greatest tool when it come to VSS integration, but it still do the job.

I hope that help.

But now when I have your attention I wonder if you can confirm the setting below:

Environment:
ESX 3.5u4
latest vReplicator 2.5.4

Purpose:
Being able to restore a single W2k3R2 domain controller in a few minutes (this demand rules out vRanger)

Means:
Using vReplicator taking replicas once a day WITH Guest Queiscing enabled, removing the file sync driver and enabling VSS on the DC.
Is this the best setting? Will it give me a fully functioning restore when needed?
I’ve read that removing the file sync driver makes snapshots crash-consistent, doesn’t sound good, does it?

Regards,
henketh

But now when I have your attention I wonder if
you can confirm the setting below:

Environment:
ESX 3.5u4
latest vReplicator (sep 2009)

Purpose:
Being able to restore a single W2k3R2
domain controller in a few minutes (this demand
rules out vRanger)

Means:
Using vReplicator taking replicas once a day
WITH Guest Queiscing enabled, removing
the file sync driver and enabling VSS on the
DC.
Is this the best setting? Will it give me a
fully functioning restore when needed?
I’ve read that removing the file sync driver
makes snapshots crash-consistent, doesn’t
sound particulary nice, does it?

Regards,
henketh

I am sorry for the confusion, but if you read the article clearly you will find it cut into many parts with different configuration for different situation. As you are posting on the third part of the series I assume you are trying to backup a VM with a Database on it.

Please note in the article if you had looked at the part when running VCB you will find it clearly that we had asked to remove the “file sync driver”. We had skipped this step when going over the LAN as vRanger setting in regard of the file sync driver can stop the file sync driver when setup in the GUI, but it can’t control that when backing up using VCB. Any way if you don’t want to get confused which method to go for, you can always remove the “file sync driver” from database VMs.

I hope that clear it up .

In the event viewer you should see – NTDS Replication – “Active Directory has been restored from backup media”

Though a rule of thumb when backing up Active Directory is to always depend on have an extra system state backup a side. If you have a smaller enviornment and only one domain controller then backing up using the VSS & vRanger should give you a consistent image, but if you have more than one DC you should not risk it to use images backup and restore as the lag between the version of your domain controllers will definetly cause you a problem, beside if only one domain controller has failed its a lot easier to install a new one and DCPromo it than restoring it from an image & risk a crash in your AD.

I hope that help.

Thanks for your comment. You are absolutely right, though only if you have all the ESX server in your environment updated to VMware ESX 3.5 U2 or higher & ensured all have the VMWare tools updated to that version as well.

If you have some servers still running an earlier version of VMware & you VMotion the virtual machine to that server & take a backup there then you will have a consistency problem. What make me avoid mentioning this earlier is that you will not figure out your mistake while doing the backup as that will always complete, but you discover it when you have to restore which is very risky. Though if you have all your servers updated then its safe to say that you can use the VMware Tools VSS without any problem with vRanger & VCB. To make sure I share the full info about this, below is what vRanger had put up on their site in this regard:

========= Quote below form vRanger forum by gporter ======

You may or may not know VMware now has VSS build into VMware Tools.

How can vRanger Pro engage the VMware Tools built in VSS?

By unchecking “Disable Guest Quiescing” this will pass the API flag to use VMware Tools Quiescing. In ESX U2 the Quiescing is VSS. This works for both Network backups, VCB and vReplicator.

Note: A VM running on ESX U2 MUST have the VMware tools updated!

Unchecking this option for a VM that does not have the VMware tools updated to U2, could result in a running VM having a data integrity issue, as found in the VMware knowledge base around the LTOsync driver.

If you’re using vizioncore’s VSS on ESX 3.5 U2, you should leave the “Disable Guest Quiescing” checked. To avoid having two VSS providers running at the same time.

What is not supported

Unchecking the “Disable Guest Quiescing” option for a VM that does not have the VMware tools updated to U2 and is not running on a ESX 3.5 U2 host.

Running mixed mode jobs while Unchecking the “Disable Guest Quiescing” option , if you have a job that has VM’s running on a older version of ESX 3.5 and VM’s that are on running on a U2 host; This would result in your non ESX 3.5 U2 hosts running the unsafe “LTOsync” driver and this could result in data integrity issues. If you would like to use VSS and have mixed versions of ESX in your vRanger Pro backup jobs, you should utilize vizioncore’s VSS driver until you have all your hosts updated to ESX 3.5 U2. This will remove the risk of invoking VMware’s LTOsync driver and having a data integrity issue on running VM’s.

Unchecking the “Disable Guest Quiescing” option for a VM that can VMotion from a ESX U2 host to a non-ESX U2 host.

Using vizioncore VSS and unchecking “Disable Guest Quiescing” on a VM that is running on ESX 3.5 U2 and has the VMware tools up to date.

What about my existing backup jobs?

If you upgrade your ESX hosts too U2 and upgrade your VMware tools in place, but do not change your backups jobs you have two result’s possible.

1. If your backup jobs have the -noquiesce option, then your jobs will be fine.

a. You can remove this flag once all your ESX hosts and VMware tools have been upgraded to U2 to utilize the VMware tools VSS.

2. If your backup job does not have the –noquiesce option then you’re running the same risk today in regards to data integrity issues. Once you go to 3.5 U2 and U2 VMware tools the data integrity issues will be removed and you will be using VMware Tools VSS.

Note:

By using the VMware API (unchecking “Disable Guest Quiescing”) to execute VSS via VMware tools, vRanger and vReplicator no longer need IP connectivity to the VM, to execute VSS. Because we talk to Virtual Center or the ESX host to send the Guest Quiescing request , VMware then sends this request internally to VMware tools, thus removing the need for vizioncore’s VSS service on the VM, that requires IP connectivity to the guest.
Glen Porter
vizioncore, inc
847-589-2222 p
847-279-1868 f
gporter@vizioncore.com
http://www.vizioncore.com

========= End of vRanger Quote ======

Thanks again Martin & I hope my answer was helpful.