[Edited 12/12/2007 to correct KB/MB error in the log file sizes; thanks to Chris Scharff for catching it.]
Recently, I've seen a couple of pieces of misinformation about Exchange 2007 and DPM floating around in the ether. Rather than let them go uncontested, I figured I'd mention them here and give them the good puncturing they deserve:
- Exchange 2007's continuous replication features rely on backup and restores. Um, wow. This is so wrong I can't even begin to figure out what mistake in understanding brought this one about. The continuous replication options (LCR, CCR, and SCR) rely on log shipping -- the process of taking the transaction logs from one copy of the protected mailbox database and sending them to another copy. Here's the key thing: this process is not backup and restore. True, copying outstanding transaction logs is a necessary part of an Exchange backup strategy, but an Exchange backup is also taking copies of the mailbox database files directly. Remember how Exchange uses transaction logs:
- A write operation is generated by Exchange, such as when a new message is placed in a mailbox or a client makes an update to a message property.
- The operation is written sequentially to the next open transaction log file (these files are always 5MB in size in Exchange 2000/2003, 1MB in size in Exchange 2007). Note that this sequential write is performed to increase disk performance.
- The write operation is marked as complete and Exchange moves on to the next operation. It has not, however, yet been written to the database!
- At some later time, Exchange takes the queued-up write operations and applies them, in order, to the actual mailbox database. This is a random write operation, which in turn requires more seek operations (and is slower), so Exchange tries to make this happen when there's less I/O on the database.
- Continuous replication options don't protect against database corruption. Again, no. If you take a look at the process I just talked about for the previous point, you should see why this second myth is also false. Each I/O operation is written to the transaction log first, then applied to the database at a later point in time. If you ship the transaction log files to a second replica, that replica is recreating its own copy of the database. It's not a bit-for-bit copy of the source Exchange database; it's an independent re-creation. The particular hardware and load conditions that contribute to any given database corruption on the source database don't exist on the target database.
- DPM doesn't do block-level copies; it's just copying Exchange data as a file copy. Well, this is true if you're using DPM 2006; it doesn't have native support for Exchange, so you first have to use something like NTBackup to dump the database to a file on disk, which DPM 2006 can then protect.
In DPM 2007, however, this all changes -- you now have native Exchange support. Not only will DPM 2007 do direct copies of your Exchange databases at the disk block level, ensuring that only the blocks that have changed are synchronized, but it also watches the transaction logs and copies them to. DPM essentially keeps another replica of your protected databases in its storage pool, which means you have a restore granularity unmatched by conventional backup programs.
Now that Exchange 2007 SP1 is here, more and more people will be deploying Exchange 2007. That means more opportunities for vendors, consultants, and competitors to attempt to spread FUD and sell you on their product. Don't fall for these myths and be fooled into paying for something you already get with Exchange and DPM.
What myths have you heard? I'd love to hear them and address them in later posts!