Anyone could help us with resolution of catalog inconsistency. We are trying to upgrade from 126.96.36.199 to 188.8.131.52, our system is windows server 2008R2 and we are out of official support.
If possible, take a look at attached logs - nbcc 8.1.
hmm blind try - as i never faced such error
Why this master server has no tape storage unit? maybe there was some media server which was not properly decomissioned... there is only one STU - catalog stu - basic disk or so...
maybe 20_4 says that media are orphaned... no clue...
oper_20_4 is left over from an upgrade from 5.x to 6.x It should have been fixed back then.
There is a 'merge table', one of the tables in NBDB, which was to deal with 'probelm' entries between the upgrade to 6.x, where the entries relate to tapes.
File 731.dat in the nbcc output is the merge table in the version of NBU you have (.dat files can change between versions). You can also list media in the merge table with nbemmcmd -listmedia -mergetable - the outputs should match.
If I rightly remember, you have two conflicting entries for the same tape, only one will be correct.
Technically, nbcc is only needed to upgrade from 5.x -> 6.x, after that it is optional, that is, nbcc issues when upgrading from 6.x to higher shouldn't cause a failure /problem with the upgrade (despite there being an nbcc -upgrade option). Not fixing nbcc issues can however cause issues with the operation of NBU and can lead to dataloss.
Merge table entries are one of the things that are meant to be fixed, not really optonal - nbcc stops repoting any futher issues until oper_20_4 issues are resolved.
The only supported way to fix this is via nbcc.
Given there are merge table issues, I suspect there will be many other nbcc issues - some of these could put data at risk and so the only real way forward is to get a valid support contract and work through nbcc properly.
The result of the commando "> nbemmcmd -listhosts" is correct about my servers and this site has only one master/media server. The tape library is not working and I excluded it. Making the scenario worst, yesterday, my deduplication volume crashed and I had to remove it too. Now I'll try to make another dedup pool, so I'd like, first of all, to upgrade my software until my last registered/compliance version.
The "CONSISTENCY_ERROR Oper_20_4" message desapeared with the following commands (21 old medias removed):
nbemmcmd -listmedia -mergetable
nbemmcmd -deletemedia -mediaid [XXXXXX] -originhost [masterServerName]
nbemmcmd -deletemerge -assignedhost NONE -mediaid [XXXXXX]
But, like you had supposed, inconsistency keeps. Now, I believe that there are something wrong with my valid medias. I attached the new result of nbcc command, so if possible, take a look to help me in this case.
Thanks about nbcc information, otherwise, like you said, it's better to run it to prevent some dataloss, am I right?
Ahh, yes - I had forgotten about that -deletemerge command (didn't have my laptop yesterday when I was replying to the post). If the media deleted without being expired, it looks like they had no 'assign' time, and therefore in theory contained no valid images.
You have a choice:
1. Obtain a valid support contract to allow nbcc to be run and properly check the system
2. Upgrade without nbcc - this should not cause an issue in terms of causing an upgrade to fail, it just means any nbcc issues that might be there before the upgrade, will still exist after the upgrade.
Than bad luck....
Try to upgrade - without being worried about NBCC. Once you will be on the supported release (and will have valid maintenance contract) open a case to sort this out...
That's all - I never faced such code... I do faced few others... and am able to sort some out by my self... but mostly vrts CE is needed.
You are most welcome.
Oh, although you have no frozen tapes, I do not ever recommend un-freezing tapes unless you know why they are frozen. I have over the years seen 2 cases where a damaged tape was repeatedly unfrozen (they didn't take the hint ...) which then went into all of the drives in turn damaging every one - meaning every drive had to be replaced. OK, it's rare, but it happens.