Understanding How Backups Work

[Previous] [Next]

Now that you know what to include in a backup, you need some basic information about the backups themselves. This section covers the five basic types of backups that you can perform with Windows 2000 Backup and also discusses a few backup strategies.

Types of Backups

You can perform five basic types of backups with the Windows 2000 Backup utility (and with most other backup utilities). The key difference among these backup types is how each one handles the archive bit that is found in every Windows 2000 file. When a file is created or modified, the archive bit is set to on, as shown by the A in the Attributes column in Figure 24-1. After some types of backups run, the archive bit is set to off, which indicates that the file has been backed up. If, prior to the backup, a files's attribute has been set to archive manually by an administrator, that file will be backed up with the others.

Figure 24-1. Contents of the Mdbdata folder, showing the archive bit set to on.

The five types of backups are as follows:

• Normal During a normal backup, all selected files are backed up, regardless of how their archive bit is set. After the backup, the archive bit is set to off for all files, indicating that those files have been backed up.
• Copy During a copy backup, all selected files are backed up, regardless of how their archive bit is set. After the backup, the archive bit is not changed in any file.
• Incremental During an incremental backup, all files for which the archive bit is on are backed up. After the backup, the archive bit is set to off for all files that were backed up.
• Differential During a differential backup, all files for which the archive bit is on are backed up. After the backup, the archive bit is not changed in any file.
• Daily During a daily backup, all files that changed on the day of the backup, which are identified by the modified date of the file and not the archive bit, are backed up, and the archive bit is not changed in any file.

NOTE

---

In this chapter, we will refer to a full backup. This is simply a normal backup with all Exchange-related items selected.

When you initially create a backup job, you manually select the files to be backed up. In most backup software programs, including the Windows 2000 Backup utility, these jobs can be saved and reused. In some cases, not all of the files selected are actually backed up. Normal and copy backups back up all of the files selected, but in the case of an incremental, differential, or daily backup, the selected files must also meet the selection criteria of the backup type, as just listed.

All five types of backups apply to Exchange 2000 data, although only three are commonly used: normal, differential, and incremental. Daily and copy backups normally apply only to file-level (Word documents or Excel spreadsheets) backups. The following list describes what happens with regard to Exchange 2000 Server during each type of backup:

• Normal The selected Exchange stores are backed up, and the transaction logs for those stores are flushed.
• Copy The selected Exchange stores are backed up, but the transaction logs are not flushed.
• Daily With respect to Exchange, a Daily backup performs the same backup as a Copy backup.
• Differential Only the transaction logs for the selected stores are backed up. Because differential backups are supposed to back up all changes to the stores since the last normal backup, the transaction logs are not flushed so that they can be backed up again during the next differential or normal backup.
• Incremental Only the transaction logs for the selected stores are backed up. Because incremental backups are supposed to back up only the changes to the stores since the last normal or incremental backup, the transaction logs are flushed.

Circular Logging

Circular logging enables Exchange Server to conserve disk space by maintaining a fixed number of transaction logs and overwriting those logs as needed. Circular logging should be enabled only if you are performing regular full backups of your Exchange data. Otherwise, you should leave it disabled, allowing Exchange Server to create as many transaction logs as necessary and letting the backups clean up the old logs as they are performed. If circular logging is enabled, you will not be able to successfully perform either a differential or an incremental backup. To check the status of circular logging on your server, navigate within Exchange System to a storage group, right-click it, and choose Properties from the shortcut menu. You will see the Enable Circular Logging check box at the bottom of the General tab of the storage group's property sheet (Figure 24-2). For more information on transaction logs and circular logging, see Chapter 2. Chapter 11 also discusses circular logging with respect to planning storage groups.

Figure 24-2. Property sheet for a storage group, showing the Enable Circular Logging check box.

Backup Strategies

Given the five types of backups covered in the preceding section, most administrators use one of three strategies for backing up a server. These strategies all start with a full backup of the Exchange server, performed on a regular basis—for example, every Sunday. One strategy then continues with full backups daily, another involves performing an incremental backup on all of the other days of the week, and the last calls for performing a differential backup on all of the other days of the week.

• Full daily backup Every day of the week, complete a full backup of your Exchange server. If you follow any other backup strategy, you run the risk of having to revert to a backup that is several days or weeks old. An example of a failure would be if your weekly full backup failed in a normal plus daily incremental backup strategy. You would then have to restore all of the previous week's backups. Money spent on large-capacity backup systems (such as DLTs) is money well spent.
• Normal plus daily incremental backup On Sunday of each week, perform a full backup of all the files on the Exchange server that you have decided need to be backed up. On Monday, perform an incremental backup that backs up all files that have changed since the full backup. On Tuesday, perform another incremental backup that backs up all files that have changed since the last incremental backup on Monday. At the end of the week, you have performed a full backup and six incremental backups. To restore these backups, you would first restore the full backup and then restore each incremental backup, in order.
• Normal plus daily differential backup On Sunday of each week, perform a full backup of all files. On Monday, perform a differential backup that backs up all files that have changed since the full backup. On Tuesday, perform another differential backup that backs up all files that have changed since the last full backup, which occurred on Sunday. Each consecutive differential backup backs up all files that have changed since the last full backup. To restore these backups, you would first restore the full backup and then restore only the most recent differential backup.

In all strategies, plan to use your transaction logs to your advantage. Every backup strategy must incorporate the role transaction logs play in recovering data up to the point of the disaster. Remember, your transaction logs represent what will happen to your database in the future. Often they hold committed transactions that have yet to be written to the database. (Consult Chapter 2 for a good discussion of the transaction log architecture.) When a disaster strikes your Exchange server, the information that has been generated in your Exchange organization since the last backup can be recovered from the transaction logs.

For instance, if your server finished a full backup last night at 11:30 P.M., and then at 4:30 P.M. today the disk containing one of your Exchange stores experienced a failure, you would recover today's information from your transaction logs. This ability to recover assumes you have your transaction logs on a different physical disk than the store that experienced a failure. If the logs were on the same disk as the store, you would only be able to recover up to 11:30 last night when the backup took place. Let's continue this example under the premise that the logs are on a separate disk and the disk with the store experiences a failure. To recover, you do a full restore of last night's backup from tape. Then, when you start the store.exe process, it will attempt to replay all the transactions in the transaction logs back into the databases. When it is finished playing these transactions back into the database, the service will start and your databases will have been restored to the point in time when your disaster occurred.

When the store.exe process is started under normal (non-recovery) conditions, such as during a proper shutdown and restart of the Exchange server, all of the transaction logs will be replayed unless the checkpoint file is available. Essentially, that file tells the store process which portions of the transaction logs have already been written to the databases and which have not. If the checkpoint file is available, only those portions of the transaction logs which were not previously written to the database will be written to the database. However, in a recovery situation, like the one mentioned above, a special key is created in the registry by the restore process called the Restore in Progress key. This key controls the startup sequence of the store process and uses the LowLog Number registry entry, rather than the checkpoint file, to act as the checkpoint to determine which logs should be played into the database.

Let's illustrate this important point. Suppose your backups concluded last night at 11:30 P.M., and your disk failure occurred at 4:30 P.M. today. During this period of time, 40 new transaction logs were created, 30 of which had been written to the database and 10 of which had not. Thus, at the point of the system malfunction, the checkpoint file would be pointing to the 31st transaction log.

Now, if you restore last night's backup from tape and then start the store.exe process without the Restore in Progress key present, the store process will start committing transactions from the 31st transaction log to the database. This action will result in a corrupted database because your transactions will be committed to the database out of order and the information in the first 30 transaction logs will be completely lost. Because the key is automatically created by the restore, the LowLog Number points to the first transaction log as the starting point for log replay during the store.exe process startup. The key to the success of the recovery is using an Exchange-aware backup solution, like the version of Windows 2000 Backup that is included with the installation of Exchange 2000 Server.

Hopefully, you'll see why it is important to make sure that your transaction logs are sitting on a different spindle from your databases, preferably one that has some type of disk fault tolerance, such as mirroring or disk striping with parity. If you lost your databases, you can recover by using the combination of tape backup and transaction logs. If you lose your transaction logs but not your databases, perform a clean shutdown of the store.exe process and your database will be up to date because all of the committed transactions in memory will be written to disk. Hopefully, you can better understand now why it is very important to guard your transaction logs.

REAL WORLD   Mission-Critical Backups

Most companies consider Exchange Server to be a mission-critical application, meaning that unscheduled downtime needs to be kept to a minimum. In these cases, a single daily backup (normal or otherwise) is simply not enough. In the event of a server failure, you'll need your transaction logs as well as your last set of backups, including the full, incremental and/or differentials. An alternative method to ensure you'll have your transaction logs is to perform a normal backup of your Exchange data daily and several differential backups throughout the day. For example, you might perform the normal backup at night, when server usage is lowest. Then throughout the day (at 7:00 A.M., 11:00 A.M., 3:00 P.M., and 7:00 P.M., for example) you could make a differential backup of the transaction logs. Don't worry about the effect on the system of performing differential backups during the day; you'll be backing up only several megabytes of data, which will take just a few minutes, depending on your backup hardware.

The point of using this method is to keep restore time to a minimum. Nobody cares that the backups took four hours last night, but they definitely will care when restoring them takes you four hours. A restore using this method would require only two sessions: the previous evening's normal backup and the latest differential backup. Using this method would, in this example, restore your server's data to within four hours of the crash. You can, of course, schedule the differential backups more or less frequently, depending on your need for relevant, recent data.