NetBackup™ Snapshot Manager Install and Upgrade Guide
- Introduction
- Section I. NetBackup Snapshot Manager installation and configuration
- Preparing for NetBackup Snapshot Manager installation
- Meeting system requirements
- Snapshot Manager host sizing recommendations
- Snapshot Manager extension sizing recommendations
- Creating an instance or preparing the host to install Snapshot Manager
- Installing container platform (Docker, Podman)
- Creating and mounting a volume to store Snapshot Manager data
- Verifying that specific ports are open on the instance or physical host
- Preparing Snapshot Manager for backup from snapshot jobs
- Deploying NetBackup Snapshot Manager using container images
- Deploying NetBackup Snapshot Manager extensions
- Before you begin installing Snapshot Manager extensions
- Downloading the Snapshot Manager extension
- Installing the Snapshot Manager extension on a VM
- Installing the Snapshot Manager extension on a managed Kubernetes cluster (AKS) in Azure
- Installing the Snapshot Manager extension on a managed Kubernetes cluster (EKS) in AWS
- Installing the Snapshot Manager extension on a managed Kubernetes cluster (GKE) in GCP
- Install extension using the Kustomize and CR YAMLs
- Managing the extensions
- NetBackup Snapshot Manager cloud plug-ins
- NetBackup Snapshot Manager application agents and plug-ins
- About the installation and configuration process
- Installing and configuring Snapshot Manager agent
- Configuring the Snapshot Manager application plug-in
- Configuring an application plug-in
- Microsoft SQL plug-in
- Oracle plug-in
- NetBackup protection plan
- Configuring VSS to store shadow copies on the originating drive
- Additional steps required after restoring an AWS RDS database instance
- Protecting assets with NetBackup Snapshot Manager's agentless feature
- Volume Encryption in NetBackup Snapshot Manager
- NetBackup Snapshot Manager security
- Preparing for NetBackup Snapshot Manager installation
- Section II. NetBackup Snapshot Manager maintenance
- NetBackup Snapshot Manager logging
- Upgrading NetBackup Snapshot Manager
- Uninstalling NetBackup Snapshot Manager
- Preparing to uninstall Snapshot Manager
- Backing up Snapshot Manager
- Unconfiguring Snapshot Manager plug-ins
- Unconfiguring Snapshot Manager agents
- Removing the Snapshot Manager agents
- Removing Snapshot Manager from a standalone Docker host environment
- Removing Snapshot Manager extensions - VM-based or managed Kubernetes cluster-based
- Restoring Snapshot Manager
- Troubleshooting NetBackup Snapshot Manager
- Troubleshooting Snapshot Manager
- SQL snapshot or restore and granular restore operations fail if the Windows instance loses connectivity with the Snapshot Manager host
- Disk-level snapshot restore fails if the original disk is detached from the instance
- Discovery is not working even after assigning system managed identity to the control node pool
- Performance issue with GCP backup from snapshot
- Post migration on host agents fail with an error message
- File restore job fails with an error message
Prerequisites for the agentless configuration
Have the following information with you:
Host user name
Host password or SSH key
Snapshot Manager requires these details to gain access to the host and perform requested operations.
On hosts where you wish to configure this feature, grant password-less sudo access to the host user account that you provide to Snapshot Manager.
Snapshot Manager requires a host user account to connect and perform operations on the host. You must grant password-less sudo access to the user account that you provide to Snapshot Manager. This is required for all the hosts where you wish to configure the agentless feature.
Note:
The following steps are provided as a general guideline. Refer to the operating system or the distribution-specific documentation for detailed instructions on how to grant password-less sudo access to a user account.
Perform the following steps on a host where you want to configure the agentless feature
Verify that the host user name that you provide to Snapshot Manager is part of the
wheelgroup.Log on as a root user and run the following command:
# usermod -aG wheel hostuserID
Here, hostuserID is the host user name that you provide to Snapshot Manager.
Log out and log in again for the changes to take effect.
Edit the
/etc/sudoersfile using the visudo command:# sudo visudo
Add the following entry to the
/etc/sudoersfile:hostuserID ALL=(ALL) NOPASSWD: ALLIn the
/etc/sudoersfile, edit the entries for thewheelgroup as follows:Comment out (add a # character at the start of the line) the following line entry:
# %wheel ALL=(ALL) ALL
Uncomment (remove the # character at the start of the line) the following line entry:
%wheel ALL=(ALL) NOPASSWD: ALL
The changes should appear as follows:
## Allows people in group wheel to run all commands # %wheel ALL=(ALL) ALL ## Same thing without a password %wheel ALL=(ALL) NOPASSWD: ALL
Save the changes to the
/etc/sudoersfile.Log out and log on to the host again using the user account that you provide to Snapshot Manager.
Run the following command to confirm that the changes are in effect:
# sudo su
If you do not see any prompt requesting for a password, then the user account has been granted password-less sudo access.
You can now proceed to configure the Snapshot Manager agentless feature.
The user account used to connect to remote instance should be able to:
Access remote admin share (ADMIN$). Enabled by default.
Access to
root\cimv2
Configure the following ports:
Modify the security group to allow inbound traffic on the ports 135, 445 and dynamic port or fixed port for WMI .
Enable inbound rules in the firewall for the ports 135, 445 and the dynamic or fixed WMI-IN ports on Windows hosts.
Note:
The dynamic range for the ports is 49152-65535.
You can use fixed or dynamic WMI-IN ports. If you want to configure a fixed WMI-IN port, see Setting Up a Fixed Port for WMI.
Disable User Account Control for the users groups accessing the agentless feature.
For protecting SQL applications, the user account used for connecting to the cloud host, must have the required admin privileges to access the SQL server.