2011-12-01 11:39 AM
I would like the ask the community for a little help in validating the SME layout that we have here and see if it makes sense. Please bear with me because this is a little difficult to explain.
We have a number of Exchange 2010 databases but for the sake of this exercise I will simplify it.
Suppose we have 2 Exchange 2010 database servers (A and B) in a DAG and a single database. Each server has access to data and logs LUNs in separate volumes and on separate filers. SME is configured to only backup the database on one of the servers (A).
Now, we want to archive the data to a third filer. SME is set up with access to a dataset on server A and when a backup runs on A it successfully archives the data according to the schedule.
That all works well - the problem results when the active copy of the database is moved to from server A to B. Not only is B not configured to take a backup, it is not configured to perform an archive copy either because there is no Snapvault relationship.
Server A --- volumes DATA-A and LOGS-A on FILER-1 (the primary copy, usually active)
Server B --- volumes DATA-B and LOGS-B on FILER-2 (the secondary copy, usually passive)
Snapvault relationship between DATA-A/LOGS-A and ARCHIVE-A on FILER-3
What is the typical scenario for maintaining a primary backup and an archive (Snapvault) relationship when the database is in a DAG and at any point in time either server could have the active copy of the database?
2011-12-01 12:01 PM
afaik there is no way to have this layout working in any way. The basic problem - a DAG does have the same content but the databaes don't have any relationship to each other.
The idea of a DAG is to have distinct copies which do work completly independent. You could or should have a backup on each side of the dag if you need to keep a complete history in case of a failover.
SME itself does have a functionality to create a copy backup on the passive side of a dag. just add the DAG itself as Exchange server in the console and schedule a backup on both nodes. The node with the active copy will run the job, the other one will just do nothing. but, the layout to have just one destination on a third filer and snapvault the data depending which one of the copies is active is just not possible. Snapvault does not have any idea of the data. for snapvault it's just two different source volumes.
hope this helps.
2011-12-01 12:21 PM
Well, I had pretty much come to the conclusion that it wasn't possible but wanted someone to verify that anyway.
Is the most sensible solution here just to run all of the backups on the primary filers and not bother with archiving/snapvault at all? Or perhaps have a 3rd server in the DAG that just does backups? I just don't know what to do for the best here...
2011-12-01 12:29 PM
the 3rd server doing backups would have the same problem as the other two before. the server doing backups failing would leave you with no backup at all - as long as this server is dead.
we had a customer doing backups on both of the primary nodes and no archiving at all. enough storage available this shouldn't be a problem and seemed to be the best solution.
2011-12-02 12:34 PM
Thanks for your insights. I'm looking into the available options. I have a ton more storage available on my snapvault secondary than I have on my primaries, with the intention of holding more backups on cheaper disks and on a cheaper controller and with next business day support instead of 4 hour. Running backup snapshots on a primary filer only seems to defeat the purpose. Shouldn't SME be capable of backing up the database you specify, whether it's active OR passive on a particular server?
2011-12-05 11:05 PM
Basically yes, in my particular expierence you need to modify the commandline the wizard is creating. Just remove the parameters for the database (telling the sme to discover all databases on the given server at time of running the job) and do not select anything about active / passive databases in the wizard window. you should end up with a commandline just containing the servername, cluster aware, some parameters around keeping logs or not but thats it.