Near loss-less data protection for Microsoft Exchange

First a little bit about me. I've been working with Microsoft Exchange since Exchange 4.0 in 1996. I've spent a number of years architecting, administrating and teaching others the various facets of the product. Moreover, I spent considerable time with the directory changes in Microsoft Exchange 2000 when it switched to Active Directory.

One key area that hasn't had much attention within Exchange is recovery databases, logfiles and the issues related to tools like eseutil, isinteg, and the volume shadow service in the Windows operating system.  Since 1996, when Exchange 4.0 was released, there have been only a few changes to the Extensible Storage Engine (ESE). The primary issue in 1997 was consistent databases, log files and data recovery. 

In 2007, Microsoft addressed this issue by including a major change in Exchange 2007 which I had the chance to review earlier this year. Their fix was to ship the product with Lost Log Resiliency (LLR) enabled. By default, LLR allows a database to be considered consistent and mount if a maximum of 6 log files are lost (that's six megabytes of data per store that can be lost).

Six megabytes doesn't seem like, much, but that's per storage group and it doesn't directly address consistency - it just addresses log file tolerance to ensure consistency. InMage Systems DR Scout recovery for Microsoft Exchange goes several steps beyond the LLR function with Microsoft Exchange 2007. In particular, it provides continuous protection of Exchange log and data files across passive backup systems and geographies. The details of the product can be found in a whitepaper titled The Move to Push Button Business Continuity.

I interviewed David Self at InMage Systems, who is the VP of Systems Engineering. I would classify David as an Exchange expert, being an ex-Aelita/Quest employee and who has seen a fair share of changes in Exchange and Active Directory.

In my conversation with David, I learned that InMage Systems' DR-Scout uses Volume Shadow Copy Service (VSS) APIs to set the database as consistent. What's unique about this mechanism is that it forces Exchange to flush the log files into the databases and mark the database as "consistent".

Anyone who has had issues with Exchange database consistency and ESEUTIL understands and can explain why consistent databases are critical to any recovery. Moreover, Microsoft's introduction of LLR in Exchange 2007 further confirms the lengths they will go to reduce recovery woes and ensure consistent databases in your Exchange environment.

InMage Systems goes beyond Exchange 2007 and supports Microsoft Exchange 2003.  This gives rise to a database consistency AND resiliency option for Microsoft Exchange 2003, in light of no LLR support.

The thought of a known-good consistent database every fifteen minutes with disk based recovery for Exchange is exciting.  If I were supporting Microsoft Exchange 2003 or 2007 it would be a slam dunk to use InMage's product to solve Exchange system and data resiliency.  I wouldn't think twice about replacing my existing backup solution with InMage, simply to have a consistent database and a near real-time recovery.