40 Posts
0
3209
Which CLI command can be used to report Networker job status for each client?
I would like to monitor the job results for individual clients covered by Policy/Workflow/Action with a script. The CLI command ‘jobquery’ can be used to monitor the results of workflows. But which command can be used to report the status of individual actions in a workflow? In addition, we found multiple cases when the protection group of a policy/workflow/action contains multiple clients, for example we use a NSR rule to include all the VMs in a VMware folder in a protection group, a backup failure of a VM might not trigger the failure of the backup action, and the status of the workflow was also successful. That means you will not notice that the backup for a VM failed if you just check at the workflow and action level. I need a way to check job status at the client level.
DPA does report job status at client level. But the data sources used by DPA have their own issues about reporting multiple instances of the same job or missing sub-jobs.
ChiXC
40 Posts
0
February 17th, 2021 20:00
After reading bingo.1’s comments, I realized that there is no single CLI command that I can use to check job status at client level. I finally got some spare time to look around for the log file option per bingo.1’s suggestion. It seems the Networker log file \EMC NetWorker\nsr\logs\policy_notifications.log provides some detailed status information about each scheduled policy/workflow/action. But be careful, you need to check not only the “Action status:”, but also the detailed “---Failed backups---“, “--- Failed Clone Save Sets ---“ and other details. For example, I have seen a case with a successful VM backup action for a VM folder, but the backup of one VM failed while the backups for all other VMs succeed.
Although the syntax of this log file is little bit messy, it is not difficult to write a script to extract only failed jobs at client level for a specific time period. Such a script can be run, for example, by a daily scheduled job to send out an alert email when there is any failed client backup or clone job during the previous day.
I will mark this reply as the solution in order to close this threat.
bingo.1
2.4K Posts
0
January 21st, 2021 15:00
IMHO it is not possible to check for action on the client level.
I can only suggest that you write a script which will investigate the logs for appropriate messages.
The other possibility is that you compare statistical information. For example you could compare the last backups with the previous ones and find out if there is one missing.
Not an easy job to be done ...
barry_beckers
393 Posts
0
March 10th, 2021 06:00
is your issue that a failed VM backup is not reported not caused by running nw19.3.0.0 until 19.3.0.2? This as nw19.3.0.3 has a fix addressing this through dynamically selection using a rule instead of manual selection of VM's?
There was a recent DTA about that:
https://www.dell.com/support/kbdoc/000181320/dta-xxxxxx-networker-dynamic-vm-workflow-backup-is-marked-as-successful-in-nmc-even-when-vms-are-failing-resulting-in-a-data-loss?lang=en
DTA 181320 NW Dynamic VM workflow-backup is marked as successful in NMC even when VM are failing resulting in a data loss
ChiXC
40 Posts
0
March 14th, 2021 16:00
Thanks barry_beckers. It seems this DTA addressed exactly one of the status report problems we are facing. We are using a Rule resource to define a Protection Group which includes dynamically all the VMs in a vCenter folder as the backup client of a policy/workflow. And we have seen multiple occasions when the backup of one of the VMs failed, but the workflow was marked as successful. That is one of the reasons why we ran a scheduled job to parse system logs to check the backup/clone status at client level. It is good that this issue has been fixed in a new Networker version. Thanks again for the heads-up. Really appreciated.
BTW, with the CLI command ‘jobquery’, you can also get some client level status information when using the types: backup action job, clone job, save job, synthetic full job, vproxysave job, etc. But the outputs of the command are not easy to parse either, for example the mapping from the internal VM object ID to the VM host name.