Please enter search query.
Search <book_title>...
NetBackup™ Deployment Guide for Kubernetes Clusters
Last Published:
2023-04-24
Product(s):
NetBackup (10.2)
- Introduction
- Section I. Deployment
- Prerequisites for Kubernetes cluster configuration
- Deployment with environment operators
- Deploying NetBackup
- Primary and media server CR
- Deploying NetBackup using Helm charts
- Deploying MSDP Scaleout
- Deploying Snapshot Manager
- Section II. Monitoring and Management
- Monitoring NetBackup
- Monitoring MSDP Scaleout
- Monitoring Snapshot Manager
- Managing the Load Balancer service
- Managing MSDP Scaleout
- Performing catalog backup and recovery
- Section III. Maintenance
- MSDP Scaleout Maintenance
- Upgrading
- Uninstalling
- Troubleshooting
- Troubleshooting AKS and EKS issues
- Troubleshooting AKS-specific issues
- Troubleshooting EKS-specific issues
- Troubleshooting AKS and EKS issues
- Appendix A. CR template
Resolving an issue where the primary server or media server deployment does not proceed
primary server or media server deployment does not proceed even if
in primary server or media server CR spec and no other child resources are created. It is possible that the Config-Checker job has failed some of the configuration checks.To resolve an issue where the primary server or media server deployment does not proceed
- Check the status of Config-Checker Configcheckerstatus mentioned in primary server or media server CR status using the kubectl describe <PrimaryServer/MediaServer> <CR name> -n <namespace> command.
If the state is failed, check the Config-Checker pod logs.
- Retrieve the Config-Checker pod logs using the kubectl logs <config-checker-pod-name> -n <operator-namespace> command.
Config-Checker pod name can be in the following format:
<serverType>-configchecker-<configcheckermode>-randomID
, for example if its Config-Checker for primary server with configcheckermode = default, pod name isprimary-configcehcker-default-dhg34
. - Depending on the error in the pod logs, perform the required steps and edit the environment CR to resolve the issue.
- Data migration jobs create the pods that run before deployment of primary server. Data migration pod exist after migration for one hour only if data migration job failed. The logs for data migration execution can be checked using the following command:
kubectl logs <migration-pod-name> -n <netbackup-environment-namespace>
User can copy the logs to retain them even after job pod deletion using the following command:
kubectl logs <migration-pod-name> -n <netbackup-environment-namespace> > jobpod.log