Recently I had the pleasure of working with a customer who decided to eliminate backups within their Exchange Organization. They were upgrading from Exchange 2007 to Exchange 2010 and wanted to take advantage of many of the new features that Exchange 2010 had to offer such as larger mailbox databases and cheaper storage. The customer was increasing mailbox quotas for approximately 12,000 users from between 120 or 200MB to 2 or 3GB with a handful of users with unlimited mailbox size limits. There was also a subset of approximately 19,000 users who had 35MB mailbox quotas which would be increased to 75MB in Exchange 2010. Their email retention time was currently 180 days but they were in the process of reviewing that with their legal department and possibly reducing that to 30 days. While going through their design session we came upon the topics of backups and what they planned to do going forward with Exchange 2010 while increasing the mailbox size limits. After running through the Exchange 2010 Mailbox Server Role Requirements Calculator with the Messaging and Storage Teams, the amount of storage they would have to purchase for their backup system was just not going to be feasible from a budgetary standpoint.
After numerous discussions about Exchange 2010 regarding backups, storage and database copies. The customer decided they wanted to explore the idea of using Exchange Native Data Protection with Exchange 2010 and eliminate backups completely from their environment. With the guidance of the following TechNet article: http://technet.microsoft.com/en-us/library/dd876874.aspx the choice was clear that by going to Exchange 2010, traditional backups for would no longer be necessary. We were able to meet many of following considerations for using Exchange Native Data Protection which allowed the customer to meet their business and technical requirements for upgrading to Exchange 2010.
1. Your recovery time objective and recovery point objective goals should be clearly defined, and you should establish that using a combined set of built-in features in lieu of traditional backups enables you to meet these goals.
- Resolution: In working with the customers legal department the decision was made that the retention time for email would be reduced to 30 days for all users. We used this information to enter into the Exchange 2010 Mailbox Server Role Requirements Calculator for the retention time to be 30 days with a combination of Single Item Recovery
2. You should determine how many copies of each database are needed to cover the various failure scenarios against which your system is designed to protect.
- Resolution: The customer decided that they would have 3 copies of each database spread across two Datacenters which were configured in an Active/Active configuration. In this case, the customer had F5 GTM and LTM load-balancers as well as a very high-speed connection between the Datacenters as well as multiple backup connections with different carriers if the primary WAN link were to go down.
3. Can you afford to lose a point-in-time copy if the DAG member hosting the copy experiences a failure that affects the copy or the integrity of the copy?
- Resolution: Because there are 3 copies of each database and a very high-speed connection between Datacenters this will not be an issue in this specific deployment.
4. Exchange 2010 allows you to deploy larger mailboxes, and the recommended maximum mailbox database size has been increased from 200 gigabytes (GB) in Exchange 2007 to 2 terabytes (when two or more highly available mailbox database copies are being used). Based on the larger mailboxes that most organizations are likely to deploy, what will your recovery point objective be if you have to replay a large number of log files when activating a database copy or a lagged database copy?
- Resolution: Again for this customer, this was a moot point because of their Datacenter configuration. However, we did deploy a single lagged copy with a 7 day playback time for around 150 Executive level users in the very rare event of logical corruption, see the following point.
5. How will you detect and prevent logical corruption in an active database copy from replicating to the passive copies of the database? What is your recovery plan for this situation? How frequently has this scenario occurred in the past? If logical corruption occurs frequently in your organization, we recommend that you factor that scenario into your design by using one or more lagged copies, with a sufficient replay lag window to allow you to detect and act on logical corruption when it occurs, but before that corruption is replicated to other database copies
- Resolution: After speaking with a number of my colleagues as well as a few folks at Microsoft, logical corruption is something that a very, very unlikely to happen with the changes in disk technology since the release of Exchange 5.5. Ever since the release of Exchange 2000/2003, Microsoft has built in a number of safeguards that help prevent logical corruption.
Every customer environment is different and careful planning and understanding of both the business and technical requirements are crucial. By moving to Exchange 2010, this customer was able to reduce the costs and improve the performance of their messaging environment in a number of ways. First, by using multi-role servers we were able to reduce the number of servers deployed in the environment from 15 down to 10. Second, all of their storage was low-cost, high-capacity, direct attached storage. And third, by implementing multiple database copies along with deleted item retention and single item recovery, traditional backups and the amount of disk needed to backup larger mailboxes was eliminated.
Might I simply just say, what a relief to find people that genuinely knows about exactly what they are speaking of on the web. You without a doubt know the correct way to carry a matter to illuminate as well as make it really important. Much individuals have to take a look at this as well as understand this kind of part of the story. I cant imagine you are not alot more well-known considering that you undoubtedly have got the Skill-set.
It’s difficult to find knowledgeable people today on that issue, nevertheless, you sound like you know what you’re referring to! Thanks