What is /nsr/debug?

Those new to NetWorker may wonder what the purpose of the “/nsr/debug” directory is. When working in Windows environments, the path to the directory will be different, but it’s still in the same relative location – a child directory to the “nsr” directory on the backup server.

This is a somewhat special directory that the NetWorker server monitors for files whose presence will change the behaviour of the server on the fly. To my knowledge, there’s never been a definitive list published of files that can be created in the debug directory (the same as there’s never been a definitive list published externally to EMC of all the allowed NSR_ environment variables).

While this is good, in that it protects novices from shooting themselves in the foot, power users such as myself and many others have long been curious about what other delights are to be found in the /nsr/debug directory.

To change the behaviour of the NetWorker server, one would simply create a (optionally empty) file with the correct filename (under Unix, this would be as simple as “touch filename”). Files that still serve some purpose are:

• no_striped_recover – By default NetWorker will attempt to read from as many pieces of media as it is physically able to simultaneously to faciltiate a recovery. If you’ve got ten tape drives and you need to read from ten tapes, NetWorker can mount all ten and start the recovery in parallel. However, in some circumstances (normally, a Linux only problem), if NetWorker would need to mount more media than can be physically supported by the number of tape drives, the entire recovery may hang. If this is happening, touch no_striped_recover in the /nsr/debug directory to have NetWorker process the recovery sequentially.
• no_immediate_save – These days the main differences between Power and Network edition in NetWorker are the number of devices and units of parallelism per storage node. This wasn’t always the case – at some point in the past, another difference was that a storage node’s client process could communicate with local nsrmmds via shared memory, rather than through the TCP/IP stack. However, this was eventually dropped, and all storage nodes, regardless of whether you’re on Power or Network edition, have their own client<->nsrmmd communications go through shared memory instead of TCP/IP. The no_immediate_save option is there to turn this feature off if you want. For example, if you have a dedicated storage node that is also a very large Oracle server, it may be that all shared memory is always occupied by Oracle processes, and that it would be more efficient to have client<->nsrmmd communications go through TCP/IP. (Truth be told I think it’s still there more for handling of esoteric bugs or systems where shared memory has, for some reason, been disabled.)

If you’re still on a pre-NetWorker 7.3.2 release, you’re also lucky enough to be able to create a file called no_suppress, which turns off that annoying “x lines of output has been suppressed” message that appears in savegroup completions when you need to debug errors. Unfortunately, someone in their infinite wisdom in NetWorker development* decided that this is a bad thing and pulled it out. Unfortunately, while supposedly there have been various “changes” that allow you to see this information, you can’t, unless you run the backup command manually from the client, which sort of defeats the purposes of true and accurate debugging of issues! (EMC PowerLink documents and manual pages insist you can see it by reviewing the /nsr/tmp/sg/* information and the messages/daemon.raw files. This is, ahem, inaccurate.)

So, if you’re concerned about say, why there is an /nsr/debug directory on your backup server (or client, or storage node), there’s no need to be – it’s all part of the general architecture of NetWorker, and is there to serve a real purpose when needed.

—
* Prefacing what I’m about to say with I don’t have access to the source code so this is all speculation – I believe this has been done due to the inherent architectural limitations of nsrjobd and using a RAP database to store jobs data. This results in the artificial need to reduce as much as possible information that may appear in the savegroup completion notifications. That’s just my theory, but everything I see in the behaviour of the jobs database backs that theory up.