In my first post on Commvault, I provided an overview of the platform. In this post, I will cover what Commvault can do for Exchange Server databases, at a high level.

Reducing and protecting data in Exchange Server

With the basics of Commvault covered previously, let’s dig into some details about support for Microsoft Exchange. Within an Exchange DAG, mailbox databases can be replicated across multiple servers to provide high availability. The preferred architecture for Exchange calls for the usage of commodity servers and storage, including JBOD. What I have found, is that most large organization virtualize Exchange and store databases on a SAN still. Many large organizations have invested heavily in virtualization and SAN solutions and have optimized processes around them. They have become comfortable with these technologies and most workloads are pushed to use them, even if it doesn’t make for the most architecturally efficient design. In these orgs, reducing data via deletion and\or stubbing from can provide key value them.

A common requirement is to have a second\backup copy of data that is off-application, at different locations, and/or on different storage platforms to protect against logical corruption, catastrophic loss, vendor lock-in, administrator accidents, malicious actions, malware, and more.

Protecting databases

For data protection, which include database and individual items in Exchange, CV has VERY extensive support. For example, CV is DAG aware, so you can setup a policy so certain or all databases are always backed up from a passive copy, including support to fallback to the active copy if all passive copies are unavailable. If a SAN is used, CV can backup the databases directly from it, in an application consistent way, leveraging the SAN’s hardware snapshot technology. This is done by using the VSS calls, to ensure the databases have been quiesced correctly. Once CV gets the confirmation that the VSS call was successful, the LUN that the database(s) are on are snapped on the SAN, via the native APIs. In most cases, these LUNs are then mounted directly on a CV server and the databases are deduped against the previous data from early backups and the new unique data is sent to the CV configured storage, based on the storage policy. Using this method, databases are not streamed directly from production disk over the network from the Exchange Server to the target media. This means the backup I/O doesn’t impact the servers or users. Even if Exchange is running on a non-supported SAN or DAS, a VSS based streaming backup can be utilized.

From the backup copies, which can include the existing snapshots on the SAN, the databases can be restored back to their original location, to recovery databases, or directly to the file system. Database backups can even be browsed so individual items or entire mailboxes can be restored\exported.

In my next post, will cover what Commvault does for Exchange Server and Exchange Online for item and message level data management.

Posts in this series:
1st post: Using Commvault, by an Exchange MVP 
2nd post: Using Commvault for Exchange Server (This post)
3rd post: Using Commvault for Exchange & Exchange Online for Items

Disclaimer: Views expressed in this post are solely the author’s and don’t represent the views of Commvault.