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: <[EMAIL PROTECTED]> 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. -------------------------------------------------------------------------------------- _______________________________________________ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu