http://www.symantec.com/business/support/index?page=content&id=TECH174371
Hi,
We are suffering from the symptoms as described in the TECH174371 .
NBU 7.1.0.2 on Windows 2008 R2.
This is probably because we have configured custom retentions (10 years & 1 hour etc).
Its not clear what releases this effects. Would rollback to 7.x help?
Whilst we wait for 7.1.0.4 or 7.5 to fix this, does anyone have any ideas of a work around?
Idea 1 : Configuring the AIR target domain master retentions to match : does not solve it.
Idea 2 : Deselecting 'remote retention' on target import & select choosing specific retention : can't apply this; pop up box "At least one storage destination should have remote retention period"
Idea 3 : Removing custom retentions & reverting to defaults : probably the only workable idea but not ideal as it may eat up MSDP storage, as we would have to choose the next highest default retention period.
More ideas welcome.
thx, Rich.
Comments
I would log a call and see if
I would log a call and see if they have an engineering EEB that you can apply
#edit#
Having read it again it does just say "schedule type" which implies that it relates to something missing on the target site.
For example if the main site has a SQL policy with an application schedule in it, but the remote site did not, then it would cause the failure.
So if a dummy policy was set up on the remote site for a SQL backup would that resolve it? (or Oracle etc. etc.)
Authorised Symantec Consultant
Don't forget to give a "Thumbs Up" or mark as "Solution" if someones advice has helped you.
I will try it..
OK thx Mark, that sounds like a good idea & easy to test.
Did I miss something??
7.1.0.3?
When was that released?
I cannot find anything in Release Details (http://www.symantec.com/business/support/index?pag...)
Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows.
Handy NBU links
edit = 7.1.0.2
Good spot. Typo. 7.1.0.2.
However, the technote still says
"This issue is scheduled to be fixed in the following release:
Which rather suggests that if 7.1.0.3 does become GA, it will not incude the fix I need.
Open a case
Call us, open a case and demand an escalation and EEB.
We built an EEB for 7.1.0.1 (Etrack 2511449) so I have to think if you asked for one for 7.1.0.2, one would have to be provided. (Go ahead and ask them for a 7.1.0.3 EEB while you're at it ;-) )
Have a verbose bpdm log ready to provide to your TSE because they'll surely ask you for one to confirm the issue before they escalate the case.
Yes - EEB needed
Having tested & failed at all other ideas suggested above, EEB looks like the way to go.
thx for the etrack #
EEB fixed it
For anyone else experiencing this on, the EEB route works.
The EEB was supplied next day, which is a good turn around.
On our platform, the EEB was called "eebinstaller.2647545.1.AMD64.exe" - may be worth quoting if you need to raise you own support call.
thx again Mark & Chris
Great!
Good to hear the EEB was provided so quickly. It looks like we've also got one built for 7.1.0.3 as well (for which I will assume we can thank YOU, Richard!) available via Etrack 2647549 (as opposed to the 7.1.0.2 EEB at 2647545 - note different last digit)
Would you like to reply?
Login or Register to post your comment.