Forum Discussion

sayedmackin's avatar
9 years ago

Master server build and catalog import

we are in the process of building a new master server on RHEL 6 with NBU version 7.5.0.1 and then import the catalog which is stored in the DD connected thru SAN.  Once the catalogue is imported swap the master servers and have the newly built master server control the environment by renaming all the parameters like name, IP, domain, etc. Do some test backups and restores and then upgrade it to NBU version 7.6.1.

Please let me know step by step approach to doing this as it is very critical for the environment, as missing some steps might make the entire upgrade process useless.

Waiting for some valuable information from all the experts.

 

  • "we are in the process of building a new master server on RHEL 6 with NBU version 7.5.0.1

    and then import the catalog which is stored in the DD connected thru SAN. 

    Once the catalogue is imported swap the master servers and have the newly built master server control the environment by renaming all the parameters like name, IP, domain, etc. Do some test backups and restores and then upgrade it to NBU version 7.6.1."

     

    You don't import a catalog, you recover the catalog from a catalog backup.  Apologies if this is what you meant.

    Next - you say you will rename the server after the 'import' - this is not possible.  A master server cannot be renamed (unless you engage consulting services from a partner, using the catman tool).

    The IP does't matter, as long as everything resolves to the correct names, that will be fine.

    In summary.

    You have to build the new master using the same version of NBU as you are recovering from.

    The path NBU is installed to has to be identicle, so if it's installed in /usr/openv/ then the new install has to be the same.

    You cannot rename the master, so it has to be built with exactly the same name as the original (else it will fail).

    You do not import catalogs, you recover them - this is very easy from tape or basic disk (you create the basic disk where the catalog backup is using the same name as originally).  It's a bit harder if it is on advanced disk as the media id (eg. @aaaaf) it was on originally might be different on the new server - there are ways around it though.  There was a bug somewhere around 7.5 that could cause catalog recovery to fail from OST/ advanced disk (well, partly fail) - again it could be worked around.  To perform catalog recovery you also need the DR file , the steps are all documented in the disastor recovery guide.

    You need to clarify what you meant by 'import catalog', as I say, you may have menat 'recovery' but then again, you may have had something else in mind.

  • "we are in the process of building a new master server on RHEL 6 with NBU version 7.5.0.1

    and then import the catalog which is stored in the DD connected thru SAN. 

    Once the catalogue is imported swap the master servers and have the newly built master server control the environment by renaming all the parameters like name, IP, domain, etc. Do some test backups and restores and then upgrade it to NBU version 7.6.1."

     

    You don't import a catalog, you recover the catalog from a catalog backup.  Apologies if this is what you meant.

    Next - you say you will rename the server after the 'import' - this is not possible.  A master server cannot be renamed (unless you engage consulting services from a partner, using the catman tool).

    The IP does't matter, as long as everything resolves to the correct names, that will be fine.

    In summary.

    You have to build the new master using the same version of NBU as you are recovering from.

    The path NBU is installed to has to be identicle, so if it's installed in /usr/openv/ then the new install has to be the same.

    You cannot rename the master, so it has to be built with exactly the same name as the original (else it will fail).

    You do not import catalogs, you recover them - this is very easy from tape or basic disk (you create the basic disk where the catalog backup is using the same name as originally).  It's a bit harder if it is on advanced disk as the media id (eg. @aaaaf) it was on originally might be different on the new server - there are ways around it though.  There was a bug somewhere around 7.5 that could cause catalog recovery to fail from OST/ advanced disk (well, partly fail) - again it could be worked around.  To perform catalog recovery you also need the DR file , the steps are all documented in the disastor recovery guide.

    You need to clarify what you meant by 'import catalog', as I say, you may have menat 'recovery' but then again, you may have had something else in mind.

  • Here are the HOWTO TNs:

    Using catalog backup and recovery to transfer NetBackup catalogs between UNIX or Linux master servers as part of a hardware refresh
    http://www.veritas.com/docs/000041077

    Using catalog backup and recovery to transfer NetBackup catalogs between Windows master servers as part of a hardware refresh
    http://www.veritas.com/docs/000041076

    How to migrate the NetBackup catalog information from one platform to another (UNIX to Windows or vice versa), rename a Master Server, cluster an existing Master Server, or merge multiple NetBackup domains.
    http://www.veritas.com/docs/000026956

     

  • Thanks Martin for the information given.

    Importing the catalog i meant that after the NBU is installed in the new master server, the next would be to have the catalog information updated in the new master server from the catalog backup that is already present from the old or current master server.

    Regards,

    Sayed

     

  • Sure, that is fine and I thought you 'might' have meant that.

    Please take into consideration the other points I made and those TNs highlighted by Marianne.

    Basically, the new server has to be identicle (apart from IP) for a catalog recovery to work, install paths, path of where the NBDB lives, hostnames etc ...

     

  • Have been forced to change just the suffix on a master, because of an change of AD. Not something I remember fondly, took a quite a while before all the issues had be migated/solved and this was a pretty basic system without deduplication or SLPs.

    Think it would be safer to install the new master under the new name and then import the images or alternatively replicate them from the old master, these approaches also have the benefit of being supported by Veritas as far as I know.