Incremental and differential backups

By Jerry Cochran 01 Nov 2004 | SearchExchange.com

Digg This!     StumbleUpon     Del.icio.us

The following is tip #3 from "20 tips on protecting and recovering Exchange data in 20 minutes," excerpted from the book, "Mission Critical Microsoft Exchange 2003" (Digital Press, a division of Elsevier, Copyright 2004). For more information about this book and other computing titles, please click here. Return to the main page for more tips on this topic.

It is also worth mentioning that since the databases are not copied, no page verification or checksumming is performed on the database to ensure integrity (during recovery, the log file records are also checksummed to ensure integrity). This is a notable point when selecting which backup strategy you will use for your Exchange deployment. Since an incremental or differential backup only operates on the log files, if circular logging is enabled, neither incremental nor differential backup operations will be capable of providing complete recovery. Like a normal backup, an incremental backup will delete log files up to the truncation point once they have been backed up. This is the key point of difference between incremental and differential backups. To restore from an incremental backup, you will need your last normal (full) backup set plus any incremental backup sets that have been made since. For Exchange 2000/2003, you must indicate when the last backup set has been restored in order for the ESE database instance to recover the database properly.

Like an incremental backup, the differential backup is also only concerned with transaction log files. The point of difference from an incremen¬tal backup is that a differential backup does not delete the log files at the truncation point (i.e., the current checkpoint location). While the start of the backup operation is marked by closing and renaming the current E0n.LOG to E0nnnnnn.LOG and creating a new E0n.LOG generation, the log files are left intact. To restore from a differential backup set, as was the case with an incremental backup, the last normal (full) backup set is required. Next, this is combined with the latest differential backup set. This is due to the fact that, since the differential backups have left log files intact throughout subsequent backup operations, the latest differential backup contains all log files created since the last normal backup set. As was the case with the incremental backup recovery operation, the last backup set must be indicated for the ESE recovery storage instance to properly recover the database or storage group.

Brick-level versus normal backup
Customers have requested the ability to restore a single message, folder or mailbox since the earliest days of Exchange. This is not possible using the normal backup API because data is read from the database in 4-KB pages and is written to tape in that manner. This means that the physical structures of the database are backed up devoid of the logical structure that is meaningful to individual mailboxes and public folders. There is no contextual information written along with the data, so a full restore is necessary before the data is reordered into a proper database structure.

Several backup software vendors have attempted to provide the necessary features to support single message restore (like what folder it is in, whether it contains attachments, and so on) in their Exchange-compliant backup products. This mode requires that data be written to backup media with all its contextual information intact, so the normal backup API cannot be used. Instead, a connection is made using the MAPI protocol in much the same way as a normal MAPI client, and data is read out in mailbox order. This is referred to as a "brick" backup. A brick restore is one in which a single item (mailbox, folder or other item) is extracted from the backup media and inserted into the information store. Restoring a single item is much easier with this approach, but backup times are significantly longer due to the requirement to write out additional information -- brick backups do not use single-instance storage, and they have to expand the MAPI properties of each message, bloating the backup data.

Typically, brick backups take four to five times longer than a normal backup. I do not recommend that you use a brick backup as the basis for your daily backup routine. Instead, if you use a product that supports brick backups, consider using this feature once a week and use a normal backup every other day. Another possibility is to use such a product feature for key personnel in the enterprise. Microsoft may never provide brick-level backup for Exchange, but many third-party products can provide some solution to this problem.

With the ability to partition the information store into smaller units of manageability in Exchange 2000/2003 and to recover individual deleted items and mailboxes, brick-level backups may become less important.

Get more "20 tips on protecting and recovering Exchange data in 20 minutes". Return to the main page.

About the author: Jerry Cochran is a contributing editor for Windows IT Pro and Exchange & Outlook Administrator and a group program manager for Microsoft. He is the author of Mission-Critical Microsoft Exchange 2000 (Digital Press).

Digg This!     StumbleUpon     Del.icio.us

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary