Changes to Backup and Restore in Exchange Server 2010

10/10/2010 9:55:06 AM
Exchange Server 2010 changes the way you back up your Exchange mailbox databases, removing the ESE streaming backup application programming interface (API) and adding a Volume Shadow Copy Service (VSS)–based plug-in for Windows Server Backup. Now the only supported online backup method is using the VSS plug-in for Windows Server Backup or an Exchange-aware VSS backup solution.

Together with the functionality that allows you to create copies of your databases on multiple Exchange servers, Exchange high-availability features closely link with disaster recovery.

1. Integrating High Availability and Disaster Recovery

You can integrate your high-availability deployment with disaster recovery, especially if you consider the Exchange Server 2010 high-availability features sufficient to satisfy your backup requirements.

1.1. The Link Between High Availability and Disaster Recovery

Using the high-availability features built into Exchange 2010 such as database availability groups (DAGs) allows you to minimize downtime and data loss in the event of a disaster but can also reduce the total cost of ownership of the messaging system. By combining these features with other built-in features, such as Single Item Recovery and Legal Hold, you are able to reduce or eliminate your dependency on traditional point-in-time backups and reduce the associated costs. You can spread database copies across multiple sites, which allows you to address datacenter failures and maintain offsite copies of a database.

1.2. High-Availability Provides Options Beyond Traditional Backup and Restore

Using DAGs to configure a lagged, or point-in-time, copy of a database allows you to delay committing changes to the database for up to 14 days. Thus, you continuously maintain a database at the states it went through during the previous day or week. Therefore, if you have an issue with your current database, such as a rogue administrator or a script changing many items at once, you can revert to a lagged database copy and commit the transaction logs to a specific time that you decide.

Using lagged database copies, together with maintaining multiple database copies across more sites, means that organizations can consider reducing the amount of nightly backups. This is particularly true for medium-sized and large organizations because they generally have a more complex backup and restore infrastructure in place than small companies.

Evaluate the cost of your current backup infrastructure, including hardware, installation, and license costs, as well as the management cost associated with recovering data and maintaining the backups. Depending on your organization's backup requirements, a DAG environment together with Exchange 2010 features such as Single Item Recovery may provide lower total cost of ownership (TCO) than a traditional backup environment. If you can reduce the backup-to-tape dramatically this also would save you storage costs for the tapes for example.

1.3. Large Mailbox Considerations

Mailboxes that are more than 10 GB in size require a more flexible backup and restore method because the amount of data they contain is dramatically more than those with which Exchange Server administrators typically deal. The main concern here is always about how long it takes to recover a database. Even though the Exchange Server 2010 database structure handles large mailboxes better than previous versions, you should be aware of the additional data requirements for backup.

The amount of time it takes to restore a backup during disaster recovery skyrockets when you have large mailboxes. When you're planning to implement large mailboxes, consider using multiple database copies and using the Single Item Recovery feature for Exchange Server 2010 to recover data. These features provide you with options to move away from traditional backups.

1.4. Backup and Restore Requirements in a Highly Available Deployment

Even though it may appear that highly available deployments no longer require traditional backups, they may still be needed in your environment. You may want to use existing backup strategies that provide offsite data storage at secure locations, even if Exchange 2010 can provide additional offsite database copies. Sometimes backups also serve an archival purpose, and typically organizations use tape to preserve point-in-time data for extended periods, as mandated by compliance requirements.

Additionally, remember that integrating high-availability features as an alternative to backups only works for the mailbox database, not for other Exchange Server resources, such as the Hub Transport configuration. You still may need to consider using traditional backup for your Hub Transport servers.

2. Removal of ESE Streaming APIs for Backup and Restore

Previously, Exchange Server used Extensible Storage Engine (ESE) streaming backup APIs as well as the Volume Shadow-Copy Service (VSS) for Exchange-aware backup and restore. Now, Exchange Server 2010 supports only VSS-based backups. To back up and restore Exchange Server 2010, you must use an Exchange Server–aware application that supports the VSS writer, such as Windows Server Backup or Microsoft System Center Data Protection Manager or a third-party, Exchange-aware, VSS-based application.

3. Storage Group Removal

One significant change in Exchange Server 2010 is the removal of storage groups. In Exchange Server 2010, each database is associated with a single log stream as represented by a series of 1-MB log files. Each Mailbox server with an Enterprise Server license can host up to 100 active or mounted database copies, and with a Standard Server license can host up to five active database copies. Passive database copies and recovery databases are not included in this per-server limit as you are able to create up to 257 databases per server.

4. Database Not Tied to a Specific Mailbox Server

Another significant change for Exchange Server 2010 is that databases are not tied to a specific Mailbox server. Database mobility expands the system's use of continuous replication by replicating a database to multiple servers. This provides better database protection and increases availability. If failures occur, the other servers with database copies can mount the database.

5. Using DAGs to Eliminate Traditional Point-in-Time Backups

Because you can have multiple database copies hosted on multiple servers in a DAG, you can also consider eliminating traditional point-in-time backups from your organization and turning on circular logging on your databases. This removes the transaction logs that are no longer required for any copies of the database, so they do not accumulate. Normally, transaction log files are removed when you do a full Exchange Server backup. Circular logging accomplishes the same task without doing a full backup.

  •  Programming Windows Azure : Using the SDK and Development Storage
  •  Programming Windows Azure : Building a Storage Client
  •  Working with the REST API
  •  Excel Programmer : Fix Misteakes
  •  Excel Programmer : Change Recorded Code
  •  Excel Programmer : Record and Read Code
  •  Configuring Server Roles in Windows 2008 : New Roles in 2008
  •  Windows Server 2003 : Creating and Configuring Application Directory Partitions
  •  Windows Server 2003 : Configuring Forest and Domain Functional Levels
  •  Windows Server 2003 : Installing and Configuring Domain Controllers
  •  Manage Server Core
  •  Configure Server Core Postinstallation
  •  Install Server Core
  •  Determine Your Need for Server Core
  •  Install Windows Server 2008
  •  Windows Server 2008 : Configure NAP
  •  Incorporate Server Core Changes in Windows Server 2008 R2
  •  Decide What Edition of Windows Server 2008 to Install
  •  Perform Other Pre-Installation Tasks
  •  Developing Windows Azure Services that Use SQL Azure
    Top 10
    Programming Hashing Algorithms (part 5) - Validating Hash Codes
    Exploring the T-SQL Enhancements in SQL Server 2005 : Common Table Expressions
    Windows Server 2008: Domain Name System and IPv6 - Understanding the Need for DNS
    The giant of Cambridgeshire (Part 1)
    Sharepoint 2007: Get Started with Your Personal Site
    Windows 7 : Searching Your Computer (part 2) - Search Filters
    Restoring SharePoint Using SharePoint Central Administration
    Protecting SharePoint with Advanced Antivirus and Edge Security Solutions : Securing SharePoint Sites Using Forefront UAG
    Choosing The Right Parts For Your Build (Part 6) - Picking the right RAM, Picking the right cooling, SLI and CrossFire
    SharePoint 2010 : Security - Claims Based Authentication
    Most View
    Manipulate File Paths
    The best music apps for your iOS Device (Part 3) - ITUNES U, VOXER
    Mobile Application Security : The Apple iPhone - Networking
    Logisys Dracula VGA Cooler
    HomePlug Buyer’s Guide (Part 1) - TP-Link TL-PA211KIT
    Building LOB Applications : Data Validation through Data Annotation
    Network Programming with Windows Sockets : In-Process Servers
    Windows 7 : Using Desktop Gadgets (part 3) - Using the Stock, Currency, Slide Show gadget
    Externalizing BLOB Storage in SharePoint 2010 (part 2) - Installing and Configuring RBS & Migrating and Moving BLOBs Between BLOB Stores
    SharePoint 2010 : Creating and Managing Workflows - Workflows in SharePoint 2010
    Microsoft SQL Server 2005 : Report Definition and Design (part 2) - Business Intelligence Development Studio
    Windows Server 2008 : Configure NAP
    Password Cracking
    Opening a Local File from a Silverlight Application
    Find It Online : Toodledo, CrashMyPad, Quora, RetailMeNot & Storify
    Synchronizing Mobile Data - Using Merge Replication (part 1) - Using Good Design to Avoid Synchronization Failures
    Automatic Windows Fixes (part 2)
    SharePoint 2010 : Security - Secure Store Service & Using SSS with BCS
    The Membership Data Store
    Windows 7 : Creating Backups and Preparing for Problems (part 1) - Configuring System Protection