35% of all restores do not do what their owners expect. This does not mean that backup software is accident
prone, more often than not, the problem is a simple human error. The most common cause is slipshod planning or faulty logic. My challenge to you is this, test a restore and so prove that your
backup tapes will
return the Exchange 2003 server to full working order.
What distinguishes the 65% of restores that succeed from the 35% that fail, is anticipating what could go wrong. You must give the restore process proper respect. Your server performs 100s
of backups for
every restore, nevertheless, as you configure a backup, so you must visualise how it will restore the mailboxes. Ask not what backup can do for your Exchange data, but ask what backup can do to make
the restore process easier. If you desire a smooth restore then understand how the databases interact with their log files. Your twin goals are: to restore the mailbox.edb database from backup and then
to replay the transaction logs and so return the mailstore to its current state.
Think of restoring an Exchange 2003 database as opening a combination lock. Once you have all the correct numbers in a line, then eureka, the lock opens. When you have the full backup set, any
differential tapes and the transaction logs, then restore just unlocks all that email.
Guy Recommends:
The SolarWinds Exchange Monitor
Here is a
free tool to monitor your Exchange Server. Download and
install the utility, then inspect your mail queues, monitor the Exchange
server's memory, confirm there is enough disk space and check the CPU
utilization. This is the real deal - there is no catch. SolarWinds
provides this fully-functioning product for free, as part of their commitment to
supporting the network management community.
Verify that MSexchangeIS service is running. Even though a restore requires you to dismount the affected mailbox, Exchange 2003 still needs the MSExchangeIS service to be running throughout the recovery procedure.
' This database can be overwritten by a restore ' Good databases like Exchange 2003 protect their data from accidents. Unless you deliberately select:
' This database can be overwritten by a restore ' then the existing .edb files cannot be replaced from backup.
Where do you find this checkbox? Mailstore, Properties, Database Tab.
' Last Backup Set ' or Eseutil /cc As you complete the restore procedure, watch out for:
Last Restore Set. After the database files are restored, then the log will start to replay the transactions. Without this setting the checkpoint file will prevent a hard recovery of the Exchange store.
When you restore multiple differential or incremental tapes, you need to uncheck the ' Last Backup Set '. However, when you reach final tape, this time, you tick ' Last Backup Set '. If you forget to tick the ' Last Backup Set
'
box, no worries, just run eseutil /cc instead.
'
Mount Database After Restore ' Of all the restore commands, '
Mount Database After Restore ' is the least important. The reason is that when you are ready, it's easy to Mount any database using the Exchange System Manager.
To be sure that the recovery is complete, wait until you see an ESE event ID 205 in the Event
Viewer, Application Log.
Terminology Check Hard recovery. Replays the Exchange 2003 logs after the last backup tape, or when you issue the eseutil /cc command. Hard recovery looks to the restore.env file for path and filename information.
Soft recovery. This is a normal procedure at startup, where Exchange's ESE (Extensible Storage Engine) replays the logs after the last Checkpoint. Uncommitted transactions get written to the database or rolled back. Just remounting a
store, triggers this built-in soft recovery routine.
Restore.env
This file holds drive and folder information about where the databases are situated. If you interrogate this file with notepad, then you can see the filenames and path of where restore expects to find key files.
To view the restore.env file issue eseutil /cm path to restore.env. Naturally you first have to navigate to the \bin folder which traditionally holds eseutil.
See more on Restore.env.
Guy Recommends: A Free Trial of the Network Performance Monitor
(NPM)
Solarwinds'
Orion performance monitor
will help you discover what's happening on your network. This
utility will also guide you through troubleshooting; the dashboard will
indicate whether the root cause is a broken link, faulty equipment or
resource overload.
Perhaps the NPM's best feature is the way it suggests solutions to network
problems. Its
second best feature is the ability to monitor the health of individual VMWare
virtual machines. If you are interested in troubleshooting, and creating network maps, then I recommend that you take advantage of Solarwinds' offer.
Re-install Exchange 2003 If the error message indicates that the problem is with a corrupt operating system file, then you could try Re-installing Exchange 2003 from the CD. Run setup as normal, then seek the Reinstall option from the
first Action Menu.
A variation of re-installing is executing setup /disasterrecovery. The difference is that the disasterrecovery switch prevents stores from being mounted at startup. The idea is that you repair any
damaged binary files, then apply service packs before you mount the stores.
Repair the .edb with Eseutil /p Eseutil /p (and /r) are kill or cure measures. So make sure that you backup your store before attempting such a drastic measure. Here is an example of a situation where you may try to repair the
Store.edb file:
Error -1216 (JET_errAttachedDatabaseMismatch) at least one log or database file is damaged.
Restore the Exchange database to another server Where ever possible, try and restore the database to the same Exchange 2003 server. However if this fails, and you restore to different server, then remember to apply the same service packs as the
original server.
Virtual Machines are great for reducing hardware costs, but they can
multiply fast and can get out of control. Solarwinds' VM Console is
the classic tool to answer this pair of questions:
Which VM's are struggling and thus need more resources.
Which VM's are idle, and so are literally a waste of (disk) space.
The benefit of a good utility such as Solarwinds Virtualization Manager
is that you see the big picture yet drill down into the detail of disk,
memory or CPU.
The only way to be sure that your backup is one of the 65% of the success stories, is to test a restore. Learning about the Exchange 2003 database and log files will not only help you to
backup and restore, but also give you ideas for proactive management. The secret of good disaster recovery is planning. In the case of restore that means attention to detail at the backup stage.
Disaster recovery is a case where the tail (restore) should wag the dog (backup).
Here is a
free tool to monitor your Exchange Server.
Download the utility, then inspect your mail queues, monitor Exchange server's
memory, confirm there is enough disk space and check the CPU utilization.
To be sure that the recovery is complete, wait until you see an ESE event ID 205 in the Event
Viewer, Application Log.
