Re: Backend Exchange migrate to New Hardware (Server)
- From: "hardy" <hardik03@xxxxxxxxx>
- Date: 31 Oct 2006 02:47:59 -0800
Use Below Steps to restore the server
Restoring Exchange Mailbox or Public Folder Stores
Note
The term database is used in this guide to generically refer to
Exchange mailbox stores and Exchange public folder stores.
When you use Backup to restore Exchange databases, application
programming interface (API) calls are made to the Exchange Extensible
Storage Engine (ESE) to restore Exchange database files and their
associated log files. You can use Exchange database backups to restore
one or more damaged mailbox or public folder stores. In a disaster
recovery scenario that involves rebuilding a server, use Backup to
restore your Exchange databases after you run Exchange Setup and any
Exchange service packs in Disaster Recovery mode.
Note
Installing Exchange (and any service packs that were running on your
server before the disaster) in Disaster Recovery mode prevents the
Setup program from mounting the databases after the Setup program is
completed. You can then correctly restore and mount your Exchange
database backups at the end of the setup process. Before you restart
your server, as prompted by Exchange Setup, make sure that the log
files have completed replaying.
This section contains the following information about restoring
Exchange databases:
• Overview of the database restore process.
• Recovering an Exchange database.
• Resolving Exchange database restore problems.
• Restoring Exchange databases to another server.
Overview of the Database Restore Process
When a restore operation begins, Backup informs the ESE that the
process has begun, causing ESE to enter restore mode. The database
(made up of a pair of files: an .edb file and an .stm file ) is then
copied from the backup media directly to the database target path. The
associated log files are copied to a temporary folder, and a separate
instance of ESE is started to replay the transaction logs from their
temporary location into the restored database.
The restore process creates the Restore.env file, which keeps track of
the storage group that the database belongs to, the paths of the
database files when they were backed up, the path to the database when
they were restored, the range of log files that were restored, and
other pertinent data.
You must restore a full backup set (either a normal or copy backup)
before you can restore a differential or incremental backup set. This
is because restoring a full backup set creates the Restore.env file.
Restoring a differential or incremental backup set only updates the
Restore.env file; it does not create one. If the Restore.env file does
not exist, the differential or incremental updates cannot restore.
Always use different temporary folders for each full backup set that
you are restoring. For example, if you were to restore two normal
backups to the same temporary folder the second Restore.env file that
would be created would overwrite the first Restore.env file. Therefore,
always specify a different temporary folder for each normal or copy
backup set that you are restoring.
However, when you restore an incremental or differential backup,
specify the same temporary folder you used for the full backup that the
incremental or differential backup belongs with, so that they are
paired with the correct Restore.env file.
After the database files are copied back to their original locations
and the Restore.env and transaction log files have been copied to the
temporary folder, ESE initiates a hard recovery to replay log files
into the database. This brings the database up-to-date with the time
that it was lost if all the log files since the backup was taken are
available. First, Restore.env is used to determine which transaction
logs will be played from the temporary folder. Then, if it is possible,
additional transaction logs from the target storage group are also
replayed.
Following hard recovery, the temporary instance of ESE is stopped. If
you select the Mount Database After Restore check box in Backup, the
newly restored database is automatically mounted in the target storage
group.
Figure 3.16 illustrates the Exchange restore process.
Recovering an Exchange Database
Exchange Database Recovery Checklist
Dismount the databases for each mailbox or public folder store that
you are restoring.
Configure the databases so that the restore can overwrite them
(optional).
Determine the database and log file locations of the files that you
are restoring (optional).
Copy the current database files to another location (optional).
Make sure that the mailbox and public folder store names in
Exchange System Manager match your backup media.
Make sure that the Microsoft Exchange Information Store service
(MSExchangeIS) is running.
Select the backup files that you want to restore from your backup
media.
Restore the selected files.
Make sure that the restore process was successful.
Replay the transaction log files (Eseutil /cc) (optional).
Mount the databases (stores).
Dismounting the Exchange Databases That You Are Restoring
Before you perform the restore process, you must dismount the Exchange
databases that you want to restore. If a database that you try to
restore is still mounted, the restore process will fail.
Note
When mailboxes and public folders are dismounted, they are inaccessible
to users. Because Exchange supports multiple storage groups and
multiple mailbox and public folder stores, you must dismount only the
databases that are being restored from your backup. To restore a
database without affecting e-mail users who have mailboxes on that
database, consider using a recovery storage group instead of its
original storage group, Typically, recovery storage groups are used
only when you want to extract or merge specific data from the backup
database to the original still running database.
To dismount the mailbox and public folder stores that you are restoring
1. Open Exchange System Manager. Click Start, point to Programs, point
to Microsoft Exchange, and then click System Manager.
2. In Exchange System Manager, navigate to the database that you want
to restore, right-click the database, and then click Dismount Store .
Note
You must dismount every database that you want to restore.
Configuring the Exchange Databases so That the Restore Process
Overwrites Them (Optional)
To ensure that the restore process overwrites Exchange databases, you
must configure the databases that are being restored. However, you do
not have to configure the databases if you restore them to their
original locations, or if you use recovery storage groups. It is only
required when the databases that you restore have different GUIDs in
Active Directory. For example, a different GUID is required when you
restore a database to another forest, such as a test forest. A
different GUID is also required if the Active Directory object for the
database has been deleted. When you re-create deleted objects in Active
Directory, you give each object a new GUID.
Unless you know that you must overwrite the database, do not use this
option.
To configure the Exchange databases so that the restore process
overwrites them
1. Open Exchange System Manager. Click Start, point to Programs, point
to Microsoft Exchange, and then click System Manager.
2. In Exchange System Manager, navigate to the database that you want
to restore, right-click it, and then click Properties .
3. On the Database tab, select the This database can be overwritten by
a restore check box
Determining the Database and Log File Locations of the Files You Are
Restoring (Optional)
If you plan to make copies of the damaged database so that you can try
to repair it later if necessary, you determine the location of the
database and log files so that you can move or copy them.
In the following procedure, you must record information from the
properties dialog boxes from both the database and the storage group
that contains the database. You must do this for each database you want
to move or copy.
To determine the database and log file locations of the files you are
restoring
1. Open Exchange System Manager. Click Start, point to Programs, point
to Microsoft Exchange, and then click System Manager.
2. In Exchange System Manager, navigate to the storage group that
contains the database that you want to move or copy, right-click the
storage group, and then click Properties
3. On the General tab, note the paths in the Transaction log location
and System path location boxes, and then click OK
Record these paths for each storage group that contains a database that
you want to move or copy.
The Transaction log location is the path where log files are written
for the whole storage group. These log files record every change made
to a database in that storage group. The System path location is where
other files critical to the storage group are kept, such as the storage
group's checkpoint file.
4. In Exchange System Manager, right-click the database that you want
to move or copy, and then click Properties.
5. On the Database tab, note the paths of both the Exchange database
file and the Exchange streaming database file, and then close the
dialog box
.
- References:
- Re: Backend Exchange migrate to New Hardware (Server)
- From: hardy
- Re: Backend Exchange migrate to New Hardware (Server)
- From: Alexander
- Re: Backend Exchange migrate to New Hardware (Server)
- Prev by Date: Re: Backend Exchange migrate to New Hardware (Server)
- Next by Date: Re: OALGen could not generate full details for some entries in the off
- Previous by thread: Re: Backend Exchange migrate to New Hardware (Server)
- Next by thread: Re: OALGen could not generate full details for some entries in the off
- Index(es):