Like most, I’ve been coming to terms with the storage performance requirements (or, lack thereof) in Exchange 2010.
For any previous Exchange deployment (certainly 2003) you’d start with a SAN and use features like snapping to ensure you can backup without affecting performance.
To my mind SANs remain stubbornly expensive for what’s actually delivered (I was just quoted over £3500 for a single 15K 600GB SAS disk which is certified to run in a SAN!).
So the fact I really don’t need one for Exchange 2010 is perfect.
But how do I back up?
Microsoft will tell you they don’t back up at all, just rely on the native protection and deleted items retention.
I’m a little – just a little- less gung-ho than that and I suspect many of my customers are, too.
There’s very little product choice on the market, or indeed much Microsoft collateral about how to backup Exchange 2010, so I thought I’d take a stab at a possible solution myself!
- Don’t “waste” the genuine data protection tools native to Exchange 2010
- Prepare for the day when an exchange corruption is replicated to ALL databases (however impossible that might be)
- Provide a longer-term archive.
Consider the following environment:
We’ve got a single DAG with four copies of every database. Let’s say for argument sake we’ve got 5000 users with a 1GB mailbox. Of course, our disks are directly attached and we’re using nice-and-cheap SATA storage on JBOD. Let’s use 1TB because smaller disks are beer money less.
So far, so good, so like every other Exchange 2010 design piece. We’re leveraging the native protection and we’ve got four copies of the data.
But how to protect against the replicated corruption scenario?
I’m using another new feature of Exchange 2010; lagged replication. So this server in question is always behind the other servers; in theory then should the “replicated corruption” scenario occur, we can take action before it plays into our time delayed mailbox server.
But how long? Too short a delay and the corruption might get missed and played into the lagged database anyway Too long and and invocation of the lagged server might risk losing mail.
My best-guess figure was about 24 hours; this is comparable to a normal restore if we don’t have logfiles.
Now, observant types will have noticed there’s extra disk arrays attached to the lagged mailbox server. To break with custom, these will be RAID5 and their purpose is to act as a file share area to perform backup-to-disk operations. I’m doing disk-to-disk backups because:
I can, at very little infrastructure cost
Having recent backups online is always useful.
At the time of writing, the choice of backup products is underwhelming so I’m going to use the built-in tool. The real downside to this is that I can only backup from the active node, thus I need to be real careful about what I’m backing up, when. Pumping the data across the network in good time might be tricky without the right network setup.
Most likely, one or two databases will get backed up every night with all databases having at least an incremental backup
Now to the final part of the plan; the long-term archive. Hopefully never needed, but your operation might need to keep archives of data (this, probably isn’t the solution for this, you need to check out other new exchange features). But it’s most likely needed when the CEO needs an email he deleted 12 months ago.
Backup-to-tape is therefore meets my need. I’m only going to backup to tape the files produced by the disk-to-disk backup process, and I’m going to choose my timings wisely.
So there-we-have-it. A fairly robust backup architecture? I’m hoping as time progresses and products fill the void (like DPM2010) this solution will look archaic, but for now it’s my best shot at what backup could look like.