Running Backups

In our opinion, the most important daily task that an Exchange administrator performs is running and verifying backups. Many administrators will probably take exception to this, but we firmly believe backups are essential. The ability to provide recoverability from alternate media (such as a tape) will be of paramount importance if you ever experience a complete server failure. We think your users will agree with us that a few hours of outage, queues backing up, or ActiveSync not working is minimal compared with the prospects of losing everything in their mailbox.

Exchange Backup Types

There are essentially four different types of backups that can run against an Exchange 2007 database. These backup types are all considered streaming backups and are performed against production databases, not against LCR or CCR copies of databases. You will pick one or more of these backup types based on the frequency of backup, backup capacity, and restoration requirements.

• Full backup The full backup is by far the simplest to perform, and it's the simplest to restore from. A full backup of an Exchange mailbox database, public folder database, or storage group backs up the entire database file and all transaction logs associated with the database and storage group. The database is requested page by page and each page is verified to ensure that the checksum and page pointers are correct. Once this backup is complete, the transaction logs that were backed up are purged by the information store. You should be running full backups at least once per week; if you have the backup capacity and backup windows available, then you should run full backups each night.

• Differential backup Differential backups back up only the transaction logs associated with a storage group. This means that the actual data that is being backed up consists of only the changes that have been performed against a database since the last full backup. The database file is not backed up, nor are the transaction logs purged after the backup is completed. If you performing incremental backups several days in a row, the amount of transaction logs backed up each time will continue to increase but the differential backup allows for simpler restoration.

• Incremental backup Incremental backups back up only the transaction logs associated with a storage group. Once the transaction logs have been backed up, they are purged. Incremental backups back up only the changes to the database since the last full backup or the last incremental backup was run. If you are performing a weekly full backup and then daily incremental backups, a full restore will require all of the incremental backups since the last full backup was performed.

• Copy backups Copy backups are almost identical to a full backup. The entire selected database is backed up as well as the transaction logs, but the transaction logs are not purged after the backup.

Backup Frequency, Schedules, and Rotation

Regardless of how much high-availability technology you have deployed, ultimately you need to have offline copies of your Exchange data. Redundant disks, clustering, and even replication solutions do not excuse you from performing regular backups.

Some organizations back up once per day and use the same tape media (or target backup destination) all the time. Some fairly common questions for organizations that are deploying Exchange are how often should we back up, when should we back up, and how long should we keep the backup media?

Backup Frequency

The frequency of the backup will be determined partially on your backup capacity, partially on your system capacity, and partially on your recovery point objective. A recovery point objective of six hours means that you must perform some type of backup once every six hours.

Each time a backup is executed, a certain amount of system resources (CPU, network, disk, memory) is used to run the backup. This can be reduced by ensuring that backups that are run during normal work hours run as quickly as possible; you can do this by doing incremental or differential backups.

You can also lessen the overhead that a backup takes by using LCR to replicate the databases to an alternate disk drive and then perform VSS backups of the LCR databases.

Backup Schedule

Backups should be scheduled during periods of reduced activity on the server. For a typical business that supports users within a single time zone, the server is most busy supporting user activity from 7:00 a.m. until approximately 6:00 p.m. You can schedule your backup operations outside of these hours. However, you should ensure that the online backup of each database does not interfere with the online maintenance period for that database. By default, this is daily from 1:00 a.m. until 5:00 a.m., but this can be modified on the General property page of each mailbox or pubic folder database. Figure 16.1 shows the General property page and the Maintenance Schedule drop-down list.

Figure 16.1: The default online maintenance time for a database is 1:00 a.m. until 5:00 a.m.

If an online backup of a databases starts while online maintenance is running, online maintenance will halt. Microsoft recommends that online maintenance complete on each database once every two weeks, but we recommend that it complete successfully every few days. Once a database gets behind in its maintenance tasks, it takes much longer to complete the maintenance tasks.

In general, we recommend starting online backups of Exchange database between 8:00 p.m. and 10:00 p.m. This gives the online backup time to complete so that online maintenance can be run. You can also reschedule online maintenance to run at another time.

If you have a tight recovery point objective, then you should consider running multiple backups each day. For example, if your recovery point objective is six hours, then you should consider running a full backup that completes at midnight and differential backups at 6:00 a.m., noon, and 6:00 p.m.

Backup Media Rotation

Having implemented a backup strategy that lets you rotate tapes off site, you should be sure the rotation happens. Also, you should buy a fireproof, magnetic-media storage safe and keep all other backups on site in that safe. A fireproof safe for paper does not protect magnetic media. Temperature and humidity control requirements for magnetic media are higher than for paper.

As we have implied throughout this chapter, you can make an initial backup to tape or disk. If you choose to do initial backups to disk, here are a few precautions you might want to consider. First, don't back up to the disk that contains what you're backing up. You can't recover the disk if the backup is blown away when the disk is blown away. Second, immediately back up to tape whatever you backed up to disk. Even if your backup is on a different disk, it will do you no good if that disk fails. Third, rotate and store these tapes just as you would initial backups to tape. You can no more afford to lose these tapes than your initial backups to tape.

How long should you keep your backups? The ultimate answer to this question is whether or not you are compelled by either a law or company policy regarding data retention. Some organizations have policies or are compelled by law to be able to restore data from five or more years in the past, while other organizations may not wish to restore past two weeks.

Tape retention policies are, unfortunately, only partly related to technical issues. For legal reasons, some organizations must retain data, including e-mail data, for extended periods. Other organizations, to avoid the legal hassles associated with the subpoenaing of data, choose to dump their backups almost as quickly as they are created. For you, there is only one issue. Your users need to understand the implications for data recovery of whatever retention schedule is implemented. If legal niceties aren't an issue in your organization, we recommend that you retain daily backups for the last two weeks and one weekly full backup for up to a month or even up to a year, depending on your level of comfort.

In larger or publicly held organizations, you should consult with someone that is responsible for data retention and/or regulatory compliance. We have a basic tape rotation schedule we recommend that provides the operation for very good recoverability for a year's worth of historical data but as time passes by the exact date that you can recover is less specific. Table 16.1 shows the how you label a series of tapes for this rotation schedule.

Table 16.1: Sample Exchange Backup Rotation Schedule
Open table as spreadsheet

Tape label	Purpose or usage
Monday - Even	Tape used on Monday if the day of the week is even
Monday - Odd	Tape used on Monday if the day of the week is odd
Tuesday - Even	Tape used on Tuesday if the day of the week is even
Tuesday - Odd	Tape used on Tuesday if the day of the week is odd
Wednesday - Even	Tape used on Wednesday if the day of the week is even
Wednesday - Odd	Tape used on Wednesday if the day of the week is odd
Thursday - Even	Tape used on Thursday if the day of the week is even
Thursday - Odd	Tape used on Thursday if the day of the week is odd
Friday - 1	Tape used on first Friday of the month
Friday - 2	Tape used on second Friday of the month
Friday - 3	Tape used on third Friday of the month
Friday - 4	Tape used on fourth Friday of the month
Friday - 5	Tape used on fifth Friday of the month
January–December	Create one tape for each month of the year. Use this tape on or about the first of the month as a long-term archive.

Naturally, this backup rotation is very simple and assumes that you perform full backups nightly and only Monday through Friday, but it can be adopted for your needs.

One backup method that is becoming popular is to use the Windows Backup utility and backing up to a BKF file rather than to tape and then keeping the two most recent backups on the server's local disk. The advantage of this method is that it is very quick to restore a recent backup file. However, if you use this method, you should save the BKF files on a separate Windows disk volume than the one on which the transaction logs or databases are located, and you should make backup copies of these BKF files to tape as part of your normal backup procedures.

Using Windows Backup to Run Exchange Backups

There are many third-party software utilities on the market that include an Exchange agent that is capable of performing online backups of Exchange databases. In our examples for this chapter, we are going to use the Windows Backup utility rather than one the third-party utilities. Let's go through an exercise of backing up the Exchange databases to a backup (BKF) file for a server.

First we launch the Windows Backup utility (ntbackup.exe), switch to the Backup tab, and navigate through the tree to the Microsoft Exchange Server container. An example of this is shown in Figure 16.2; in this example, we have selected the entire Microsoft Information Store object, which will include all storage groups and databases.

Figure 16.2: Selecting the Microsoft Information Store object for backup

If you select a specific storage group in the tree, you can view the mailbox or public folder databases in that storage group in the right-hand pane of the Windows Backup utility. Notice also in Figure 6.2 that the backup media or filename that is in use is C:\January27-Full-Backup.bkf; we are backing up to a disk file rather than to a tape. Do not select the System State selection in the directory listing tree if you are also backing up Exchange databases. System state backups should be performed separately.

When you click the Start Backup button, you are presented with the Backup Job Information dialog box. From this box, you must give the backup set a description and specify if you are overwriting the existing backup media. Be careful about appending to an existing backup file; if this is not what you intended to do, the backup file may grow until you run out of disk space. The description is important when you get ready to perform a restore of a database, so make sure the Backup Description and the If the Media Is Overwritten, Use This Label to Identify the Media boxes both include descriptive text.

If you click the Advanced button in the Backup Job Information dialog box, you will see the Advanced Backup Options dialog box. Almost everything on this dialog box is irrelevant for Exchange backups except for the Backup Type drop-down list. For Exchange backups, you can select Normal (Full), Copy, Incremental, or Differential. There is a Daily selection in this drop-down list, but it has no function for Exchange.

The Schedule button allows you to define a schedule for this backup to run. If you click the Schedule button, the first thing you have to do is to save the current backup selections to a backup selection script file (BKS). This file will be use when the ntbackup.exe program is executed by the Windows Task Scheduler service.

You must also provide a service account and password under which the scheduled job will run. The user account that you specify must have the right to log on as a service and it must have the rights to run backups on the Exchange server. Once you have specified a service account, you are prompted for the job name of the scheduled task.

By default, the job is scheduled to run immediately, but you can click the Properties button on the Schedule Data property page and view the Schedule settings. In the following example, we have scheduled this backup job to run every Friday evening at 8:00 p.m.

This wizard will schedule a command to run at the time you specify and under the security context of the account you specified. Here is an example of the weekly backup job that we just scheduled:

 C:\WINR2-64\system32\ntbackup.exe backup"@C:\Documents and  Settings\Administrator.VOLCANOSURFB\Local Settings\Application  Data\Microsoft\Windows NT\NTBackup\data\WeeklyFullBackup.bks" /n  "Weekly Full Backup" /d "Weekly Full Backup" /n "Weekly Full Backup"  /v:no /r:no /rs:no /hc:off /m normal /j "Weekly Full Backup" /l:s /f "c:\January27-Full-Backup.bkf" 

Once you save the schedule task data, you can see the scheduled jobs in Control Panel Ø Scheduled Tasks. An example is shown in Figure 16.3. From this dialog box, you can also right-click on any of these tasks and choose Run to start the job immediately.

Figure 16.3: Viewing properties of scheduled jobs

Verifying Exchange Backups

The best actual verification of a backup completion is to confirm that it restores properly. You certainly don't have time to do that every day, but we recommend that every few months you select a database and restore it to a recovery storage group just for practice.

However, there are some quick tasks that you should do as part of your daily operations. The first is to examine the backup program's log of the backup. This serves a couple of purposes, not the least of which is finding possible errors. Figure 16.4 shows the backup log from the Windows Backup utility for a backup of a mailbox and public folder store database.

Figure 16.4: Sample backup log

There are a few things you should note from this backup report:

• The backup report contains no errors. This should help you to sleep better.

• The backup report indicates that what you wanted to back up (the mailbox database and the public folder database) was backed up.

• The amount of data that was backed up corresponds with the amount of data that you believe should be backed up.

• And finally, you can see the amount of time the backup took versus the amount of data. In this example, the mailbox database was 4GB and it took just over three minutes to back up. That is about 1.3GB per minute. That is not really great backup throughput, but this is a low-end test system.

The final place you should check for information about backups is the Windows Application event log. Figure 16.5 shows the Application event log immediately after an online backup. The source column shows ntbackup-, ESE BACKUP-, and ESE-related events that are all part of the backup process.

Figure 16.5: Event viewer showing backup-related events

As you scan through the log entries created by the backup process, you will find that many of these events are just informational, such as event that let you know the backup program is starting or has completed. Events from the source ntbackup are reports of this kind, while events from ESE and ESE BACKUP are reporting on the actual Exchange backup process being used.

There are two events, though, that you should watch for and you should see for each database that you are backing up. You will see these events for any streaming backup of an Exchange database regardless of which database you are using. These events are from the ESE source and are event ID 220 and 221. They are shown side by side in Figure 16.6. Event ID 220 indicates that the backup of a specific database (named in the Description field) is now beginning, while event ID 221 indicates that the backup of that specific database has completed. The actual text of the event says "Ending the backup of the file…," but it means that the backup was successful.

Figure 16.6: Important ESE backup events

After all of the Exchange databases in a selected storage group are backed up, you will see events indicating that the transaction logs for a particular storage group are being backed up and then purged. This is another indication that all of the databases in a particular storage group have been backed up successfully. Figure 16.7 shows ESE events 223 and 224. Event ID 223 shows you the transaction logs that are being backed up for the storage group specified in the Description field.

Figure 16.7: ESE backup events related to transaction logs

Event ID 224 indicates that the backup logs have been backed up and they are now being purged. Both event ID 223 and 224 are good events. Table 16.2 shows the ESE and ESE BACKUP event IDs that you look for during an online backup. Usually to completely understand what is being backed up, you will need to read the Description field to see what database, transaction log, or storage group is affected.

Table 16.2: Exchange Database Engine Backup Events
Open table as spreadsheet

Event ID	Source	Description
210	ESE	Indicates that a full backup of a specified storage group is beginning.
211	ESE	Indicates that an incremental or differential backup of the specified storage group is starting.
220	ESE	Indicates that a backup of a specified database is starting.
907	ESE BACKUP	Indicates that the backup data transfer method is shared memory.
221	ESE	Indicates that a backup of the specified database is completed.
223	ESE	Indicates that backup of specified transaction logs is starting.
224	ESE	Indicating that transaction logs for the specified storage group are being purged after successful backup.
213	ESE	Indicates that backup of specified storage group (databases and transaction logs) has completed.

You can also view the backup status of individual databases using the Exchange Management Console or the Exchange Management Shell. Previously, we showed you in Figure 16.1 that you can see the last time an incremental or differential backup was performed on a mailbox database. You can also use the EMs cmdlet Get-MailboxDatabase and the -Status option to retrieve database status information. Here is an example:

 Get-MailboxDatabase "HNLEX04\Mailbox Database" -Status | FL Name,Server,*backup*,Mounted Name                          : Mailbox Database Server                        : HNLEX04 BackupInProgress              : False LastFullBackup                : 1/27/2007 8:59:17 PM LastIncrementalBackup         : 1/28/2007 1:06:22 PM RetainDeletedItemsUntilBackup : False Mounted                       : True