One of the ugly secrets of Microsoft Exchange Server 2010 is that at its core it uses an ancient ISAM database technology that is relatively easily corrupted.  Microsoft makes some great tools, as do others, to detect and correct this corruption.  The trick here is that you have to actually use the tools.  Many IT administrators do so religiously; however, quite a few are so busy that they just hope that the problem takes care of itself.  What does this have to do with backup?

At Unitrends, we recently switched from the old streaming backup technique for Exchange backups to the VSS method (it was about time!)  Our customers have been almost unanimous in their praise of the new Exchange agent – with a few exceptions.  The few exceptions are entirely focused on the fact that the new Exchange backup agent automatically does integrity checking of the Exchange database (the EDB.)  This integrity checking, if it fails, causes the Exchange database to go into a state where it may be repaired.

A few customers have given us the feedback that they’d like to be able to backup Exchange “the way it used to work.”  We actually can do that; we have the older agent that our current customers were using.  We’re a customer-focused company – and so we’ll do what the customer wants.  But it leaves our customer-facing people in the position of having to explain – awkwardly – that trying to recover a corrupted database may be a bit – ahem – problematic.  (That’s a nice way of saying  recovery will be a crapshoot.)

For our new customers, this isn’t a problem – when first setting up their backup appliance they simply run the necessary tools to fix the corruption if it is discovered.  Once again, what we discovered is that when you have a large installed base (1500+ customers and growing fast!) that you have to be extraordinarily careful in thinking through the ramifications of features – even those features that are improvements – and carefully communicating that information.