Actually, this may have some bearing on the problem I posted earlier, with
the configuration of the ACSLS robot. The install of the media server was
done by a coworker, so it's quite possible he simply accepted the default
installation and my media server is also acting as the media manager. The
coworker has since moved on to greener pastures, so I can't verify this with
him.
However, it would explain why the ACSLS robot can be configured on the media
server in the first place. Still don't understand why it can't be
configured on the Master, unless it's some kind of conflict with the
possible Media Manager installation on the media server. Any ideas how I
can verify if the Media server is in fact configured as a Media Manager as
well? And if so, how do I correct the configuration?
Ken Zufall
Technical Analyst
Phone: 216.471.3613
Pager: 440.303.1656
Fax: 216.491.4051
"It's not the most intellectual job, but I do have to know all the letters."
Vanna White
-----Original Message-----
From: John_Wang AT enron DOT net [mailto:John_Wang AT enron
DOT net]
Sent: Thursday, December 28, 2000 11:26 AM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] New Media Server and status
219's
Hello
Well, after rebooting the master server, both media servers
and the master
server now report the same thing for the bpstulist command
but the test backups
targeting the new storage unit still fails on a status 219.
It doesn't even
seem to leave the master server before it fails, i.e.: snoop
sessions don't show
any traffic triggered by issuing the manual backup. One
interesting thing is
that one of my production classes had been set up with use
any available for the
storage unit hence some of the backups attempted to use the
new media server
failing on status 37's which simply means that the client
did not recognize the
new server as being a server yet. This would mean that the
master server has
enough brains to address the new media server in the
wildcard mode but not when
the new storage unit is explicitly requested.
I'm thinking that it may be because this site has the volume
database not on the
master server but on the first media server. Probably out
of default, I'll bet
that they just loaded one master and one media server and
the default
installation of a media server always places a volume
database locally. Most
sites would've installed their first server as both media
and master hence the
volume database would be co-located with the master server.
I've already
noted strange behaviour in this cluster such as the
Netbackup catalog backups
not recognizing media id's in the media manager to back up
to, which I suspect
is due to the separation of master from the volume database.
If the problems stems from the location of the volume
database, how would I move
the volume database to the master server? Obviously it
already has data in it
so I can't just auto-populate a new database but could I
shut down all the
daemons, tar the /usr/openv/volmgr/database directory over,
reconfigure with
tpconfig and restart the daemons? Does it sound plausible
that the status
219's from attempting to direct the backups specifically to
the new storage unit
may be caused by the volume database not being local to the
master server?
Regards,
John I Wang
Sr. Systems Engineer
Steverson Information Professionals
---
Enron Broadband Services
3 Allen Center 3AC872e
ph (713) 345-6863
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
