nsrwatch gets an update

 NetWorker  5 Responses »
May 112011
 

Having used NetWorker since 1996, it’s fair to say that while I’ve watched a lot of features and interfaces in NetWorker get visible changes, the one that hasn’t has typically been nsrwatch. Sure, it’s had the backend connectivity updates, and updates to allow it to understand what it’s needed to, but superficially it’s been pretty much exactly the same from my first usage of NetWorker with a 4.x server right through to 7.6 SP1.

That’s changed in 7.6 SP2. OK, first the downside: it’s still not available on Windows. Now, the upside: you can turn on/off display sections, providing more space for those sections you leave showing, and you can scroll in each section, too. It also has had a general facelift in terms of how the displays look.

For instance, this afternoon I grabbed screenshots of a lab server using first a NetWorker 7.6 SP1 client:

nsrwatch, 7.6 SP1 and underNext, we have the same server shown via a 7.6 SP2 nsrwatch:

nsrwatch in 7.6 SP2

I think this layout is certainly cleaner than the 7.6 SP1 and lower nsrwatch – but as I said, it also has advantages of being able to toggle each of those panels off or on, using:

  • d – Devices
  • g – Groups
  • s – Sessions
  • m – Messages
  • p – Pending

For instance, having toggled off groups and sessions in a server with a large number of devices, I could see considerably more:

nsrwatch items toggled

Additionally – you can scroll – use tab in nsrwatch to jump between sections, and then arrow keys to scroll up and down. For instance, here’s a screen shot of the devices section partially scrolled through:

nsrwatch scrolled

These may seem like minor changes, but to people who live on the command line, they’re very welcome.

 Posted by Preston de Guise at 18:20  Tagged with:

Saveset sizes from 32-bit Windows

 Features, NetWorker, Windows  No Responses »
Jan 172010
 

There’s currently a bug within NetWorker whereby if you’re using a 32-bit Windows client that has a filesystem large enough such that the savesets generated are larger than 2TB, you’ll get a massively truncated size reported in the savegroup completion. In fact, for a 2,510 GB saveset, the savegroup completion report will look like this:

Start time:   Sat Nov 14 17:42:52 2009
End time:     Sun Nov 15 06:58:57 2009

--- Successful Save Sets ---
* cyclops:Probe savefs cyclops: succeeded.
* cyclops:C:\bigasms 66135:(pid 3308): NSR directive file (C:\bigasms\nsr.dir) parsed
 cyclops: C:\bigasms               level=full,   1742 MB 13:15:56    255 files
 trash.pmdg.lab: index:cyclops     level=full,     31 KB 00:00:00      7 files
 trash.pmdg.lab: bootstrap         level=full,    213 KB 00:00:00    198 files

However, when checked through NMC, nsrwatch or mminfo, you’ll find that that the correct size for the saveset is actually shown:

[root@trash ~]# mminfo
 volume        client       date      size   level  name
XFS.002        cyclops   11/14/2009 2510 GB   full  C:\bigasms
XFS.002.RO     cyclops   11/14/2009 2510 GB   full  C:\bigasms

The reporting doesn’t affect recoverability, but if you’re reviewing savegroup completion reports the data sizes will likely (a) be a cause for concern or (b) affect any auto parsing that you’re doing of the savegroup completion report.

I’ve managed to secure a fix for 7.4.4 for this, with requests in to get it ported to 7.5.1 as well, and to get it integrated into the main trees for permanent inclusion upon the next service packs, etc. If you’ve been putting up with this problem for a while or have just noticed it and want it fixed, the escalation patch number was NW110493.

(It’s possible that this problem affects more than just 32-bit Windows clients – i.e,. it could affect other 32-bit clients as well. I’d be interested in knowing if someone has spotted it on another operating system. I’d test, but my lab environment is currently otherwise occupied and generating 2+TB of data, even at 90MB/s, is a wee bit long.)

 Posted by Preston de Guise at 05:00  Tagged with: , , , , , , ,

NetWorker 7.6 Enhanced Monitoring

 NetWorker  7 Responses »
Nov 212009
 

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:

nsrwatch

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:

Consolidated monitoring in 7.6

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.

 Posted by Preston de Guise at 07:09  Tagged with: , , , ,

Quibbles – Cloning and Staging

 Quibbles  No Responses »
Aug 132009
 

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.

 Posted by Preston de Guise at 07:21  Tagged with: , , , ,

Basics – Why nsrwatch is still needed

 Basics  No Responses »
Feb 122009
 

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, via issh

 Posted by Preston de Guise at 06:53  Tagged with: , ,

nsrwatch, the most missing tool under NetWorker for Windows

 NetWorker  No Responses »
Feb 022009
 

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.

 Posted by Preston de Guise at 20:56  Tagged with: , ,
© 2012 The NetWorker Blog Suffusion theme by Sayontan Sinha