Several storage vendors have been touting advanced disaster-recovery solutions aimed at Microsoft Exchange Server deployments—solutions that use snapshot, clone, and data replication technologies. I've discussed this topic before, but recent and upcoming developments make the subject worth revisiting.
First, I must remind you that Microsoft supports only one disaster-recovery practice for Exchange Server—online API-based backups. The company has done a great deal of work on the APIs that Exchange Server's Extensible Storage Engine (ESE)—the database engine behind the Exchange Store—exposes. These online APIs are the starting point for Exchange Server disaster recovery, but where do you look for the next level of disaster recovery?
Many vendors have invested heavily in developing advanced disaster-recovery solutions for Exchange Server. Vendors such as EMC (TimeFinder and Synchronous Remote Data Facility), Network Appliance (SnapManager), and Compaq (Enterprise Volume Manager and Data Replication Manager) have customized their hardware and software to provide specialized solutions that enhance your ability to recover the Exchange Store in the event of data loss or power outages. These solutions use various mechanisms to provide redundant volumes of Exchange Server data. Clone and snapshot solutions (e.g., TimeFinder, Enterprise Volume Manager, SnapManager) create copies of the volumes in which Exchange Stores reside to provide a data backup that you can use as a recovery point. Data replication solutions (e.g., Synchronous Remote Data Facility, Data Replication Manager) work in a similar fashion to create remote clones (which can reside locally or remotely) of Exchange Server data. These products all operate on similar concepts, and the differences between vendors are small enough to interest only true propeller-heads. All these technologies let you recover your Exchange Server data faster than you can when you use Exchange Server's APIs and traditional tape-based backups. If you plan to implement such solutions for your Exchange Server deployments, keep in mind that each solution will require significant effort by you or the vendor to customize the solution to your needs. Also remember that Microsoft doesn't officially support these products, so treat them as complementary to solid online API-based disaster-recovery practices for Exchange Server.
What does the future hold for these advanced disaster-recovery solutions? Microsoft has finally realized that customers want these types of solutions for their Exchange Server deployments. .NET Server will include a subsystem called Volume Snapshot Services (VSS), which will let storage vendors use a mechanism called a provider to plug in snapshot, clone, and data replication solutions to the OS-based services. And application vendors (including Exchange Server and SQL Server vendors) will be able to implement VSS packages, called writers, that enable VSS use for applications. These developments change the disaster-recovery landscape substantially: Microsoft will finally support third-party advanced disaster-recovery solutions, and application vendors and vendors of these advanced disaster-recovery solutions simply will need to implement solutions according to the VSS specification.
In a future Exchange Server release, Microsoft will provide an Exchange Store writer for VSS that will let Exchange Server support these disaster-recovery solutions. When the vendor, Exchange Server, and VSS pieces are all in place (probably this time next year), you'll be able to leverage your favorite vendor's solution (as long as the company has developed a VSS provider) with Exchange Server. You can then use that solution to provide a redundant copy of your Exchange Server data from which you can recover your Exchange Store or mailbox. With Microsoft's long overdue support a near reality, I look forward to test-driving these advanced disaster-recovery offerings. For more information on .NET Server's VSS, see the technical overview.
