NetBackup status code: 50
Message: Client process aborted
Explanation: One of the following has occurred:
The client backup terminates abnormally. For example, a NetBackup master or media server is shut down or restarted when a backup or restore is in progress.
An administrator uses an OS-provided command line (for example, the kill command) to kill an active process. The job status does not reflect the change until one hour later, when the status changes to DONE and this status code is generated.
When NBUX is deployed on AKS, the max pods per node setting limits the number of pods (User and System) that can be created on the nodes from node pool. This number need to be set according to calculation:
MAX pods per node = (RAM size * 2) + number of kube-system pods[10] + No of nodes + 2
When NBUX is deployed on AKS, vnet needs to have sufficient number of free IP addresses.
MAX pods per node = (RAM size * 2) + number of kube-system pods[10] + No of nodes + 2
The file hash search terminates abnormally. For example, a file hash server is shut down or restarted when a file hash search is in progress.
Recommended Action: Do the following, as appropriate:
Enable detailed debug logging.
Create a bpbkar debug log directory (UNIX, Linux, and Windows clients only).
Create a bpcd debug log directory.
On UNIX clients, add the VERBOSE option to the
/usr/openv/netbackup/bp.conffile.On PC clients, increase the debug or the log level.
See "Changing the logging level on Windows clients" in the NetBackup Logging Reference Guide.
Retry the operation and examine the resulting logs.
This error may occur if nbjm terminated while a backup job was running. Examine the unified logging files on the NetBackup server for nbjm (117) for more detail on the error. All unified logging is written to
/usr/openv/logs(UNIX) orinstall_path\NetBackup\logs(Windows).On UNIX clients, check for core files in the
/directory.On UNIX clients, check the system log (
/usr/adm/messageson Solaris) for system problems.This problem can sometimes be due to a corrupt binary.
On UNIX clients, use the UNIX sum command to check the bpcd, bpbkar, and tar binaries, which are located in
/usr/openv/netbackup/binon the client. Reinstall them if they are not the same as in the client directory under/usr/openv/netbackup/clienton the server.On a Windows client, check the
bpinetd.exe,bpcd.exe,bpbkar32.exe, andtar32.exefiles, which are located in theinstall_path\NetBackup\binfolder on the client.Reinstall the client if these files are as follows:
Not the same size as on other Windows clients.
Not at the same release level.
Do not have the same NetBackup patches as other Windows clients.
Review the following when NetBackup is deployed on a Kubernetes deployment:
Check the number of pending pods. Post that to ensure that the issue occurred due to the node pool level max pods setting, and check if the workflow runner or data mover pods are in pending state. Delete the node pool and recreate the node pool with appropriate number to max pods using the following formula:
MAX pods per node = (RAM size * 2) + number of kube-system pods[10] + No of nodes + 2
Check the number of pending pods. Post that to ensure that there are sufficient number of free IPs are available. The administrator needs to ensure that sufficient number of IPs are available.
Click here to view technical notes and other information on the Cohesity Technical Support website about this status code.