07-11-2018 01:30 AM
Hi guys,
I would like to ask, if there is some way how to determine under which schedule backup job was triggered? We have multistreams enabled for FS/VM etc. and there is no evidence, when backup fails on 4239 for example there is only dash as schedule. Is there any way how to do it via PS or CMD? Thanks.
07-11-2018 04:24 AM
This should only apply to the parent job. The child jobs should all display the schedule name.
Similar to this screenshot (borrowed from Internet):
Can you show us a screenshot of your Activity Monitor?
07-11-2018 04:36 AM
Yea i know, we have this logic already applied, but now I am searching for the solution if there are not child jobs and there is schedule with dash.
For example we have backup failing:
JobID,state,status,scheduleName,client,parentJobID
-----------------------------------------------------------------
8752517,3,4239,-,CLIENT,8752517
8733585,3,4239,-,CLIENT,8733585
8715368,3,4239,-,CLIENT,8715368
8695268,3,4239,-,CLIENT,8695268
8581863,3,4239,-,CLIENT,8581863
8543391,3,4239,-,CLIENT,8543391
and there are no child jobs, so we are not able to find schedule name from the childjobs. (this is custom PS script) is there any way, how to determine it? It should be good if there is any solution how to find what schedule had to run exact day. As support team have a lot of old tickets and database is cleanedup after 7days or something...
Thanks a lot!
07-11-2018 06:22 AM
My guess is that the process flow with VMware policies is probably a bit different - that the clients are first of all validated.
So, if the client name is invalid (Unable to find the virtual machine), the schedule name becomes irrelevant.
Well, that is my view. You may want to check with Veritas Support.
07-12-2018 12:48 AM
We have such a big environments and when there is outage or something, a lot of tickets are generated and we need to find scheduleName even it is DASH, because we are not able to close these tickets, when the backups under correct schedule was not successful.
07-12-2018 01:31 AM
So, the issue then seems to be with your ticketing system and not fixing the real issue with the policy...