duplicate name; pick new name or delete old one

[gambit49]

When Networker tries to relabel an expired volume it comes up with this error:

nsrd: Jukebox 'MSL' failed: duplicate name; pick new name or delete old one

It doesn't happen all the time but when it does happen, Networker makes dozens of attempts at relabeling the volume which completely screws up the backup schedule. This is specially true when we don't catch the situation in time; e.g. at night. When we do catch it, we just delete the volume from the media database and Networker either relabels the volume successfully or it unloads the volume and tries a different one.

I heard from somewhere that enabling the "has range" attribute in the jukebox resource will fix this problem. I have gone through the Networker Admin manual but I found no reference to said attribute. Does anybody know what "has range" does? Will it fix the "duplicate name" problem? If it won't, does anyone know what will?

BTW, we're using Networker 6.1.1 on Tru64 UNIX. Any help will be highly appreciated.

 

[TDun]

This is normally a corruption.
This could be your nsrjb.res is corrupt (look at it in vi and see if you have -, "", or -99999 for any volumes. Look for barcode list corrupted, check that the number of volumes matches the numbers shown in the autochanger properties).

It could be the media database is corrupt, try an nsrim -X to sort that.

 

[pmwut5]

I have seen this problem on our silo. It can happen when Legato becomes out of sync with the silo.

I.E.
TAPE 001234 is in slot 20

but Legato thinks it is in slot 40.

When you try and relabel the tape in slot 20 (which Legato does know about) it reads the Physical Label on the tape and hence thinks this is a duplicate to the imaginery one in slot 40.

Deleting the volume works, via unix commands moving the volume from slot 20 to 40 works. Inventorying the slot 40 to make Legato notice there is nothing/something else in slot 40.

As you say when this does happen usually overnight it can halt all backups because legato goes into an endless loop.

 

[TammieR]

I am having this same problem, nsrim -X did not fix it. I do have -, "", in my nsrjb.res.

What else can I try?

 

[TDun]

You need to identify which volume this - should be.

To do this, look at the tapes before and after the -, then use Networker Administrator, Autochanger, Operations and look at the list of volumes in the autochanger (that Networker thinks it has).
Identify the volume name (e.g. AB0101) and then go to the command prompt.
Run nsrjb -x -T AB0101 (if you are using barcodes in your autochanger) or nsrjb -x -S slotno , where slotno is the number to the left of the volume name.
If this works, the - will go. If not, you will need to either:
put the tape in question back in the autochanger or:
delete your autochanger, recreate it and repopuloate it.

 

[rossj]

We have had this same problem. We have tape jukeboxes and sometimes when inserting the tape it doesn't scan the barcode like it is supposed to. When we get this error, we just manually make the jukebox scan the tapes inside it and it fixes the problem. Hope this helps.

 

[GersonTexas]

Hi! let me add my two cents, I have seen this problem in my enviroment. What I do is delete the duplicate media from the GUI and relabel the tape. Also this happen with the library is unable to read the barcode label.

 

[wallace88]

Run an mminfo command to see what information actually exists for that volume name in the media database. Look
for volume name, volume id, pool, last date labeled, etc...

Could be:

2) You recovered a bootstrap.

Let's say today you had to recover the bootstrap from
1 month ago. However since that bootstrap was created,
you have relabeled some tapes.

Because you just recoverd the bootstrap, the media
database does not know of the tapes you had relabeled
since that bootstrap was created. So when you try to
label them again, the label information does not match
up against what's in the media database... hence the
error.

When you label a tape, it first reads the current label,
and checks not only the volume name, but also the
volume id and pool. (not sure of pool or something else)
If it finds the volume name and everything else matches
in the media database, then it will continue with the
label process, otherwise it will spit out the duplicate
volume error message...

In this case, the solution is to delete the volume name
from the media database before relabeling.

2) Corrupted media database. Solution is to either
reindex the media database (media scavenging) or recover
the bootstrap.