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

Etrack details 2874757

Created: 22 Feb 2013 • Updated: 02 May 2013 | 3 comments
This issue has been solved. See solution.

Hi everyone,

Does anybody has details for Etrack 2874757 or has any idea how to get them. I´ve tried to use SORT but can´t find it. What i can read on the release notes of 7.5.0.5 is: 

Associated Primary Etrack: 2865426

Hyper-V backups failed with a status code 156 and 1542 when a snapshot failed
but was not deleted, which left the CSV in a redirected state

And we did have those issues a few weeks ago but i couldn´t find any articles on that,  specially on leaving a CSV in a redirected state. Now that i see it on 7.5.0.5, would be nice to understand if there is a particular scenario on which the error happens.

Thanks a lot.

Pamela. 

Comments 3 CommentsJump to latest comment

Yasuhisa Ishikawa's picture

Itis better to log a case with Symantec for your own issue. If it is same this this Etrack, you may get explained what it is.

Authorized Symantec Consultant(ASC) Data Protection in Tokyo, Japan

Pamela_S's picture

I agree,is the most reasonable thing to do, but last time the CSV got stuck on redirected mode was a few months ago. This caused a big deal and Hyper-V backups were suspended without even calling support, even the Master Server was turned off for a while.  

After lots of testing, we resumed  Hyper-V backups last week and now we have no errors, so i cannot call support for something that happened months ago.

There is a lot of susceptibility on not knowing if it will happen again or why did it happened. I´ve taking all actions needed in order to avoid 156 error, but i´d rather have some documentation saying "yes, there was an possible scenario that could have caused that error, and if we go to 7.5.0.5 we´re minimizing risk of happening again" 

CRZ's picture

Which version of NetBackup are you running now?

There is a lot of susceptibility on not knowing if it will happen again or why did it happened. I´ve taking all actions needed in order to avoid 156 error, but i´d rather have some documentation saying "yes, there was an possible scenario that could have caused that error, and if we go to 7.5.0.5 we´re minimizing risk of happening again"

But that's basically what the Release Notes blurb says, isn't it? 

This is one of the many fixes inclued in 7.5.0.5.  If you apply 7.5.0.5, this issue should be one that you won't experience (or experience again, if you were hitting it before).


bit.ly/76LBN | APPLBN | 75LBN

SOLUTION