Backing Up the Exchange Server 2010 Environment : Roles and Responsibilities & Developing a Backup Strategy

2/14/2011 8:58:24 AM

Roles and Responsibilities

With any process that is likely to include more than one person, it is useful to clearly define the roles and responsibilities of those people. This ensures that the people involved know what is expected of them and they know who to go to in various situations.

Separation of Duties

A typical Exchange Server environment involves members from potentially many groups. For example, one group might be responsible for Exchange Server services and configuration, whereas another group might be tasked with management of Windows and security patches. Often, yet another group is responsible for performing backups of the systems. Each of these groups must be aware of what other groups are doing. For example, if the Windows group needs to install Windows patches on the Exchange servers, the backup group also needs to be aware of this because they might need to change the scheduling of the backup job. This type of interdependency must be taken into account when configuring the backup schedule.

Escalation and Notification

If a backup job fails, it is critical for the support staff to know what they are supposed to do and who they should contact. It is recommended to build a matrix of common issues and create an escalation path for various events. It is also quite useful to have those events automatically notify the responsible party. For example, the server monitoring group might be told that in the event of a backup failure, they should do the following:

  • Contact the backup group to alert them of the failed job.

  • Contact the Exchange Server group to alert them of the failed job.

  • If neither group contacts you within 30 minutes, contact the IT manager.

  • If the IT manager doesn’t contact you within 60 minutes, contact the IT director.

By knowing who to call, it is easier to get a qualified party to look at the issue and potentially fix the issue in time to allow another backup job to be attempted before the backup window is expired.

Developing a Backup Strategy

Developing an effective backup strategy involves detailed planning around the logistics of backing up the necessary information or data via backup software, media type, and accurate documentation. To truly be effective, organizations should not limit a backup strategy by not considering the use of all available resources for recovery.

Along with planning and documentation, other aspects of a backup strategy include assigning specific tasks and responsibilities to individual IT staff members, considering the best person to be responsible for backing up a particular service or server and ensuring that documentation is accurate and current depending on their strengths and area of expertise.

What Is Important to Exchange Server Backups?

In general, the critical thing to capture in an Exchange Server backup is any unique data whose loss would impact users. This typically means that you need to back up the mailbox databases, public folder databases, and the log files that go with them. Files such as the operating system or the System State data are less important. This information can be easily recovered because it is stored in the Active Directory (AD). In the case of Database Availability Groups, the backup of log files is less important because multiple copies of the databases and logs are in other locations that can take over if the primary replica fails. In these configurations, the primary purposes for the backups is to enable for long-term storage of data to protect against deletion and to truncate log files so that servers don’t run out of space and shut down Exchange Server.

Creating Standard Backup Procedures

Creating a regular backup procedure helps ensure that the entire enterprise is backed up consistently and properly on a regular basis. When a regular procedure is created, the assigned staff members soon become accustomed to the procedure because they are given a guide that walks through each required step. If there is no documented procedure, certain items might be overlooked and not be backed up, which can be a major problem if a failure occurs. For example, a regular backup procedure for an Exchange Server 2010 server might back up the Exchange Server databases on the local drives every night, and perform a System State backup with Windows Server Backup Features once a month and whenever a hardware change is made to a server. These differences might be overlooked if no one is following regular change control and documented procedures.


It is a best practice to add documentation updates into standard server change control processes. This ensures that any modifications to server configurations also get added into server build documents.

Protecting Data if a System Failure Occurs

Server failures are the primary concern most organizations plan for, because a complete system failure creates the most impact and, ultimately, a scenario in which data needs to be restored from backup tape. Server hardware failures include failed motherboards, processors, memory, network interface cards, disk controllers, power supplies, and, of course, hard disks. Each of these failures can be minimized through the implementation of RAID-configured hard disk drives, error-correcting memory, redundant power supplies, or redundant controller adapters. In a catastrophic system failure, however, it is likely that the entire data backup would need to be restored to a new system or repaired server.

Because data is read and written to hard drives on a constant basis, hard drives are frequently singled out as the most possible cause of a server hardware failure. To address this, Windows Server 2008 supports hot-swappable hard drives and RAID storage systems, enabling for the replacement of the drive without server downtime. However, this is only if the server chassis and disk controllers support such a change. Windows Server 2008 supports two types of disks: Basic disks, which provide backward compatibility, and Dynamic disks, which enable software-level disk arrays to be configured without a separate disk controller. Both Basic and Dynamic disks, when used as data disks, can be moved to other servers easily. This provides data or disk capacity elsewhere if a system hardware failure occurs and the data on these disks needs to be made available as soon as possible.


If hardware-level RAID is configured, the controller card configuration should be backed up using a utility available through the vendor.

With most array controllers today, dynamic reading of the disk configuration can be done if the disks are placed into a new system using the same disk order. If this is not supported, the controller can be moved to the new systems, or the configuration might need to be re-created from scratch to complete a successful disk move to a new machine.

This process should always be tested, verified, and documented in a lab environment before being considered as a valid recovery option.

To protect against a system failure, organizations need to have a full image backup that can then be restored in its entirety to a new or repaired server system. This also requires completing and documenting these steps in advance to ensure that it can be completed and administrators understand the steps involved.

Protecting Data if a Database Corruption Occurs

Data recovery also is needed if a database corruption occurs in Exchange Server. Unlike a catastrophic system failure, which can be restored from the last tape backup, data corruption creates a more challenging situation for information recovery. If data is corrupt on the server system, a restore from the last backup might also contain corrupt information in its database, so a data restore needs to predate the point of corruption. This typically requires the capability to restore the database from an older full backup tape and then recover incremental data since the clean database restoral.

Providing the Ability to Restore a Message, Folder, or Mailbox

In other situations, an organization might need to recover a single message, folder, or mailbox rather than a full database. With most full backups of an Exchange server, the restore process requires a full restore of all messages, folders, and mailboxes. If an administrator needs to work with only a full image backup, typically a full restore must be performed on a spare server and information extracted from the full restore as necessary.

If message, folder, or mailbox recovery is required on a regular basis, the organization might elect to back up information in a format or process that provides an easier method of information recovery. This might involve the purchase and use of a third-party tape backup system, or a combination of various utilities available in Exchange Server 2010 to restore individual sets of information.

Assigning Tasks and Designating Team Members

Each particular server or network device in the enterprise has specific requirements for backing up and creating documentation around hardware and the service it provides. To make sure that a critical system is backed up properly, IT staff should designate a single individual to monitor that device and ensure the backup is completed and documentation is accurate and current at all times. Assigning a secondary staff member who has the same set of skills to act as a backup if the primary staff member is unavailable is a wise decision, to ensure that there is no point of failure among IT staff performing these tasks.

Assigning only primary and secondary resources to specific devices or services helps improve the overall security and reliability of the device and services provided to network users. By limiting who can back up and restore data—and even who can manage servers and devices—to just the primary and secondary qualified staff members, the organization can be assured that only competent, trained individuals work on systems they are assigned to manage. Even though the backup and restore responsibilities lie with the primary and secondary resources, the backup and recovery plans should still be documented and available to the remaining IT staff for additional training and a final means of support if needed.

Selecting the Best Devices for Your Backup

Each device used on any network could have specific backup requirements. As mentioned earlier, each assigned IT staff member should also be responsible for researching and learning the backup and recovery requirements of each device to ensure that all backups have everything that is necessary to also recover from a device failure.

As a rule of thumb for network devices, the device configuration should be backed up whenever possible—using the device manufacturer’s configuration software whenever possible or just by documenting the configuration for use as a reference should a device require reconfiguration.


It is also a best practice to evaluate the hardware used in your environment to determine which areas might be the most likely points of failure. Having spare devices can reduce the overall downtime in case of a failure. When dealing with Exchange Server 2010 considerations, these spare hardware devices can be pieces such as hard drives to support a failed drive in a RAID configuration.

Understanding How Devices Affect Backups

Depending on how a given environment is architected, there might be several different options on how it will be backed up. Administrators lucky enough to have network attached storage (NAS) or storage area networks (SANs) for their Exchange Server 2010 servers might have significantly faster options for performing backups than administrators who use direct attached storage (DAS). Many times, the NAS or SAN devices can perform local snapshots, or the SAN might be backed up by a tape device that is plugged directly into the Fibre Channel fabric. This has great advantages when compared to backing up an Exchange Server 2010 server over the network. For example, Gigabit Ethernet enables for 1Gb/sec of throughput. Fibre Channel not only offers speeds of 4Gb/sec to 8Gb/sec but is also a more efficient protocol.

One way to drastically speed up backups performed is to use a faster media for the final destination. Although current AIT and LTO tape technologies are very fast, they still can’t compare to an array of hard drives for the destination. Technologies such as System Center Data Protection Manager can take regular snapshots of Exchange Server 2010 and store them on disks. Longer-term backups are made from the disk images to tape. Because this transfer from disk to tape happens on the backup server, it can be done during the day without impacting end users or interfering with the regular backups. Technologies exist for most backup software in the form of virtual tape libraries that are actually files within a set of disks that can enable you to retain the normal methodologies of traditional tape backup while taking advantage of the speed and size of modern hard drives to drastically shrink the backup window on network attached backups.

Determining Backup Speeds and Times

The time needed to perform a backup of Exchange Server 2007 is influenced mostly by the speed of the backup device. Although vendors quote values for MB per minute that their device can back up, this isn’t always an accurate value when backing up an Exchange Server 2010 server. It is always recommended to perform test backups of Exchange servers to determine the speed at which they can be backed up. By knowing how long jobs take, an administrator can better select the backup window in which the backups occur. As Exchange servers grow in terms of the storage used by mail data, the backups take longer to occur. Pay careful attention to the network utilization and to the backup device utilization so that you can watch for bottlenecks that cause backup jobs to take too long.


Consider backing up Exchange Server 2010 to a backup server that uses disks as the media for the backup. This is typically the fastest media that you can utilize for “over the network” backups. Then take the locally stored backup and back that up to tape. Because you are backing up “cold” data, there is no concern about performing the backup during the day. This allows you to keep your backup window relatively short. The side benefit is that if you ever experience a failure that requires you to restore from the backups, you’ll be doing a disk-to-disk restore, which is much faster than a tape-to-disk restore.

Validating the Backup Strategy in a Test Lab

Regardless of what methodology you choose for backups of your Exchange Server 2010 environment, it is critical to test the processes in a lab environment. The goal of this validation is not only to prove that data can be backed up and restored, but also to refine and document the exact steps used. It is much easier to figure out how to perform a restore in the lab than it is in production when hundreds or thousands of mailbox users are down. The goal of a production restore is to follow accurate, validated instructions and not have to figure out what you need to do on-the-fly.

  •  Backing Up the Exchange Server 2010 Environment : Supporting Backups with Documentation
  •  Backing Up the Exchange Server 2010 Environment : Understanding the Importance of Backups & Establishing Service Level Agreements
  •  Making the Best Use of SAN/NAS Disks with Exchange Server 2010
  •  Optimizing an Exchange Server 2010 Environment - Properly Sizing Exchange Server 2010
  •  Optimizing an Exchange Server 2010 Environment - Analyzing and Monitoring Core Elements
  •  SharePoint 2010 : Beyond Built-In SharePoint PowerShell Cmdlets
  •  SharePoint 2010 : Understanding Advanced PowerShell Topics
  •  Optimizing an Exchange Server 2010 Environment : Monitoring Exchange Server 2010
  •  Optimizing Exchange Server 2010 Servers
  •  Business Intelligence in SharePoint 2010 with Business Connectivity Services : Consuming External Content Types (part 3) - Business Connectivity Services Web Parts
  •  Business Intelligence in SharePoint 2010 with Business Connectivity Services : Consuming External Content Types (part 2) - Writing to External Content Types
  •  Business Intelligence in SharePoint 2010 with Business Connectivity Services : Consuming External Content Types (part 1) - External Lists & External Data
  •  Optimizing an Exchange Server 2010 Environment : Analyzing Capacity and Performance
  •  Examining Exchange Server 2010 Performance Improvements
  •  Recovering from a Disaster in an Exchange Server 2010 Environment : Recovering Active Directory
  •  Business Intelligence in SharePoint 2010 with Business Connectivity Services : External Content Types (part 3) - Creating an External Content Type for a Related Item
  •  Business Intelligence in SharePoint 2010 with Business Connectivity Services : External Content Types (part 2) - Defining the External Content Type
  •  Business Intelligence in SharePoint 2010 with Business Connectivity Services : External Content Types (part 1)
  •  Recovering from a Disaster in an Exchange Server 2010 Environment : Recovering from Database Corruption
  •  Recovering from a Disaster in an Exchange Server 2010 Environment : Recovering Exchange Server Application and Exchange Server Data
    Top 10
    300Mbps AV200 Wireless N Powerline Extender TL-WPA281
    Programming the Mobile Web : WebKit CSS Extensions (part 2) - Reflection Effects & Masked Images
    Using Text in XAML
    Port-Binding Shellcode
    Windows 7: Customizing Menus and the Control Panel (part 1) - Navigating and Customizing Your Computer’s Menus
    Maintaining Windows 7 with Backup and Restore (part 1) - Creating a Backup & Restoring Files from a Backup
    Oracle Coherence 3.5 : Accessing the data grid (part 6) - Using the Coherence API - Implementing CoherenceTarget, Testing the Cache loader
    Refrigerator Is Calling (Part 1)
    Chrome FOR Android Beta Is Out
    Summer games
    Most View
    SQL Server 2008 : Advanced Stored Procedure Programming and Optimization - Using Dynamic SQL in Stored Procedures
    Designing and Implementing Mobility in Exchange Server 2010 : Working with ActiveSync Policies
    Using the Dynamic Keyword in C# 4.0
    10 Best products of the past 200 issues (Part 3)
    iPhone Application Development : Making Multivalue Choices with Pickers - Using Date Pickers (part 1)
    Cocoa Fundamentals
    Navigating Architecture Changes in Windows Vista
    Oracle Coherence 3.5 : Accessing the data grid (part 2) - Configuring the development environment
    Home Theatre Pc Software And Operating Systems (Part 1) - Windows Media Center
    Go Baby Mobile Dongle Dock
    Algorithms for Compiler Design: LEXICAL ANALYZER DESIGN
    Safe online transactions (Part 1) - Shared keys & Public key cryptography
    Mobile Application Security : BlackBerry Security - Introduction to Platform
    Is The Personal Blog Dead? (Part 2) - Going Mainstream
    Programming the Mobile Web : Mobile Widget Platforms
    Installing Windows Server 2008 R2 and Server Core : Preplanning and Preparing a Server Installation
    Asus P8Z68-V Pro
    Exchange Server 2007: Manage Recipients - Create Distribution Groups and Dynamic Distribution Groups
    Windows 7 : Indexing Your Computer for Faster Searches (part 2) - Specifying Files Types to Include or Exclude