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
/testing/.nsr
/testing/bigfile
/testing/
/
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
 size=196176812
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 ...
/root/.elinks/globhist
/root/.elinks/cookies
/root/.elinks/gotohist
/root/.elinks/
/root/.bash_profile
/root/.tcshrc
/root/aralathan.pub
/root/.my.cnf
/root/anaconda-ks.cfg
/root/nmsql521_win_x86.zip
/root/nw_linux_x86.tar.gz
<snip>
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.

Share this using...

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

While you don’t need it any more to control remote jukeboxes, it can still be useful to know how to do remote control operations in NetWorker – particularly if you’re say, debugging backups on a client but you don’t have console access to that client.

Note that this only applies to commands that obey the following restrictions:

• Name starts with “nsr” or “save”
• Resides in the same directory as the “save” command on the client.

Thus, this isn’t about remote hijacking of a NetWorker client. Such commands can only be executed by an authorised administrator on the backup server as specified in the nsr/servers file. Before you (quite rightly) point out that it would mean that a valid NetWorker administrator could in fact hijack a client by say, doing a directed recovery out to that client of an appropriately named file, they can do that already – that’s part of the trust relationship of the NetWorker administrator anyway.

So, with all those caveats out of the way, it’s remarkably simple. Going from a Unix host, you do the following:

# export RUSER=<user>
# export RCMD=<cmd>
# nsrexec -c <client>

Where:

• user will typically be “root” or “administrator”, depending on whether your backup server is Unix or Windows.
• cmd will be a NetWorker command you want executed.
• clientName is the name of the client the command is to be executed from.

For instance, say I’ve got a NetWorker server called “nox”, and a client called “asgard” that I don’t have administrative login to, but I want to simulate a backup without firing up a savegroup. To do so, I could do the following:

# export RUSER=root
# export RCMD="save -e tomorrow -b Default -LL -q -s nox /tmp"
# nsrexec -c asgard
save: /tmp  36 MB 00:00:05     38 files
completed savetime=1235278395

Admittedly this is not a technique you should need to know often, but it’s useful to know about.

–
* You do populate your nsr/servers file, don’t you? If you don’t, go do it NOW. I mean it, stop what you’re doing, go and fix up the nsr/servers file on every client in your environment!

Share this using...

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

So these days I just put “expert” on CVs and resumés for HR people, but consider myself generally speaking to be a long term user who happens to have a lot of technical understanding of the product.

Nevertheless, I’m always surprised, delighted and sometimes a little embarrassed when I discover a feature I’ve been using for ages is more powerful and useful than what I’ve been using it for.

Take the humble rpcinfo utility. I know, not really a NetWorker component, but one that’s used so often in NetWorker debugging that I often tend to think of it as “NetWorker utility”.

The traditional use for rpcinfo, the one that I’ve been using for the last 12+ years, is the most simple:

$ rpcinfo -p nox
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp    723  status
    100024    1   tcp    726  status
    390402    1   tcp   9001
    390436    1   tcp   8772
    390435    1   tcp   8176
    390113    1   tcp   7937  nsrexecd
    390115    1   tcp   8525
    390103    2   tcp   8456  nsrd
    390109    2   tcp   8456  nsrstat
    390110    1   tcp   8456  nsrjbd
    390120    1   tcp   8456
    390109    2   udp   8179  nsrstat
    390107    5   tcp   9754  nsrmmdbd
    390107    6   tcp   9754  nsrmmdbd
    390105    5   tcp   9248  nsrindexd
    390105    6   tcp   9248  nsrindexd
    390433    1   tcp   8980  nsrjobd
    390104  105   tcp   9142  nsrmmd
    390104  205   tcp   9561  nsrmmd
    390104  305   tcp   9932  nsrmmd
    390104  405   tcp   8303  nsrmmd
    390104  505   tcp   9074  nsrmmd
    390104  605   tcp   9093  nsrmmd
    390104  705   tcp   8489  nsrmmd
    390104  805   tcp   9260  nsrmmd
    390104  905   tcp   9279  nsrmmd
    390104 1005   tcp   9934  nsrmmd
    390104 1105   tcp   8225  nsrmmd
    390430    1   tcp   9047  nsrmmgd
    390429  101   tcp   8301  nsrlcpd
    390104 1205   tcp   8155  nsrmmd
    390104 1305   tcp   8526  nsrmmd

However, recently a PSE got me to run a slightly different rpcinfo command, and I can immediately appreciate that it’ll be one I’ll periodically use again. That’s to make use of the test function, which actually does a connectivity test to the specified program number and report whether a response is received. It works like this:

# rpcinfo -t host number [version]

So, where is this useful? It’s another good way of checking not to see whether the NetWorker client is running, but to see whether it’s actually capable of responding. For example:

# rpcinfo -t nox 390113 
program 390113 version 1 ready and waiting

As you can see, that’s a useful bit of information to get back during debugging connectivity and communications problems! Proving once gain – you can teach an old dog new tricks.
–
* Or ass, if you must.

Share this using...

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

39078 02/02/2009 09:45:13 PM  0 0 2 1152952640 5095 0 nox nsrexecd SYSTEM error: There is already a machine using the name: “faero”. Either choose a different name for your machine, or delete the “NSR peer information” entry for “faero” on host: “nox”

While this may look confronting, it’s actually a trivially easy error to fix that requires just a minute or so of your time with nsradmin. First, note the client that the error is about, and the client that the error is being recorded from. In this case, the error is about the client faero, while the error is being registered against the host nox.

To fix, run up nsradmin against the client service on nox:

# nsradmin -p nsrexec -s nox

(alternatively, you can use: nsradmin -p 390113 -s nox)

At the nsradmin> prompt, enter the command:

delete type: NSR peer information; name: faero

And answer yes when prompted to confirm. For example, the session might resemble the following:

nsradmin> delete type: NSR peer information; name: faero
                        type: NSR peer information;
               administrator: root, "user=root,host=nox";
                        name: faero;
               peer hostname: faero;
          Change certificate: ;
    certificate file to load: ;
Delete? y
deleted resource id 17.0.83.117.0.0.0.0.210.37.85.73.0.0.0.0.10.0.0.1(1)

There, you’ve done it. Note that you should be periodically scanning your daemon raw/log files for errors and trying to eliminate them. The goal should be that any error or warning reported in the file is something that you do need to worry about/investigate, rather than having a lot of “false positives” floating around in the system.

[Update, 2009-05-12]

I thought I’d mention that one of the most common times I see these warnings occur is after I’ve uninstalled/reinstalled NetWorker on a client, as opposed to having upgraded. Since on some clients it’s more or less necessary to uninstall/reinstall rather than upgrade, that helps to understand why the information is lost periodically. My surmise is that on a new install, the NetWorker client processes generate a new ‘certificate’ or ‘identity’. As this new information conflicts with existing information the backup server has on the client, that’s what triggers the error.

It could be that other factors can cause this, but it seems that this is at least a primary cause.

Share this using...

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.