< Day Day Up > |
When a site becomes unavailable due to a physical access limitation or a disaster such as a fire or earthquake, steps must be taken to provide the recovery of the Exchange server in the site. Exchange does not have a single-step method of merging information from the failed site server into another server, so the process involves recovering the lost server in its entirety. To prepare for the recovery of a failed site, an organization can create redundancy in a failover site. With redundancy built into a remote site, the recovery and restore process can be minimized if a recovery needs to performed. Creating Redundant and Failover SitesRedundant sites are created for a couple of different reasons. First, a redundant site can have a secondary Internet connection and bridgehead routing server so that if the primary site is down, the secondary site can be the focus for inbound and outbound email communications. This redundancy can be built, configured, and set to automatically provide failover in case of a site failure. See Chapter 3, "Installing Exchange Server 2003," for details on creating Routing Group connectors and bridgehead servers. The other reason for redundant site preparation is to provide a warm spare server site so that a company will be prepared to perform a server restore of a site server in case of a site failure. The site recovery can simply be having server documentation available in another site or having a full image of server information stored in another site. The more preparatory work is conducted up front, the faster the organization will be able to recover from a system failure. Creating the Failover SiteWhen an organization decides to plan for site failures as part of a disaster-recovery solution, many areas need to be addressed and many options exist. For organizations looking for redundancy, network connectivity is a priority, along with spare servers that can accommodate the user load. The spare servers need to have enough disk space to accommodate a complete restore. As a best practice, to ensure a smooth transition, the following list of recommendations provides a starting point:
Allocating hardware and making the site ready to act as a failover site are simple tasks in concept, but the actual failover and failback process can be troublesome . Keep in mind that the preceding list applies to failover sites, not mirrored or redundant sites configured to provide load balancing. Failing Over Between SitesBefore failing over between sites can be successful, administrators need to be aware of what services need to fail over and in which order of precedence. For example, before an Exchange server can be restored, Active Directory domain controllers, Global Catalog servers, and DNS servers must be available. To keep such a cutover at a high level, the following tasks need to be executed in a timely manner:
Failing Back After Site RecoveryWhen the initial site is back online and available to handle client requests and provide access to data and networking services and applications, it is time to consider failing back the services. This can be a controversial subject because failback procedures are usually more difficult than the initial failover procedure. Most organizations plan on the failover and have a tested failover plan that might include database log shipping to the disaster-recovery site. However, they do not plan how they can get the current data back to the restored servers in the main or preferred site. Questions to consider for failing back are as follows :
The answers really lie in the complexity of the failed-over environment. If the cutover is simple, there is no reason to wait to fail back. Providing Alternative Methods of Client ConnectivityWhen failover sites are too expensive and are not an option, that does not mean that an organization cannot plan for site failures. Other lower-cost options are available but depend on how and where the employees do their work. For example, many times users who need to access email can do so without physically being at the site location. Email can be accessed remotely from other terminals or workstations. The following are some ways to deal with these issues without renting or buying a separate failover site:
|
< Day Day Up > |