NetWorker 7.6 Enhanced Monitoring

One of the features most missed by NetWorker users since the introduction of NetWorker Management Console has been the consolidated view of NetWorker activities that had previously been always available.

For the last few releases, this has really only been available via nsrwatch, the utility available in NetWorker on Unix platforms, but sadly missing in NetWorker on Windows systems. If you’re not familiar with nsrwatch (which is possible if you’ve only recently been working with NetWorker, or mainly come from a Windows approach), it gives you a view like the following:

This style of view used to be available in the old “nwadmin” program for both Unix and Windows, and administrators that came from historical releases which supported nwadmin have sorely missed that overview-at-a-glance monitoring as opposed to wading through separate tabs to see glimpses of activities via NMC. It’s sort of like the difference between looking into a building where the entire front wall is made of glass, or looking into a building where there’s 4 windows but to open one you have to close the other three.

With NetWorker 7.6, you can kiss goodbye to that blinkered approach. In all its glory, we have the overview-at-a-glance monitoring back:

Is this compelling enough reason to run out and immediately upgrade to 7.6? Probably not – you need to upgrade based on site requirements, existing patches, known issues and compatibilities, etc. I.e., you need to read the release notes and decide what to do. Preferably, you should have a test environment you can run it up in – or at least develop a back-out plan should the upgrade not work entirely well for you.

Is it a compelling enough reason to at least upgrade your NMC packages to 7.6, or install a dedicated NMC server running 7.6 instead of a pre-7.6 release?

Hell yes.

Quibbles – Cloning and Staging

For the most part cloning and staging within NetWorker are pretty satisfactory, particularly when viewed from a combination of automated and manual operations. However, one thing that constantly drives me nuts is the inane reporting of status for cloning and staging.

Honestly, how hard can it be to design cloning and staging to accurately report the following at all times:

Cloning X of Y savesets, W GB of Z GB

or

Staging X of Y savesets, W GB of Z GB

While there have been various updates to cloning and staging reporting, and sometimes it at least updates how many savesets it has done, it continually breaks when dealing with the total amount staged/cloned in as much as it resets whenever a destination volume is changed.

Oh, and while I’m begging for this change, I will request one other – include in daemon.raw whenever cloning/staging occurs, the full list of ssid/cloneids that have been cloned or staged, and the client/saveset details for each one – not just minimal details when a failure occurs. It’s called auditing.

Basics – Why nsrwatch is still needed

In a previous post, I bemoaned the lack of nsrwatch on Windows. I thought it would be worthwhile pointing out an example of where nsrwatch comes in handy, for the non-believers.

You’re on the road, you don’t have the option of pulling your laptop out, and you need to check on the state of your NetWorker server. Via a mobile phone ssh session, nsrwatch really is your friend here:

 

nsrwatch, via issh

nsrwatch, the most missing tool under NetWorker for Windows

I started administering NetWorker servers in 1996. At the time I was working with Solstice Backup, the Sun OEM rebadged version of NetWorker, but the product was essentially the same. I think the main difference between the two products was that a search and replace was done on the NetWorker source code replacing Legato NetWorker with Solstice Backup.

At the time, many of the NSR/SBU servers I administered were remote – really remote. I also had very low bandwidth connections to them – as low as 4KB/s that was shared with email links, etc. This meant it was necessary to be incredibly economical with administrative commands*.

As such, I learned nsradmin faster than I learned the GUI. I still feel more comfortable making most configuration changes via nsradmin rather than the GUI, though NMC is as at least occasionally tempting me to run from time to time.

I also learned the simple elegance of nsrwatch, the command line monitor for NetWorker that in a simple terminal window showed all of the following:

1. Server summary details – number of backups, number of restores, etc.
2. All devices, and their current activity.
3. All currently running sessions.
4. Current server messages.
5. Pending alerts.

Back in the days of smaller environments, this literally gave you a complete view of everything on the NetWorker server in an 80×25 terminal window.

I was a dedicated Unix system administrator at that time and it wasn’t until I moved into consulting in 2000 that I first had to administer a NetWorker server on Windows. I was rather shocked to find nsrwatch missing on Windows.

To this day, I still find it frustrating that nsrwatch is missing on Windows. I have to say, I feel sorry for Windows NetWorker administrators (particularly in a Windows only environment) who have to run up a big GUI to show details that could be shown in such an economical amount of space.

The nsrwatch tool has also been very important when the NetWorker server is operating under load. The old Windows NetWorker GUI for instance used to hammer the NetWorker server for detail requests, and get to the point where the server and the GUI wouldn’t communicate with each other under heavy load, resulting in operators randomly rebooting backup servers in the middle of the night just because it looked like NetWorker had hung.

Even to this day, while NMC responds faster and is less interruptive to NetWorker, it still doesn’t show all those details in one easy screen. Thus, I’m still not aware of a single NetWorker administrator on Unix platforms who doesn’t still run nsrwatch, even if they also use NMC for day to day operations and administration.

It seems that these days nsrwatch seems to only get token updates to ensure it continues to work with current releases of NetWorker. It’s a shame – it needs more attention; it needs to be enhanced so that it say, supports dynamic drive sharing (only showing the active instance of a drive), and it needs to be ported to Windows.

It really, really needs to be ported to Windows.

—
* Nothing in those days was worse than running up the visual Veritas Volume Manager GUI. Bringing up a GUI that visually represented plexes, disks, volumes, etc., across a very low bandwidth link was about as much fun as being poked in the eye with a burnt stick. Thankfully, Volume Manager has far more economical GUIs, and better command line options these days.