Please enter search query.
Search <book_title>...
NetBackup™ Deployment Guide for Amazon Elastic Kubernetes Services (EKS) Cluster
Last Published:
2022-09-08
Product(s):
NetBackup & Alta Data Protection (10.1)
- Introduction to NetBackup on EKS
- Deployment with environment operators
- Assessing cluster configuration before deployment
- Deploying NetBackup
- About primary server CR and media server CR
- Upgrading NetBackup
- Deploying MSDP Scaleout
- Upgrading MSDP Scaleout
- Monitoring NetBackup
- Monitoring MSDP Scaleout
- Managing the Load Balancer service
- Performing catalog backup and recovery
- Managing MSDP Scaleout
- About MSDP Scaleout maintenance
- Uninstalling MSDP Scaleout from EKS
- Troubleshooting
- 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