The two physical sites would be on two different segments of our campus so we have redundant network links as well as power for both. Load would be distributed between the two of them (2 servers per site) with replication between the two. We have also been considering a third non-local site 30 to 40 miles away, but we are still looking at bandwidth at that site. That would be a third copy of our DB's and we would put some latency on the copies (possibly a few days) basically for DR purposes only.
We currently have a 30 day deleted item retention period for users. We also have a 6 month Deleted Mailbox Retention period on the servers so we can recover a mailbox up to 6 months. Our Tivoli Backups give us an extra 60 days on top of that. Our current Exchange deployment uses a DS 4800 but with the new Exchange 2010 and expanded quota requirements and DAG, the SAN storage is too expensive of a solution especially if we are breaking up or server location in 2 to 3 sites. Our current Tivoli backups are running about 8 hours to backup 3.2 terabytes for full backups. Our whole backup strategy for Exchange 2010 is being looked at closely. The team still would like to be able to have some off-site backups (currently done with Tivoli) for that extra comfort level. Pete Pfefferkorn University of Cincinnati Systems Engineer/Messaging Administrator (513) 556-9076 pfeff...@ucmail.uc.edu From: Sobey, Richard A [mailto:r.so...@imperial.ac.uk] Sent: Thursday, July 29, 2010 4:49 AM To: MS-Exchange Admin Issues Subject: RE: Exchange 2010 DAG and backup options/recommendations. That would be my biggest concern: the absence of a backup to restore someone's mailbox from two to three months ago. There's backup for disaster recovery, then there's backup for user stupidity. From: bounce-9036114-8066...@lyris.sunbelt-software.com [mailto:bounce-9036114-8066...@lyris.sunbelt-software.com] On Behalf Of Neil Hobson Sent: 29 July 2010 09:44 To: MS-Exchange Admin Issues Subject: RE: Exchange 2010 DAG and backup options/recommendations. In addition to what has already been said, let's talk a little about your statement "a backup system isn't really required". What you're referring to there is Exchange native data protection and if you go down this route there are some very clear things that you need to consider. For example, the MS recommendation is that you have at least 3 database copies if you implement native data protection; you've said 2 copies per database in your statement. I don't know your environment, and I know it's extremely unlikely to happen, but could your 2 on-site buildings be taken out at the same time? Consider a 3rd copy somewhere completely remote. You say you're worried about database corruption - that's where lagged database copies come in, so you'd need to consider those (which will take your design to 3 database copies anyway). Also, what are you planning to do regarding single item recovery? That affects the users and your ability to restore in the absence of a backup. From: Pfefferkorn, Pete (pfeffepe) [mailto:pfeff...@ucmail.uc.edu] Sent: 28 July 2010 21:02 To: MS-Exchange Admin Issues Subject: Exchange 2010 DAG and backup options/recommendations. We are going to be moving to Exchange 2010. Basically we will have 14,000 users and will allow users to go up to 4 gig mailboxes. We will have 4 backends distributed between 2 on-site buildings for redundancy (power/network). We will also be deploying a DAG configuration with 2 copies per database. We are talking a ton of storage and the question keeps arising about backups. I've heard with the DAG deployment, a backup system isn't really required because of the database replication, but my mind keeps going back to the possibility of database corruption. Total data to be backed up could be 192 terabytes, so it's a large amount of data. I was wondering what other large shops are using for that type of data. Comments on backup strategies for 2010? Pete Pfefferkorn University of Cincinnati Email Services-Systems Engineer pete.pfefferk...@uc.edu<mailto:pete.pfefferk...@uc.edu> (513)556-9076
