If
an Exchange Server database is corrupt, it is not extremely effective
to restore the corrupt database to a production server. The server might
continue to operate, but database corruption never goes away on its
own, and you eventually need to repair the database. In fact, when minor
database corruption is not repaired, the corruption can get to the
point that entire sections of the Exchange Server database become
inaccessible.
A couple of methods can
be used to repair a corrupt Exchange Server database, or at least
restore the database and extract good information from the database. Key
to the successful recovery of as much information as possible is using
the right tool. In many cases, administrators jump right into using the ESEUTIL /p
repair command; instead of repairing the Exchange Server database to
100% condition, the utility finds a corrupt section of the database and
deletes all information from that portion of the database on. So,
although the Exchange Server system becomes 100% clean, the utility
deleted 20%–30% of the data that was in the database to get the database
to a clean state. The ESEUTIL /P command
is the task of last resort: Other tools work around corrupt database
areas and enable the administrator to recover as much of the data as
possible.
Exchange Server 2010 makes
this process easier for the new administrator by introducing the
Database Recovery Management tool that analyzes the failed databases for
the administrator and choose what tools to run against them.
Flat-File Copying the Exchange Server Databases
One of the best
techniques Exchange Server experts use when working to recover
corruption in a database is to make a flat-file copy of the Exchange
Server databases. A flat-file copy is merely an exact copy of the
Exchange Server databases copied to another portion of the server hard
drive or to another server. To do a manual copy of the databases, do the
following:
1. | Dismount
the Exchange Server database stores by going into the Exchange System
Manager. Traverse the tree past Administrative Groups, Servers, Storage
Group. Right-click on the mailbox store, and select Dismount Store.
|
2. | Dismount the store for all mailbox stores you will be working on.
|
3. | Copy (using Windows Explorer, or XCOPY) the *.edb files to a safe location.
|
Note
If the databases need to be
manually restored, a simple XCOPY (or Windows Explorer copy) of the
databases back to the original subdirectories will bring the data back
to the condition the databases were in at the time the databases were
copied off the system. If the Exchange Server databases were properly
dismounted before they were copied, the logs would have already been
committed to the database, and the database can be remounted exactly
where it left off.
Moving Mailboxes to Another Server in the Site
One way of
extracting mail from a corrupt database is to move the mailbox or
mailboxes to a different server in the site. Instead of trying to run
utilities to fix the corruption in the database, which can take several
hours (or even days, depending on the size of the database and the
amount of corruption that needs to be fixed), an administrator can set
up another server in the Exchange Server site and move the mailboxes to a
new server.
Moving mailboxes
grabs all the mail, calendar, contacts, and other mailbox information
from one server and moves the information to a new server. As the
information is written to the new server, the information is
automatically defragmented, and corruption is not migrated. In addition,
mailboxes can be moved from one server to another without ever having
to bring down the production server. A mailbox user must be logged off
Outlook and must not be accessing Exchange Server before the mailbox can
be moved. However, if mailboxes are moved when individuals are out of
the office, at lunch, or on weekends, the mailboxes can be moved without
users ever knowing that their information was moved from one system to
another.
The two caveats to
moving mailboxes are these: Corrupt mailboxes will not move, and user
Outlook profiles will be changed. For Outlook profiles, because a user’s
Outlook profiles point to a specific server, when a mailbox is moved
from one server to another, the user’s profile also needs to point to
the new server. Fortunately, with Exchange Server and Outlook, when a
user’s mailbox is moved, Outlook tries to access the mailbox on the
original server, and the server notifies Outlook that the mailbox has
been moved to a new Exchange server. The user’s Outlook profile
automatically changes to associate the profile to the new server where
the user’s mailbox resides. So, as long as the old server remains
operational and the user attempts to access email from the old server,
the profiles will be automatically changed the next time the user tries
to access email. Typically, within one to two weeks after moving
mailboxes from one server to another, the user profiles are all
automatically changed.
As
for corrupt mailboxes, unfortunately, Exchange Server typically does
not move a corrupt mailbox. So, if a user’s mailbox has been corrupted,
the mailbox remains on the old server. Moving the data from the corrupt
mailbox needs to be handled in a manner specified in the following
section, “Recovering Data with a Recovery Storage Group.” However, if
80%–90% of the user mailboxes can be moved to a new server, the
administrators are trying to recover only a handful of mailboxes instead
of all mailboxes on a server. This could mean far less downtime for all
users who had mail on the server and could limit the exposure of data
loss to a limited number of users. It will also result in much faster
results when running the database recovery tools as the database will be
much smaller.
To move mailboxes between servers in a site, do the following :
1. | Open the Exchange Management Console.
|
2. | Expand Recipient Configuration and click Mailbox.
|
3. | Highlight the mailboxes to be moved.
|
4. | From the Action menu, choose New Local Move Request.
|
5. | Select the destination for the mailbox to be moved, and click Next.
|
6. | Choose how you want the tool to deal with corrupted messages, and click Next.
|
7. | Review the proposed changes and if you are satisfied that they are correct, click New.
|
8. | You
can review the status and results of the move request in the newly
added Move Request section by expanding Recipient Configuration in
Exchange Management Console.
|
Running the ISINTEG and ESEUTIL Utilities
When a database is
determined to be corrupt, usually an administrator is directed to run
the built-in utilities on Exchange Server to run maintenance on the
databases. The utilities are the ISINTEG (“eye-ess-in-tehg”) and ESEUTIL
(“ee-ess-ee-u-tihl”). However, depending on the condition of the
database, a corrupt database can take several hours to run, only to
result in the loss of data. Some administrators are incorrectly told to
never run the utilities because they will always result in loss of data.
It’s typically just a lack of knowledge of how the utilities work that
leads to misunderstanding the potential results of the databases.
As noted in the
previous two sections, there might be better options for recovering
information from a corrupt database. Instead of trying to fix a known
corrupt database, simply migrating the information off a server or
extracting information from corrupt databases is frequently a better
fix. However, if the determination is to run the utilities, a few things
should be noted:
The ISINTEG
utility is a high-level utility that checks the consistency of the
database, validating the branches of the database that handle data, data
directory tables, attachment objects, and the like. Fixing the database
table makes way for a more intensive data integrity check of the
database.
The ESEUTIL utility is a low-level utility that checks the data within the database. ESEUTIL
does not differentiate between a corrupt section of the database and
how that section impacts mailboxes or messages. So, when a complete
repair is performed using ESEUTIL,
entire mailboxes can be deleted, or all attachments for the entire
database can be eliminated to fix the corruption. This is why running ESEUTIL to repair a database is a function of last resort.
To run ISINTEG
on a database takes around one hour for every 10GB scanned for a
moderately corrupt database. The repairs are done relatively quickly,
and the database is ready for more extensive scanning.
Running ESEUTIL
on a database takes anywhere from one hour for every 10GB to up to one
hour per 1GB, depending on the level of repair performed. It is not
unreasonable to see a relatively corrupt 30GB database take more than 24
hours to complete the repair.
ISINTEG and ESEUTIL
can be performed only offline, meaning that the Exchange server is
offline during the process. Users cannot access their mailboxes during
the ISINTEG and ESEUTIL
processes. Thus, if it takes 20 to 40 hours of downtime to complete the
repair of a database, the Move Mailbox method that can be run without
bringing servers offline is frequently a more palatable solution.
However, if run on a regular basis, the ISINTEG and ESEUTIL
utilities can clean up an Exchange Server database before serious
corruption occurs. Administrators who get scared off performing
maintenance because of the potential threat of losing data could
actually minimize their chance of data corruption if the utilities are
run regularly.
The common parameters used for the ISINTEG and ESEUTIL
utilities are as follows. For regular maintenance, such as checking the
database structure’s integrity and performing defragmentation of the
database, the following commands should be run:
isinteg –s SERVERNAME –test allfoldertests
eseutil /d priv1.edb
Note
The ISINTEG and ESEUTIL utilities typically reside in the \Program Files\Microsoft\Exchange Server\V14\Bin directory of the Exchange server.
When a database needs to be repaired, eseutil /p priv1.edb can be run. Beware: The /p
repair command is a brute-force repair and deletes sections of the
database to make the integrity of the database clean. A message provides
an additional warning about ESEUTIL. When running the /p command in ESEUTIL, entire sections of the database might be deleted to repair and recover the state of the database.
Note
Prior to a disaster, if the ISINTEG or ESEUTIL
utilities have not been run against an Exchange Server database for a
long period of time, restore the database from tape to an Exchange
server in a lab environment to run tests. These tests can tell you how
much corruption might be present and give an indication of how long it
might take to repair the database.
