Virtual machine snapshots and tier-1 apps: Not always supported

After seeing a discussion in the vExpert forums and in my own experience in talking to customers, I came to the conclusion that many people aren’t aware of some of the support restrictions around virtualizing tier-1 Microsoft applications.

The one support requirement that many folks aren’t aware of is the use of virtual machine snapshots on Microsoft applications, particularly Exchange or SQL.  For both applications, Microsoft is explicit in stating that virtual machine snapshots of any kind are not supported.

Why does this matter?  Many popular virtual machine backup products (purposely not naming any) rely on snapshots to take clean backups of running VMs.  That means using these products to backup Exchange or SQL VMs may be unsupported.

Here are the official Microsoft support statements for Exchange and SQL:

Microsoft Exchange 2010 System Requirements:

Some hypervisors include features for taking snapshots of virtual machines. Virtual machine snapshots capture the state of a virtual machine while it’s 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 aren’t application aware, and using them can have unintended and unexpected consequences for a server application that maintains state data, such as Exchange. As a result, making virtual machine snapshots of an Exchange guest virtual machine isn’t supported.

Support policy for SQL Server running in a hardware virtualization environment (covers all versions):

Virtualization Snapshots for Hyper-V or for any virtualization vendor are not supported to use with SQL Server in a virtual machine. It is possible that you may not encounter any problems when using snapshots and SQL Server, but Microsoft will not provide technical support to SQL Server customers for a virtual machine that was restored from a snapshot.

Pretty clear, right?  The SQL policy actually explains this the best.  They’re saying that you may not have any trouble using virtual machine snapshots, but if you restore a VM using a backup product that relies on snapshots then they will not support any issues with that restore.

What about virtual machine backup products that use an application aware VSS writer?  I’ve spoken to Microsoft about this in particular and the answer I got back matches what their policy states.  That is, if you’re using a virtual machine backup product that relies on snapshots, that solution is unsupported and you may be redirected to the backup vendor for support.  This is true whether or not the virtual machine backup uses an application aware VSS writer, as some popular backup products do.

When you are virtualizing your mission critical applications like Exchange or SQL, support is extremely important.  So what are your options?

1)  If you have a Microsoft Premier support agreement, then Microsoft will make reasonable efforts to support you even if you run in unsupported configurations.  If your organization has a Premier support agreement then you’ll most likely get support if you use a backup product that relies on virtual machine snapshots.  Always confirm with your Microsoft rep in advance to ensure they will support the configuration.

2)  Talk to your Microsoft representative and try to get the support statement clarified. Show them your configuration and get confirmation that it is or is not supported.

3)  Rely on the backup vendor for first level support if your restored VM is having issues.

4)  Use a different type of backup product for Exchange or SQL virtual machines.

As I said, mission critical applications have more strict requirements for support and I believe that you should make all attempts to follow these requirements.  These applications are usually too important to an organization to risk a lengthy outage due to a miscommunication or disagreement about what is or is not supported.

Share This:

21 thoughts on “Virtual machine snapshots and tier-1 apps: Not always supported

  1. This is really a serious thing that many of the people are not aware about the support restrictions of virtualizing tier-1 Microsoft applications. They should know this thing very well because virtual machine backup products are so useful to backup exchange.

  2. If one backs up a virtualized SQL or Exchange just using a regular backup, as if it were a regular physical server, not going through the virtualized center, is that OK?

    1. Hi Susan,

      Thanks for the comment. You’re correct – if you use traditional backup solutions that do not leverage virtual machine snapshots, then you are ok. You should still make sure that your backup product has an application aware VSS writer so that your backups are consistent.


      1. So is it safe to use the vendor’s snapshot backup in conjunction with the normal sql agent backup? So we would restore the snapshot first, followed by the normal sql restore?

        1. When you say “vendor’s snapshot” what do you mean exactly? Do you mean a snapshot using a supported VSS, or a virtual machine snapshot?

          If we’re only talking about a VSS snapshot and that is used as part of a traditional in-guest backup product then you should be supported. Microsoft is explicit in that they don’t support any virtual machine snapshots, even if an application aware VSS writer is used in conjunction with the snapshot.

          I would say that if you backup your SQL virtual machine in the same way that you backup your physical SQL server then you should be safe. You can always check with your Microsoft rep to be sure.

          And if you have a Microsoft Premier support agreement, you are likely to have support almost no matter what.

          Hope this helps!


          1. Ok, to clarify, if I use the Backup Exec Vmware agent to backup up the vmdk files through the vcenter to get the vm that I could restore – and then use the regular backup using their sql agent to restore sql… would that be supported?

          2. Hey Susan,

            I admit I don’t know that product very well so I can’t tell you for certain. What I do know is that it leverages things like VMware’s Changed Block Tracking feature which does in fact require virtual machine snapshots. So if you follow Microsoft’s support statement, that backup solution is unsupported.

            Now with that said, I am fairly certain that Symantec can provide first level support in the event that Microsoft will not support a virtual machine restored with that product. And again if your organization has a Microsoft Premier support agreement then you are likely going to be supported either way.

            At the end of the day, will Microsoft really not support you if you use a backup product that relies on virtual machine snapshots? It’s hard to say, but many organizations are unwilling to take that risk for a mission critical application like Exchange or SQL.

            I would reach out to Symantec to get their position on this subject. I suspect they will say that they’ve never heard of the Microsoft support policy I described in this post. That is part of the reason why I wrote this post in the first place – many have never heard of this policy. See what they say and hopefully that should give you the peace of mind that you need.

            If you do reach out to them, feel free to come back here and post what they tell you.


  3. This is a frustrating, if possbily understandable position by Microsoft. from what I’ve read in the Exchange System Requirements document I think that Microsoft is not so concerned about the backup of virtual disks via snapshot so much as those products which backup the VM memory state as well. That seems understandable, to prevent database corruption due to writes of in-memory data. However it leaves most every VMware-aware backup product out in the cold for tier-1 apps.

    So can you list any known products that provide VMware-aware, consistent image backups which do NOT use the snapshot mechanism?

    1. Hey Victor,

      The issue for Exchange (and SQL) is with VSS enabled snapshots and the fact that regular hypervisor snapshots do not include application aware VSS writers.

      For the most part, any product that takes an image level backup of a virtual machine will need to use a snapshot in order to maintain a consistent backup. I don’t know of any of the major VM backup product that does not use snapshots. You need snapshots to use advanced features in vSphere like Changed Block Tracking, so most products will use snapshots regardless.

      Like I said in the article many of those products include application aware VSS writers that make them safer to use with tier 1 applications. But you should confirm with Microsoft whether or not that backup method is supported. I know when I had conversations with folks at Microsoft about this I was told flat out that even if the snapshot is application aware it is still unsupported.

      For these applications I would stick with traditional backup methods and products. I know that Symantec, Commvault, and others have made these kinds of products for years.

      Hope this helps!


    1. I think we might be talking about two different things so let me see if I can clarify. There are two scenarios I can think of that involve snapshots of SQL Server virtual machines.

      1) Using a virtual machine backup product that uses snapshots to ensure a consistent backup. In that case the snapshot is taken, the virtual machine is backed up, and then the snapshot is deleted.

      2) Using a virtual machine snapshot as a method of rolling back a SQL Server virtual machine to a previous point in time.

      Scenario 1 is really what this post was about and that should be fully supported provided the backup product you’re using has a SQL Server aware VSS writer. Many popular products like Veeam or VMware’s VDP product support SQL Server and they should be ok. Restoring a backup of a virtual machine taken with one of these products should be supported.

      Scenario 2 is a little different. In that scenario you’re actually rolling back to a previous point in time and using a standard vSphere snapshot. vSphere snapshots can be VSS integrated but they’re only going to quiesce the operating system writes, not application level writes. Based on Microsoft’s updated support guidance, that scenario would not be supported. Whether or not it would work is a different question, but if we’re just purely talking about supportability then I think it wouldn’t work.

      Does that help clarify things for you?


      1. Greetings Matt:
        Yes, that does clarify things (Thank you!) and I’m more intrested in the 2nd scenario as I would actually be taking the snapshot of the VM while it was shut down to prevent any inconsistencies between OS level writes and app level writes.

        Now I’m curious if VMware would write anything into the OS layer event logs saying VM was rolled back as I don’t see how MS would know that a VM has been rolled back via snapshot unless they were told in this kind of scenario.

        Thanks again!

        1. I don’t think that VMware Tools writes anything into the Event Log when a snapshot rolls back (never checked but I don’t think so). But consider that if you roll back to a point in time that is days earlier, the Event Log is going to jump ahead in dates and you’ll have a gap in your logs. All logs on the server will do that, including those for Windows, SQL, etc.

          Remember that it isn’t so much an issue of Microsoft just saying, “We don’t support this” but rather “We can’t help you troubleshoot this if you call in for support if you’ve used snapshot technology that doesn’t include a SQL aware VSS writer.” You could run into problems if you’re taking a snapshot right when a transaction is coming in and that transaction is lost or corrupted. SQL may end up writing logs to that effect if that occurs.

          Depending on what you’re doing, it might actually be better to look at database snapshots at the SQL Server application level. Have you considered that?


          1. Greetings Matt:
            I didn’t think that VMware would, but now it’s matter of finding a lab environment and trying it out. 🙂

            Most of my current project revolve around migrations and / or platform upgrades (SQL 2000 -> SQL 2008 R2 etc) and the VMware level snapshots are for a “rollback position” in case the upgrade or configuration goes side ways.

            Yes I agree there is the potential of transaction corruption if the VMware level snpashot being taken while “hot”, but again the timing of the VMware level snapshot would be in an VM OFF state (OS and SQL not running) so there will be no potential interactions between the OS / SQL and VSS writers.

            Yes I agree DB snapshots would be the prefered method if I was rolling out code (SP / functions) or schema change, but it’s not applicable in the current scenario of upgrades / migrations.

            Besides not everyone has deep pockets to afford SQL Server Enterprise Edition. 😉

            Thanks for the insight and discussion!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.