Backup strategy
Before you slap a tape into a drive to backup an Exchange server you need to understand the physical file structure of an Exchange storage group and how Exchange manages data in these files Each storage group consists of two files EDB and STM
The STM file is a temporary storage point for SMTP mail that stores Multipurpose Internet Mail Extensions MIME content Once an email has been accessed by a MAPI client such as Outlook the content is stored in the EDB file In addition to these two file types Exchange uses log files as an intermediate step in the writetodatabase process These logs files help ensure data consistency integrity and performance The log files are a critical component in the restoration process In fact it is only after a normal backup using an Exchangeaware backup client that these log files are deleted One important item to note is that while Exchange supports circular logging do not use this feature in a production environment because of the possibility of data being overwritten Also remember that the System State needs to be backed up to facilitate the recovery process in the event of complete system failure You will also have to backup the IIS metabase if your organization uses Outlook Web Access While there are many Exchangeaware backup clients including NTBackup which is a solid tool for smaller shops the task of developing a backup strategy is the same regardless of the tool
The three backup choices are full incremental and differential A full backup is the best option to choose if you have the storage space and a sufficiently large enough backup window to complete the task A restoration from a full backup is straightforward It is also the fastest method of restoring your Exchange environment in the event of problems An incremental backup archives the data that changed since the last incremental backup This is the fastest backup method You should use this method if you have a short backup window and are comfortable handling the additional complexity of a restoration In the event of a system failure you will need to have the last full backup and every incremental backup since A differential backup represents a tradeoff between a full and an incremental backup As it will archive all data that has changed since the last full backup it does not provide the fastest backup method A restore will only require the last full backup and the last differential backup While the process of backing up Exchange is straightforward data recovery is not The biggest challenge in recovery is recovering individual items or mailboxes This is called bricklevel backup and restoration Unfortunately this is one of Exchanges biggest drawbacks The API approach developed by Microsoft provides only for backup up at the database level While many products allow bricklevel backups be aware that performance will be dramatically slower when performing such a backup Perhaps more importantly bricklevel backups should not be considered foolproof as they often have difficulty with open items as well as thirdparty Exchange addins Fortunately Exchange 2003 makes the bricklevel restoration easier than in earlier versions
Before you slap a tape into a drive to backup an Exchange server you need to understand the physical file structure of an Exchange storage group and how Exchange manages data in these files Each storage group consists of two files EDB and STM
The STM file is a temporary storage point for SMTP mail that stores Multipurpose Internet Mail Extensions MIME content Once an email has been accessed by a MAPI client such as Outlook the content is stored in the EDB file In addition to these two file types Exchange uses log files as an intermediate step in the writetodatabase process These logs files help ensure data consistency integrity and performance The log files are a critical component in the restoration process In fact it is only after a normal backup using an Exchangeaware backup client that these log files are deleted One important item to note is that while Exchange supports circular logging do not use this feature in a production environment because of the possibility of data being overwritten Also remember that the System State needs to be backed up to facilitate the recovery process in the event of complete system failure You will also have to backup the IIS metabase if your organization uses Outlook Web Access While there are many Exchangeaware backup clients including NTBackup which is a solid tool for smaller shops the task of developing a backup strategy is the same regardless of the tool
The three backup choices are full incremental and differential A full backup is the best option to choose if you have the storage space and a sufficiently large enough backup window to complete the task A restoration from a full backup is straightforward It is also the fastest method of restoring your Exchange environment in the event of problems An incremental backup archives the data that changed since the last incremental backup This is the fastest backup method You should use this method if you have a short backup window and are comfortable handling the additional complexity of a restoration In the event of a system failure you will need to have the last full backup and every incremental backup since A differential backup represents a tradeoff between a full and an incremental backup As it will archive all data that has changed since the last full backup it does not provide the fastest backup method A restore will only require the last full backup and the last differential backup While the process of backing up Exchange is straightforward data recovery is not The biggest challenge in recovery is recovering individual items or mailboxes This is called bricklevel backup and restoration Unfortunately this is one of Exchanges biggest drawbacks The API approach developed by Microsoft provides only for backup up at the database level While many products allow bricklevel backups be aware that performance will be dramatically slower when performing such a backup Perhaps more importantly bricklevel backups should not be considered foolproof as they often have difficulty with open items as well as thirdparty Exchange addins Fortunately Exchange 2003 makes the bricklevel restoration easier than in earlier versions
No comments:
Post a Comment