Video Screencast Help

Backup exec secondary media servers on two node Active/active SQL cluster

Created: 14 Apr 2010 • Updated: 20 Oct 2010 | 3 comments

I am trying to install 2x Backup Exec Media servers with SSO on a two node active/active MSCS SQL cluster and allowing the servers to be managed by a third Primary SSO Server which is also the CASO.

The user guide does not talk at all about active/active but does mention that the MSDE SQL server is recommended.

Does anyone know how to install in this environment? and can I use the MSDE install for the BEDB rather than the application instances of SQL?

The Cluster is running 3 resource groups, 1- the Main cluster group, 2- a large SQL instance pinned to node 1, 3- another large SQL instance pinned to node 2.

I want to be able to backup the SQL instance on each node to FC shared tape, I do not need cluster aware job failover.

I have tried a standard non-cluster install on both nodes but neither media server can see the SQL instance (only the system state and local drives).

Comments 3 CommentsJump to latest comment

mhorner's picture


Anyone know of any configuration details for SQL Active/active cluster installs?

Colin Weaver's picture

As we don't recommend using the SQL instance for a critical production database as teh onwer/repository of the Backup Exec database - i'd avoid considering using one of your existing instances for this.

Typically Backup Exec uses local SQL Express instances on each node that then both think the MDF and LDF files for the Backup Exec database from a the same shared disk - the SQL services for the instance then only run on the active node. This is all created by configuring Backup Exec locally on each node (with default SQL Express setups) and then using the cluster wizard to sort out the movement of the database to the shared disk. - Note: sort out any CASO.SSO configuration before running the cluster wizard.

Also typically (and recommended) is that Backup Exec should have it's own virtual server/cluster resource group within the cluster - I believe this is more to do with what might happen to other clustered resources if you ever uncluster Backup Exec - and as you sometimes have to uncluster to troubleshoot this might become an issue.

Now against your special 'pseudo' Active-Active SQL environment (which if really two Active-Passive instances with affinity set to different nodes)
Backup Exec in clustered configuratiion will always run on one node (Active Passive) - so the SQL instance that is Active on the other node at the time of a backup job will be backed up across the network - which assuming you have a SAN connected, shared tape library will lose the speed/bandwidth benefit on one node.

If you don't cluster Backup Exec but just install it locally on each node then you get the speed benefit of the SAN back, but may have to keep a duplicate set of jobs on hold for when a failover is in place or play about with the job load balancing that is part of CASO to let the backup jobs job set the best media server at the time of the backup. You will also portentially need at least 2 tape devices in your library.

mhorner's picture

Hi Colin, thanks for the response. We have gone down the route of a non-cluster aware install of BE in each node as we need the speed of direct FC tape (db's will be upto 10TB). Failover of the jobs is not so much of a concern as the nodes have critical support and should therefore be functioning again very shortly after a failure.

The problem we have run into with the non-clustered installs is that we can not see the SQL instances when browsing the remote agents from the CASO (or locally on the media servers). We have tried installing directly on the nodes and via the virtual SQL servers but this makes no difference.

Looking through the forums I have seen many references to this problem with permissions being the main culprit. The Backup Exec service account has been given both Domain and local admin rights and we still have the issue.