Forum Discussion

mturbo's avatar
mturbo
Level 2
13 years ago
Solved

Right order to upgrade & migrate Netbackup in clustered enviroment

Hi,

We are going to upgrade Netbackup 7.1 to 7.5 and then to 7.5.0.4 but which is correct order to perform upgrade and migration in clustered enviroment as manuals instructions differs from other

We have two node, hot and cold...

 

* Cluster guide:

Before cluster is starded:      

On each inactive node to which NetBackup may failover, install the NetBackup server software.

Note the following:  Follow the instructions for how to upgrade NetBackup as described in the Symantec NetBackup Installation Guide

* Installation guide:

Do not start the NetBackup job-related processes until all nodes are upgraded

* But Upgrade guide:

This step applies only to cluster installations.

After all image metadata migration processes have completed on this master server,
for other master servers in the cluster, you can update the remaining nodes to
NetBackup 7.5 by using the normal cluster upgrade process. For complete details,
see the NetBackup 7.5 Installation Guide.
 
So, is migration done before or after all nodes are upgraded, because it reguire netbackup service be up and running ?
 
And how about rollback if everything goes terribly wrong....We are planning to do for rollback purpose Veritas cluster split after system is down for db mounts and tar /usr/openv/*
 
Thats why wondering could we do upgrade with rollbackup plan as follow:
 
- shutdown services (cluster offline, freeze)
- split db disk and tar binaries to "backup"
- upgrade hot node
- start services on hotnode and migrate
- verify its working
- shutdown
- upgrade cold node
 
- rollback if system is not working
- shutdown
- restore binaries for tar "backup"
- attach old veritas db mount points back.
 
 
 
 
  • You did not mention the Clustering software in use? I believe steps differ for different Cluster software products.

    See my comments:

     shutdown services (cluster offline, freeze)
    Note that only NBU resource should be offlined, not entire service/resource group. If you offline the entire service group, the Virtual name will be unavailable and diskgroup will be deported - EMM cannot be upgraded.

    upgrade hot node
    Upgrade all the way to 7.5.0.4 before services are started. See recommendation in Upgrade Portal.
    Before installing patch, verify that /usr/openv/db/data is not a symbolic link. See this TN:

    (ET2783979) During installation of a 7.5.0.x maintenance release, if the <install_path>/openv/db/data directory is a link, the installation will fail.  http://www.symantec.com/docs/TECH189078

    - shutdown 
    - upgrade cold node 

    No need to shutdown active node while upgrading inactive node.

  • You did not mention the Clustering software in use? I believe steps differ for different Cluster software products.

    See my comments:

     shutdown services (cluster offline, freeze)
    Note that only NBU resource should be offlined, not entire service/resource group. If you offline the entire service group, the Virtual name will be unavailable and diskgroup will be deported - EMM cannot be upgraded.

    upgrade hot node
    Upgrade all the way to 7.5.0.4 before services are started. See recommendation in Upgrade Portal.
    Before installing patch, verify that /usr/openv/db/data is not a symbolic link. See this TN:

    (ET2783979) During installation of a 7.5.0.x maintenance release, if the <install_path>/openv/db/data directory is a link, the installation will fail.  http://www.symantec.com/docs/TECH189078

    - shutdown 
    - upgrade cold node 

    No need to shutdown active node while upgrading inactive node.

  • Hi,

    Veritas cluster.

    So should we do:

    - offine nbu resourse, freeze, hagent stop to both nodes

    - upgrade hot node

    - upgrade cold node

    - start services (cluster) and migrate

    OR;

     

    - offine nbu resourse, freeze, hagent stop to both nodes

    - upgrade hot node 

    - Start nbu only to hotnode 

    - migrate

    - upgrade cold node if hotnode seems to be working

    - add coldnode back to cluster