Conventional backup tools copy files from a source location to the backup media -- xcopy is actually a backup tool...
in disguise. Leaving aside the question of how you select which files should be backed up, file-copy-based backups are an acceptable strategy for file-based data. However, Exchange (and other database applications such as Oracle and SQL Server) keeps its data files open all the time. There are commercial solutions that purport to allow you to safely and consistently back up files that are open by another application, but this method is somewhat unreliable -- there is no guarantee that the backup copy of the file will have exactly the same data as the original version because a write operation to the source file might change its contents after that portion of the file has been copied.
In both cases, you must have software that uses the appropriate API. Both of these alternatives allow you to make an online backup; that is, one that is made while the databases being backed up are mounted and available to users. In the case of the ESE API, Microsoft ships a modified version of the ntbackup utility as part of Exchange, and every major backup software vendor -- including Computer Associates, Hewlett-Packard, VERITAS, and Yosemite -- offers an Exchange-aware agent or version of their software. You can always ignore these products and make your own offline backups, which are made while the database is dismounted; however, these backups require you to interrupt service, and they don't check the integrity of the file as it is being backed up.
Exchange supports four types of backup:
Each has associated benefits and drawbacks, most of which revolve around whether the transaction logs are purged as part of the backup.
Full backups are straightforward. When you make a full online backup of an Exchange storage group, all of its databases are copied, and the log files for that storage group are removed after their data are incorporated into the databases (a process known as truncation). Full backups are self-sufficient because you can restore a complete copy of the database without anything else. For example, if you have a full backup taken at 0600 Monday, you can roll back to that point in time using only that backup.
Incremental backups are pretty straightforward, too; they record only those database pages that changed since the most recent full backup. The Exchange online backup mechanism actually does this by copying the log files, not the entire database. As a result, to restore a database that has incremental backups, you need to have the full backup plus all of the incremental backups between the full backup and the desired RPO. It's common for Exchange shops to do weekly full backups combined with daily incrementals.
Suppose that your weekly backup is taken on Saturday at 0400, with incrementals Sunday through Friday. If you want to restore the database to Tuesday's data, you need the Saturday full backup, plus the incrementals for Sunday, Monday, and Tuesday. This requirement puts extra emphasis on backup media tracking and control procedures -- if you lose an incremental backup set you can't restore any data past that backup. In this example, if you lose Monday's tape, you can only restore back to Sunday's system state.
Differential backups combine the best aspects of full and incremental backups. A differential backup must be used in combination with a full backup because it copies all of the transactions that have occurred since that full backup. A Saturday full backup coupled with daily differentials can be restored to any point in time by restoring the full backup first, then restoring the differential backup taken closest to the point of failure. This method makes media management somewhat easier, although the differentials increase in size as more time passes since the original full backup was created. In addition, later differentials take longer, which is often a bigger concern than the amount of space they consume.
Copy backups do nothing except copy the database data. They don't purge the transaction logs, and they don't update the database header to indicate that the database was actually backed up. Copy backups are the most transparent type of backup operation, which makes them a good choice for times when you want a known-good copy of the database but don't want to interfere with your existing backup processes.
10 tips in 10 minutes: Fundamentals of Exchange Server disaster recovery
Tip 1: Defining Exchange disaster recovery
Tip 2: How Exchange backs up data
Tip 3: Choosing a backup type for Exchange
Tip 4: Online vs. offline Exchange Server backups
Tip 5: Basic Exchange backup and restore
Tip 6: Exchange vendor snapshots and point-in-time copies
Tip 7: VSS for Exchange
Tip 8: Exchange Server replication
Tip 9: Exchange design choices and issues
Tip 10: Exchange disaster recovery planning
This chapter excerpt from the free e-book The Definitive Guide to Exchange Disaster Recovery and Availability, by Paul Robichaux, is printed with permission from Realtimepublishers, Copyright 2005. Click here for the chapter download or download all available chapters here.