Section 20.3. Backup

20.3. Backup

Now that we have examined the various elements of Exchange architecture, let's take a look at how to back it up, starting with your backup strategy.

20.3.1. Backup Strategy

Your backup strategy is the starting point in the success or failure of your eventual restores. A good Exchange system administrator shouldn't be thinking about "if" some piece of hardware or software will fail on his Exchange Server, but "when." Taking proactive steps to ensure your backups occur at regular intervals and that the backups you make contain useful and necessary data can make the restore a breeze and help make you the hero of your organization.

When figuring out your backup strategy, keep several things in mind. Does your organization have a predefined disaster recovery plan (DRP) to which you might be bound? For example, if you do business with certain government agencies, you may have strict rules governing what must be backed up and how often. Does your group have a service-level agreement (SLA) with other groups in the company? This SLA might also dictate that you have certain response times to mailbox recovery or just generally provide guidelines you must follow for your industry.

While considering what type of backup strategy to implement, it will also be necessary to think of the technical side. How long will the backups take? How much storage will I need to perform any of the different types of backups? Should I do full backups all the time or will differential or incremental be sufficient?

20.3.2. Backup Types

Backup types are specified using the Default Backup Type drop-down on the Backup Type tab under the Options setting in ntbackup as shown in Figure 20-6. Here you can specify the type of backup you want performed. Each type is described in the following subsections. In 2000, simply run the Backup wizard (StartRun, and type Backup), and specify the type of backup on the "Type of Backup" page. For the remainder of the chapter, screenshots are specific to Exchange Server 2003. Almost all the same options are available in 2000; simply run the wizard to configure your backup, and set these parameters.

Figure 20-6. Backup types

20.3.2.1. Normal

A normal or full backup is the safest bet when backing up your Exchange Server. This backup type provides a full backup of all the information you select. It is important to do a full backup regularly so that the transaction logfiles are purged. Otherwise, it is possible to hit the maximum limit of logfiles. While this number is high, currently 1,048,540 for 2003, in a high-volume environment it is conceivable to reach this limit quite easily. Keep in mind that while full backups are supposed to purge old transaction logs, there are times when this is not the case. Currently, if a database within the same storage group is dismounted when you select it for backup, the transaction logs are not purged. Additionally, if you don't select all the databases within a particular storage group, only the transaction logs that have the oldest full backup PIT are truncated.

20.3.2.2. Copy

A copy backup is a backup in which all the Exchange Server files are copied onto the backup medium without purging the transaction logs or updating the last backup date. The main advantage of this type of backup is that it can be performed without affecting any of the other backups.

20.3.2.3. Incremental

With Exchange Server 2003, incremental backups copy only the logfiles from the last full or incremental backup to the backup medium. The advantage here is that incremental backups are much faster than full backups. However, it takes all the incremental backups plus the last full backup to bring Exchange to it most recent state.

20.3.2.4. Differential

Differential backups are similar to incremental backups because they both back up only the logfiles. However, unlike incremental backups, the transaction logs are not purged during a differential backup. This makes restoring from a differential easier than restoring from an incremental because you need only the last full backup and the last differential backup to make the Exchange Server current. The downside to this method is that since the transaction logs are not purged, it is necessary to keep a watchful eye on the number of logfiles and implement one of the previous two backup strategies to make sure the logfiles are purged at some point. For smaller organizations this may not be an issue, but if you are managing a high-volume Exchange Server, this can be problematic.

20.3.2.5. Daily

Do not confuse daily backup with the generic terminology of a daily backup. In this context, it refers to a copy backup that backs up only the current day's data. Like the copy backup, it does not purge the transaction log or update the last backup date.

20.3.3. Determining What to Back Up

A fully successful backup of your Exchange 2003 Server may entail more than just the databases and transaction logs. A host of additional information may need to be restored to bring your Exchange Server to a fully operational state.

20.3.3.1. Exchange-specific

It goes without saying that in order to restore a failed Exchange Server you'll need all the Exchange components restored. These include Exchange databases, stores, storage groups, transaction logs, and checkpoint files.

Other Exchange pieces you may wish to back up include connector information, full-text index, message tracking logs, site replication service, Exchange cluster data, SRS database, the application software itself, third-party software such as Exchange-specific virus scanners, and any scripts you've created for ease of administration.

20.3.3.2. Windows-specific

While it is important to back up your Exchange Server, it is just as important to back up the server that Exchange lives on. Depending on your organization's particular setup, you may have more than just Exchange data on this server. Often Exchange is intermixed with Active Directory or, as in the case of Small Business Server, all your primary functions live on the same server.

Chapter 11 provides you with the details necessary to recover a failed Windows server, but it is worth mentioning that it is always a good idea to back up the following Windows server components in addition to your Exchange data: Registry, IIS metabase, Active Directory, operating system files, system state, boot files, boot partition, partition information, COM+ class registration database, SYSVOL directory, DNS information, cluster service, and certificate service database including the certificates themselves.

20.3.3.3. What not to back up when backing up Windows

Take special precautions when backing up your server that you have a backup application that is Exchange-aware. If your backup program doesn't have links to the Exchange API that coordinate the backup with Exchange, you run the risk of corrupting your databases and will not have an effective backup of your Exchange Server. In order to prevent this, exclude the following components from your server backup if it isn't Exchange-aware: database and logfiles (anything in the MDBDATA folder), and installable filesystem drives (IFSs).

20.3.4. Backup Methods

The days of having to bring all databases to a quiesced state in order to back them up are long gone. While not new in Exchange Server 2003, online backups are much improved and safer than previous versions. As with 2000, there is no reason in 2003 to stop the server or dismount the stores in order to get a good, complete backup. In fact, with Exchange 2003, if you don't do regular online backups, you could be doing your server more harm than good because the transaction logfiles are not being purged. Additionally, many consistency checks are done for both 2000 and 2003 during the backup; if these checks fail during the backup, the backup will terminate.

20.3.4.1. Online backups

Online (a.k.a. hot) backups are now the typical method for backing up your Exchange Server. As the name implies, online backups can be performed while the database is operational, avoiding any downtime that may impact your users. Additionally, online backups provide a cyclical redundancy check (CRC) as the data is backed up for extra verification of the data; the offline mode does not. Backups performed online also clear out the ever-increasing number of transaction logfiles.

20.3.4.2. Offline backups

While online backups are the preferred way to back up your Exchange Server, offline backups are not without their place. The main disadvantage of offline backups is the fact that the storage group must be dismounted, which means that the database is unavailable to users during this time. Also, because of the nature of this backup, no transaction logs are purged, and the last full backup flag is not set. The only way to rectify this situation is to perform one of the backup types that purge the files. One advantage of offline backups is that they can include all Exchange configuration data, such as connector information. Other benefits are the ease with which these backups can be performed and their speed. Backups of this type can be scheduled through ntbackup or, more simply, the .edb and .stm files can be copied with system commands such as copy or xcopy.

20.3.4.3. Streaming backups

Microsoft Exchange Server 2003 provides an API that can provide access to streaming backups. This method provides continual backups that stream to the backup medium. This ensures that the backup is always up to date.

20.3.4.4. Shadow copy backups

Microsoft Exchange 2003 Service Pack 1 supports a feature called Volume Shadow Copy Service when running on Windows Server 2003. This technology allows for point-in-time snapshots to be taken of the Exchange databases. These snapshots can be one of two different types, clone or copy-on-write. As the name suggests, the clone is just that, a complete copy of the original volume. The copy-on-write method stores only the changes made to the original volume since the last snapshot. Both methods can be implemented either in software or hardware. However, only those backups made to hardware are transportable, or able to be moved to other servers.

In order to use Volume Shadow Copy Service, your backup software, the application you are trying to back up (in this case, Exchange), and your backup device must support it. There are three capability levels for the Volume Shadow Copy Service:

Requestor

Generally an additional piece of software, such as a backup application, that can use the shadow copy feature.

Writer

The component that enables snapshots to be taken, generally application-specific, such as a writer for Exchange or SQL Server.

Provider

Software or hardware that actually writes to the hardware.

The default behavior for ntbackup is to operate as a Volume Shadow Copy Service requestor. However, the ntbackup requestor uses only the copy-on-write method. In order to back up using the other method, a third-party application that ties into the Volume Shadow Copy Service is necessary.

Because of the nature of these snapshots, and the fact that data is constantly streaming to them, you need a lot of storage space. For that reason, a NAS or a SAN device is the perfect storage location for shadow copies. Some NAS vendors have even implemented this feature directly into their hardware, making backups and restore incredibly easy.

20.3.4.5. Verifying backups

As important as it is to make backups, it is just as important to verify them. All of your hard work making a backup schedule and implementing it is completely and utterly useless unless you verify that the backups you are making can be restored.

The first step in verifying your backup is to review the backup log after the backup has completed. This gives you an overall status but could lack some specific details. For specific details, review the application log in the Event Log. This often provides a great deal more information that the report. There is also a verify option for ntbackup so that you can have it verify the backup. This is a good plan in addition to the other steps, but don't rely on this method alone.

For the ultimate in verification, consider doing a restore. A restore to a test server has many benefits besides just proving that your backups are fine; it also initiates you into the restore procedure so you can prepare for a real emergency. In addition, it gives you a chance to walk through the steps involved in a non-job-threatening situation, so you can calmly and collectedly take notes and get your restore procedure down. That way, when the real emergency occurs, you are a hero.