Veritas-bu

[Veritas-bu] New Media Server and status 219's

2000-12-28 11:26:13
Subject: [Veritas-bu] New Media Server and status 219's
From: John_Wang AT enron DOT net John_Wang AT enron DOT net
Date: Thu, 28 Dec 2000 10:26:13 -0600
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






<Prev in Thread] Current Thread [Next in Thread>