NetWorker Blog

Commentary from a long term NetWorker consultant and Backup Theorist

  • This blog has moved!

    This blog has now moved to 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.
  • Advertisements
  • This blog has moved!

    This blog has now moved to 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.

Using NetWorker for Live Search

Posted by Preston on 2009-10-01

There was recently a discussion on the NetWorker mailing list regarding a situation whereby a company was skipping certain media files (e.g., *.mp3) from a fileserver, but still wanted to know when those files were present. In this case, the backup administrator didn’t have administrative rights to the fileserver, so doing a straight search of the fileserver wasn’t really an option.

One proposed solution was to change the “skip” to “null”, which does cause some index information to be stored that can be searched with nsrinfo. How useful that “some” is though is of debate. The reason for this is that if you “null” a file in a backup, it will only be reported via an nsrinfo -v command, and it won’t be reported with the full path to the file, meaning it’s necessary to walk the nsrinfo -v output to scan each new change of path then construct the null’d file paths from there.

As an exercise for the list, I tried this out – here’s what I reported at the time:

Creating the test area we want to test with using the following commands –

# mkdir /testing
# cp bigfile /testing
# cd /testing
# dd if=/dev/zero bs=1024k count=1024 of=test.dat

Following this, configure a /testing/.nsr directive with the following content:

<< . >>
null: test.dat

Now a backup can be run of the “/testing” directory; because of the directive, “test.dat” will be excluded.

Finding test.dat in nsrinfo output however is a little more tricky:

[root@nox testing]# nsrinfo -t `mminfo -q "name=/testing" -r nsavetime` nox
scanning client `nox' for savetime 1254265148(Wed 30 Sep 2009 08:59:08 AM EST)
from the backup namespace
4 objects found

There’s no test.dat listed there. Resorting to ‘-v’ on nsrinfo, we do get the information, but as you can see, it’s more challenging to isolate the full path to the file:

[root@nox testing]# nsrinfo -t `mminfo -q "name=/testing" -r nsavetime` -v nox
scanning client `nox' for savetime 1254265148(Wed 30 Sep 2009 08:59:08 AM EST) from the
backup namespace
UNIX ASDF v2 file `/testing/.nsr', NSR size=188, fid = 2304.586641, file size=23
UNIX ASDF v2 file `/testing/bigfile', NSR size=196195024, fid = 2304.97665, file
UNIX ASDF v2 file `/testing/', NSR size=244, fid = 2304.97664, file size=4096
 ndirentry->586641    .nsr
 ndirentry->97669    test.dat          <----- Here it is ------>
 ndirentry->2    ..
 ndirentry->97665    bigfile
UNIX ASDF v2 file `/', NSR size=772, fid = 2304.2, file size=4096
 ndirentry->3677476    .vmware/
 ndirentry->846145    mnt/
 ndirentry->97633    .autorelabel
 ndirentry->11    lost+found/
 ndirentry->2343169    lib64/
 ndirentry->2701153    media/
 ndirentry->1985185    opt/
 ndirentry->2668609    etc/
 ndirentry->1431937    sbin/
 ndirentry->4133089    srv/
 ndirentry->618337    boot/
 ndirentry->97638    .bash_history
 ndirentry->1366849    bin/
 ndirentry->2766241    selinux/
 ndirentry->3417121    tmp/
 ndirentry->97644    .autofsck
 ndirentry->585793    root/
 ndirentry->1692289    lib/
 ndirentry->97647    nsr
 ndirentry->0    sys/
 ndirentry->97648    home
 ndirentry->1887553    usr/
 ndirentry->2147905    var/
 ndirentry->2245537    d/
 ndirentry->0    dev/
 ndirentry->0    net/
 ndirentry->0    misc/
 ndirentry->0    proc/
 ndirentry->2    ..
 ndirentry->97664    testing/
4 objects found

So while this solution works, I’m not convinced it’s ideal in all instances.

The other solution I came up with I think works a little better, more reliably, and has the advantage of doing a live search on the filesystem even if the backup administrator doesn’t have administrator privileges.

So, the other solution is to make use of the RUSER/RCMD functionality in NetWorker to “have a chat” to the client daemons and get them to do something useful. Note that this is reasonably secure – you can only ask to run commands starting with “nsr” or “save”, and those commands must reside in the same directory as the save binary. In this case, we want to invoke save. All you have to do is turn off whatever directives are in place for the client, then setup a no-save command execution for the client.

In the example below, we’re going to get the client “asgard” to do a no-save backup of its /root folder, reporting back to the server “nox” but without actually transferring any data:

[root@nox testing]# RCMD="save -s nox -n /root"
[root@nox testing]# RUSER=root
[root@nox testing]# export RCMD RUSER
[root@nox testing]# nsrexec -c asgard
Warning: Could not determine job id: Connection timed out. Continuing ...
32477:(pid 29247):
save: /root 155 records 32 KB header 855 MB data

save: /root 855 MB estimated

This style of command will work equally for Windows and Unix systems – indeed, I’ve done similar things on both Windows and Unix.

Obviously, once you’re done gathering the file list, it’s important to then re-enable any directives turned off for the test/file walk.


Sorry, the comment form is closed at this time.

%d bloggers like this: