Best Practices for Minimizing the Impact of a Disaster
Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2007-08-29
An important step in creating a disaster recovery strategy is to consider ways in which you can avoid or minimize the impact of a disaster. There are many different preventive measures you can take to help prevent or minimize the effects of disasters such as hardware failure or power outages. The time required to recover from a disaster depends on what needs to be restored—a single mailbox, a single database (and its transaction logs), an entire server including all of its databases and logs, or multiple servers in a site (for example, servers that are running Microsoft Exchange, DNS servers, domain controllers, and so on). Obviously, restoring multiple servers in a site takes the longest time.
You can take several actions to lessen the impact of a disaster and help avoid the need to perform a full restore from backup. Actions include the following:
- Use Continuous Replication Exchange 2007 includes asynchronous log shipping technology that can be used to create and maintain a copy of a production storage group on another set of disks, or on another server.
- Use Deleted Item Retention Deleted items retention allows a single item or entire folders to be restored from the Microsoft Outlook client without administrator intervention.
- Use Deleted Mailbox Retention Deleted mailbox retention allows for the restore of deleted mailboxes by using the Exchange Management Console without restoring from backups.
- Monitor Servers Proactively One of the best ways to deal with a disaster is to prevent it before it occurs. Monitor your servers to solve problems before they worsen.
- Locate Your Users on Multiple Mailbox Databases Distributing users across a larger number of mailbox databases can lesson the impact of the loss of a single database, and allow for quicker restores when a restore is needed.
Continuous replication is present in two Exchange 2007 features that use built-in asynchronous replication technology to create a copy of a storage group and keep it up-to-date using log shipping and replay. Replication facilitates this by applying the log files of a production database to a copy of that database. The two features that contain this technology are local continuous replication (LCR) and cluster continuous replication (CCR).
- Local continuous replication LCR lowers the total cost of ownership for Exchange 2007 by reducing the number of regular backups that are required for data protection. Although LCR does not eliminate the need to take backups (data backup are important to have if a disaster strikes), it does significantly reduce the need to take regular, daily backups. LCR provides fast recovery with current data, as well as a single-server solution for transaction log copying and replaying. For more information about LCR, see Local Continuous Replication.
- Cluster continuous replication CCR combines automatic management of redundancy and application-level data replication. CCR is a solution that can be deployed without a single point of failure in a single datacenter or between two datacenters. Transaction log replication is used to copy the databases and maintain the concurrency of the data among cluster nodes. The scheduled outage functionality in CCR is designed to make sure that all log data on the active node is successfully copied to the passive node. Therefore, scheduled outages do not result in loss of data, even though replication occurs asynchronously. For more information about CCR, see Cluster Continuous Replication.
When a user deletes an item, it appears deleted to the user. However, a copy of the deleted item is kept in the user's mailbox database for a specified time, which allows the item to be recovered if it was deleted unintentionally.
When the Exchange database receives a request to delete a message, it determines if the message should be soft deleted or hard deleted. Soft deletion is also referred to as logical deletion, and hard deletion is also referred to as physical deletion.
|The default setting for deleted item retention in Exchange Server 2007 has changed from 7 days to 14 days.|
A hard deletion of a message is performed when any of the following criteria are met:
The client specifically requests a hard deletion.
The effective item retention time is zero.
The registry key that indicates Force Hard Deletes is enabled for the mailbox or public folder database.
The account requesting the deletion is a gateway.
The account requesting the deletion is a system.
When a message is hard deleted, the message reference is immediately removed from the MsgFolder table. At this point, the message is no longer available to the mailbox that contains the folder, even if you use deleted item recovery. The reference count of the message is checked. When the message reference count drops to zero, which means that no other mailbox has a copy of the message, an entry is made in the DeletedMessages table that indicates that the message is ready to be removed from the messages table.
During the next background cleanup process, the entries in the DeletedMessages table are examined and the corresponding entries in the messages table are deleted. This process occurs every hour by default. However, you can control this schedule by editing the following registry entries:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS \ParametersPublic\Background Cleanup (value in milliseconds)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ ParametersPrivate\Background Cleanup (value in milliseconds)
|Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.|
If you enable and increase the deleted item retention time, you may need to perform additional capacity planning. The following example demonstrates that messages can be present for an extended duration even after the messages have been deleted by the user:
Deleted item retention is set for 48 hours.
Exchange database maintenance is set to run between 03:00 and 07:00.
Background cleanup is configured to run every hour.
For example, if you delete a message at 08:00, the message does not become a candidate for hard deletion for 48 hours. The next Exchange database maintenance procedure is scheduled to finish at 06:00, so the message is not hard deleted, meaning the record is not removed for 71 hours.
A soft deletion is performed if none of the criteria for a hard deletion are met. A flag is set on the entry in the MsgFolder table that indicates that the message has been soft deleted from the folder. The MsgFolder table is a mapping between entries in the folder table and the messages table. Message counts for the mailbox and folder are also updated. At this point, the message is available for deleted item recovery.
During the next scheduled Exchange database maintenance process, each folder is examined to determine if any of the soft-deleted messages that the folder contains have passed the deleted item retention time. If such a message is found, the message is hard deleted.
By default, deleted items are stored in an Exchange database for a certain number of days before they are permanently deleted by Exchange. You can set the length of the deleted item retention period by either using the database defaults, or by selecting the number of days that a deleted item is kept before it is permanently deleted.
You can select a number from 0 through 24,855 when specifying the number of days to retain a deleted item. We recommend that you configure this setting to 14 days. If the deleted item retention period is set to 0, the deleted items are permanently removed from the server immediately. Unless disk space is an issue, we recommend that you do not disable the deleted item retention feature.
Deleted item retention can be configured on a per-database and a per-user basis. Individual user settings override database settings. For detailed steps about how to specify the deleted item retention at the database level, see How to Configure Deleted Item Retention for a Mailbox Database. For detailed steps about how to specify the deleted item retention at the user level, see How to Configure Deleted Item Retention for a User.
|By default, Microsoft Outlook enables deleted item recovery from the Deleted Items folder only. If you press SHIFT+DELETE on a message from your Inbox, the message does not go to the Deleted Items folder. Therefore, the message will not be available for recovery. You can use the DumpsterAlwaysOn registry value to enable recovery of items that have been deleted using SHIFT+DELETE by following the instructions in Microsoft Knowledge Base article 246153, How to recover items that have been hard deleted in Outlook.|
In Exchange 2007, deleting a mailbox does not mean that it is permanently deleted (or purged) from the Exchange mailbox database immediately. Instead, the mailbox is flagged for deletion, and users cannot access it. At the end of the mailbox retention period, the mailbox is permanently deleted from the database. You can also permanently delete the mailbox by choosing to purge it at any time. If you mistakenly delete a mail-enabled user account, you can re-create that user object, and then reconnect that mailbox during the mailbox retention period.
By default, the deleted mailbox retention period is 30 days. You can configure the deleted mailbox retention period at the mailbox database level. You can select a number from 0 through 24,855 when specifying the number of days to retain a deleted mailbox. If the mailbox retention period is set to 0, deleted mailboxes are permanently removed from the server immediately. Unless disk space is an issue, we recommend that you do not disable the deleted mailbox retention feature.
For detailed steps about how to configure deleted mailbox retention, see How to Configure Deleted Mailbox Retention.