Snapshot of Exchange VM

[JoJoGabor]

Microsoft's Exchange support policy states:

+Some

hypervisors include features for taking snapshots of virtual machines.

Virtual machine snapshots capture the state of a virtual machine while

it is running. This feature enables you to take multiple snapshots of a

virtual machine and then revert the virtual machine to any of the

previous states by applying a snapshot to the virtual machine. However,

virtual machine snapshots are not application-aware, and using them can

have unintended and unexpected consequences for a server application

that maintains state data, such as Exchange Server. As a result, making

virtual machine snapshots of an Exchange guest virtual machine is not

supported.+

However now that VMware snapshots support VSS quiescing surely this is a supported way of Snapshotting Exchange, seeing as it is VSS aware. DOes anyone know this to be true, or if Micrsofot are plannign on supporting this method?

[kghammond2009]

I am not sure about Microsoft supporting this method, but we had MS in for a visit yesterday and they mentioned that Exchange 2007 SP2 has VSS integration. I have been reading that once a VSS snapshot is taken, Exchange will commit its logs...

So it is feasible that a snapshot of Exchange may convince Exchange that a backup was completed. You may need to sync your Exchange backups with your snapshots, or use some other method to ensure your log integrity until a backup is performed.

[JoJoGabor]

As far as I am aware anything later than Exchange 2003 running on Windows 2003 is VSS aware. As is SQL Server 2005 and Sharepoint 2003. I guess where I am coming from is can we now safely snapshot these types of VMs without the risk of corruption as VSS should be being called within the Guest.

[paultwo]

Another question related to Exchange snapshots...

If you create a snapshot of an Exchange server and revert back to it later (lets say 1 day). What happens to the new mail that was delivered to Exchange? Does it get imported back into the Exchange mailbox if it has been downloaded to Outlook (offline files)?

[JoJoGabor]

No it will be deleted, as the mail is stored on the disk and the disk is reverted to your snapshot. The mail is not stored anywhere else as Exchange has confirmed it as delivered. The exception to this would be if you used independant disks for your database so that these were not snapshotted and reverted.

[kghammond2009]

JoJoGabor wrote:As far as I am aware anything later than Exchange 2003 running on Windows 2003 is VSS aware. As is SQL Server 2005 and Sharepoint 2003. I guess where I am coming from is can we now safely snapshot these types of VMs without the risk of corruption as VSS should be being called within the Guest.

My understanding is that any VSS aware snapshot will create a stable, recoverable, point in time recovery of any VSS application (Recent versions of Exchange, SQL, SharePoint). My point is that taking a snapshot of Exchange may flush or commit your transaction logs. So if you are snapshotting your VSS aware virtual machine, and then you swing by later with a tape backup agent, there will be inconsistencies in your backups and recovery methods.

For example, you backup Exchange at 6 PM and flush the logs. Now you snapshot at 11 PM which also flushes the logs. Exchange gets corrupted at 1 AM. At this point in time, you have one Exchange DB on your tape backup with all your email through 6 PM, you have one copy of Exchagne in your snapshot with all your email through 11 PM, and you have transaction logs on your server with email from 11 PM until 1 AM. If you recover from your tape backup, you will not be able to reply the logs from 11 PM - 1 AM since it is missing the logs from 6 PM until 11 PM.

Now I understand you can just recover to the snapshot and replay the logs from there. The point is that if you are backing up your VSS enabled application with a backup agent and you are snapshotting it with a VSS agent as well, you will need to be aware of which backup method was the last successful VSS backup of application when you need to recover it.

I hope that makes sense.

Kevin

[JoJoGabor]

Hi Kevin,

Its the backup program that commits then deletes the transaction logs. All the VSS provider will do is quiesce the database and check for consistency. This process will take approx 2 seconds. Here is the full details of how it works...

So to me it would seem that taking a vSPhere Vss-integrated VM-level backup should produce reliable crash-consistent and application-consistent backups, so I can't see why Microsoft would not support it as it is using their VSS framework. However Hyper-V uses the same process and they still don't support Exchange using Hyper-V snapshots so I'm interested to know why

[JoJoGabor]

I think I've just ofund my answer in the above link...

Verification of snapshot consistency is a mandatory requirement for the solution to be supported by the Exchange team.

Due to the snap nature of VSS backups, JET does not get the opportunity to touch all the pages to do the necessary consistency checks. Therefore, it is VSS Requestor's responsibility to ensure snapshot consistency.

However, I still think they are being overly-cautious. VSS has proven itself to be reliable so I can't see a reason not to perform VSS-integrated snapshots

[kghammond2009]

Hi Kevin,

Its the backup program that commits then deletes the transaction logs. All the VSS provider will do is quiesce the database and check for consistency. This process will take approx 2 seconds. Here is the full details of how it works...

So to me it would seem that taking a vSPhere Vss-integrated VM-level backup should produce reliable crash-consistent and application-consistent backups, so I can't see why Microsoft would not support it as it is using their VSS framework. However Hyper-V uses the same process and they still don't support Exchange using Hyper-V snapshots so I'm interested to know why

Hmmm, that was my understanding as well, but I have read some forum posts lately that challenged that belief. Maybe you are correct though that it is the Snapshot program that is the one deleting the transaction logs... I don't know the techniques used to remove the transaction logs, but does either the VMware VSS provider or VSS itself offer the capability to flush the transaction logs after a successful snapshot? I have not tested VSS integrated snapshots in our VMware enviornment yet, so I can't comment on personal experience to validate any of the above.

I believe one of the places that I came across this information was regarding Vizioncore's vRanger VMware Backup program.

It looks like I have more research to do.

Kevin

[vtek63]

What would happen if the setup was with Exchange 07 and the Database and logs were stored on a seperate LUN that is attached to the VM via raw mapping (physical compatibility mode).

And the Exchange VM was reverted back a day?

With the physical compatibility mode, that LUN wouldn't get snapshotted

right? would exchange get confused with the database and logs?

[Rumple]

As long as all database and logs (including storage group files) were not stored on the C: drive then a rollback of the operating system shouldn't cause any issues since everything exchage related (except for binaries) are stored on the other drives.

I'd be pretty damn sure I'd be testing that with a test environment prior to trying that in production though...I'd also make sure I had some good exchange backups as well.

I've done it with Exchange 2003 more then a few times using physical Live imaging software, just haven't tried that with 2007 yet.

[JoJoGabor]

I was speaking to an ex-colleague who now works at Microsoft in SQL Server support, and he was explaining to me why SQL Server does not support snapshots. Its to do with it constantly requiring Disk IO, if this is paused SQL will have a fit and this can result in a corrupt database. It is the same for Exchange server. He is trying to get a definitive answer for me regarding VSS aware snapshots in vSphere, but until I have this answer, I strongly recommend not to run any snapshotting on database based systems