NetBackup™ for Microsoft SQL Server Administrator's Guide
- Introducing NetBackup for SQL Server
- Installation
- Host configuration and job settings
- Managing SQL Server objects for use with SQL Server Intelligent Policies
- About discovery of SQL Server objects
- About registering SQL Server instances and availability replicas
- Registering instances or availability replicas with an instance group
- Configuring backups with SQL Server Intelligent Policy
- About tuning parameters for SQL Server backups
- Performing restores of SQL Server
- Redirecting a SQL Server database to a different host
- Protecting SQL Server data with VMware backups
- About protecting an application database with VMware backups
- Configuring backups with Snapshot Client
- Using copy-only snapshot backups to affect how differentials are based
- About SQL Server agent grouped snapshots
- Protecting SQL Server availability groups
- Protecting SQL Server availability groups with intelligent policies
- Protecting SQL Server availibility groups with legacy policies
- About protecting the preferred replica in a SQL Server availability group (legacy backup policies)
- About protecting a specific node in a SQL Server availability group (legacy backup policies)
- About protecting the preferred replica in a SQL Server availability group (legacy backup policies)
- Protecting SQL Server in a cluster environment
- Configuring backups with legacy SQL Server policies using clients and batch files
- About using batch files with NetBackup for SQL Server
- About schedule properties
- Performing user-directed backups of SQL Server databases
- Performing user-directed backups of read-only filegroups
- Using NetBackup for SQL Server with multiple NICs
- Performance and troubleshooting
- About debug logging for SQL Server troubleshooting
- About disaster recovery of SQL Server
- Appendix A. Other configurations
- About SQL Server backups and restores in an SAP environment
- About NetBackup for SQL Server with database mirroring
- Appendix B. Register authorized locations
About SQL Server credentials
To protect SQL Server, you must add (or register) credentials to the SQL Server instances or availability replicas. The NetBackup web UI supports Windows authentication and Windows Active Directory authentication. It does not support Mixed Mode or SQL Server authentication. Credentials are not supported at the database or the availability group level.
Table: Options to register credentials
Option to register credentials | Environment and configuration |
---|---|
Use these specific credentials (recommended) |
The user account that is used to register credentials must have the SQL Server "sysadmin" role and be a member of the Windows Administrators group. The NetBackup services can use the Local System logon account. If you want to use a different logon account, that account must also have certain local security privileges. |
|
The user account that is used to register credentials must have the SQL Server "sysadmin" role and be a member of the Windows Administrators group. You must also configure the logon account for the NetBackup Client Service and the NetBackup Legacy Network service. |
Command line |
|
To register an instance or replica from the command line, the following configuration is required:
The NetBackup administrator must authorize the nbsqladm command for a specific DBA or user on a specific host.
On the NetBackup primary server, use nbsqladm to authorize the user:
nbsqladm [-S primary_server] -add_dba host_name user_name
If you have multiple NICs, authorize the DBA using the private interface name of the SQL Server host.
For a SQL Server cluster, authorize the DBA for each node in the cluster. (Do not authorize a DBA using the virtual name of the SQL Server cluster.) For the -host name provide one of the node names in the SQL Server cluster.
For a SQL Server cluster with multiple NICs, authorize the DBA using the private interface name for each of the nodes in the SQL Server cluster.
Once a DBA is authorized to use the nbsqladm command, the DBA can register instances with the local credentials (-local_credentials) or other specific credentials (-user name -domain name).
For complete details on the nbsqladm command, see the NetBackup Commands Reference Guide.
When NetBackup discovers a SQL Server cluster, it adds a single entry on the Instances tab. This instance represents all nodes in the cluster. The host name is the virtual name of the SQL Server cluster. When you add credentials for this instance NetBackup validates the credentials on the active node. The credentials must be valid for all nodes in the cluster.
When NetBackup discovers a SQL Server host that uses multiple NICs, it adds an entry using the NetBackup client name on the Instances tab. If you installed the NetBackup client using the public interface name, you must configure the NetBackup client name as the private interface name. Then add credentials to the instance with its private interface name. For a SQL Server cluster that uses multiple NICs, add credentials to the instance with the private virtual name of the SQL Server cluster.
NetBackup discovers and displays failover cluster instances (FCIs) under the cluster name and the physical node names. For example, instance FCI
is enumerated with both its physical nodes hostvm10
and hostvm11
and with its cluster name sql-fci
. Databases that exist for FCIs are also enumerated with the node names and the cluster name. Depending on how you want to protect a database, add credentials to either the cluster name (that are valid for all nodes) or to a physical node name.
After you add credentials, NetBackup validates the credentials and starts the database and availability group discovery. When discovery completes, the results are displayed on the Databases or the Availability group tab.
For a SQL Server cluster or if an availability group instance is part of SQL Server cluster, NetBackup validates the credentials on the active node. The credentials must be valid for all nodes in the cluster. For a SQL Server availability group, replicas are registered and validated individually. Note that the registered date reflects the date and time the credential was added or updated. It does not indicate if the credentials are valid.