Unless one uses a solution like CommVaulut's Galaxy backup application which has maintained SIS doing item level backups for the better part of a decade. Not the cheapest solution on the market, but given the price of tapes and full restores it makes sense for many organizations.
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Albert Eddie > Posted At: Wednesday, June 08, 2005 8:02 PM > Posted To: swynk > Conversation: Brick level backups > 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.
