I keep trying to get my hands on the Galaxy, but every place I work at
already has someone in charge of backups who already went with some other
solution. 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris
Scharff
Sent: Wednesday, June 08, 2005 10:06 PM
To: Exchange Discussions
Subject: RE: Brick level backups

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.

_________________________________________________________________
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.

Reply via email to