What is disaster recovery? The obvious answer is that it’s the act of recovering from data loss or loss of access to key systems for a significant period of time. When you think of DR in terms of Exchange Server 2007, you’d be wise to plan for more than one disaster scenario.
Instances when a user deletes a mail folder or item from his mailbox or accidentally deletes one or more mailboxes from a store don’t represent true DR situations. In those cases, you can use Microsoft’s recovery storage group feature. If you’ve configured your stores with best practice settings, you shouldn’t need to resort to backup tapes to rectify those issues. Deal with them by implementing a solid day-to-day business as usual (BAU) process.
On the other hand, the following four events can truly be classified as DR situations, and they require a much more detailed level of planning:
- Database corruption or loss that leaves many users without access to mail
- Server failure that prevents all users from accessing mail
- Storage failure
- Data center loss
In general, a number of situations exist where you may need to consider the process of restoration, and each event varies in terms of severity and complexity. Figure 1 shows a general rule for Exchange Server recovery instances. The ultimate goal is that you never have to resort to your backups.
How to mitigate disaster
Exchange Server 2007 has a number of built-in features designed to help mitigate DR situations and reduce the severity and restoration complexity required in businesses of all sizes. Going back to your tapes or other backups takes time and, even in the case of recovery storage groups, can be invasive within your production environment. Therefore, any preventative measures that you can put in place will pay dividends later.
Table 1 shows available features that can help protect against the need for full DR. Depending on the size of your organization and its resources, you may choose one or more of these options to safeguard against critical failure.
For example, some organizations deploy a mix of cluster continuous replication (CCR) with standby continuous clusters (SCCs) and basic Exchange servers with SCC targets for redundancy.
|Feature||Standard Edition||Enterprise Edition||Description|
|Continuous cluster replication (CCR)||No||Yes||Server node hardware failure, single storage model failure, provides a 2nd copy of your database that can be activated at any time.|
|Single copy cluster (SCC)||No||Yes||Server node failure, makes use of shared storage for Exchange databases and transaction logs. This is the more traditional clustering model from previous versions of Exchange.|
|Local continuous replication (LCR)||Yes||Yes||Local controller or disk enclosure failure, local offline backup copy of your database and transaction logs.|
|Standby continuous replication (SCR)||Yes||Yes||Server failure, provides a remote copy of your databases and transaction logs for activation when required.|
|Mailbox retention||Yes||Yes||Protects against accidental mailbox deletions -- they are kept in the store for a defined period of days before being removed.|
|Item retention||Yes||Yes||Protection against mail item deletions that are kept in the store for a defined number of days.|
|Recovery storage groups||Yes||Yes||Allows for backups to be restored to a non-production storage group and database where individual mailboxes can be merged back into production.|
Table 1. Exchange Server 2007 high-availability features
However, even small efforts such as setting good retention periods for mailboxes and items at the database level can make it so you don’t have to restore to a recovery storage group. I suggest that you set your deleted mailbox retention per database at about 10 days and the item retention at about 14 days so you have enough time to notice an issue and reconnect the mailbox or recover the deleted item. Keep in mind that these settings will increase your overall database sizes, but they save you the time and effort of having to invoke a full restore.
Put your disaster recovery plan on paper
Every organization, no matter how large or small, should have a document that contains information outlining its disaster recovery plan. Although the process of defining a recovery plan might seem like an arduous task at first, the fact that it saves you time will prove invaluable.
Your DR document should do the following:
Describe what your organization defines as a “disaster.” For example, some enterprises consider losing the CEO’s mailbox as a disaster situation.
Determine how much time it will take to restore a database or lost Exchange Server. When you have five databases, each around 100 GB in size, you should have an idea of how long it will take to recover them.
Establish expedience expectations. Will you perform a dial tone recovery or simply invoke a full recovery? Define this according to the level of outage you have (e.g., have you lost the server?) and the time it will take to recover from backup.
What restoration method will you use? Document the restoration process for every scenario.
Who will do what? Depending on the size of your IT team, allocating roles during an outage can make the best use of everyone’s time. Assign roles for each admin and describe who will manage the problem, perform the restore, work with the service desk and so on.
Document disk configurations. At the very least, you should document your disk configurations, as they will be essential if you need to fully recover your Exchange Server.
Backup tool selection
There are a number of tools on the market that provide reliable backup solutions for Exchange Server. The most common are Symantec Backup Exec and Microsoft DPM, Windows NT Backup for Windows 2003 Servers, as well as Windows Server 2008 Backup with the Exchange VSS Plug-in for Exchange 2007 SP 2 on Windows 2008. (You can also use this tool with Windows 2003, but the interface and functionality will vary slightly.)
Unless you are a very small business with limited resources, I don’t recommend using Windows 2008’s backup tool as the weapon of choice for DR. It has the following limitations that don’t make it suitable for larger environments:
Support is limited to volume level. For example, if you have more than one database and storage group on the same LUN, both will be backed up as part of the backup set.
It does not support tape drives; you can either back up to a local disk or to a universal naming convention path.
You only have the option of full VSS snapshots; partial snapshots won’t clear the transaction log files.
You can only back up the local Exchange server; there is no remote support.
You need to be very mindful that the plug-in automates the “This database can be overwritten by a restore” option. This is particularly important when taking into account the fact that backups are made at a volume level. If you restore a volume with two databases in the backup set, both will be restored to the point of origin.
Support is limited to VSS-based backups. The tool does not support streaming backup.
Although the Windows Server Backup tool isn’t suitable to granularly back up your Exchange environment, it can still be an effective DR tool -- particularly in the case of full server failure or storage failure.
To install the Windows 2008 Server Backup tool, open a command prompt with administrative privileges and type in the following command:
serverManagerCMD –i Backup-Features
If you’re using Windows 2008 R2, open a PowerShell window and type these commands:
Depending on what you hope to achieve in the recovery process, consider what you want to back up. Table 2 gives a few rules of thumb for various scenarios.
|Recovery scenario||Active Directory||Exchange Server databases and transaction log|
|Full Data Center (or domain) failure||X||X|
|Full Exchange Server failure (database remains intact)|
|Full server failure (databases are damaged)||X|
|Database failure (corruption)||X|
Table 2. Exchange Server recovery rules of thumb
Using Windows Server 2008 Backup with Exchange 2007
Backing up Exchange with Windows Server Backup 2008 is straightforward. Launch the backup program from START->Programs->Administrative Tools->Windows Server Backup and then click on either Backup Schedule to configure reoccurring backups or Backup Once from the Actions Menu on the right-hand side.
Select Backup Once to see the screen shown in Figure 2, then click Next.
A screen will prompt you to select the type of backup that you want to use. I recommend using the first option -- Full Server -- as the full DR scenario for your Exchange Server. This method takes a copy of all volumes and the system state on your server. The second option -- Custom -- allows you to protect your databases, minus the system state.
Next, choose your volumes. Remember that the Exchange Plug-In does not present you with a store view, only a view of volumes in which Exchange databases will be backed up. You can also choose to back up the system state. Once you’ve made your selections, click Next.
You will be asked where you would like to place your backup set -- locally or to a remote share. I recommend placing them to a remote share; however, in this instance, I’ll back up to a dedicated LUN within my test lab. Once you’ve made your selection, click Next.
On the next page, choose your destination. If you chose a local LUN, as shown in Figure 2, it will appear in the drop-down box. If you chose a UNC destination, you will be prompted to enter that path.
Next, you’ll be prompted to select the mode in which you’d like the VSS functionality to work. In the case of Exchange Server, this should be set to VSS full backup. Once the configuration page gives you a summary of your choices, click Next.
The backup progress window should appear (Figure 3).
When the backup completes, click Close. You now have a full backup of the volumes and system state data, if selected.
Recovering from a full server failure
This tip describes just one method for recovering from a corrupted database. Check out the key points you'll need to know if you must recover from a full server failure.
Recovering from a brownout and other disasters
Suppose that a corruption occurs within one of the databases on your Exchange Server. I’m going to simulate this corruption in the lab and then attempt to recover from the newly created backup. The corruption that I’m simulating could be equated to a storage brownout that caused the database to be written incorrectly -- preventing it from mounting.
My mailbox server has two databases configured. Figure 4 shows which database I will corrupt.
You can no longer mount the database. Upon further review of the events log, you’ll be presented with the following error:
Error Non-database file or corrupted database starting Storage Group
Exchange/CN=Justice/CN=Administrative Groups/CN=Exchange Administrative
01/CN=InformationStore/CN=General_Users_SG on the Microsoft Exchange
Storage Group - Initialization of Jet failed.
In order to restore the database to operational service, here’s what you’ll need to do.
Open Windows Server Backup from START -> Programs -> Administrative Tools -> Windows Server Backup.
From the Actions menu on the right, choose Recovery.
When the screen shown in Figure 5 appears, verify that This Server (Name) is selected and then click Next.
Select the date of the backup set that you want to restore and click Next.
At the Recovery Type screen, select Applications and then Next.
Ensure that you have selected Exchange as your application. You don’t need to choose the Auto Roll Forward option at this stage, but you can. I generally ensure that I have a viable database and manually perform this task; however, you may want to select it and have the restoration process automatically replay any viable transaction logs into the database. Once you’ve made your selection, click Next.
At the next screen, ensure that the Recover to Original location option is set and click Next. Take a look at details about the volumes that are contained within your backup set.
Remember: All databases and TS logs that were on the volume will be restored to their original state, including the damaged database. After you’ve read this information, click Next. Windows Server Backup will then restore your databases. Once the process completes, click on the Close button and exit the tool. Finally, mount the database through the Exchange Management Console.
ABOUT THE AUTHOR:
Andy Grogan, an Exchange MVP based in the U.K., has worked in the IT industry for the last 14 years, primarily with Microsoft, HP and IBM technologies. His main passion is Exchange Server, but he also specializes in Active Directory, SQL Server and storage solutions. Andy is currently working for a large council in West London as the networks and operations manager supporting 6,000 customers on more than 240 sites. Visit Andy’s website at www.telnetport25.com.