I've had to do this a couple times. The following is some info I got from 
Veritas tech support.

Rasana


     Server hostname changes and moving NetBackup and Volume Manager
     databases to a different server.

     Modification of the hostname of a NetBackup server to which backup or
     archive images have been written will result in the inability to easily
     restore from those images. This is because the server's hostname is
     associated with the image in the NetBackup image database.

     Restoring from these images will involve manual manipulation of
     database files.

     Another problem will be encountered when the images expire. NetBackup
     will be unable to delete these expired images, and an error will be
     noted in the error log.

     Moving NetBackup and Volume Manager databases to another server is not
     recommended without involving an OpenVision consultant to determine the
     extent of changes which would need to be made based on your specific
     configuration and requirements.

     This is fyi, use it at your own discretion.


1.  Backup EVERYTHING

2.  Use bpimage command to convert to new host name.

3.  Change vmhost on master and all slaves to new host name.

4.  In bp.conf on ALL systems, change the top server name to new name

5.  Change the client name on master's bp.conf to the master's new name
    or the master won't be able to backup itself.


     1.  Backup NetBackup database on existing master:

     a) From xbpadm, select the Job Monitor to make sure no backups are in
     process or in the queue. Also, stop the NetBackup Request Daemon,
     bprd, to make sure no other jobs get initiated.
     From xbpadm, select Terminate NetBackup Request Daemon.

     b) To make sure you have a current backup of the NetBackup database,
     from the File option on xbpadm on the existing master,
     select "Immediately Backup NetBackup DB."
     Make sure the media identified in the "Change NetBackup DB Attributes"
     window, is in a standalone drive or in the robot, if it is robotic
     media. Proceed with the NetBackup DB backup.


        Start conversion process:


     c) Run /usr/openv/netbackup/bin/admincmd/bpimage -newserver <name>
     -oldserver <name> -id <media id>.  Note see page 311 of
     NetBackup SysAdmin Guide.


     d) Change the new master bp.conf so that the new master is the first
     server entry. Make sure it has all the server related parameters that 
were
     in the existing master server's bp.conf file. Change the client info in
     the bp.conf to reflect the new master name.

     2. Update the bp.conf on the slave servers and clients so that the new
     master server hostname is the first server entry in all the bp.conf
     files.

     3. Using the xdevadm GUI from the new master to update robot
     and drive definitions, particularly the Volume Host Name. On the new
     master the robot/drive configuration will now reflect what the
     configuration was on the old master.


        a) Using xdevadm, select Robot, Change VM Host, make sure the
     volume manager host name is the new master host name. When you
     update the volume manager host name for the robot, it automatically
     updates the VM host name for all the drives configured in that robot
     that are connected to that machine.


     4. On master, use the xbpadm GUI to check that the
     hostname field in the storage unit window for all storage units
     reflects the hostname of the machine to which the drives in the
     storage unit are connected.

     5. On the new master, using xvmadm, make sure that the volume
     manager database associates the correct server hostname with volumes
     which are defined to be in a robot.

     To modify the hostname, you must `move' the volumes that are in a
     robot to  non-robotic state and `move' them back  into the robot. Use
     the Action, Move Volumes option of the xvmadm GUI. If all the
     volumes are in an ACS robot, in this case, there is no need to do this
     step.

     In the case of volumes in an ACS robot, the robot host name will
     remain as the hostname of the machine running ACSLS (storagetek), so
     there is no need to `move' volumes in and out of the robot. However,
     if there are volumes in non-ACS robots, you need to do this
     step just for those volumes.

     6. Complete configuration of  the new master server:

        a) using xbpadm, choose  "Change NetBackup Configuration" from the
     File menu.  Review the settings, such as E-mail address, which may now
     be different on the new master.

        b) review the bp.conf file on the new master to ensure the
     server only settings, such as ALLOW_MEDIA_OVERWRITE are consistent
     with the existing master server settings.


Note:  If you think you may be doing this often, try:


        1. Set up an alias for your host in the /etc/hosts file.  You must
        have your master named as the the alias.

        2.  Whenever you change your host name, change the name associated
        with the alias.





Subject:    Re: Changing the Master Server Name

There is not a simple straight forward answer to your question.  It
depends on several factors that aren't included with the original question.

Is the original master also a media server?

Is the new master the same os type (sun to sun, hp to hp)?

Will the original master still be available on the network after the move?

If the original master was not a media server and both the
old and new are similar types, it is a relatively simple task.

If you want to provide a more detailed scenario I will try to
give you a more detailed answer.

In all cases the first step is a full netbackup database backup and a
backup of /usr/openv.

If the original master is not a media server, both servers are similar
platforms and the original master remains available...
  1. Stop all netbackup/volmgr process on master and slaves.
  2. Install netbackup server software on new master.
  3. Move image database and vsnDB to new master.
     This can be done with bprecover of database backup
     or simple ftp.
  4. Change bp.conf on every system (new master, all media servers
     and all clients) to reflect the name of the new master.
  5. Change the volume database host on all media servers to reflect
     the name of the new master.
  6. Move the poolDB to the new master.

These same basic steps apply if the master was also a media server but
there are several additional steps required.  These involve handling the
mediaDB that relates to media written on this server.  There are also a
couple of steps involved to 'move' the volumes from the old robot on the
original master/media server and to the new robot on the new master/media
server.

  1. Move all volumes in the old robot to non-robotic.
  2. Define a new robot on the new master/media server.
  3. If barcodes are used, inventory the new robot.  This causes the
     volumes to now be resident on the new server.
  4. Move the mediaDB from the original master to the new master.
  5. Run bpimage -newserver (name) -oldserver (name)
  6. Change all storage units that were going to old server to
     use the new server.

There are always things that come up so we strongly suggest getting
consulting involved in all but the most simple changes.  The above steps
should be close but I am not in a position to try them so use them as
a guideline, not gospel.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com