Im a bit late in on this conversation.

Jihm

I have done move of media and catelog from one master in to a existing
different master. I moved all tapes from a solaris master into a windows
master.

I did get help from veritas support but at one stage but when some things
didnt work out another support staff said "he should not have done this
under support"

Perhaps you are best to pay for consulting services.

Below is the mail I got from veritas support on the issue. Only the name
of the veritas support staff has been removed.

Now I can hardly remember what I did:

I did manually copy over indexes for clients.
I did manually edit the pool databases file. I had no pools ID clashes and
I think that turned out to be quite critical.

I did run commands like "bpmedia -m  ADI694  -movedb -oldserver
OLDSERVERNAME -newserver NEWSERVERNAME". I had to do some set up for this
first.

I used commands like: "vmadd -m  HFG933  -mt dlt -p  17" where I got info
for the command from the output of vmquery

one gotya I had was needing to put the old server in the "restore failover"
list of the new server.

I definately had a few issues and was wishing that I had got veritas to do
it under contract.


Subject: VERITAS Support: Case ID 230-061-782
To: <bevan.broun at adi-limited.com>

Hi Bevan,
=20
now fully understanding the "challenges" ahead for you :), below is some
helpful information of the various Netbackup databases you will be
attempting to merge onto the final Netbackup master server, all at the
same level of NBU 5.1.
=20
Have a read of the following and I'll await your feedback. I have
included various extracts from different internal documents as there is
no Public Technote to do what you are doing - and the official take on
it is it is a "Consulting" issue rather than a "Support" responsibility,
but I am happy to assist you where I can :)
=20
- Chris.
--------------------------
Netbackup Databases invovlved:
----------------------------------------------
There are six main databases that need to be considered when
reconfiguring a NetBackup environment:* The image database - this is a
flat file structure held on the NetBackup master server.  In general
this database can be moved from one location to another with a simple
copy operation.  However it is important to remember that this database
contains links to the media database, which need to be kept consistent.

* The media database - the only distributed database in most NetBackup
environments.  While it is possible to manipulate this database by
various editing techniques there are no NetBackup CLI options to modify
it.  It is therefore recommended that you endeavor to keep the media
database consistent and bring the image and volume database in line with
it.

* The policy database - another flat file structure that can simply be
copied between master servers (provided, of course, that the same class
name is not in use on both servers).  Be sure to update the storage unit
information associated with classes when moving them between servers. *=20
=20
The volume database - volume database information can be extracted and
updated by using the vmquery command.  When merging two environments the
best approach is to use vmquery to extract information from one volume
database and then a combination of vmadd and vmquery -assignbyid to
create corresponding information in the other volume database.  Note
that it is not possible to carry over tape usage information from one
database to another.

* The pool database - this database usually consists of a relatively
small number of entries.  The important thing to bear in mind is that it
is the number associated with each pool record, not the name, that is
used to link to the other databases.  This means that, unless the pool
records have been added in exactly the same order in two environments,
some tapes are likely to change pools following a merger.

* The global device database - this database contains information about
all devices on all media servers in a domain.  Storage units usually
change as a result of mergers and splits so it is simpler to define the
storage units you require rather than attempting to export and import
information. You may also choose to merge the jobs and error databases
if required but this is not essential and is not covered in this
document.
--------------------------------------------
=20
Merging Master Servers:
--------------------------------------------
In the interests of simplifying the management of a NetBackup
installation customers often seek to combine two or more domains under a
single, more powerful master server.  In most cases this presents few
problems but it is important to ensure that there is no risk of conflict
before starting such a merge When merging master servers you are
concerned with the following aspects of the NetBackup database:=20
* Image database
* Policy database
* Client database
* Global device database

Note: the merging of the volume or pool databases have not yet been
discussed here.  This is being treated as a separate subject as the
volume and pool databases. Merging the image database is a simple task
as this a flat file structure with all the backups for a given client
located in a tree under the client name sub-directory.  Assuming that
all the client names used by both servers are unique, the image
databases can be merged by simply copying the directory tree from one
server to another.   Merging the global device database (globDB)
involves using the vmoprcmd command to scan the media servers and direct
the information gathered to the new master server.
------------------------------------------------------------------------
---
=20
Merging Volume Database Hosts:
---------------------------------------------------------
When merging two NetBackup domains you will, initially, end up with two
volume database hosts.  Ideally these should be combined to form a
single database host, however this may not be possible for the following
reasons:
1) The pool numbers assigned to pool names in the two domains cause a
conflict
2) Identically numbered tapes are in use in both environments.=20
The important thing to remember about pools is that it is the pool
number, not the pool name, that relates the image, media and volume
databases. The best way to merge two or more volume database is by
exporting the contents of one database and importing it into the other.
For the purposes of this document the terms 'source' and 'target'
database are used to denote the two databases.

Merging of the pool databases is best achieved by simply creating the
missing pool entries in the target database, making sure that the pool
numbers are correct as well as the names. Before starting to merge two
or more volume database hosts, minimise the number of tapes and pools in
the source volume databases wherever possible.
Ways of doing this include:
* Deleting all tapes from the global scratch pool
* Deleting unassigned tapes from other pools
* Deleting all empty pools

Remember that unused tapes in a robot can always be re-added after the
merge by doing a robot inventory. The biggest problem you are likely to
encounter when merging two volume databases is that the pool numbers
used on the source system do not match the pool numbers used on the
target system.

If the global scratch pool on the source database conflicts with an
active pool on the target database simply delete this pool (remember you
should already have deleted all the tapes from it, these can be added to
the target global scratch pool with a simple inventory operation).  If
the global scratch pool on the target database conflicts with an active
pool on the source database, delete all the tapes in the global scratch
pool and then delete the pool record.  This will release the pool
number.  Now create a pool record with the name of the active pool on
the source database, assuming there are no lower 'free' numbers in your
pool database, this pool will assume the correct number.  Then create a
new pool record for the global scratch pool. For example, if the global
scratch pool on the target machine is pool 6 and pool 6 on the source
machine in NT_Backups, delete the global scratch pool on the target
machine and then add an NT_Backups pool.  This pool should assume the
number released by deleting the global scratch pool, i.e. 6.

If an active pool on the source system has a different name to the
corresponding active pool on the target system the name of the pool
associated with the tapes on the source system will change after the
merger. This is because the pool number associated with the media will
remain the same but the pool name associated with that number would be
different. If the two volume databases to be merged contain tapes with
identical names, then extra care must be taken to ensure that the active
state of the tapes is correctly preserved, thus active tape entries in
the source database must replace inactive tape entries in the target
database but not vice-versa.

Note:  It is not possible to merge two volume databases when the same
tape number is active in both databases.  The tape and its contents must
be
expired in one location before the merge can take place. The following
commands can be used to obtain information about a tape from the media
database and then add it to the volume database:

bpmedialist -ev <tape> - l | awk '{print $1,$5,$13}'
This will obtain the tape label ($1), the assigned date in Unix time
($5) and the pool number ($13).  These parameters can be fed into vmadd
and vmquery to set the tape attributes correctly in the volume manager
database:

vmadd -m $1 -p $13
adds the volume in the correct pool (you can also do this with a robot
inventory) but the most important command here is :

vmquery -assignbyid $1 <media type> $13 0 $5
This will ensure that the tape has the correct pool and media assigned
date
-------------------------------------------
=20
Media Servers:
--------------------------
NetBackup media servers have two important databases associated with
them, the local device database and the local media database (mediaDB).
In general, when you move a media server the devices move with it so
changes to the device database are not required.  The media database
also moves with the media server but is linked to the image database
held on the master server.  It is therefore important to ensure that the
image database is kept in sync with the media database.  When moving
media servers between domains, make sure that the media database and the
corresponding image database entries on the master server are consistent
before moving them.

Maintaining consistency between the image and media databases deals with
the consistent updating of media database entries and the associated
image database entries.  This is an important operation as the image
database records the name of the server that hosts the associated media
database and this information must remain consistent to ensure that
tapes are actually expired when empty. When moving media between media
servers, whether in the same environment or as part of a merge or split
operation, it is crucial to ensure that the image database records match
the current status so that a) the volume database can be bought into
line and b) images and tapes can be reliably expired.  The key commands
to be used when carrying out operations of this kind are:
1) bpmedialist -h <old server>
2) bpmedia -m <volume> -movedb -oldserver <old server> -newserver
<newserver>
The nature of the bpmedia -movedb command makes it preferable to have
the old and new media servers reachable within the same NetBackup domain
(and able to talk to each other) at the time of the move activity.  If
this is not possible (for example because the server is being renamed
rather than replaced with a new machine) the move can be carried out as
a two-stage operation using the master server as a staging point.  In
this case, logically move the tapes from the old server to master
server, decommission the old server, commission the new server and then
logically move the tapes from the master server to the new server (be
sure to keep a list of the tapes so that you move the right ones to the
new server).

Adding media servers to the global device database:
Device information from the media servers is added to the global device
database at installation time by using the command:
vmoprcmd -h ${host} -autoconfig "-set_gdbhost ${gdbhost}"
where {host} is the media server name and {gdbhost} is the global device
database host, usually the master server. This command can be used after
a merge to add device information in the same way.
--------------------------

-- 
Bevan Broun
Systems Engineer
THALES
Services Division
W: (02) 9562 2861
M: 0407 225 492
F: (02) 9562 2857


DISCLAIMER:---------------------------------------------------------------------------
This Email may contain confidential and/or privileged information and is 
intended 
solely for the addressee(s) named. If you have received this information in 
error, or
are advised that you have been posted this Email by accident, please notify the 
sender by return Email, do not redistribute it, delete the Email and keep no 
copies.
--------------------------------------------------------------------------------------