E-mail, and more particularly Microsoft Exchange, is a classic example of how user adoption can turn an application mission critical before the IT guys catch on. Most IT departments protect Exchange servers with the same techniques they use to protect other applications. Replicate the data to another disk somewhere and have an idle Exchange server mount the database for failover. Rather than collect data at the file or block level, MailShadow collects Exchange objects at the transaction layer for replication. Working higher on the stack brings MailShadow some significant advantages.

The biggest advantage is not replicating database corruption the way disk replication can, especially as the production server crashes. Replicating transactions also means less data to replicate. Exchange writes every transaction at least twice, once in the transaction log and once in the .EDB file and a disk replicator has to send it each time. Disk replicators use a lot of bandwidth in the middle of the night when Exchange does an online database defragmentation.

Failover is faster than mounting a crash-consistent database since the target Exchange server is always running against it's own database. All MailShadow has to do is a little magic so the client stations will connect to the backup server. Source and target can be running different versions of Exchange. At least one customer has used this feature of MailShadow to migrate to a newer version of Exchange.