Because
hardware occasionally fails and, in the real world, operating systems
do have problems, a server-recovery plan is essential, even though it
might never be used. The last thing any administrator wants is for a
server failure to occur and to end up on the phone with Microsoft
technical support asking for the server to be restored from backup when
no plan is in place. To keep from being caught unprepared, the
administrator should have a recovery plan for every possible failure
associated with Windows Server 2008 systems.
Restoring Versus Rebuilding
When a complete
system failure occurs, whether it is because of a site outage, a
hardware component failure, or a software corruption problem, the method
of recovery depends on the administrator’s major goal. The goal is to
get the server up and running, of course, but behind the scenes, many
more questions should be answered before the restore is started:
How long will it take to restore the server from a full backup?
If
the server failed because of software corruption, will restoring the
server from backup also restore the corruption that actually caused the
failure?
Will
reloading the operating system and Exchange Server manually followed by
restoring the System State be faster than doing a full restore?
Loading the Windows Server
2008 operating system and Exchange Server 2010 software can be a
relatively quick process. This ensures that all the correct files and
drivers are loaded correctly and all that needs to follow is a System
State restore to recover the server configuration and restore the data.
One of the problems that can occur is that, upon installation, some
applications generate Registry keys based on the system’s computer name,
which can change if a System State restore is performed.
Exchange Server 2010 has a setup /recoverserver
installation option and does not need the server’s System State
restore—just the original computer name and domain membership, as long
as computer and user certificates are not being used. Using this switch
also prevents the Exchange Server computer from creating the default
storage groups and databases. This simplifies the process of restoring
the server later.
The key to
choosing whether to rebuild or restore from backup is understanding the
dependencies of the applications and services to the operating system,
and having confidence in the server’s stability at the time of the
previous backups. The worst situation is attempting a restore from
backup that takes several hours, only to find that the problem has been
restored as well.
Keep in mind that if one is
utilizing redundant systems with a DAG configuration, the decision of
restore versus rebuild is almost entirely a question of which is faster.
Environments not based on DAG are more dependent on the identity of the
individual servers and tend to favor restores.
Manually Recovering a Server
When a complete
server system failure is encountered and the state of the operating
system or an application is in question, the operating system can be
recovered manually. Locating the system’s original configuration
settings is the first step. This information is normally stored in a
server build document or wherever server configuration information is
kept.
Because each system is different, as a general guideline for restoring a system manually, perform the following steps:
1. | Install
a new operating system on the original system hardware and disk volume,
or one as close to the original configuration as possible. Be sure to
install the same operating system version—for example, Windows Server
2008, Enterprise or Standard Edition.
|
2. | During installation, name the system using the name of the original server, but do not join a domain.
|
3. | Do not install additional services during installation, and proceed by performing a basic installation.
|
4. | When
the operating system completes installation, install any additional
hardware drivers as necessary and update the operating system to the
service pack and security patches that the failed server was expected to
have installed. To reduce compatibility problems, install the service
packs and updates as outlined in the server build document to ensure
that any installed applications will function as desired. During a
restore is not the time to roll out additional system changes. The goal
is to get the system back online, not to upgrade it.
|
5. | Using
the Disk Management console, create and format disk volumes and assign
the correct drive letters as recorded in the server build document.
|
6. | If
the server was originally part of a domain, join the domain using the
original server name. Because many Windows Server 2008 services use the
server name or require the service to be authorized in a domain, perform this step before installing any additional services or applications.
|
7. | Install any additional Windows Server 2008 services as defined in the server build document.
|
8. | Install
Exchange Server 2010 using the same version of Exchange Server
(Standard or Enterprise) that was originally installed. Apply any
Exchange service packs and updates that were expected to be on the
original server as well. When installing Exchange Server, use the setup /recoverserver installation process that will install Exchange Server but will not add new databases.
|
9. | Restore Exchange Server data to the new server.
|
10. | Test functionality, add this system to the backup schedule, and start a full backup.
|
Note
If certificates were
issued to the previous server, the new server must import the same
certificates or enroll with the certificate authority (CA) for a new
certificate before encrypted communication can occur.
