Data Protection for SQL Server supports SQL Server 2012 and later versions that run in a Windows failover cluster environment.
Consider the following information before you use Data Protection for SQL Server to protect SQL Server
2012 and later versions in a Windows failover cluster
environment. References to the SQL Server pertain to the virtual SQL Server name in a Windows failover cluster environment.
Follow these cluster setup guidelines:
- A Windows Failover Cluster environment is required for AlwaysOn Availability
Groups.
- A SQL Server instance must be installed on a node in a Windows failover
cluster environment. The cluster node must be online.
- Each availability replica of an availability group must be on a different node
in the same Windows failover cluster environment.
Follow these installation and configuration guidelines:
- Install Data Protection for SQL Server on all nodes from where you intend to run backup and restore
operations.
- When you use shared disk clusters, install Data Protection for SQL Server on all nodes on a disk
that is local to each node and not on a shared cluster disk.
- Use the configuration wizard to register an AlwaysOn Node on the Tivoli® Storage
Manager server. The AlwaysOn Node manages backups of
availability databases. This node is a shared node that allows data backups and restores of
availability databases from any replica.
- Databases that are not in an availability group are backed up under the
standard Data Protection for SQL Server node name.
To migrate your database backups to the AlwaysOn node, an option is available for you to back
up all databases to the AlwaysOn node.
- Use identical configurations in the Data Protection for SQL Server options file when you
configure Data Protection for SQL Server on each node
of the cluster.
- If you use the Tivoli Storage
Manager
scheduler to automate data backups, install the scheduler service on each node of the cluster
to enable failover support.
Follow these operational guidelines:
- The Tivoli Storage
Manager server treats backups as
originating on a single SQL Server (the virtual server) regardless of which node of the cluster
is backed up.
- When you perform a VSS full backup on a secondary replica, the copy-only type
of backup is used to take the snapshot.
- Legacy full backups of availability databases on secondary replicas are
copy-only. The copy-only option is not automatically used with log backups because log backups
that truncate logs are supported on secondary replicas.
- Because of a limitation with the SQL Server, you cannot restore a VSS backup
to an alternate instance. VSS backups must be restored on the same SQL Server instance where
the snapshot is taken.