Ah ok, I see what my problem was qith jobquery... unlike nsradmi it does not give you prompt... so I thought it was hanging.. ok, so I see following when doing simple query:

printf "show failed clients list;name\nprint type: savegroup job; actual exit code: 1\n" | jobquery -i

I get the list of 4 groups...2 FS and 2 archive log groups.  Those archive log groups already run afterwards, but I guess data is still in there since query goes agains whole jobdb which I keep for 2 days.  So I will either have to translate time to epoch and compare it with "end time" or just exctract savegrp names and check work list and completion lines in NSR group as originally planned.

Of course, following line will do the trick too:

printf "show failed clients list;name\nprint type: savegroup job; completion status: failed\n" | jobquery -i

Maybe that one is even better in case that failure is caused by some other return code...

It sounds like you're doing some cool stuff here. I was looking into the jobquery command some time ago but found no obvious use for it.

Is this any better than what you can get from gstclreport ?

regards,

Johannes

Oh yeah... and it is even reasonably fast

I just figure out a structure (not whole, but for what I need) and running that stuff above is not the best way to go.  I can kill few lines of parsing if I directly query save job resource for failed instances as it contains group name, saveset name, etc... in short, everything I need.  You still need link between save job and savegroup job if you wish to make sure you do not re-run group which is still running (in case where this job is already reported failed).  As I don't like how restart option works (or doesn't work to be honest) so I usually re-run whole client which has failed as 99% of failed backups are usually some VSS saveset on win2k8 box, but you can also execute command (which is also part of save job resource) on client using RPC calls by NetWorker.