Managing and protecting all enterprise data


News Stay informed about the latest enterprise technology news and product updates.

Rough going for Exchange replication

Replicating databases for disaster recovery isn't easy, and Microsoft Exchange is no exception.

As more users rely on remote replication as the cornerstone of their disaster recovery (DR) procedures, it's becoming clear that replication and database optimization don't always go hand in hand, particularly when it comes to Microsoft Exchange.

To reclaim unused space, users must take Exchange databases offline for defragmentation and compaction. Further complications arise in a replication scenario when database changes must be mirrored remotely, which increases traffic. So far, replication vendors can't offer clear remedies.

More on storage backup and replication
NetApp to acquire Topio
BlackBerrys suck juice out of Exchange storage  

Universities lean on each other for better disaster recovery  

Remote data replication gets affordable and more robust
"From what I've seen, it's across the board," said Bob Roudebush, director of solutions engineering at Double-Take Software. "It's not particular to a specific solution or a type of replication technology."

To get around this, some companies are splitting up their archive and replication processes. For example, putting mailboxes that must be archived on other Exchange servers separate from those marked for replication, according to Brian Babineau, an analyst at the Enterprise Strategy Group. "This is a piecemeal solution," Babineau said. "It's still, fundamentally, a problem that hasn't been solved."

Double-Take offers an alternative by letting users disconnect replication. If the database must be taken offline, replication can be reconnected after defragmentation and other database maintenance takes place. Double-Take will then remirror the data using a block checksum comparison and transmit only the blocks that have changed.

Microsoft is recommending its Cluster Continuous Replication (CCR), a new feature in Exchange 2007, which will ship by year's end. Using log shipping technology, CCR allows an active node in a Windows Server 2003 Cluster to replicate to a passive node in the same cluster, which can be geographically distant. Instead of performing offline defragmentation, Scott Schnoll, technical writing lead for Exchange user education at Microsoft, suggested using Exchange's Move Mailbox feature. This feature creates an empty database and the old database can be deleted once all mailboxes are moved into the new one. The clean database is then replicated remotely.

"As new data is added from the Move Mailbox operation, it's all being written in contiguous blocks," Schnoll said. "The interruption in service is only while each individual's mailbox is being moved." He added that this online operation can be scheduled.

None of these solutions offers complete satisfaction, particularly for very large enterprise environments. One user, a senior systems engineer at an international communications company, is in the midst of implementing a disaster recovery plan for 43,000 Exchange users worldwide with approximately 13 terabytes (TB) of data. As he sees it, the ideal solution for keeping database copies clean would be for a vendor to create its own Exchange defragmentation engine that could run at the primary and disaster recovery sites simultaneously. "But that would definitely make Microsoft really unhappy," he said.

Article 7 of 15

Dig Deeper on Database storage

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

Get More Storage

Access to all of our back issues View All