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
|
