5 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 is being moved from one server to
another server, to prevent users from accessing any of their data, and
queuing up any incoming messages. There are situations when a huge (5GB)
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 and, as such, the
end-user experience has been greatly improved.
This is what happens during an online Move-Mailbox, when a mailbox is moved (see Figure 9) from one server (EXBMX01) to another server in the same organization (EXMBX11), for example:
On
Mailbox Server EXMBX11, an empty copy of the user's mailbox is created,
just like a "legacy" move-mailbox operation. But instead of taking the
current mailbox offline (on EXMBX01), the original mailbox is kept
online. This is still the primary mailbox for the client, and new
messages still are delivered in this mailbox.
The
contents of the "old" mailbox are copied over to the mailbox on server
EXMBX11 and this mailbox is synchronized with the old mailbox.
As new items are delivered to the old mailbox, they are immediately copied over to the new mailbox.
When both mailboxes are in sync, the old mailbox is taken offline and the last messages are copied over to the new mailbox.
Active
Directory is updated with the location of the new mailbox, and the
mailbox is brought online again. The user may need to restart their
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.
6 Backup and restore
Exchange Server 2010 only
runs on Windows Server 2008 and Windows Server 2008 R2. This means that
the (free) NTBackup utility in Windows Server 2003 cannot be used to
backup Mailbox Databases on Exchange Server 2010. In any case, NTBackup
was only capable of creating "streaming backups" of your Exchange data,
not Volume Shadowcopy 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.
6.1 VSS or snapshot backups
With Exchange Server 2010, Microsoft has finally 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 point in time, which can be used to roll back the database in
case of a disaster. The Volume Shadow Copy Service, in Windows Server 2003 and later, provides an infrastructure to create these point-in-time images, which are 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. Effectively,
the backup consists of the data in the shadow copy combined with the
data on the original location, and both need to be available to
reconstruct the original data.
The Volume Shadow Copy Infrastructure consists of the following components:
Requestor
– this is the software that invokes the VSS and creates, breaks or
deletes the shadow copy. The Requestor is typically the backup
application.
Writer
– a software part that is provided by an application vendor. In our
case this is provided with the Microsoft Exchange Server. A writer is
responsible for providing a consistent point-in-time image by freezing
or quiescing the Exchange Server at the relevant moment. Please note
that an Exchange writer is provided for Exchange Server 2003 and higher,
right out of the box.
Provider
– a provider is the interface to the point-in-time image. This can
either be on a storage array (hardware provider) or in the Operating
System (software provider). Windows Server 2003 and above incorporate a
software Provider with VSS functionality out of the box.
The following steps occur when a VSS backup is performed:
The
Requestor (i.e. the backup application) sends a command to the Volume
Shadow Copy Service to create a shadow copy of the Storage Groups.
The VSS service sends a command to the Exchange writer to prepare for a snapshot backup.
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.
The
Exchange writer temporarily stops or quiesces the Storage Group 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.
The shadow copy is now created.
The VSS service releases the Exchange server to resume ordinary operations and all queued write I/Os are completed.
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
were not 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.
If
successful, the requestor creates either a differential or a 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. The backup is now complete.
NOTE
It
is the responsibility of the backup application to perform a
consistency check of the shadow copy. The Exchange writer does not
perform this check.
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 still take hours to complete depending on the size of the
databases.
6.2 Backup with Windows Server Backup
Windows Server Backup is a feature
in Windows 2008 (R2), and it can be installed using the Server Manager.
Open the Server Manager, select Features, and then select the Windows
Server Backup in the feature list to install it. When backing up your
Exchange data using Windows Server Backup, at least one disk is needed
to store the backups. This can be either a physical disk in the server
or a disk on a storage device.
When starting Windows
Server Backup there's no indication that it is Exchange Server 2010
aware; when the Exchange databases are located on drive G:\ and drive
H:\, these drives have to be manually selected in Windows Server Backup.
After selecting these disks, another
disk needs to be selected to store the actual backup. This can be any
disk, except the ones that are being backed up or the system disk (i.e.
the C:\ drive). When the backup is running, you'll notice that Windows
Server Backup checks the Exchange database for consistency.
When Windows Server Backup
has finished backing up the Exchange database, the header of the
database is updated with relevant backup information. The status of the
database can be examined using ESEUTIL /MH:
[Edited for readability]
Windows Server Backup also
logs all activities in the Eventlog. When checking the Eventviewer
you'll see the ESE and MSExhangeIS events, like:
And
When the backup
has successfully finished, the log files will be purged as well. Which
log files are purged will depend on how busy the server is during backup
(lots of new messages, moving mailbox, etc.) and the checkpoint depth.
Purging the log files is logged in the Eventlog as well:
NOTE
Windows
Server Backup is only capable of creating a full backup or a copy
backup. Incremental or differential backups are not supported.
6.3 Windows Server Backup and database replication
Windows Server Backup
can also create backups of databases that are in a Database
Administration Group (DAG), although a limitation of WSB is that it can
only create a backup of an active copy of the database. If you create a
backup of an active copy, the backup will succeed, but when the active
copy moves to another server and the local database becomes passive, the
backup will now fail!
The process of creating
backups is identical as in earlier paragraphs, except for the truncation
of log files. Log files are only truncated if all log files are
replicated and relayed to other database copies. Only then will the log
files on the active copy be truncated. This can take some time, which is
no reason for worry. It is also logged in the Eventlog:
