Why does DPM use the Recovery Storage Group in Exchange?

Microsoft

Feb 15, 2019

First published on TECHNET on Jun 05, 2008

One of the more common questions that we hear from DPM customers is around the DPM dependency on the Exchange RSG, while other backup technologies do not require it.

How Microsoft customers were protecting Exchange previously

When Microsoft looked at how customers were protecting Windows applications today, we found two troubling scenarios:

1. Most customers were using one or more technologies for traditional nightly tape backup , particularly within heterogeneous environments. In addition, many were using or considering the use of different technologies for disk-to-disk replication , often per workload. And some were also using a third type of storage technology for long-distance synchronization for disaster recovery or business continuity solutions. Often the mix of these solutions from various vendors created their own supportability issues, based on interoperability as well as multiple management tools and monitoring views.

2. Many customers expressed frustration over a support gap between protection/recovery solutions and the workloads themselves. We have often heard customers and partners complain that while their backup software reported successful backups and their recoveries reported complete, when they attempt to bring the data online, they either can’t or discover corruption.

· Calling the backup vendor, they are told that it must be the application.

· Calling Microsoft support, we provide best effort support but sometimes surmise that the data was not backed-up or restored properly.

There isn’t necessarily fault here, just the reality of multiple vendors with multiple approaches to solving the problem.

DPM 2007 was designed with these two scenarios in mind:

1. To provide a consistent and unified disk-to-disk-to-tape experience, that included near-continuous protection, routine tape backup and disaster recovery long-distance replication within a single protection product .

2. Provide the best possible backup and recovery solution that assured not only reliability, but also supportability.

Strategic Choices for how DPM does what it does

To do this, we did make some strategic choices. Because there were already several heterogeneous backup technologies that many customers believe fall short around complex Windows server application deployments – we chose to focus on the workloads that we are committed to, namely the Microsoft platforms and products: Windows Server, SQL Server, Exchange Server, SharePoint products and technologies, and our virtualization environments.

The other strong commitment we made was to use only the backup and recovery methods that are wholly supported by the product teams of the workloads we are protecting:

To protect data, we rely on the Volume Shadowcopy Services capabilities that Microsoft has been providing since Windows Server 2003 and the application servers of that timeframe. Almost every DPM protected workload uses a VSS writer that is provided by that product team, or other backup mechanism provided by the workload itself, as the best known and most supported way to secure that information -- as it was intended from those who know the inner-workings of the application itself. These are not hidden mechanisms or secret calls - they are well published as the intended mechanisms provided by the application as the intended way to back them up. But many legacy protection products choose to use other methods.

To restore data, we comply with the restoration capabilities and architecture of the application. In the case of Exchange, that means using the Recovery Storage Group – and specifically restoring the database into the RSG, and then using Exchange tools to selectively restore more granular objects. In the case of SharePoint, we use the ‘Recovery Farm’ capability that the SharePoint team developed for that purpose. In each case, our restore capability is tied to the functionality provided by that platform. Each protected workload has its own restore capabilities, and DPM is specifically designed to leverage them. Again, these mechanisms are well published, but not followed by some legacy protection products.

Supportability for Exchange protection solutions

While we are aware that there are some other backup products which offer a restore experience that is perceived as more integrated or transparent, this experience is made possible by reverse engineering the Exchange database and the use of other processes which are not supportable by the Exchange team. These approaches create a risk of database corruption in your Exchange installation and limits the Exchange team’s ability to fully support that installation should you encounter problems later.

Even before DPM was released, Microsoft saw significant issues with some backup technologies that tried to synthesize Exchange information stores to selectively restore data – and then push it directly back into the production database. This sometimes resulted in latent corruption that was only later discovered. The Exchange team published a number of KB articles detailing these risks and the associated support limitations they create , including:

KB 904845 addresses “ Microsoft support policy for third-party products that modify or extract Exchange database contents ”

Similarly, for disk-to-disk replication mechanisms, KB 895847 addresses “ Multi-site data replication support for Exchange Server ”

What is the future of Mailbox Recovery?

Looking towards the future, we are actively working with the application product teams to help them create innovative solutions that include restore capabilities that are either more direct (instead of the RSG/Recovery Farm), more granular (mailbox/message), or perhaps simply more transparent – but which are also fully supported – at which point, DPM will most happily deliver on that experience. We are making progress in that front. But innovation takes time.

In the near term, we have identified select partners that have been able to enhance the DPM backup capability with a more granular recovery mechanism, but in a way that is understood and approved of by the application product teams – e.g. Quest Recovery Manager for Exchange , enabling mailbox & message level restoration from the DPM restored replica. Details can be found on their site .

Finally, we also wanted to address some inaccuracies in the DPM Whitepaper on “How to Protect Exchange with DPM 2007” . The initial release inadvertently glossed over some of the details and did not reflect the full capabilities and processes for mailbox recovery correctly. When we learned that the paper was not providing clear guidance from some Exchange community folks and DPM customers, we immediately pulled the paper to correct it. We worked with the DPM engineering team as well as an Exchange MVP writer to provide better guidance, and it was re-posted last week at http://go.microsoft.com/fwlink/?LinkId=92497 .

We hope this clarifies why DPM does what it does around Exchange protection to ensure that our customers have not only a great backup solution that protects Exchange in the manner that the Exchange developers believe that it should -- leveraging its VSS writer for fast block-based synchronization along with log backups, with additional benefits like offloading ESEUTIL and providing flexible protection options for CCR environments -- but also a strong and flexible recovery solution that allows for storage group, database and yes, mailbox, recovery in a way that is wholly supported and sustainable.