Ransomware attackers specifically target and attempt to destroy backup systems to increase the probability of payment. Hardening your system is critical. Please ensure you have reviewed your platform security using the Security Hardening Checklist
Cohesity

COHESITY Documentation

Explore our documentation to get started, discover products & new features, access troubleshooting guides, register sources, platforms support.

Products
Data Security Alliance
Visit Cohesity.com
Demos
Support
Blogs
Developers
Partner Portals
Cohesity Community
© 2026 Cohesity, Inc. All Rights Reserved.
Terms of Use|
Privacy Policy|
Legal|
  1. Home
  2. NetBackup™ Deployment Guide for Amazon Elastic Kubernetes Services (EKS) Cluster
  3. Troubleshooting
  4. Resolving an issue where the primary server or media server deployment does not proceed
NetBackup™ Deployment Guide for Amazon Elastic Kubernetes Services (EKS) Cluster

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 configcheckmode = default 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

  1. 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.

  2. 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 is primary-configcehcker-default-dhg34.

  3. Depending on the error in the pod logs, perform the required steps and edit the environment CR to resolve the issue.
  4. 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

Feedback

Was this page helpful?
Previous

Resolving an issue where the Storage class does not exist

Next

Resolving an issue of failed probes

Feedback

Was this page helpful?