I've been using SnapManager products for a few years in many different systems but we are currently moving to SQL AlwaysOn groups for our SQL environment. The documentation from NetApp on this topic seems very limited and I'm struggling to understand how it all hangs together in a SQL AlwaysOn environment.
I have a number of questions, if anyone can shed some light it would be really useful.
We currently have a 2 node AlwaysOn cluster with a single availability group. I am wanting to offload all the backup workload to the secondary node. I've installed SnapDrve and SnapManager for SQL and configured as best I can with the available information.
I've successfully run a back up and restore so that all good. Now the issues...
- If I failover the primary to secondary the backups fail, I am assuming because the group ownership has changed? there is no additional information in the logs to suggest what the problem is.
If that is the case then how do I ensure that backup's continue independent of where there are? I can install SnapManager on all the nodes but this won't fix things as the databases will still move around and backup that are associated with groups will fail......or am I incorrect.
On the outset it looks like there is no intelligence in SnapManager to know which node the AlwaysOn group is on?
Any advice on how I can ensure that backups aren't affected by failovers would be greatly appreciated.
I have a 4 node SQL 2012 environment with over 2,000 DBs and all SQL instance AO/AGs replicate to one of the nodes which is marked as 2ndary for all. All backups are taken on this 2ndary server. We generally only failover to the 2ndary for maintenance/updates on the primarys or if there is an outage on a primary. I took over this environment a few months ago and I have to say I haven't tested whether I can perform backups while an AG is failed over to the 2ndary. Are your AGs set to Synchronous Commit - Availability Mode and are they set as Readable Secondary?
I realize the original post is a year old and perhaps you opened up a support incident. I thought I'd comment anyway.