How to Backup Exchange 2010 RTM at Release Timeframe

Friday, October 30, 2009

As with any other major release of Exchange, there will be a gap in third-party vendor support for Exchange 2010 when it is released to general availability next month.

One of those gaps will be supported backup solutions for Exchange 2010.  Thankfully, Microsoft recognized this and added VSS backup support to the built-in Windows Server Backup feature in both Windows Server 2008 and Windows Server 2008 R2.  This capability has been introduced in Exchange 2007 SP2 and Exchange 2010 RTM, allowing you to backup Exchange 2007 SP2 and Exchange 2010 using a native VSS application provider.

Exchange automatically registers its application provider in VSS when Exchange 2010 is installed or when the Exchange 2007 server is upgraded to SP2.  This happens even if the Windows Server Backup feature isn't installed on the server yet.  You simply need to add the Windows Server Backup feature using Server Manager to your Exchange server to enable the Exchange aware VSS backup capability. 

Windows Server Backup (WSB) will allow you to perform Exchange aware backups, similar to NTBackup, with a few notible points:
  • Legacy (streaming) backups are not supported.
  • Since Windows Server Backup performs volume-only Volume Snapshot Service (VSS) backups, there is no specific "Exchange only" backup capability.  When you perform a backup of a volume that contains Exchange data (EDB and log files), WSB automatically performs an Exchange aware backup.  The only visual queue you will see is this, just before the data is backed up:
  • Once WSB notifies Exchange that the VSS Full Backup has completed successfully, Exchange will truncate the log files for all the Exchange 2010 databases or Exchange 2007 SP2 Storage Groups.
Note: The default behavior of WSB is to perform a VSS Copy Backup, which will not truncate the logs. To configure a VSS Full Backup you must configure a Custom backup (not Full Server), add the volumes that contain the Exchange data, click Advanced Settings, and select VSS Full Backup on the VSS Settings tab.
  • Backups must be run against the active node on Database Availability Groups (DAGs) or the active node in an Exchange 2007 CCR cluster.  When the backups complete successfully and the logs are truncated on the active node, the same operation will occur on the passive node.
  • You can backup either to a local hard drive or a network share
  • There is no remote server backup functionality. You must perform the backup from the Exchange server.
  • You can schedule the backups using WSB or install the WSB command line extensions to run a backup from the command line.
  • When restoring, you do not have to restore the whole backed up volume. You can choose to restore only Exchange application data by choosing to recover only the Exchange application, as shown:

And then select Exchange:

  • Recovery can be performed to the original location (overwriting the existing data) or to a new folder or location.  If you choose to recover to another location, WSB will copy just the application data, not recover the Exchange application itself.  You can then use this data in an Exchange 2010 Recovery Database (RDB) or an Exchange 2007 Recovery Storage Group (RSG).
  • You can redirect the restore of an Exchange application to another server.
  • Microsoft Data Protection Manager (DPM) 2010 is also in beta and is available for download.
In a future article, I will explain the process of using an Exchange 2010 Recovery Database (RDB) to recover data from a backup set.


  1. Hi everyone, been doing some backup testing and found some problems. It backs up Mailbox Databases from drive c: but not those from drive Y: I'll explain.
    First I will detail my lab. All computers are Windows 2008 SP2, Exchange 2010 RTM (updated from Exchange 2010 RC).
    2 EDGE Computers, 2 AD computers, 2 HUB/CLIENT computers.
    2 Exchange Mailbox Role computers in DAG: These 2 last computers have the next config each:
    Drive c: Besides O.S and Exchange files also database and logs for Mailbox Databases installed by default.
    Drive Y: (LUN from SAN) Mailbox Database 3
    Drive L: (LUN from SAN) Logs for Mailbox 3
    Circular logging disabled on all databases.
    All active mailboxes from DAG on server from which I do the backup.

    1 Test: Backup of C: with ENABLE SYSTEM RECOVERY option and Drive Y. Backup finishes OK but when I start to recover and I choose View details of Exchage Application I can Only see the Mailboxes Databases from Drive C:.

    2 Test: Backup of Drive Y. Backup finishes OK but when I start to recover and I can’t choose Applications because it is grayed out.

    3 Test: I move the Mailbox Database and logs from drive Y: and L: to C: and do a backup of C: with ENABLE SYSTEM RECOVERY option. When I start to recover and I choose View details of Exchage Application I can see all Mailbox Databases.

    My Conclusion: I’m doing something wrong or there is a bug because I can only backup Mailbox Databases from drive C:\.
    I hope it’s not a bug and someone can give me some help.

    Thanks to all,

    Ivan Mckenzie

  2. You have to backup both the Logs and Databases. This is why it works when you moved everything back to C:. Run the backup and select L: and Y:.

  3. I have ran through this about 5 times and it is not truncating the logs. Doing a VSS FULL and selecting the volumes that exchange is on (iscsi mount points). When I look at a restore I get the option for the application so I know it's seeing exchange and it even says during backup its checking consistency. Ideas?

  4. Tom, as mentioned in comments above, make sure you're backing up both the database and log volumes in the same backup job.

  5. Jeff,
    I did - I even selected the drive and the mount points under it for all of exchange and still no truncation... I just selected E and all the mount points mounted under E that contains all the logs and DB's. No truncation happening and circ logging is off.

  6. It's a nice post and it helped me adding the C: drive to the backup :) -- BUT!

    My system: 2008 R2, Exchange 2010 RTM fresh install. System/programs on C:, data on D: (mapped LUN).

    After finally got things to do real backup, the logs truncated but the .edb file stayed the same (8 MB) although we have a few GB of data already in the mailboxes. So the DB directory is now 52 MB in size which somehow doesn't go together. What happened? The backup VHD files are 17 and 12 GB large.

  7. Jeff:
    I'm having a similar problem as posted on here where my backup runs on the Exchange server without any issues or errors but still will not truncate the logs. This is an Exchange 2010 server (M/H/C) in a DAG, Database and Logs are on the E: Drive as well as the Exchange System Files. The two databases that sit on this server are Active and not passive copies. Nothing on the C: Drive for Exchange. I've ran through this several times and cannot see anything causing this from working. Any thoughts?

  8. luka_bike: I'm not clear about your email, but it sounds like you might be looking at the initial EDB file created on C: after the install? I can't understand how you can have a few GB of data in a 52MB EDB. The EDB size will not change after a backup.

    Mike: In a DAG scenario you should backup the passive database copy. When the VSS backup completes successfully, the logs will truncate on the passive node and the Exchange Replication Service will replicate that to all the other members of the DAG. See

  9. My readings show that the Windows Backups will fail when trying to backup a passive copy and that only the Active database can be copied.

    From TechNet:
    # The VSS plug-in that ships with Exchange 2010 can be used to back up volumes containing active mailbox database copies or standalone (non-replicated) mailbox databases only. It can't be used to back up volumes containing passive mailbox database copies. To back up passive mailbox database copies, you need either Microsoft System Center Data Protection Manager or a third-party Exchange-aware VSS-based application.
    # Passive mailbox database copies are backed up using a separate VSS writer in the Microsoft Exchange Replication service. The Microsoft Exchange Replication service VSS Writer doesn't support restores. Although you can back up a passive mailbox database copy using Microsoft System Center Data Protection Manager or a third-party Exchange-aware VSS-based application, you can't perform a VSS restore directly to a passive mailbox database copy. However, you can perform a VSS restore to an alternate location, suspend replication to the passive copy, and then copy the database and log files from the alternate location to the location of the passive database copy in the file system.


  10. Jeff:
    Not sure if I missed it but I couldn't find anything in that article saying you should be backing up the "passive" copy in DAG scenario. I was familiar with how it would replicate that back to passive copies of the db and truncate the logs in that copy as well as on the Active database in which the backup was performed on.

    Nonetheless, I did find what the problem was. I had the Exchange server holding the passive copy with the information store services shutdown so it could replicate that change, once I saw that and started the Information Store service it was able to replicate that and truncate the logs.

    Thanks for you feedback on my question!

  11. Mike, great that you found the answer to your problem. I assume you're using Windows Backup, not DPM? The two backup solutions have different backup providers that function differently. The article I referred to explains how they work.

    Either way, I'm glad it's working for you now.

  12. Correct, Windows Backup for this. Looks like DPM 2010 is the only MS Backup product that will support backing up DAG configurations of Exchange 2010 and I'm sure you know that it's not close to going RTM.

    Thanks again!

  13. I've been trying to get this working for weeks now without success - I'd love some insight.
    - Simple Exchange 2010 single server environment
    - Windows Server Backups complete without any errors

    When attempting RESTORE, the Applications option is greyed out.
    When performing the backups, it goes straight from PREPARING TO RUN CONSISTENCY CHECK to SCANNING to BACKING UP - no RUNNING CONSISTENCY CHECK.
    Nothing in the logs showing a problem
    WSBEXCHANGE service is installed
    VSSadmin List Writers shows the Exchange writer is OK.

    Any ideas how I can get a succesful backup?

  14. I am seeing similar symptoms to Ben.

    I have a two member DAG with two active databases on each member and a PF database. I have setup WSB to back them up (only the active databases) and it is completing with errors. Looking at the details of the errors, it shows that the consistency check was not run, and that Exchange cannot be recovered from the backup. The log files are not truncated.

    The OS is 2008 R2 and Exchange is 2010 RU1.

  15. @Ben: You seem to have the backup running not on the volume level, but on a folder level. Please make sure to backup all volumes that belong to the database and their logs in order to get the Application option during restore.

    @Dave: You seem to have passive database copies on the server that you want to backup. If this is the case, WSB cannot be used. You can either move the passive database copies to a different volume, or have all passive copies on a single server (that you obviously do not backup). Sorry, but this is a limitation in WSB.

  16. Thanks for the suggestion Sigi - however I'm pretty sure that the backup is running at a volume level, yet still gives the same behaviour.

    Is there any trick to running WSB at a volume level, other than selecting the root level of the drive?

  17. A little off subject; but thought I'd ask. Does anyone know of any free or inexpensive tools for doing item (brick) movement from one EDB to another for either Exchange 2010, 2007, or 2003?

  18. That point about the default backup option (VSS Copy) in the gray shaded area is key in my scenario. I will try this tonight to see if the transaction logs are cleared.



Thank you for your comment! It is my hope that you find the information here useful. Let others know if this post helped you out, or if you have a comment or further information.