Murrstock - stock.adobe.com
NetBackup best practice states that all clients should be on the same standardized version. This simplifies the day-to-day support of the infrastructure because different code versions can introduce subtle differences, and a standardized version is a known good component.
Below is a brief explanation of how to obtain information about the NetBackup version that is running in both the client and master server.
To obtain the required information, the NetBackup version command can be used via Secure Shell. Log in and write out the file to the screen. If the installation was done with defaults, users can find the NetBackup version information file "netbackup" with the following command:
At the other end of the setup are the servers to back up. For NetBackup, these servers are referred to as clients. Obviously, there are differences in the configuration. The servers that are being backed up do not need all the configuration details that the NetBackup master servers do (Akin to it being a client-server relationship).
On the master server it is possible to gather information on the clients using the command bpgetconfig, which is usually located in /usr/openv/netbackup/bin folder.
Running this command from the server will output all the connected clients. If the reader knows a little bash scripting it can be very useful to gather and sort information. For example, using the grep command will allow for searching and reporting:
./netbackup/bin/bpgetconfig | grep "version"
Bash has lots of tools that would allow the user to interrogate and manipulate the data NetBackup returns.
Instead of reporting all the information, using the above would just report the version rather than presenting the entire configuration.
If the user is interested in just one machine, use the bpgetconfig command with a hostname to output more verbose settings. This kind of setup can be very useful to quickly extract a lot of information, such as ensuring that the version is consistent across all the clients connected to the server. Below we delve into information that can be obtained from the clients themselves.
One tip here is that there is a lot more to that one command than meets the eye. For example, using bpgetconfig -L will output a list format. To see all the options available just run bpgetconfig without any options. A full breakdown of the available parameters and their usage is available on the Veritas site. There is also the bpsetconfig command for updating parameters. The whole ethos is all the workload can be reduced by clever management from the NetBackup server.
Accessing client information
There is a lot more to that one command. For example, using bpgetconfig -L will output a list format. To see all the options available, run bpgetconfig without any options. A full breakdown of the available parameters and their usage is available on the Veritas site. There is also the bpsetconfig command for updating parameters. This uses management from the NetBackup server to reduce the workload.
By default, all client installations have a version file, like the one on the master server, but the specific version details can be found in the relevant "installation folder"
Users can also find the version information in the GUI. If users locate and run the nbwin.exe application and go to the About menu, it will also provide the version information. Again, if users cannot find the file, try the Windows search functionality to locate it.
Linux follows a similar naming convention and the NetBackup version command is usually in
If it can't be found by the user but is installed, any modern Linux distribution will be able to locate it using the locate version command /opt/openv/netbackup/bin/version. However, it will highlight all files called "version."
Why use these commands?
When it comes time to upgrade the infrastructure, the NetBackup version command enables the administrator to gather data on all the endpoints and know in advance if any are not up to correct version. It can be important because NetBackup and other systems tend to implement a current version minus one configuration. In simple terms, the endpoints must be no older than one major point release to be usable.
The clients should also never be newer than the master server release or they will not work. It would be hard to work out a scenario in which this would happen, especially in larger environments.