This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C3BE79.86691620
Content-Type: text/plain;
charset="iso-8859-1"
When you remove the tape from the original robot, you have to then update
your inventories so the tape is marked as out-of-library. When you inject
the tape into the other robot, it'll then be marked correctly. Same from
moving it from remote to local.
In short, every move from robot to robot must include an out-of-library
inventory in-between the two robotic locations.
The remote robot does have the master server in common with the local robot,
right? That'd be a requirement. If they are different media servers on
each robot, you'll have to move the media information from the one media
server to the other. By default, NB will try to restore the tape on the
media server that wrote the tape.
You can move the media DB info with "bpmedia -movedb -ev <tapenum>
-oldserver <orig_media_svr> -newserver <new_media_svr>"
-M
-----Original Message-----
From: Dennis Dwyer [mailto:dfdwyer AT tecoenergy DOT com]
Sent: Tuesday, December 09, 2003 6:53 AM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] Moving an Active Tape From One Robtic Library to
Another
Hopefully someone has seen (or done this before)
Environment:
NBU 4.5 (FP3) for Solaris
(3) Sun E450 Servers (1-master, 2-media)
(2) STK L700 Robotic Libraries
(1) STK 9710 Robotic Library
We have an STK L700 library located at a remote site about 70 miles away.
Because of some retention period issues, we removed some of the full tapes
from this robot and replaced them with new scratch tapes and transported the
removed tapes back to the data center for long-term storage. Naturally,
someone wanted something restored from a tape that was formerly in the
remote robot and we thought, why not just put it in the local 9710 rather
than drive 70 miles. The process on how to do this correctly is not very
clear and when we started the restore it was still looking for the tape to
be in the remote robot.
Anybody have a fool-proof, sure fire procedure that they want to share on
how to get a scenario like this to work? I hate to think that these 200
tapes that we've relocated will have to be expired and imported into the
alternate library before we can restore from them or at the very least, we
have to drive 70 miles and reload them back into the original library.
Any insight would be greatly appreciated.
Regards,
Dennis Dwyer
Tampa Electric Company
------_=_NextPart_001_01C3BE79.86691620
Content-Type: text/html;
charset="iso-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1276" name=GENERATOR></HEAD>
<BODY style="MARGIN-TOP: 2px; FONT: 10pt Batang; MARGIN-LEFT: 2px">
<DIV><SPAN class=566352017-09122003>When you remove the tape from the original
robot, you have to then update your inventories so the tape is marked as
out-of-library. When you inject the tape into the other robot, it'll then
be marked correctly. Same from moving it from remote to
local.</SPAN></DIV>
<DIV><SPAN class=566352017-09122003></SPAN> </DIV>
<DIV><SPAN class=566352017-09122003>In short, every move from robot to robot
must include an out-of-library inventory in-between the two robotic
locations.</SPAN></DIV>
<DIV><SPAN class=566352017-09122003></SPAN> </DIV>
<DIV><SPAN class=566352017-09122003>The remote robot does have the master
server
in common with the local robot, right? That'd be a requirement. If
they are different media servers on each robot, you'll have to move the media
information from the one media server to the other. By default, NB will
try to restore the tape on the media server that wrote the tape.</SPAN></DIV>
<DIV><SPAN class=566352017-09122003></SPAN> </DIV>
<DIV><SPAN class=566352017-09122003>You can move the media DB info with
"bpmedia
-movedb -ev <tapenum> -oldserver <orig_media_svr> -newserver
<new_media_svr>"</SPAN></DIV>
<DIV><SPAN class=566352017-09122003></SPAN> </DIV>
<DIV><SPAN class=566352017-09122003>-M</SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT
face=Tahoma>-----Original Message-----<BR><B>From:</B> Dennis Dwyer
[mailto:dfdwyer AT tecoenergy DOT com]<BR><B>Sent:</B> Tuesday, December 09,
2003
6:53 AM<BR><B>To:</B> veritas-bu AT mailman.eng.auburn DOT
edu<BR><B>Subject:</B>
[Veritas-bu] Moving an Active Tape From One Robtic Library to
Another<BR><BR></FONT></DIV>
<DIV>Hopefully someone has seen (or done this before)</DIV>
<DIV> </DIV>
<DIV>Environment:</DIV>
<DIV> </DIV>
<DIV>NBU 4.5 (FP3) for Solaris</DIV>
<DIV>(3) Sun E450 Servers (1-master, 2-media)</DIV>
<DIV>(2) STK L700 Robotic Libraries</DIV>
<DIV>(1) STK 9710 Robotic Library</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>We have an STK L700 library located at a remote site about 70 miles
away.
Because of some retention period issues, we removed some of the full tapes
from this robot and replaced them with new scratch tapes and transported the
removed tapes back to the data center for long-term storage. Naturally,
someone wanted something restored from a tape that was formerly in the remote
robot and we thought, why not just put it in the local 9710 rather than drive
70 miles. The process on how to do this correctly is not very clear and when
we started the restore it was still looking for the tape to be in the remote
robot.</DIV>
<DIV> </DIV>
<DIV>Anybody have a fool-proof, sure fire procedure that they want to share
on
how to get a scenario like this to work? I hate to think that these 200 tapes
that we've relocated will have to be expired and imported into the alternate
library before we can restore from them or at the very least, we have to
drive
70 miles and reload them back into the original library.</DIV>
<DIV> </DIV>
<DIV>Any insight would be greatly appreciated.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV> </DIV>
<DIV>Dennis Dwyer</DIV>
<DIV>Tampa Electric Company</DIV></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C3BE79.86691620--
|