Networker and upgrading OS on linux

wouldn't you wanna consider moving towards NW NVE (networker virtual edition) instead? so not use a RHEL but rather use the Dell prvided OVA template (assuming you have a platform that you could run the NW server on as VM?

We considered this to be the way forward, replacing RHEL based backup servers with the NVE ones (Suse under the hood). Many RHEL admin don't like to perform major upgrades, so going from 6 to 8 or whatever, hence we had to consider either deploying a new higher RHEL next to it and perform a nsrdr on it, or deploy NW NVE.

But as there is not an official mentioned way to perform a nsrdr from a RHEL NW server on a NW NVE to perfrom such a platform migration (but I also cannot recall a specific statement it is NOT supported), we opted to "simply" deploy a NW NVE next to the RHEL servers and migrate clients and their configurations from old to new NW server. We considered hacking our way into gving the NW NVE deployment the same name and config as the old backup server, but then we could not apply the new naming convention to differentiate between RHEL and NVE based backups servers, but more importantly we considered the option to have no downtime at all, by migrating clients from old to new backup server (something we did already for many years for various reasons, for example when needing to migrate away from unix based nw servers in favor of RHEL based ones) and also a way to get rid of many old pains and configurations that where very cumbersome to change (as for example they were from nw8 times which had a savegroup approach (and naming convention we based around that) versus the policy base engine from nw9 onwards and an ever-imprving new naming convention and choices made along the way). However with a new backup server next to the old, that would not be as problematic, giving more than enough time to pre-create many required backup definitions.

But if it would have been up to us at the time, we would have been OK to try an actual RHEL OS upgrade, where one would first would make a VM snapshot for easy backout - and then upgrade the OS and hope for the best. However for now went all-in on NVE and "simply" migrate clients from old to new backup server. More work, but possibly also good to get rid of many a legacy configuration along the way.

For reference still the nsrdr approach:
https://www.dell.com/support/kbdoc/en-us/000022804/how-to-recover-a-bootstrap-using-nsrdr

BTW, there is a newer version of the NW cross platform migration, but it states specifically:

"NOTE: The procedure that is outlined in this document is only supported if performed by Professional Services. Crossplatform migrations that are performed by end-customers and partners are not supported."

"Any change of Operating System (OS) is considered a cross-platform migration. For example, a
migration from Windows to UNIX or Linux is considered to be a cross-platform migration.
Any change in CPU or OS architecture that requires a different data layout is considered a cross-platform migration. If you are in doubt, assume that the migration requires you to follow the cross-platform migration process and is not a simple upgrade.
A change of the OS version is not considered a cross-platform migration. For example, Windows 2003 to Windows 2008 is a direct upgrade."

However this document is not freely available.

From NW9 onwards things like a NW server rename is no longer supported as its name is registered in way too many config files outside of /nsr as well, and also dealing with various certificates and so on, it is simply not supported anymore to do just that, unlike the past up until nw8...

Way too much that might go wrong during a cross platform migration. But in your case going from rhel7 to rhel 8 or 9 would not be considered a platform migration, so for that doing a nsrdr would be OK and no that much unlike the recovery procedure needed during an actual NW backup server disaster.

We used the leapp upgrade.  Things went about as well as we had hoped - there is always that moment of trepidation right after one presses the (metaphorical) Go button.

Our servers are VM's, and we took snapshots before the process.  Also, we had 1 server that was less heavily-used so we had the luxury of testing/validating with that one first

NMC server (separate from backup servers) was also upgraded with leapp - went fine as well.

No issues were encountered.

@AndreaBolo​ in what way might NVE not be suitable (at least at the time)? Assuming that you actually have a virtualization platform that vm's can run on? Of course the NW server should be running on different hypervisors than the clients being protected, so the smaller and environment is, the more problematic that might be... but you need to prevent that catch22 of needing to have the backup server available to restore clients if the hypervisor is down that was used to run both. Some migth even have the backup target on that very same hypervisor, like a DDVE deployed on it as well.

We went all-in on virtualization years ago, in favor of physical (Solaris and HPUX) in favor of RHEL linux vm's. However no we transition towards NW NVE instead, as we have the idea that a specific tailored OS is more likely to do the job, also support wise. One of the things you get suddenly is an actual firewall configured by default on linux, with all required rules, no need to alter and it would also add/remove any rules possibly in the future. And specifically tuned kernel settings.

Yes things can go wrong, and will go wrong and have gone wrong with an NVE approach (like actually not performing the actual OS patching due to a peculiar requirement needing to do a root login to check something which was prevented due to having altered sshd_config in such a way that broke this root login, but instead of properly reporting this, it only generated a vague error message. Not automatically rebooting the NW server after OS patching was a give-away in hind-sight, even though the package specifically states it would need to perform a reboot).

But NW NVE has given the backup team great control over the OS and customization (even so slightly). OS patching is also fully under our control, with the Dell provided OS roll-ups.

The use of NVE was not recommended to us a few years ago in the initial design of the environment. 
We use integrations with RMAN, NDMP, VTL, vmware deployed on multiple VCs, some customizations on the backup server and initially a different choice was made. There was no real particular reason.

I think NVE may still be fine for our use, maybe I would lose something in versatility for backup server customizations, but I have not investigated.
My intention is to proceed with upgrades via Leapp, supported by RedHat.

I will update the thread upon completion. Thanks again to all for the suggestions.