There is no bug id for this issue.
You can find a service request that we have opened to EMC and related
instrcutions for this problem.
Problem:
You are receiving errors when NetWorker attempts to label tapes
automatically reporting: -
Error: duplicate name: pick new name or delete old one.
You have "match bar code labels set to yes" and due to this error being
reported scheduled saves during the backup window are being delayed due to
the tape requests not being serviced correctly.
Recommendation:
I stated in my mail that there are usually 2 causes of this issue: -
1. Drive mapping changing ¿ this is as a result of persistent binding not
being correctly implemented/configured within the storage nodes and
NetWorker server OS. To allow the tape devices to be consistently
recognized by the OS with the same ¿name¿ persistent binding must be
configured. Each Unix/fabric vendor has different instructions on how to
do this, and I cannot supply these instructions to you. However I believe
the Unix Administrators should be able to ensure this is on place. There
are patches and instructions for Microsoft Windows which are detailed in a
Support Note in our Knowledgebase reference esg83905. If the above is not
in place then NetWorker has the potential to load two drives and write to a
different tape unknowingly.
2. Core dumping daemons ¿ this was an issue at very early releases of 7.3.
You should be highlighted to this quickly as we record the fact there has
been and issue and core dumps are produced under /nsr/cores/<daemon name>
directories. The situation here is that the code has an issue and only
partially completes the process updates required leaving us in an
inconsistent state for the label written to tape and the Media database
entries. Apart from identifying this has happened there is really no other
action you can take apart from ensuring that when this occurs you identify
the issue as soon as possible.
3. With respect to NetWorker keep wanting to use the same volume with the
issue there are changes scheduled for the product so if this is encountered
we treat it similar to a hardware issue on a tape drive and keep some type
of ¿error count¿ for the volume, then once this hits a threshold target we
stop considering this volume for selection. This function is not in the
present releases but is planned; however I do not have the details of the
expected release where this will be introduced.
I hope this goes some way to explaining the situation and causes to your
satisfaction and again apologise for you having to prompt me for a
response.
Problem:
You are receiving errors when NetWorker attempts to label tapes
automatically reporting: -
Error: duplicate name: pick new name or delete old one
You have "match bar code labels set to yes" and due to this error being
reported scheduled saves during the backup window are being delayed due to
the tape requests not being serviced correctly.
Recommendation:
1. I have identified certain tapes from the log files which are causing
this issue to be seen. From the list below we may be able to identify the
root cause, however this may not be possible. Due to the nature of the
possible causes it is possible that more tapes could exhibit his behaviour
in the future as they become recyclable, each possible cause can be looked
at individually and the necessary actions taken to correct the problem.
2.Usually this issue is experienced from 2 sources: -
a). A drive mapping issue which could have been corrected, however due to
the mapping being incorrect some tapes could have been labelled with a
volume name which does not match the outside bar code of the physical tape.
This is the most likely reason given the version of software you are
running, however I cannot discount b). below.
b). There was an issue when last labelling the tape and not all the
necessary updates were carried out to the media database due to a problem
with the daemon (usually a core dump). This usually happened on very early
versions of 7.3.3 but could happen on your software version also.
3. For the Drive Mapping issue as a cause: -
a). As I do not have the output from nsrjb for each jukebox I would like
you to look for the tape volumes in the relevant jukebox and see if the
volume label from NetWorker actually matches the bar code reported for the
tape. As you have "match bar codes" set this should always be the case,
however if there has been a drive mapping issue in the past (how long ago
will depend upon the retention times you have for the data) they may
possible not be in sync.
b). If you have the situation above then you will correct this by doing
the following: -
i). Mark the volume as manual recycle.
ii). Look for the NetWorker volume which has a NetWorker label referenced
by this volumes bar code. There can be a maximum of 3 volumes in a chain,
it is more common that 2 volumes are linked. Mark this volume also
manually recyclable.
iii). When both volumes are recyclable within NetWorker then delete both
volumes from the Media Database and client file index and relabelled
manually.
4. For the Label update not 100% complete: -
a). Usually for this the volid on the tape does not match the volid written
on the tape as part of the labelling process. These messages are usually
reported also in the daemon.log file however I do not see then in the log
files you have supplied. We can confirm the volid entry matches the volid
written on the tape by running the following command for each volume: -
nsrjb -lvvv -S <slot number of tape> -j <jukebox name>
or
nsrjb -lvvv -T <bar code> -j >jukebox name>
If these command complete without reporting an issue with the volid then
this is not the cause f the duplicate name error.
b). If the volid does not match the we need to do the following to correct
the issue: -
i). The volume is recyclable as NetWorker would not attempt to reuse the
volume otherwise.
ii). We need to delete the volume from the media database and label the
tape into a pool.
5. List of volumes which have an issue: -
B00616JJ
B01207JJ
B01231JJ
B01253JJ
B01275JJ
B01737JJ
B01739JJ
A00044JA
A00270JA
A00624JJ
Meltem
Peter Viertel
<Peter.Viertel@MA
CQUARIE.COM> To
Sent by: EMC NETWORKER AT LISTSERV.TEMPLE DOT EDU
NetWorker cc
discussion
<NETWORKER@LISTSE Subject
RV.TEMPLE.EDU> Re: [Networker] duplicate name;
pick new name or delete old one
29.01.2008 01:43
Please respond to
EMC NetWorker
discussion
<NETWORKER@LISTSE
RV.TEMPLE.EDU>;
Please respond to
Peter Viertel
<Peter.Viertel@MA
CQUARIE.COM>
Same here... Currently I cope with this by having a script that does
'nsrmm -o manual' automatically - I decided not to delete automatically
because there is a chance of a false positive...
Then I just sit down every now and then and verify and relabel all the
ones with X (recyclable AND manual).
> -----Original Message-----
> From: EMC NetWorker discussion
> [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On Behalf Of Vincent Lin
> Sent: Monday, 28 January 2008 1:48 AM
> To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
> Subject: Re: [Networker] duplicate name; pick new name or
> delete old one
>
> We are having the exact same problem. EMC/Legato have not yet
> provide us a solution after so many years.
> Our current work around is to setup a script to perform "#
> nsrmm -s <nsr-svr> -dy <volume-id>" manually.
>
> ----- Original Message ----
> From: Yaron Zabary <yaron AT ARISTO.TAU.AC DOT IL>
> To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
> Sent: Sunday, January 13, 2008 10:44:53 PM
> Subject: Re: [Networker] duplicate name; pick new name or
> delete old one
>
>
> I just started to experience the bug mentioned below.
>
> Does anyone know its bug ID ?
>
> Is there a fix available for 7.2.2 ?
>
> Thanks.
>
> Peter Viertel wrote:
> > This happens for me when the media database locking gets messed up,
> EMC
> > wont fix it for me, and instead suggest using 7.3+. I don't yet
> know
> > if that's true or not......
> >
> > For example when recycling a tape:
> >
> > 1. it reads the label.
> > 2. it rewrites the label on the tape.
> > 3. it goes to delete the old label out of the media db, but because
> of a
> > failure to get the lock it fails.
> > 4. it unloads the tape... A bit later it decides to recycle the
> tape
> > again.
> > 5. it reads the label.
> > 6. the label on tape doesn't match the one in the db, and it spits
> out
> > that duplicate label error you are seeing.
> > 7. and so on and so on etc.
> >
> > So - why does the media db get locked?
> >
> > I have found that you can get into this state if you are deleting a
> lot
> > of savesets at once (eg what happens at the end of a
> nsrstage run, or
> if
> > you have a script which is running nsrmm -d at lot of times
> in a row)
> > and this happens at the same time a bootstrap backup is happening.
> >
> > Once it happens you have to restart the nsr daemons to fix the lock
> > problem , but even then, you still have a quantity of tapes
> which are
> in
> > the state where the medaia db does not match the tape label, but I
> see
> > you've already figured out how to fix them.
> >
> > How to avoid it?
> >
> > Do you have adv_file and use nsrstage?
> > Make sure nsrstage is not running when bootstrap is due.
> > Do you have adv_file and manual 'staging' scripts?
> > Build into your script to watch for the bootstrap messages and
> > wait until the bootstrap is finished before deleting further
> savesets.
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: EMC NetWorker discussion
> >> [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On Behalf Of Rachel
> Polanskis
> >> Sent: Thursday, 27 September 2007 12:05 PM
> >> To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
> >> Subject: [Networker] duplicate name; pick new name or
> delete old one
> >>
> >> Hi,
> >> I think I have a problem.
> >>
> >> I am getting repeated instances of:
> >>
> >> duplicate name; pick new name or delete old one
> >>
> >> For freshly recycled and relabeled volumes.
> >>
> >> Should not be getting this for barcode managed media in an L700.
> >>
> >> If I have a Pool of volumes that expire, when we relabel them
> >> and then mark them as recyclable, usually the volume gets reused
> >> successfully. Or if the volume doesn't need relabling and
> >> just expires
> >> and is then marked recyclable.
> >>
> >> But lately, I am getting a spiral of doom situation where Legato
> >> will select a free volume for use in a backup and then
> >> after checking its label will print the dreaded:
> >>
> >> duplicate name; pick new name or delete old one
> >>
> >> And then it will proceed to grab the next free volume which
> >> will possibly have the same issue. And so, if I am asleep,
> >> in the middle of the night, the magical Legato spiral of doom
> >> will manifest and the system will continuously load and unload
> >> volumes forever, printing the dread mantra:
> >>
> >> duplicate name; pick new name or delete old one
> >>
> >> instead of doing real work (ie backing stuff up),
> >> until I intervene, run "nsrmm -yd <volid>" on the offending tapes
> >> and then manually relabel them.
> >>
> >> This is an onerous task, given we have thousands of volumes
> >> and I want a solution!
> >>
> >> Why does this happen with barcoded media? They are
> supposed to be
> >> unique ID's and relabeling or recycling a volume should
> "just work".
> >>
> >> Comments, suggestions, etc please....
> >>
> >>
> >> rachel
> >>
> >> --
> >> Rachel Polanskis Systems Admin, University of
> >> Western Sydney
> >> ADD Werrington North Campus (+61 2) 9678 7291
> >> <r.polanskis AT uws.edu DOT au>
> >> If you want a Nuclear Future, vote for Yesterday's Man.
> >> "Who do you trust?" - John W Howard
> >>
> >> To sign off this list, send email to
> >> listserv AT listserv.temple DOT edu and type "signoff networker" in
> >> the body of the email. Please write to
> >> networker-request AT listserv.temple DOT edu if you have any
> >> problems with this list. You can access the archives at
> >> http://listserv.temple.edu/archives/networker.html or
> >> via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
> >>
> >
> > NOTICE
> > This e-mail and any attachments are confidential and may contain
> copyright material of Macquarie Bank or third parties. If
> you are not the
> intended recipient of this email you should not read, print,
> re-transmit, store or act in reliance on this e-mail or any
> attachments, and
> should destroy all copies of them. Macquarie Bank does not
> guarantee the
> integrity of any emails or any attached files. The views or opinions
> expressed are the author's own and may not reflect the views
> or opinions of
> Macquarie Bank.
> >
> > To sign off this list, send email to
> listserv AT listserv.temple DOT edu and
> type "signoff networker" in the body of the email. Please write to
> networker-request AT listserv.temple DOT edu if you have any problems with
> this list. You can access the archives at
> http://listserv.temple.edu/archives/networker.html or
> > via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
>
>
> --
>
> -- Yaron.
>
> To sign off this list, send email to listserv AT listserv.temple DOT edu and
> type "signoff networker" in the body of the email. Please write to
> networker-request AT listserv.temple DOT edu if you have any problems with
> this list. You can access the archives at
> http://listserv.temple.edu/archives/networker.html or
> via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
>
>
>
>
>
>
>
> ______________________________________________________________
> ______________________
> Never miss a thing. Make Yahoo your home page.
> http://www.yahoo.com/r/hs
>
> To sign off this list, send email to
> listserv AT listserv.temple DOT edu and type "signoff networker" in
> the body of the email. Please write to
> networker-request AT listserv.temple DOT edu if you have any
> problems with this list. You can access the archives at
> http://listserv.temple.edu/archives/networker.html or
> via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
>
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type
"signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
