In a CCR environment how do you always make sure backups occur on a specific node? The reason why I am asking this is because I want SnapMirrors to always occur on the volumes allocated to the Passive node. If the Passive node's role changes to active then backups will occur on a node in which Snapmirror is not setup on and backups will be missed when snapmirror is ran. Can SME be confiugred to do this?
You definitely can choose to backup a single member of an Exchange CCR, or even both if you wanted to.
I encourage you to review and read through the Admin Guide, so you can feel comfortable with the configuration as you'll apply it - and also to reference any design and layout best practices to ensure you have the best supported and operational configuration.
Here is a caption taken from the Admin Guide for SME 4.0 (and SME 5.0)
Note If you do not select the backup advanced option "Create a copy database on another CCR node along with current backup", then you only backup the CCR node that you are connected to, which is either an active or a passive node.
Note You cannot connect to the active and passive nodes at the same time and perform backup operations on both the nodes simultaneously.
What you explained below is definitely correct if you manually perform a backup on the Passive Node however, if you schedule a backup on the passive node, there is a Parameter that says -CCRActive Node $False. If the Passive node ever became the active node due to some task then the backups will not be done on the proper node... So, is SME capable of doing what I am explaining?
Re: How to make Exchange backups occur on a specific node in a CCR cluster?
I'd love to better understand the context and concerns you have in your particular configuration.
On the surface the static configuration of -CCRActive $True or $False is exactly that - a static reference to the state of the CCR node.
In some configurations you will see SME loaded on both nodes of the CCR - Where, it will reference to only perform this operation on the Passive node.
Given how you described your situation, It looks like only a single node (Passive?) is the only resource which has that capability to support this operation?
If I were in that situation, with a typically Passive host configured to perform these operations (staticly in the script) and wanted to ensure continual backups in the event of the promotion of my Passive node to Active, I would either have a secondary script (effectively the same with "-CCRActive $True", or some logic in the operation to check the host machine and have it flip in the event I would need to execute on that operation.
I will further test out this configuration in my lab when I have the opportunity, but on paper - it looks as though kicking off the operation should fail based upon the configuration of that particular True/False - as it should in a Prod environment to ensure that only a finite operation can occur during a finite circumstance.
Kita, this is something I'd be happy to discuss further so we can try to identify what might be the best method of operation to ensure that the environment is protected, and all circumstances accounted for in operation.
Let me know if I can be of further assistance on things
Included is the syntax for Clusteraware, with comments in italics/underlined.
This flag assumes significance only when scheduling jobs in cluster configurations. This flag will facilitate scheduling the same job in multiple cluster nodes to improve fault tolerance.
In the case of Single Copy Cluster, if a job is scheduled with -Clusteraware flag, the job will run only if the host in which it is scheduled is the active node of the cluster.
In the case of Cluster Continuous Replica, the -clusteraware is processed with the context of -CCRActive $True or $False parameter.
If a job is scheduled with -Clusteraware flag, the job will run only: (This speaks of a finite reference to will or will not)
If the host in which the job is scheduled is a CCR active node and if the job targets the active node using -CCRActiveNode $True.
If the host in which the job is scheduled is a CCR passive node and if the job targets the passive node using -CCRActiveNode $False.