NetWorker Blog

Commentary from a long term NetWorker consultant and Backup Theorist

  • This blog has moved!

    This blog has now moved to nsrd.info/blog. Please jump across to the new site for the latest articles (and all old archived articles).
  •  


     


     

  • Enterprise Systems Backup and Recovery

    If you find this blog interesting, and either have an interest in or work in data protection/backup and recovery environments, you should check out my book, Enterprise Systems Backup and Recovery: A Corporate Insurance Policy. Designed for system administrators and managers alike, it focuses on features, policies, procedures and the human element to ensuring that your company has a suitable and working backup system rather than just a bunch of copies made by unrelated software, hardware and processes.
  • This blog has moved!

    This blog has now moved to nsrd.info/blog. Please jump across to the new site for the latest articles (and all old archived articles).
  •  


     


     

  • Twitter

    Error: Twitter did not respond. Please wait a few minutes and refresh this page.

What is /nsr/debug?

Posted by Preston on 2009-06-03

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.

Advertisements

2 Responses to “What is /nsr/debug?”

  1. Dave Gold said

    There are some others, I find the easiest way to figure them out to check the strings in various NetWorker binaries.

    Here are a few other likely ones:
    /nsr/debug/cdidisable
    no_session_wait (regarding networker 7.2.1/7.3.0 timeframe)

    –Dave

    • Preston said

      Hi Dave,

      Thanks for pointing out the extra options! I imagine that ‘cdidisable’ would turn off CDI for all devices? I’ll have to play around with that. Certainly for pre 7.4.4 in the 7.4 tree that would be handy, as there were a lot of issues with CDI handling in the 7.4 series.

      Cheers,

      Preston.

Sorry, the comment form is closed at this time.

 
%d bloggers like this: