NetBackup™ Deployment Guide for Kubernetes Clusters
- Introduction
- Section I. Configurations
- Prerequisites
- Recommendations and Limitations
- Configurations
- Configuration of key parameters in Cloud Scale deployments
- Tuning touch files
- Setting maximum jobs per client
- Setting maximum jobs per media server
- Enabling intelligent catalog archiving
- Enabling security settings
- Configuring email server
- Reducing catalog storage management
- Configuring zone redundancy
- Enabling client-side deduplication capabilities
- Parameters for logging (fluentbit)
- Section II. Deployment
- Section III. Monitoring and Management
- Monitoring NetBackup
- Monitoring Snapshot Manager
- Monitoring fluentbit
- Monitoring MSDP Scaleout
- Managing NetBackup
- Managing the Load Balancer service
- Managing PostrgreSQL DBaaS
- Managing fluentbit
- Performing catalog backup and recovery
- Section IV. Maintenance
- PostgreSQL DBaaS Maintenance
- Patching mechanism for primary, media servers, fluentbit pods, and postgres pods
- Upgrading
- Cloud Scale Disaster Recovery
- Uninstalling
- Troubleshooting
- Troubleshooting AKS and EKS issues
- View the list of operator resources
- View the list of product resources
- View operator logs
- View primary logs
- Socket connection failure
- Resolving an issue where external IP address is not assigned to a NetBackup server's load balancer services
- Resolving the issue where the NetBackup server pod is not scheduled for long time
- Resolving an issue where the Storage class does not exist
- Resolving an issue where the primary server or media server deployment does not proceed
- Resolving an issue of failed probes
- Resolving token issues
- Resolving an issue related to insufficient storage
- Resolving an issue related to invalid nodepool
- Resolving a token expiry issue
- Resolve an issue related to KMS database
- Resolve an issue related to pulling an image from the container registry
- Resolving an issue related to recovery of data
- Check primary server status
- Pod status field shows as pending
- Ensure that the container is running the patched image
- Getting EEB information from an image, a running container, or persistent data
- Resolving the certificate error issue in NetBackup operator pod logs
- Pod restart failure due to liveness probe time-out
- NetBackup messaging queue broker take more time to start
- Host mapping conflict in NetBackup
- Issue with capacity licensing reporting which takes longer time
- Local connection is getting treated as insecure connection
- Primary pod is in pending state for a long duration
- Backing up data from Primary server's /mnt/nbdata/ directory fails with primary server as a client
- Storage server not supporting Instant Access capability on Web UI after upgrading NetBackup
- Taint, Toleration, and Node affinity related issues in cpServer
- Operations performed on cpServer in environment.yaml file are not reflected
- Elastic media server related issues
- Failed to register Snapshot Manager with NetBackup
- Post Kubernetes cluster restart, flexsnap-listener pod went into CrashLoopBackoff state or pods were unable to connect to flexsnap-rabbitmq
- Post Kubernetes cluster restart, issues observed in case of containerized Postgres deployment
- Request router logs
- Issues with NBPEM/NBJM
- Issues with logging feature for Cloud Scale
- The flexsnap-listener pod is unable to communicate with RabbitMQ
- Troubleshooting AKS-specific issues
- Troubleshooting EKS-specific issues
- Troubleshooting issue for bootstrapper pod
- Troubleshooting AKS and EKS issues
- Appendix A. CR template
- Appendix B. MSDP Scaleout
- About MSDP Scaleout
- Prerequisites for MSDP Scaleout (AKS\EKS)
- Limitations in MSDP Scaleout
- MSDP Scaleout configuration
- Installing the docker images and binaries for MSDP Scaleout (without environment operators or Helm charts)
- Deploying MSDP Scaleout
- Managing MSDP Scaleout
- MSDP Scaleout maintenance
Backing up a catalog
You can backup a catalog by using one of the following methods:
Automatically
Manually
You can backup a catalog by using the automatically created catalog backup policy which is applicable only for fresh/new deployment.
To backup a catalog automatically
- A catalog backup policy can be automatically configured during a new installation. This can be done by supplying the DR Secret through the drInfoSecret field of the
environment.Specinhelm/values.yamlfile. - The drInfoSecret field must be created before deployment using the following command:
kubectl create secret generic dr-info-secret --namespace <nbu-namespace> --from-literal=passphrase="Y@123abCdEf" --from-literal=emailAddress="abc@xyz.com"
The passphrase field is compulsory.
- Once catalog policy is created, configure Recovery Vault storage in the catalog backup policy. For more information, see NetBackup Deduplication Guide.
- In the automatically configured catalog backup policy, the DR package path is set to
/mnt/nbdb/usr/openv/drpackage_<storage server name>. If required, this can be changed by editing the policy from the Web UI. - If the email field is included in the DR Secret, then on running a catalog backup job, the created DRPackages would be sent through email. this is applicable only when the e-mail server is configured. Configuring email server
To backup a catalog manually
- Exec into the primary server pod using the following command:
kubectl exec -it -n <namespace> <primary-pod-name> -- /bin/bash
- Create a directory DRPackages at persisted location using
mkdir /mnt/nblogs/DRPackages. - Change ownership of DRPackages folder to service user using
chown nbsvcusr:nbsvcusr /mnt/nblogs/DRPackages. - Set the passphrase to be used at time of catalog recovery.
Open NetBackup Administrator Console (Java UI).
Navigate to Security Management > Global Security Setting > Disaster Recovery.
In Encryption for Disaster Recovery section, add the passphrase, confirm passphrase, and save it.
- Add respective external media server entry in host properties through NetBackup Management > Host properties > Master Server > Add Additional server.
Note:
It is recommended to use an external media server for catalog backup and recovery.
- Exec into the primary server pod using the following command:
kubectl exec -it -n <namespace> <primaryserver pod name> -- bash
Set the KMS_CONFIG_IN_CATALOG_BKUP configuration option to 1 in
/usr/openv/netbackup/bp.conffile of primary server to include the KMS configuration as part of the disaster recovery package during catalog backup. - Restart the NetBackup services in primary and external media server.
Exec into the primary server pod using the following command:
kubectl exec -it -n <namespace> <primary-pod-name> -- /bin/bash
Deactivate NetBackup health probes using the /opt/veritas/vxapp-manage/nb-health deactivate command.
Run the /usr/openv/netbackup/bin/bp.kill_all command. After stopping all services restart the services using the /usr/openv/netbackup/bin/bp.start_all command.
Activate NetBackup health probes using the /opt/veritas/vxapp-manage/nb-health activate command.
Run the /usr/openv/netbackup/bin/bp.kill_all command. After stopping all services restart the services using the /usr/openv/netbackup/bin/bp.start_all command on the external media server.
- Configure storage unit on earlier added external media server.
For more information, refer to the NetBackup™ Administrator's Guide,Volume I
Note:
It is recommended to use AdvancedDisk or BasicDisk storage unit.
- Configure NetBackup catalog backup policy.
Add package path as
/mnt/nblogs/DRPackageswhile configuring the catalog backup policy. - Run the catalog backup job.