Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Canceling a Job Fails even in 2012.....

Created: 09 Sep 2013 • Updated: 10 Sep 2013 | 4 comments
EVC's picture
This issue has been solved. See solution.

I have been using Backup Exec on and off at various jobs for many years.  During that time, even after it was sold to Symantec, there have been many nagging and annoying glitches in this software that simply drive me crazy.

One of them is the inability to cancel a locked up job without restarting the services.  It amazes me how Symantec just polished this Veritas turd with some crazy new UI and threw it back at us with the SAME BROKENS as we had 10 years ago!

What's next, are we gonna use tiles and touch screens?  Why don't you stop with the crappy documentation and the horrible redesigns and focus on making this software actually work the way you claim it is supposed to work.  Hmm, I think I asked someone at Veritas that same question once.......

Operating Systems:

Comments 4 CommentsJump to latest comment

CraigV's picture

...instead of ranting your way through the forums, rather consider putting this in as an Idea. Not only will nobody else respond here, but having an Idea will bring focus to it. The more votes up, the more chance you have of it being implemented.

I've seen the cancelling of jobs fail across a couple of versions, so there are a number of people who have had this issue.

https://www-secure.symantec.com/connect/backup-and-recovery/ideas

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

Colin Weaver's picture

The reason why a job cancel operation may or may not work is that for a job to cancel the job thread / process that is ongoing at the time has to reach a point where a graceful close of any open media (that is being written to) and a graceful removal of any snapshots etc can be done. As such a cancel is not as simple is just killing everything immediately.

If the reason you are cancelling a job is that a job appears non responsive then it could be that one of the background processes is either hung up or just running very very slowly. 

Hitting cancel in this situation may need that slow proces to finish before the cancel can take place, hence the cancel is acknowledged but either never completes (because of a hung background process) or takes a very long time (because of a slow background process.) In any one job there are multiple background threads and processes going on as such it can be almost impossible for us to indentify why the cancel did not take place (which hopefully explains why job cancel issues are present throughout all BE versions.

Note 1: if you have a repeating job that you often have to cancel then really you should fix the need to cancel instead. 

Note 2: if you end up stopping services because a cancel never happens then remember to tidy up any snapshots (especially if you stopped services with VMware \ AVVI jobs running.

SOLUTION
EVC's picture

Thank you for your reply!!  This is the first time I've had anyone suggest something other than "restart the services" without any kind of explanation as to why this is happening. 

You mentioned "tidying up" the snapshots.  Could you point me in the direction for some documentation on what you mean by that. 

Thanks again!!
No more rants, I promise..
 

Colin Weaver's picture

For VMware use the vSphere Client to confirm is any SYMC snapshots are in the Snapshot Manager (for each VM) and remove them

For standard agent on Windows check that the VSS writers are stable (VSSADMIN LIST WRITERS command) and also check the Shadow Copies of the volumes.

For Hyper-V I am not sure what might need checking.

Also if you ever cancel a database incremental job then plan to run a full to restart the job sequence.

EDIT: One more point if you stop servcies in the middle of writing to tape you may end up with no end marker being written resulting in the tape only being available for overwrite, this would be an expected condition.