What to Do Before Performing Any Server-Recovery Process

What to Do Before Performing Any Server-Recovery Process

If a full server recovery will be conducted , or if a number of different procedures will be taken to install service packs , patches, updates, or other server-recovery attempts as an attempt to recover the server, a full backup should be performed on the server.

It might seem silly backing up a server that isn't working properly, but during the problem-solving and debugging process, it is quite common for a server to end up being in even worse shape after a few updates and fixes have been applied. The initial problem might have been that a single mailbox couldn't be accessed, and after some problem-solving efforts, the entire server might be inaccessible. Having a full backup of the server in its current state provides a rollback to the point of the initial problem state. When the backup is complete, verify that the backup is valid, ensuring that no open files are skipped during the backup process or that, if the files are skipped , they are backed up in other open file backup processes.

CAUTION

When performing any recovery of an Exchange server or resource, be careful what you delete, modify, or change. As a rule of thumb, never delete objects that are known throughout the directory; otherwise , you will not be able to restore the object due to the uniqueness of each object. As an example, if you plan to restore an entire server from tape, you do not want to first delete the server and then add the server back during the restoration process. The restoration process requires the existence of the old server in the directory. Deleting the server object and then adding the object again later gives the object a completely different globally unique identifier (GUID). Even though you restore the entire Exchange server from tape, the ID of the server and all of the objects in the server will be different, making it more difficult to recover the server. Other replicable objects that should not be deleted include public folders, public folder trees, groups, and distribution lists.

Preparing for a More Easily Recoverable Environment

Steps can be taken to help an organization more easily prepare for a recoverable environment. This involves documenting server states and conditions, performing specific backup procedures, and setting up new features in Exchange Server 2003 that provide for a more simplified restoration process.

Documenting the Exchange Environment

Key to the success of recovering an Exchange server or an entire Exchange environment is having documentation on the server configurations. Having specific server configuration information documented helps to identify which server is not operational, the routing of information between servers, and ultimately the impact that a server failure or server recovery will have on the rest of the Exchange environment.

Some of the items that should be documented include these:

• Server name

• Version of Windows on servers (including Service Pack)

• Version of Exchange on servers (including Service Pack)

• Organization name in Exchange

• Site names

• Storage group names

• Database names

• Location of databases

• Size of databases

• Public folder tree name

• Replication process of public folders

• Security delegation and administrative rights

• Names and locations of Global Catalog servers

Documenting the Backup Process

Important in simplifying a restore of an Exchange environment is to start with a clean backup to restore from. A clean backup is performed when the proper backup process is followed. Create a backup process that works, document the step-by-step procedures to back up the server, follow the procedures regularly, and then validate that the backups have been completed successfully.

Also, when configurations change, the backup process as well as system configurations should be documented and validated again, to make sure that the backups are being completed properly.

Documenting the Recovery Process

An important aspect of recovery feasibility is knowing how to recover from a disaster. Just knowing what to back up and what scenarios to plan for is not enough. Restore processes should be created and tested to ensure that a restore can meet service level agreements (SLAs) and that the staff members understand all the necessary steps.

When a process is determined, it should be documented, and the documentation should be written to make sense to the desired audience. For example, if a failure occurs in a satellite office that has only marketing employees and one of them is forced to recover a server, the documentation needs to be written so that it can be understood by just about anyone . If the IT staff will be performing the restore, the documentation can be less detailed, but it assumes a certain level of knowledge and expertise with the server product. The first paragraph of any document related to backup and recovery should be a summary of what the document is used for and the level of skill necessary to perform the task and understand the document.

The recovery process involved in resolving an Exchange problem should also be focused not only on the goal of getting the entire Exchange server back up and operational, but also on considering smaller steps that might help minimize downtime. As an example, if an Exchange server has failed, instead of trying to restore 100GB of mail back to the server, which can take hours, if not days, to complete, an organization can choose to restore just the user inboxes, Calendars, and contacts. After a faster system recovery of core information on a server, the balance of the information can be restored over the next several hours.

Including Test Restores in the Scheduled Maintenance

Part of a successful disaster-recovery plan involves periodically testing the restore procedures to verify accuracy and to test the backup media to ensure that data can actually be recovered. Most organizations or administrators assume that if the backup software reports "Successful," the backup is good and data can be recovered. If special backup consideration is not addressed, the successful backup might not contain everything necessary to restore a server if data loss or software corruption occurs.

Restores of file data, application data, and configurations should be performed as part of a regular maintenance schedule to ensure that the backup method is correct and that disaster-recovery procedures and documentation are current. Such tests also should verify that the backup media can be read from and used to restore data. Adding periodic test restores to regular maintenance intervals ensures that backups are successful and familiarizes the administrators with the procedures necessary to recover so that when a real disaster occurs, the recovery can be performed correctly and efficiently the first time.