This is great, thanks! I can't figure out why there aren't more resources out there on this. I'd use it for archiving old email, not for disaster recovery.
Thanks, Erick -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Albert Eddie Sent: Wednesday, June 08, 2005 6:02 PM To: Exchange Discussions Subject: RE: Brick level backups I thought this might be helpful.. /ALE http://www.ultrabac.com/kb6/htm/UBQ000042.htm INFO: The Pros and Cons of an Exchange Brick Level Backup And Restore UBQ ID Number: UBQ000042 Last Modified: 2000-06-05 at 10:43:26 SUMMARY: Can UltraBac do a brick level (single mailbox) backup and recovery? DETAILS: UltraBac does not do a brick level backup of Exchange. The reasons are as follows: A brick level (single-mailbox) recovery requires a brick level backup. A brick level backup is not designed to fully protect an Exchange server, one mailbox at a time. It is not an alternative to a monolithic backup/restore. That's because the brick method uses MAPI, which cannot access all of the data in the information store. In other words, the sum of the mailboxes is less than that of the store. Thus, a brick restore cannot be used to recover the Information Store after a disaster. If used, a brick level backup must be utilized in conjunction with a monolithic backup, in order to fully protect the server. When investigated with Microsoft, engineers discounted the ability of any product that claims to have the ability to do single mailbox recovery. In order for any vendor to claim this feature, the product would have to backup multiple copies of the same message. In other words, it would have to change the Exchange Single Instance architecture database. Removing the Single Instance architecture is possible but it would mean longer backup time and greater tape usage. Single Instance architecture is a method used by Exchange to reduce the size of the database and also to minimize disk space fluctuation when users read and delete their mail messages. A case in point is that when a message is being sent to 100 users. If all 100 users were on the same server, then Exchange would store only a single copy in the database, but would create a pointer in each of the 100 mailboxes that the message was being sent. When the user reads and deletes the mail message, only the pointer is deleted. Without the Single Instance architecture, 100 copies of the message would have to be created. More importantly is that when the users read and delete the message, it creates tremendous disk usage fluctuation. The problem with Single Instance architecture is that when you restore a user's mailbox, you are only restoring the pointer. Hence, you need to restore the complete database so that mailbox pointer would work. In order to restore a user mailbox, Exchange would have to restore all messages found on each of the mailbox pointers. That is very difficult using tape technology. To accomplish a complete mailbox restore, the backup software would have to remove the Single Instance architecture by replacing the pointer with the message. This requires more time for the backup and also more tapes are used. Furthermore, by replacing the Single Instance architecture, what happens if one needs to restore the whole database? Will the Single Instance Architecture be maintained? Current brick level backup capabilities rely on MAPI to access each mailbox to re-create all of the mailbox data in the message store. Performance can be as slow as 8MB/min. If studies are to be believed, each message is sent to an average of 4 users. Therefore, the size of the resulting data-file (it's not an information store) would increase dramatically because the notion of a single-instance does not apply. For example, using the 4:1 ratio, a 30GB Information Store could end up occupying 120GB on 3-4 tapes (assuming 40GB tapes). And that is in addition to the monolithic backups done for disaster recovery! As you might guess, brick level backups and restores can easily get out of proportion, both in time for the backups to take place, and in space once the database is restored. (An Exchange database that was backed up brick level, when restored, could be about 4 times larger than it was originally!) MORE INFORMATION: See UBQ: UBQ000020 - Static Exchange & SQL Backups See UBQ: UBQ000022 - Defining UltraBac Account as an Exchange Administrator See UBQ: UBQ000029 - Exchange Single Mailbox or Single Message Recovery See UBQ: UBQ000038 - Exchange Stop/Start Command Lines CATEGORIES: Exchange VERSION: 2.x to 5.x Copyright UltraBac.com 1999-2001 Another of the GOOGLE hits... http://www.msexchange.org/tutorials/Exchange-Backup-Strategies.html > Behalf Of Erick Thompson > > Does anyone have a good link to a site about Brick level backups, as > in what they are, how they work, why they are good/bad? We're looking > at new backup strategies, and we're considering brick level backups. _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/read/?forum=exchange To subscribe: http://e-newsletters.internet.com/discussionlists.html/ To unsubscribe send a blank email to [EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with. _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/read/?forum=exchange To subscribe: http://e-newsletters.internet.com/discussionlists.html/ To unsubscribe send a blank email to [EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with.
