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
Snapshot Manager extension sizing recommendations
The Snapshot Manager extension serves the purpose of scaling the capacity of the Snapshot Manager host to service a large number of requests concurrently running on the Snapshot Manager at its peak performance capacity. You can install one or more Snapshot Manager extensions on-premise or in cloud, depending on your requirements to run the jobs without putting the host under additional stress. An extension can increase the processing capacity of the Snapshot Manager.
The Snapshot Manager extension can have the configuration same or higher as the Snapshot Manager host.
See Meeting system requirements.
Supported Snapshot Manager extension environments:
VM based extension for on-premise
Cloud based extension with managed Kubernetes cluster
Note:
For Snapshot Manager 10.0, the VM based extensions are supported on Azure Stack hub and Kubernetes based extension are supported on Azure, AWS and GCP.
Veritas recommends the following configurations for the Snapshot Manager extensions:
Table: Typical Snapshot Manager extension configuration for VM based extension (Azure stack)
Workload metric | Snapshot Manager extension configuration |
|---|---|
Up to 16 concurrent operational tasks |
CPU: 4 CPUs Memory: 16 GB For example, in Azure stack, the Snapshot Manager extension should be an equivalent of a t3.xlarge instance in AWS. |
Up to 32 concurrent operational tasks | CPU: 8 CPUs Memory: 32 GB or more For example, in Azure stack, the Snapshot Manager extension should be an equivalent of a t3.2xlarge or a higher type of instance in AWS. |
Table: Typical Snapshot Manager extension configuration for Kubernetes based extension (Azure, AWS and GCP)
Workload metric | Snapshot Manager extension configuration |
|---|---|
Up to 24 concurrent operational tasks | For Azure
Note: Above configuration would run 16 jobs per node at once. |
Up to 24 concurrent operational tasks | For AWS CPU: More than 2 CPU's RAM per node: 8 GB Autoscaling enabled, with minimum =1 and maximum =3 Note: Above configuration would run 8 jobs per node at once. |
Up to 24 concurrent operational tasks | For GCP CPU: More than 2 CPU's per node Memory: 8 GB per node Autoscaling enabled, with minimum =1 and maximum =3 |
General considerations and guidelines:
Consider the following points while choosing a configuration for the Snapshot Manager extension:
To achieve better performance in a high workload environment, Veritas recommends that you deploy the Snapshot Manager extension in the same location as that of the application hosts.
The cloud-based extension on a managed Kubernetes cluster should be in the same VNet as that of the Snapshot Manager host. If it is not, then you can make use of the VNet peering mechanism available with the Azure cloud, to make sure that Snapshot Manager host and extension nodes can communicate with each other over the required ports
Depending on the number of workloads, the amount of plug-in data that is transmitted from the Snapshot Manager host can get really large in size. The network latency also plays a key role in such a case. You might see a difference in the overall performance depending on these factors.
In cases where the number of concurrent operations is higher than what the Snapshot Manager host and the extensions together can handle, Snapshot Manager automatically puts the operations in a job queue. The queued jobs are picked up only after the running operations are completed.