Search <book_title>...

Veritas NetBackup™ for Microsoft SQL Server Administrator's Guide

Last Published: 2021-06-07

Product(s): NetBackup (9.1)

About credentials used with SQL Server Intelligent Policy

SQL Server instances or replicas must be registered with Windows credentials that have the proper permissions to perform backup and restore operations. Intelligent Policy 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 SQL Server DBA provides the NetBackup administrator with the SQL Server user credentials. The SQL Server DBA does not want the NetBackup services running as a privileged SQL Server user on the client. Configuration requirements 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. See Configuring the NetBackup services for SQL Server backups and restores. See Configure local security privileges for SQL Server.
Use credentials that are defined locally on the client	The user account that installed NetBackup is already running as a SQL Server privileged account. The SQL Server DBA does not want to provide credentials to register instances or replicas. The NetBackup administrator does not have access to the SQL Server credentials. Configuration requirements 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 services. See Configuring the NetBackup services for SQL Server backups and restores.
Add to group and register using group credentials	You want to be able to do one or more of the following: Logically group your instances or replicas in some way. Use a particular tuning parameter to improve the performance for each of the instances or replicas in the group. (Optional) Automatically register new instances or replicas and add them to a group. See Registering instances or availability replicas with an instance group.
Command line	The DBA does not have access to the NetBackup Administration Console. The NetBackup administrator does not have the credentials for SQL Server. The DBA wants to maintain the SQL Server credentials independently of the backup administrator. See Configuring credentials from the command line.

Configuring credentials from the 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 master server, use nbsqladm to authorize the user:
nbsqladm [-S master_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.

Registering instances when SQL Server hosts are clustered or use multiple NICs

When NetBackup discovers a SQL Server cluster, it adds a single entry in the Applications utility. This instance represents all nodes in the cluster. The host name is the virtual name of the SQL Server cluster. When you register 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 in the Applications utility. If you installed the NetBackup client using the public interface name, you must configure the NetBackup client name as the private interface name. Then register the instance with its private interface name. For a SQL Server cluster that uses multiple NICs, add and register the instance with the private virtual name of the SQL Server cluster.

See Configuring the NetBackup client with the private interface name.

Registering Microsoft SQL Server failover cluster instances (FCIs)

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.

Validation of credentials

After you add credentials, NetBackup validates the credentials, marks the instances as registered, and adds the instances to the NetBackup database. NetBackup requests detailed information about the instances or replicas from the NetBackup client and displays it in the Microsoft SQL Server > Instances or Microsoft SQL Server > Availability Group nodes.

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 and does not indicate if the credentials are valid.

See Troubleshooting credential validation .