NetApp Snapshots & Exchange 2010 -Which Copy?

A vendor-and-partner email conversation with Devin Ganger (http://www.thecabal.org/) in his role as Exchange Grand Poobah at Trace3 (http://www.trace3.com/) about Snapshots brought a few things to light. He has a customer who wants to take backups of the active Exchange 2010 database and then spool the data off, using NetBackup (NBU) to DataDomain. Well, that's as simple as falling off a log. SME to snap the stores, FlexClone the snap, mount it to the NetBackup server, drag the data off and then destroy the FlexClone. Done and done. Everyone home in time for Vimto and NAAFI sandwiches.

Not so fast. What happens if the active copy changes from node1 to node2? No problem. SME gives you three options. (1) backup the stores on a specific server. (2) backup the active or passive copies. (3) backup a specific activation preference. So in this particular case you use SME to connect to the DAG rather than the node which brings up a screen with those three options. Specify the active and walk the rest of the way through the wizard. What SME does is create a job on all the servers in the DAG that have a copy of the stores you selected.

That's all very easy but Devin had some extra requirements. He wanted to verify the snapshot and get it to the DD box with NBU. There are a few ways to achieve this. SME has an after-process capability to kick off something else such as an alert to some other system or, as in this case, telling a different server to do something. In this case SME will run the snap and its last act will be to instruct the verification server to kick off the scheduled verification task of the most recent snapshot. That's going to do its thing and then the 2nd to last act of that job, before it tears down the FlexClone is to stream the flat file that constitutes the snapshot off to DD.

It's true there are quite a few steps in that process but they can be integrated if you want or left isolated. None of it is rocket science and it's all PowerShell or SDCLI both of which are readable in pretty much plain English.

What I didn't point out but possibly should have done is the extra IO that's being generated. It might not matter because there may be plenty of spindles in the aggregate to handle the load, especially if the customer is using legacy FC disks following an upgrade from (say) 2003 and the disks are still in support but the verification is going to consume disk IO and the transfer to DD is going to prolong it. Unless you have a business requirement it might be a better idea to snap the passive or a particular preference and then to the verification and transfer on the passive or another copy attached to a different aggregate.