Business
Scale your disaster recovery plans for Exchange Server 2003
Over the last several weeks, we've examined disaster recovery (DR) practices for Microsoft Exchange Server 2003 and how to protect its various components. This week, we'll put it all together for small, midsize, and enterprise organizations.
Over the last several weeks, we've examined disaster recovery (DR) practices for Microsoft Exchange Server 2003 and how to protect its various components. This week, we'll put it all together for small, midsize, and enterprise organizations.
Each of these types of organizations has different needs, and different budgets. That means they must create different DR plans.
Small business
If you are using a third-party tool, you may also wish to perform mailbox-level backups (especially if you're still on Exchange 5.5, which has fewer options for deleted mailbox retention and recovery than the 2003 version). This will give you the basic ability to restore the data to either a recovered server, or a new server should that be required. Testing is a must, and you should be restoring data to another machine on a regular basis to ensure integrity. With a modest budget investment, you can gain a reasonable measure of DR, but if you have additional time and money to spend, you can take things to the next level.
Midsize business
With a larger infrastructure, there are more things to protect. Thankfully, you usually have more budget resources to go with it. If not, you can still rely on tape systems, provided the organization can afford to lose potentially one business day of data and one business day to restore, in a worst-case scenario.
At this level, you may have a front-end Exchange server or other SMTP gateway system, probably handling SPAM filtering, virus scanning, and other operations. You may also have more than one mailbox and public folder (database) server to protect. Most likely, the DR site will be either co-located with the production server or else have limited space at a hosting facility where you pay by the square foot or rack space needed. In these cases, you may choose to go beyond tape backup by using a replication tool and preparing for failover in the event of a loss of the primary server systems. Most likely, you're going to want to fail over to a single server that serves both front-end and back-end resources. You will need to plan accordingly by preconfiguring your DR server well in advance of bringing it into service.
If you're not replicating, you're going to want to restore full backups on a weekly basis to the DR systems, so that in the event of a disaster you'll only need to replay the latest differences to bring it up to date. If you are replicating, make sure that the tools you use can properly protect Exchange-specific data (especially the databases), and can fail over front-end services as well as the mailboxes. Test your DR plan regularly, adding in failover testing in addition to testing for data integrity.
Large enterprises
Most enterprise-class organizations have offices in many locations, not all of which will hold local resources for e-mail. Many will refer back to regional offices to get their mail and access shared systems, especially with the new technologies found in Exchange and Outlook 2003. The main things working in your favor are more than one location to host data within the organization, and relatively larger budgets to use toward that goal.
At this level, replication and failover are the hallmarks of your DR plan. Tape is still required for several reasons (point-in-time protection, log management, etc.), but it becomes a part of a larger set of systems instead of the key system in use.
Both hardware and software replication tools are available, and either may be suitable for the protection of Exchange systems. Keep in mind that hardware systems require much larger bandwidth availability and cost vastly more than their host-based counterparts, but all software tools do not provide for transactional integrity—vital for any database-dependent system such as Exchange server.
Data latency caused by such a problem will not necessarily prevent failover, but it extends your Recovery Point Objectives. Find the replication system that best meets your budget, provided the vendor can show that it properly protects the data in question. Based on the systems you choose, you can send data to any other company site that has enough bandwidth and the proper server infrastructure to support it. Here you can even provide for multiple front-end/back-end failover configurations by using DNS and other systems to ferry traffic from a failed site to a live site regardless of which part of the solution should conk out on you.
It bears repeating again: Testing is vital to the success of your solution. With all the service packs, hot fixes, and updates for Windows and Exchange, along with third-party tools, unless you test regularly you can never be sure everything will work in harmony. Failure to test will keep you from being secure in the knowledge that your DR systems will work like a charm in the event of a systems collapse.
No matter the size of the organization, you cannot afford to neglect your Exchange Server data. By building on the basics, you can scale up your DR tech to both fit within your budget and meet the needs of your business now and into the future.
Each of these types of organizations has different needs, and different budgets. That means they must create different DR plans.
Small business
If you are using a third-party tool, you may also wish to perform mailbox-level backups (especially if you're still on Exchange 5.5, which has fewer options for deleted mailbox retention and recovery than the 2003 version). This will give you the basic ability to restore the data to either a recovered server, or a new server should that be required. Testing is a must, and you should be restoring data to another machine on a regular basis to ensure integrity. With a modest budget investment, you can gain a reasonable measure of DR, but if you have additional time and money to spend, you can take things to the next level.
Midsize business
With a larger infrastructure, there are more things to protect. Thankfully, you usually have more budget resources to go with it. If not, you can still rely on tape systems, provided the organization can afford to lose potentially one business day of data and one business day to restore, in a worst-case scenario.
At this level, you may have a front-end Exchange server or other SMTP gateway system, probably handling SPAM filtering, virus scanning, and other operations. You may also have more than one mailbox and public folder (database) server to protect. Most likely, the DR site will be either co-located with the production server or else have limited space at a hosting facility where you pay by the square foot or rack space needed. In these cases, you may choose to go beyond tape backup by using a replication tool and preparing for failover in the event of a loss of the primary server systems. Most likely, you're going to want to fail over to a single server that serves both front-end and back-end resources. You will need to plan accordingly by preconfiguring your DR server well in advance of bringing it into service.
If you're not replicating, you're going to want to restore full backups on a weekly basis to the DR systems, so that in the event of a disaster you'll only need to replay the latest differences to bring it up to date. If you are replicating, make sure that the tools you use can properly protect Exchange-specific data (especially the databases), and can fail over front-end services as well as the mailboxes. Test your DR plan regularly, adding in failover testing in addition to testing for data integrity.
Large enterprises
Most enterprise-class organizations have offices in many locations, not all of which will hold local resources for e-mail. Many will refer back to regional offices to get their mail and access shared systems, especially with the new technologies found in Exchange and Outlook 2003. The main things working in your favor are more than one location to host data within the organization, and relatively larger budgets to use toward that goal.
At this level, replication and failover are the hallmarks of your DR plan. Tape is still required for several reasons (point-in-time protection, log management, etc.), but it becomes a part of a larger set of systems instead of the key system in use.
Both hardware and software replication tools are available, and either may be suitable for the protection of Exchange systems. Keep in mind that hardware systems require much larger bandwidth availability and cost vastly more than their host-based counterparts, but all software tools do not provide for transactional integrity—vital for any database-dependent system such as Exchange server.
Data latency caused by such a problem will not necessarily prevent failover, but it extends your Recovery Point Objectives. Find the replication system that best meets your budget, provided the vendor can show that it properly protects the data in question. Based on the systems you choose, you can send data to any other company site that has enough bandwidth and the proper server infrastructure to support it. Here you can even provide for multiple front-end/back-end failover configurations by using DNS and other systems to ferry traffic from a failed site to a live site regardless of which part of the solution should conk out on you.
It bears repeating again: Testing is vital to the success of your solution. With all the service packs, hot fixes, and updates for Windows and Exchange, along with third-party tools, unless you test regularly you can never be sure everything will work in harmony. Failure to test will keep you from being secure in the knowledge that your DR systems will work like a charm in the event of a systems collapse.
No matter the size of the organization, you cannot afford to neglect your Exchange Server data. By building on the basics, you can scale up your DR tech to both fit within your budget and meet the needs of your business now and into the future.