Lagged Exchange 2010 Databases - Just Say No

It's time to put some recently risen silliness to rest. When Exchange 2010 was fresh out of the box only the most experienced administrators were on the case and not a single one of them in nearly a year brought up the topic of whether they should lag an Exchange 2010 database copy their NetApp storage. They all saw that there was just no point to it and the storage platform could handle things so much better. That relatively pain-free honeymoon didn't last.

But now Service Pack 1 is in the wild the product is getting the attention of the next tier of Exchange IT professionals and it's time to answer the question on why there is no point to a lagged database copy. There have been three instances lately where the customer has stated to the Microsoft (employee) consultant that the upgrade WILL be done to NetApp storage and for that to be a central part of the planning..... So, why on earth do they still shove the lagged copy down customer's throats? They simply have no idea about the storage because they think their job is just to make the application work. Well, what is it that the Microsoft people don't get?

Two things; Snapshots and 'frequent recovery points'. Available on all storage platforms to a greater or lesser degree and by various names.....

Background. You can lag an Exchange 2010 database so that it can be as far as a fortnight out of date so long as it has all of the logs to play itself up to date. If it doesn't have the logs you will find that there is another server with the logs that the lagged copy needs. Leaving the incoming logistics aside the bottom line is that the lagged copy has a shed load of logs sat on it, waiting to be played into the store as and when instructed.

When you decide that it's all gone Pete Tong and you need to activate your lagged copy there is going to be a short period of time to wait before you're up and running. Not so bad really.

But hold on. What if you had a competent Shapshot enabled storage solution? Would you need the lag? If you were taking snaps of the stores every hour, four hours whatever, and were taking snaps of the logs every 5, 10, 15 minutes or so in between.

So what, I want my Lag. It is the one with the bigger, err, GBs. Cos Microsoft told me so. Well, no, not so much really.

A ton of logs on a given server takes up a lot of space. It is an inherent risk. If you follow the guidelines from Microsoft you're not going to back anything up in your Exchange environment so those logs are all that stand between you and a P45/pink slip when the Visigoths are sighted.

The other thing is that, usually, that copy is going to be copy four rather than three so you're inherently adding 25+n% more storage than you really needed.

And as if that wasn't enough you can only restore to the last log file unless you roll up the sleeves and get activating... I've never been one for shying away from the command line but if someone has gone to all the trouble of coming up with a GUI that does it for you and that GUI manages exactly when you want the database to abandon playing logs and mount, you should probably pay them the compliment and use it.

Our customers get to save themselves the extra storage and they get to have a GUI that takes snapshots, does database restores, does zero-space clones to test whether the thing you think want to restore is indeed the thing you need to restore and does that restore for you to the point in time you have told it to.

All very cunning really and very space efficient. Map that with my previous post and the thing that Microsoft tell you is going to take 400+GB for every 100GB of email is changed. Now you've just got yourself a multiple copy solution for Exchange that takes about 100GB per site for every 100GB of email.

Oh but, oohhhhh, ahhhh, noooo, SAN bad. SAN expensive. SAN complex. Backups bad. Whatever guys.