6.10 Best practice 10: Plan for growth s impact on disaster-recovery

6.10 Best practice #10: Plan for growth’s impact on disaster-recovery

The growth in messaging and collaboration data is a huge issue confronting organizations that have deployed messaging systems like Exchange Server. Most research organizations and storage vendors continue to forecast ever increasing storage growth rates. In addition, since we are a global economy, business is being done at all hours, and the messaging system must be available around the clock. As a result, managers of these systems face the never-ending issue of growing information stores, shrinking disaster-recovery windows, and more stringent disaster-recovery SLAs. As part of your established best practices for your Exchange deployment, you will have to consider the impacts of growth on your disaster-recovery plans. Without consideration of growth in our disaster-recovery planning, burgeoning information stores will quickly surpass the capabilities of our disaster-recovery measures and facilities. I like to plan conservatively here and anticipate as much as 100% growth every year. As an example, if the size of my databases is limited to 50 GB based on disaster-recovery constraints, I would either plan for 200% capacity in my DR facility (tape restore hardware and software rates), or I would limit my information stores to 25 GB in anticipation of future growth. My conservative approach may be a bit extreme, but I would encourage you to make your disaster-recovery plans accordingly.

Regardless of what degree of padding you choose to put into your plans, make sure you monitor how much of that buffer is being used on an ongoing basis. As you monitor growth, you can also adjust your disaster-recovery procedures and facilities according to the rate of growth being observed. Avoid the pitfall of planning for growth, but never verifying that growth occurs. Anticipating growth in your disaster-recovery requirements should also be closely tied to growth planning of your information store. Since Exchange 2000/2003 allows for greater flexibility in storage management, take advantage of this capability in your planning as well. All too often, growth is left out of the equation when deploying complex applications like Exchange Server. For your Exchange deployment, ensure that growth is factored into both your information store space planning and your disaster recovery planning.

Since the installed base of Exchange 2000 is relatively small (15%–20% of Exchange servers) and Exchange Server 2003 has only just released, it may be a little premature to claim complete knowledge of all best practices for Exchange 2000/2003 disaster-recovery. We do know that some things will not change. On the other hand, you can see that your disaster-recovery procedures for Exchange will have to be revisited once you deploy Exchange 2000/2003. From a disaster-recovery-planning perspective, you will need to understand the impact that new features such as multiple storage groups and databases will have on disaster-recovery for Exchange. Your plans may be able to drop support for the Exchange directory, but should not neglect the AD. In preparation for Exchange 2000/2003, it is time to take a look at your disaster-recovery plans and procedures. Also, don’t forget configuration management. The complexities of laying out multiple databases and storage groups will call for a high degree of configuration control. From an operations perspective, understand the various scenarios under which you may have to recover Exchange. Practice for catastrophes as well as individual mailbox recovery. Also comprehend the complete system, including hardware, drivers, patches, operating system, and other applications. If you are doing daily full backups now, you will probably want to continue to do so for Exchange 2000/2003. However, take a look at what snapshot/clone technology or backup-to-disk alternatives might buy you. Closely related are your management practices for Exchange. Practice proactive performance, configuration, and problem management. Finally, keep in touch, because many best practices for Exchange 2000/2003 disaster-recovery have yet to be discovered.