Thnks for that :)

David


> ----------
> From:         William Lefkovics[SMTP:[EMAIL PROTECTED]
> Reply To:     Exchange Discussions
> Sent:         18 June 2003 11:19
> To:   Exchange Discussions
> Subject:      RE: Brick level backups
> 
> I probably should reread this, but this was my answer to this question
> A year ago - plus an added point.
> 
> Why not to do Brick Level Backups:
> 
> 1) They take a loooong time. At my last position, the priv.edb on 
> several Exchange servers was huge with several mailboxes exceeding 
> 2GB. Backup windows of 'July' is not acceptible nor necessary.
> 
> 2) Brick Level break SIS in the process. At a previous employer we 
> had an SIS ratio of 4 (lots of little daily cash spreadsheets and the 
> like getting sent to DL's). This means that a BLB backup uses as much
> as 4 times the total tape. Now I need an autoloader to take care of 
> the boxes of tapes required each night.
> 
> 3) You can't perform a full server restore to point of failure with 
> brick level backups. You have to actually perform additional full 
> online backups as well to allow for full disaster recovery. More 
> tapes. More time. More money.
> 
> 4) A restore of several mailboxes from BLB's will cause the store to 
> grow because of no SIS. If my SIS ratio is 2 and some disaster leaves
> me with only brick-level, my restore will double the size of the priv.
> 
> 5) The redundant backups for brick level lower the overall performance
> of your exchange server as backups compete with users for CPU cycles 
> and disk reads. It is also additional and unnecessary wear and tear 
> on tape drives.
> 
> 6) Brick Level Backups do not backup items in deleted item retention. 
> As my users (for email anyway) have always been of the educated 
> variety, they know and use deleted item recovery as needed.
> 
> 7) A restore of a mailbox is seldom needed. (Probably the only 
> instance is inadvertant deletion by an administrator in Exchange5.5) 
> With deleted item retention set to a reasonable 30 days or so, and 
> with deleted mailboxes retained in Exchange2000, brick level backups 
> fall in the category of a waste of time and resources.
> 
> 8) Backups should not be a helpdesk support option. They are a 
> disaster recovery requirement. With all that tape and time, the 
> convenience of having someone restore my mailbox is so simple I can be 
> more careless with my email. I can always get my info restored.  The
> Potential for user complacency because we can always restore uses 
> Valuable IT time and resources.
> 
> 9) Yes, it's true. For me, I have only done this using ArcServeIT. 
> Because of comments here in this and other forums, CA took the 
> Exchange agent back to the lab and did some more fixing on it. For me
> it was too little too late. Basically, BLB's are not perfect. Data 
> is not perfectly recreated through the restore process. Problems 
> included header info missing, digitally signed emails corrupt, 
> attachments missing.
> 
> 10) Many, many more reputable and experienced people have shared their
> horror stories over and over in this and other forums and newsgroups. 
> So much so that I was relieved to learn in 1998 that it wasn't just me
> that felt this way. The people that have expressed this opinion I 
> hold in high regard and certainly owe it to myself to try to 
> understand why the concensus is for or against something.
> 
> 11) Microsoft provides the utility ExMerge which can be used to backup
> a single mailbox to .pst if necessary. I use this as the last step 
> before deleting a users mailbox after (s)he have left the company. It
> is a simplified, granular alternative for certain circumstances.
> 
> 12) Exchange2003 allows for a disaster recovery storage group to allow
> Production restores without a recovery server.
> 
> The above may not all apply to you.
> 
> Would you like to see the list against the use of 'confidentiality
> disclaimers'?
> 
> William
> 
> 
> 
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of David Lloyd
> Sent: Wednesday, June 18, 2003 2:58 AM
> To: Exchange Discussions
> 
> Hi guys,
> I just wanted to know why are brick level backups a bad idea. I know why
> pst
> files are.
> I can only imagine is that they take forever to complete, and not always
> all
> of them.
> 
> Sorry if this has been discussed before but i do need some reasoning for
> my
> bosses.
> 
> I know Ed hate em
> 
> 
> Thnks
> 
> David
> 
> 
> CONFIDENTIAL NOTICE
> This communication contains useless information which is confidential and
> may also be naughty. It is for the exclusive use of the intended
> recipient(s). If you are not the intended recipient please note that any
> distribution, copying or use of this communication or the information in
> it
> is strictly prohibited. If you received this communication in error,
> please
> notify us by e-mail or by telephone (020 7770 7000) and then delete the
> e-mail and any copies of it.
> 
> 
> 
> _________________________________________________________________
> List posting FAQ:       http://www.swinc.com/resource/exch_faq.htm
> Web Interface:
> http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchange&text_mode=&la
> ng=english
> To unsubscribe:         mailto:[EMAIL PROTECTED]
> Exchange List admin:    [EMAIL PROTECTED]
> 
> 
> 
CONFIDENTIAL NOTICE
This communication contains information which is confidential and may also
be privileged. It is for the exclusive use of the intended recipient(s). If
you are not the intended recipient please note that any distribution,
copying or use of this communication or the information in it is strictly
prohibited. If you received this communication in error, please notify us by
e-mail or by telephone (020 7770 7000) and then delete the e-mail and any
copies of it.


_________________________________________________________________
List posting FAQ:       http://www.swinc.com/resource/exch_faq.htm
Web Interface: 
http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchange&text_mode=&lang=english
To unsubscribe:         mailto:[EMAIL PROTECTED]
Exchange List admin:    [EMAIL PROTECTED]

Reply via email to