Developing a solid backup strategy is crucial for quick restoration of business operations even in the face of a total system failure. As such, an Exchange administrator would be remiss not to take the time to develop a solid backup plan for their Exchange Server deployment. Unfortunately, putting together a solid backup strategy for an Exchange deployment is not always a clear-cut affair.
The disparity in system and network architecture, budgets, recovery time objective, even uptime requirements across organizations, means that there is no standard checklist for administrators to implement. As such, a robust backup plan to recover from disaster needs to be individually crafted and put into action. Below are four key steps to help administrators towards the creation and implementation of a robust backup strategy.
1. What to back up
Regardless of system architecture and setup, there is no evading the basic question of which data files to back up. Below is a list of critical databases and files in Exchange 2010, sorted by server roles.
|Hub Transport Servers|
|Client Access Servers|
|Edge Transport Servers|
|Unified Messaging Servers|
Another crucial component to back up would of course be your Windows Server 2008 and Exchange Server installation. While it can be argued that these components can be rebuilt from their source installation media, rebuilding them do represent a significant time commitment that may well exceed an organization’s acceptable time window for disaster recovery. As such, it makes sense to take steps to protect the core components of your server installation, which you can read about here.
Beyond using third-party software to create replicas of the underlying infrastructure, there is also a growing acceptance to hosting Exchange 2010 within a virtual environment. Indeed, Microsoft is also announcing support for Unified Messaging Server role.
2. Backup validation
The rationale behind backup validation is to prove that data has been successfully backed up and restored. This may entail checking on random databases on a regular basis, topped off with a larger scale validation at annual exercises. Backup validation is best done in a lab environment that mirrors, or at least closely resembles, the production environment. Moreover, the process of backup validation also allows for accurate documentation to take place, as well as further serving as an opportunity to ascertain refinements that can be made to the backup process.
One advantage is that virtualization has generally made the creation of an environment to perform backup validation a much faster and painless process than in the past. Because backup validation is not typically performed on identical hardware or system loadings (for virtualized environments), it is generally not a suitable means to determine backup timings and should hence not be used as such.
It is important to properly define the roles and responsibilities of the administrators involved in the data backup and restoration process. Committing restoration procedures and signing off on them is especially important given that disasters are not something that happens often, and the wrong instructions in the high pressure environment of a downtime may result in procedures that result in further harm being done.
On the other hand, proper instructions can go a long way towards preventing mistakes arising from haste or inexperience. To stay relevant, it is important that documentation be updated whenever changes are made, which includes when new databases or servers are added or removed.
4. Other considerations
There are a number of other considerations that may influence the overall backup strategy. Below are some of the most important considerations:
Service Level Agreements
The Service Level Agreement (SLA) is arguably the most important factor to consider. One caution for the less experienced administrator to remember is that every additional “nine” in the uptime increases the required costs significantly. Uptime aside, most organizations also stipulate a Recovery Point Objective, or the amount of time required for recovery. This will obviously influence decisions such as those pertaining on off-site backup, and could well also limit the use of tape drives unless used as part of tiered storage architecture with disk drives for near-line backup.
Roles and responsibilities
While inter-team communications is not a problem for small and most medium-sized businesses, it can become a problem for larger teams. For example, there may be different team members tasked with testing and installation of system updates to the underlying operating systems, administrators directly in charge of day-to-day operation of Exchange servers, and another group specifically tasked with performing backups. It makes sense to define their roles and responsibilities clearly and in advance.
Database Availability Groups
Exchange Server 2010 introduced a new feature called database availability group (DAG) in which up to 16 Mailbox servers can be configured to host a set of database to provide for automatic database-level recovery from failures. When the master copy of a DAG goes offline, another copy of the mailbox database will be promoted to take over without affecting users. When configured with a long period of deleted item retention, the use of DAG can help reduce the need of having to restore from tertiary storage, which may influence the rest of your backup strategy accordingly.
Like this post?
If you like this post and would like to receive more Exchange Server tips, as well as the latest Exchange Server posts from across the web, plus a free ebook with 42 Exchange tools, subscribe to the IT Dojo – Exchange Sensei series!