Share via

Microsoft Exchange Server 2010: Manage database copies

  • Article

You can create and manage copies of Exchange databases for archiving and disaster recovery purposes.

Excerpted from “Exchange 2010 - A Practical Approach,” published by Red Gate Books (2009).

Jaap Wesselius

A database copy is just what it sounds like: a copy of an active database. However, it’s often stored on another Exchange Server, in the same database availability group (DAG). When you initially configure Exchange, there’s a copy of the database file sent to the other server. When you’re finished, Exchange Server 2010 starts replicating the log files of this particular database over the network to the other server.

The relative location of the passive copy of the database is identical to the location of the active copy. For example, an initial database on an Exchange Server 2010 Mailbox Server may be located in the directory C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 1444276156. If there’s a database copy enabled for this server, the same directory is created on the second server.

The process of copying a database to a second location is known as seeding. It’s a best practice to use separate disks for Exchange databases, both from a performance perspective as well as a disaster recovery perspective. After configuring Mailbox Database 1444276156 to use the separate disk G:\ for storing its information, you can configure the database copy:

  1. On the target server (the server that will hold the database copy), make sure there’s a volume identical to the one on the source server. The target server in this example needs a separate G:\ disk as well.
  2. Open the Exchange Management Console (EMC), expand Microsoft Exchange On-Premises (EXMBX01), then expand the Organization Configuration container and click on the Mailbox node. Select the Database Management tab.
  3. Select Mailbox Database 1444276156. In the lower part of the results pane, you’ll see there’s one copy (the active copy) located on the first Exchange Server EXMBX01. Right-click Mailbox Database 1444276156 and select Add Mailbox Database Copy …
  4. In the Add Mailbox Database Copy wizard, select Browse to select a Mailbox Server that will hold a copy of the database. The Activation Preference Number is the order in which Exchange will make a passive copy into an active copy when the preceding active copy fails. Of course, this is only useful if you’ve configured multiple passive copies. Click Add to continue. (You can read more about the Activation Preference Number and what happens when a database becomes active.)
  5. Exchange will now copy the database file Mailbox Database 1444276156.edb to the target server and set up replication. Depending of the size of the database file, this can take some time.
  6. When the database is copied and replication activated, click Finish.

Once the process is finished, log on to the target Exchange server. You’ll notice that on this server (on the G:\ disk in this example) there has been a Mailbox Database 1444276156 directory created where the copy of the database is stored. You’ll also see the log files replicated to this directory.

If there are a lot of databases used on an Exchange Server, using mount points is a valid alternative. In a mount point scenario, Server Manager mounts all data disks to a directory on the server—for example, F:\DB01, F:\DB02, F:\DB03 and so on.

In an Exchange Server 2007 Cluster Continuous Replication (CCR) environment, the active server also ships log files to the passive server. This in turn also loads the log files into its copy of the database. The passive server is truly passive, however. The service responsible for the database and the log files (store.exe) isn’t running. The only service that’s running is the replication service. During a failover, the passive node has to start all Exchange services. You need to have all databases mounted before that can happen.

In Exchange Server 2010, the store.exe service is already running and the databases are already mounted on all machines in a DAG. Therefore, database failover is much faster, resulting in a much shorter overall failover time.

For maintenance purposes, you can move an active database copy from one Exchange Mailbox Server to another with the following steps:

  1. Log on to an Exchange Server and open the EMC.
  2. Expand the Exchange On-Premises (SERVER). Expand the Organization leaf. Click the Mailbox and then click the Database Management tab.
  3. All the databases in your Exchange Server 2010 environment will show up in the upper half of the results pane. Right-click the database you want to move (which is, of course, also a database with multiple copies).
  4. Select Move Active Mailbox Database from the context menu.
  5. In the Move Active Mailbox Database wizard, select Browse to choose another server to which you want to move the Active Copy.
  6. Click the Move button to move the Active Copy of the database to the server you selected.

Online move-mailbox

The online Move-Mailbox feature is new in Exchange Server 2010. In older versions of Exchange Server, the mailbox is taken offline when it’s moved from one server to another server. This prevents users from accessing any of their data and queuing up any incoming messages. There are situations when a huge (5GB and up) mailbox has to be kept offline for more than an hour while the move takes place. None of these make for a particularly usable system.

With the new online Move-Mailbox functionality—now called New-MoveRequest—the time a mailbox is offline has been reduced to only seconds. This greatly improves the UX.

This is what happens during a New-MoveRequest, when a mailbox is moved from one server (EXBMX01) to another server in the same organization (EXMBX11):

  1. On Mailbox Server EXMBX11, Exchange creates an empty copy of the user’s mailbox, just like a legacy Move-Mailbox operation. Instead of taking the current mailbox offline (on EXMBX01), the original mailbox is kept online. This is still the primary mailbox for the client. New messages still are delivered in this mailbox.
  2. The contents of the old mailbox are copied over to the mailbox on server EXMBX11, and this mailbox is synchronized with the old mailbox.
  3. As new items are delivered to the old mailbox, they’re immediately copied over to the new mailbox.
  4. When both mailboxes are in sync, the old mailbox is taken offline and the last messages are copied over to the new mailbox.
  5. Active Directory is updated with the location of the new mailbox, and the mailbox is brought online again. The user may need to restart his Outlook client, but the Client Access Server should automatically detect that the mailbox has moved and start using the new location. Either way, the user can continue working in just a matter of seconds.

The online Move-Mailbox not only works between Exchange Server 2010 Mailbox Servers, but also when moving mailboxes from Exchange Server 2007 SP2 to Exchange Server 2010. Unfortunately, moving from Exchange Server 2010 to Exchange Server 2007 is still an offline move. Likewise, moving mailboxes from Exchange Server 2003 to Exchange Server 2010 is always an offline move.

Backup and restore

Exchange Server 2010 only runs on Windows Server 2008 and Windows Server 2008 R2. This means you can’t use the (free) NTBackup utility in Windows Server 2003 to back up Mailbox Databases on Exchange Server 2010.

In any case, NTBackup will only create “streaming backups” of your Exchange data, not Volume Shadow Copy Service (VSS) backups of your Exchange database. Exchange Server 2010 contains a plug-in for the Windows Server Backup (WSB) to make it possible to create VSS backups of your Exchange Server 2010 databases.

VSS or snapshot backups

With Exchange Server 2010, Microsoft has moved away from the traditional online streaming backup to VSS (or “snapshot”) backups. A snapshot is just an image of a database created at a particular moment. You can use this to roll back the database in the event of a disaster. VSS (in Windows Server 2003 and later) provides an infrastructure to create these point-in-time images called shadow copies. There are two kinds of shadow copies:

  • Clone (Full Copy or Split Mirror): A complete mirror is maintained until an application or administrator breaks the mirror. From this point on, the original and the clone are fully independent of each other, and the copy is effectively frozen in time.
  • Copy on Write (Differential Copy): A shadow copy is created as a differential, rather than a full copy of the original data. Using Copy on Write, a shadow copy of the original data is made before it is overwritten. The backup consists of the data in the shadow copy combined with the data on the original location. Both need to be available to reconstruct the original data.

The VSS infrastructure consists of the following components:

  • The requestor is software that invokes VSS and creates, breaks or deletes the shadow copy. The requestor is typically the backup application.
  • The writer is a software part provided by an application vendor. In our case this is provided with Microsoft Exchange Server. A writer is responsible for providing a consistent point-in-time image by freezing Exchange Server at the relevant moment. Note that an Exchange writer is provided for Exchange Server 2003 and higher, right out of the box.
  • The provider is the interface to the point-in-time image. This can either be on a storage array (hardware provider) or in the OS (software provider). Windows Server 2003 and above incorporate a software provider with VSS functionality out of the box.

The following steps occur when you perform a VSS backup:

  1. The requestor (backup application) sends a command to VSS to create a shadow copy of the Storage Groups.
  2. The VSS service sends a command to the Exchange writer to prepare for a snapshot backup.
  3. The VSS service sends a command to the appropriate storage provider to create a shadow copy of the Exchange Storage Group. This storage provider can be a hardware storage provider or the default Windows storage provider.
  4. The Exchange writer temporarily stops the Storage Groups and puts them in read-only mode. A log file roll-over is also performed to make sure that all data will be in the backup set. This will hold a couple of seconds for the snapshot to be created (in the next step). All write I/Os will be queued.
  5. Now Exchange creates the shadow copy.
  6. The VSS service releases the Exchange Server to resume ordinary operations, and all queued write I/Os are completed.
  7. The VSS service queries the Exchange writer to confirm that the write I/Os were successfully held during the shadow copy creation. If the writes weren’t successfully held it could mean a potentially inconsistent shadow copy, so the shadow copy is deleted and the requestor is notified. The requestor can retry the shadow copy process or fail the operation.
  8. If successful, the requestor creates either a differential or clone snapshot, and then verifies the integrity of the backup set (the clone copy). If the clone copy integrity is good, the requestor informs the Exchange Server that the backup was successful and that the log files can be purged.

Steps 1 through 7 usually take about 10 seconds, as this is the time needed to create the actual snapshot. This is not the time to create a backup, though. A backup application still has to create the backup on another disk or to tape, which can take hours to complete, depending on the size of the databases.

The backup is now complete. The backup application has the responsibility to perform a consistency check of the shadow copy. The Exchange writer doesn’t perform this check. It’s important to perform this check to ensure a clean and complete copy.

Jaap Wesselius

Jaap Wesselius is the founder of DM Consultants, a company with a strong focus on messaging and collaboration solutions. After working at Microsoft for eight years, Wesselius decided to commit more of his time to the Exchange community in the Netherlands, resulting in an Exchange Server MVP award in 2007. He’s also a regular contributor at the Dutch Unified Communications User Group and a regular author for Simple-Talk.

Learn more about “Exchange 2010 - A Practical Approach” at red-gate.com/our-company/about/book-store.

Related Content