How To prioritize backups for virtualized Exchange 2010 servers

xchange Server 2010 includes a variety of policies throughout its infrastructure that limit and control storage. Sent and received message sizes can be limited; individual mailbox sizes can be limited. You can even limit mail and attachments coming from outside an Exchange organization.

Database backup and restore is another reason why controlling mailbox size is important to the health of your Exchange Server 2010 organization. As your databases grow, so does the amount of time you need for backup or restore, as well as any related task.

Exchange admins often focus more on the backup half of backup and restore. Yes, ensuring good backups is important; however, IT pros often spend too much time watching backups to complete and waste too much effort complaining that this process takes too long.

These activities are important for preserving data, but the most important metric actually has less to do with the time required to back up data than the time required to restore it. Restore time greatly factors into backups in a virtualized Exchange environment. This is especially true with Exchange 2010’s specialized databases.

Backups for your virtualized Exchange 2010 servers can live in several places:

1. On the mailbox server — From the mailbox server, backups occur much like traditional backups in a physical environment, offloading data to tape file-by-file. This process ensures that Exchange Server’s databases pause correctly so that they back up without data corruption. One problem you may run into is that agents installed here tend to put a strain on virtual environment performance during operation.

2. On the virtual host – From this location, the .VHD or .VMDK file becomes the backup unit. Here the backup agent must interact with another agent inside the VM to ensure the successful quiescence of Exchange’s databases. VHD and .VMDK backups are famous for simple point-in-time restore of entire VMs or databases. However, retrieving a single email or lost mailbox might require you to restore an entire database first, which can significantly increase restore time.
3. Servers outside the virtual environment — Encapsulating Exchange 2010 mailbox databases into .VHD or .VMDK files may create enormous files on disk, particularly when multiple databases are contained within a single disk volume. Configuring data partitions as raw disk mappings (RDMs), pass-through disks, or iSCSI connections keeps mailbox databases in a more raw format. With the correct tools, these files can be backed up directly from storage LUNs. The obvious concerns about proper database quiescence remain here.
4. On a"Backup 2.0" solution — These solutions gather backups through a file system filter driver located on the virtual host. Backup data is then deposited onto disk rather than tape. This approach reduces the storage requirements of backup while providing fast entire-server, entire-database or even single-item restore. While this is a relatively new approach, product options in this space are growing quickly. With this approach you may need to completely rethink — and potentially repurchase — your backup solution.

Unfortunately, none of these options completely solves the problem without additional cost, effort or performance degradation. To avoid making backup and restore mistakes when virtualizing Exchange, take a long look at what types of restores are important to you and how quickly you need those restores to complete.

For example, if entire database restorability is more important than restoring individual items in Exchange 2010, placing backups on virtual hosts or on servers outside your virtual environment (options two and three above) are your best bets.

Some businesses have decided that individual item restores are not an option. These environments prefer to designate more time before permanently removing deleted items. This prioritization is also useful for journaling and archive databases, where the preservation of all data is more important than individual item restorability.

Other Exchange organizations find that restoring individual email messages, mailboxes or calendar items is just as critical as protecting an entire Exchange database. Placing backups on your mailbox server or a backup 2.0 solution (options one and four above) provide the necessary functionality for these environments. Backups residing on the mail server leverage the tried-and-true interfaces of traditional backup solutions. A backup 2.0 solution trades those interfaces for added flexibility of what is being backed up.