Hey there,
Fans of useful information, skip straight to THE SITUATION (hyperlinked and in caps for easy case-sensitive searching, NOT BECAUSE I'M SCREAMING OR ANYTHING!!! ;) as soon as you grow tired of the preamble.
I think today's post's title represents the first time I've ever so blatantly hyphenated part of an awkward sentence in order to make it seem intelligible (and not so incredibly long). As I read it now, I wonder what I was thinking. Much the same as I do every time I proofread my work. The only certain thing in this world is that I will find fault with this sentence ( probably, yes, this entire paragraph ) when I proof-read it later ;) Now that my neuroses have been shoved out the back-door, we'll get on with it.
Today we're going to look at a quick way to adapt an existing Veritas/Symantec NetBackup setup to a new set of peripherals on Solaris Unix. Due to the sheer amount of output options (which may or may not be of any use to you ever) available in almost all of NetBackup's commands, I've made my examples somewhat lengthy (although, I've cut a lot out. Those points are somtimes highlighted by ellipses - not to be confused with the ellipses used to convey the sense that my mind is wandering and my inner-or-outer-voice is trailing off into an inaudible mutter... Ellipses are really hard to convey emotion with... Thank God for the winky-eyed thingy - here's hoping I've been doing it to the correct side my entire career ;)
So, for today, we're going to assume you're running Veritas/Symantec NetBackup, approximately version 6.5.x. We'll also assume that you have NetBackup fully installed on Solaris x.x and may or may not have any number of add-on's (like Oracle or Vault modules, etc). The add-on's generally won't play into this, so we're going to forget they exist. Removing extraneous elements from the equation (if you can reasonably afford to discount them) is the best way to troubleshoot (which we won't be doing today, but I had to include that line to set up the next post... ellipses again ;) Ideally, you'd only have NetBackup running, with no add-on's or extras except the Standard License. I don't know how often that happens. I've never worked any place that didn't, at least, have multiple licenses for backing up multiple OS's. But, there you have it. Your basic setup.
Also, probably important, today we're going to look at the way things "should" go for you (with multiple commands or options to explore where possible). Tomorrow, and/or the day after, we'll look at how to figure out (and fix) what's wrong when things "don't" go as they should.
THE SITUATION: Your old tape robot, along with the drives inside it has inexplicably gone bad, you've spent hours and exhausted your support contract trying to fix it somehow, but, ultimately, you're left facing the fact that your trusty old steel-and-plastic-jukebox just isn't going to come back. Ever. If you're lucky, your warranty allows for replacement of the tape robot (A Tape Loading Device or TLD) and its internal drives (2, for now, to keep things simple - hcart2 drives, just because). Worst case you've purchased suitable replacements that match the specifications listed in the previous sentence.
Probably, your /dev/rmt directory is populated and you may even have some other logical paths created on your Solaris system that are no longer valid. Once you've connected your "MaxTape24" TLD (which exists only in my imagination, with it's two internal "FACTOTUM-TD2" drives, both working properly according to the on-board diagnostics), you should be able to verify that your system (at the very least) can recognize the TLD and, hopefully, the drives inside it. Assuming all of the equipment is good, and that it's been hooked up (however you like to daisy-chain it) properly, this shouldn't be an issue. You may choose to run:
host # devfsadm -C
before proceeding, to check for new symbolic links that need to made in your hardware device tree (and, with the -C option, remove ones you no longer need - Operating System's discretion, unfortunately), although it may not be necessary.
FINDING THE NEW HARDWARE WITH NETBACKUP FIRST: Now, contrary to what it seemed like I was leading in to, we're going to try to get NetBackup to do all the OS-work for us today (because, if it works, it's f'ing brilliant. Good job. Go home and relax :) Actually, you could probably look at this more as a way of giving NetBackup a good kick in the arse. The kind of kick that makes it stand up and take account of its surroundings ;) A good way to get started is to run the following at the command line (Oh yes, there will be no GUI instruction in these posts. If you use the GUI - which is okay - just right click on the type of thing you want to do something to and select whatever seems to be the most reasonable option from the drop-down menu. ...last on that:)
host # /usr/openv/volmgr/bin/sgscan <-- I would recommend including /usr/openv/volmgr/bin, /usr/openv/netbackup/bin and /usr/openv/netbackup/bin/admincmd in your PATH variable if you spend a lot of time working with NetBackup at the command line./dev/sg/c0t0l0: Disk (/dev/rdsk/c0t0d0): "SUZUKI MBB2147RCSUN146G"
/dev/sg/c0t1l0: Disk (/dev/rdsk/c0t1d0): "SUZUKI MBB2147RCSUN146G"
/dev/sg/c0t2l0: Tape (/dev/rmt/1): "BMI FACTOTUM-TD2"
/dev/sg/c0t3l0: Cdrom: "Hyundai DV-W28E-R"
/dev/sg/c1t0l0: Changer: "TLDHAUS MaxTape24"
/dev/sg/c1t1l0: Tape (/dev/rmt/0): "BMI FACTOTUM-TD2"
Your output may differ (even if you run this command on the same box, since I faked up the output to protect the guilty ;), but basically, this output is positive. You'll notice that sgscan has picked up a bit more than just your new TLD and its drives but that's okay. As it stands, this output is very positive, in that you can see that /dev/rmt/0 and /dev/rmt/1 have been properly mapped to the TLD's internal tape drives and the "TLDHAUS MaxTape24" TLD has been properly identified.
Other commands you could use to, basically, get the same information (or peace of mind) would include (but not be limited to) vmoprcmd, tpconfig and tpautoconf. A few examples at the bottom of the post, with the same setup as above (some whitespace has been clipped to save the virtual trees).
And that's it for today. Tomorrow we'll look at several commands (including some we're using today, but with different options) that can be used to "find" those drives if the system doesn't discover them automatically (the first thing you can try is "devfsadm -C" as noted above, followed by another sgscan).
Until then, enjoy the output and we'll continue on tomorrow. Here are a couple of handy anchor-href's for you, so you don't have to try to figure out where the command you're interested in is hiding out amongst all the flotsam below :)
vmoprcmd
tpconfig -d
tpconfig -dl
tpautoconf -t
tpautoconf -a
Cheers,
vmoprcmdhost # vmoprcmd
HOST STATUS
Host Name Version Host Status
========================================= ======= ===========
host 652000 ACTIVE
host 652000 ACTIVE-DISK
PENDING REQUESTS
DRIVE STATUS
Drive Name Label Ready RecMID ExtMID Wr.Enbl. Type
Host DrivePath Status
=============================================================================
Drive000 No No No hcart2
host /dev/rmt/0cbn TLD
Drive001 No No No hcart2
host /dev/rmt/1cbn TLD
tpconfig -d
host # tpconfig -d
Id DriveName Type Residence
Drive Path Status
****************************************************************************
0 Drive000 hcart2 TLD(0) DRIVE=1
/dev/rmt/0cbn
1 Drive001 hcart2 TLD(0) DRIVE=2
/dev/rmt/1cbn DOWN
Currently defined robotics are:
TLD(0) robotic path = /dev/sg/c1t0l0
EMM Server = host
tpconfig -dl
host # tpconfig -dl
Currently defined drives and robots are:
Drive Name Drive000
Index 0
NonRewindDrivePath /dev/rmt/0cbn
Type hcart2
Status UP
SCSI Protection SR (Global)
Shared Access No
TLD(0) Definition DRIVE=1
Serial Number 1234567890
Drive Name Drive001
Index 1
NonRewindDrivePath /dev/rmt/1cbn
Type hcart2
Status UP
SCSI Protection SR (Global)
Shared Access No
TLD(0) Definition DRIVE=2
Serial Number 0987654321
Currently defined robotics are:
TLD(0) robotic path = /dev/sg/c1t0l0
EMM Server = host
tpautoconf -t
host # tpautoconf -t
TPAC60 BMI FACTOTUM-TD2 4C60 1110365040 -1 -1 -1 -1 /dev/rmt/0cbn - -
TPAC60 BMI FACTOTUM-TD2 4C60 1110364981 -1 -1 -1 -1 /dev/rmt/1cbn - -
tpautoconf -a
host # tpautoconf -a
TPAC60 - - - -1~-1~-1~-1 2 - - - 0 - - - - - - - 0 0 - - host 4 - - 0 - - - -
TPAC60 Drive000 BMI~~~~~FACTOTUM-TD2~~~~~4C60 /dev/rmt/0cbn -1~-1~-1~-1 1 0 0 2 8 10 - - - 1110364981 - 3 0 0 - - host 0 - - 0 - - - -
TPAC60 Drive001 BMI~~~~~FACTOTUM-TD2~~~~~4C60 /dev/rmt/0cbn -1~-1~-1~-1 1 0 0 1 8 10 - - - 1110365040 - 3 0 0 - - host 0 - - 0 - - - -
TPAC60 0 TLDHAUS~~~~MaxTape24~~~~~~~310A /dev/sg/c1t0l0 -1~-1~-1~-1 0 0 0 - 8 - 23 2 1 TLDHAUS_1_9A0206A12 - 2 0 - host host host 0 - - 0 - - - -
, Mike
Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.
