Views |
||||||||||||||
What neat things can I do with nsradmin?
nsradmin -i - EOF . type: nsr client; group: groupname show name print EOF where groupnameis the name of the group you want to list. From: shaight@haight.cc.ukans.edu My current favorites: backup-server$ cat /usr/local/nsradmin/use1Drive #!/bin/ksh # # Set resources so all sessions are sent to the same drive. # When the tape gets full they all switch over to the other drive # Run after weekly full backup # /usr/opt/networker/bin/nsradmin -i - EOF . type: NSR device; name: /dev/nrmt0h update target sessions: 64 . type: NSR device; name: /dev/nrmt1h update target sessions: 64 EOF backup-server$ cat /usr/local/nsradmin/use2Drives #!/bin/ksh # # Set resources so sessions are split between both drives # Run prior to weekly full backup # /usr/opt/networker/bin/nsradmin -i - EOF . type: NSR device; name: /dev/nrmt0h update target sessions: 16 . type: NSR device; name: /dev/nrmt1h update target sessions: 16 EOF This assumes the max sessions per server is 32. I had a problem where at the end of an incremental backup I'd have two slow clients left shoe-shining each drive, but still need both drives streaming for a full backup to finish in under 23 hours. I already use groups and pools for controlling specific retention policies (for a given machine some data can be retained No Longer than X days, while other data must be kept for X months) so this solution is smoother than defining more groups and pools would have been. Eventually the group will get large enough that it still will need >24 hours for a full, at which point I'll probably add something like this: backup-server$ cat /usr/local/nsradmin/startEarly #!/bin/ksh # # Start backup early # Run prior to weekly full backup # /usr/opt/networker/bin/nsradmin -i - EOF sho start time; name . type: NSR group; name: Default update start time: "13:00" . type: NSR group; name: Default EOF backup-server$ cat /usr/local/nsradmin/startNormal #!/bin/ksh # # Start backup at normal time # Run after weekly full backup # /usr/opt/networker/bin/nsradmin -i - EOF sho start time; name . type: NSR group; name: Default update start time: "22:00" . type: NSR group; name: Default EOF Another great feature of nsradmin is the idea of a working set. When you "print" something from the nsradmin command line, the results of that query become the working set, and if you switch to visual (curses) mode, those will be the only resources you will be editing. For example, lets say you want to edit every client in the group "Default". Using a GUI, you have to visit each and every client in turn to figure out which ones are members of the Default group. Not so with nsradmin: nsradmin> print type: nsr client; group: Default <output deleted> nsradmin> v you will now be editing only resources of type "nsr client" that are members of the group "Default". Using the "select" menu item refills the working set, though, so be certain just to use the [Next], [Prev], [Edit], or [Options] menus. This is extremely useful if you have a lot of something, like clients. You group them so that you can manage them, but the GUI's don't give you that ability, while nsradmin does. Another feature of nsradmin is being able to configure any version of NetWorker. This is because it works from the straight RAP (resource administration protocol) resources. First, it performs a type: type query on the server: nsradmin> show type name
nsradmin> print type: type
type name: NSR;
type name: NSR notification;
type name: NSR license;
type name: NSR device;
type name: NSR stage;
type name: NSR group;
type name: NSR directive;
type name: NSR schedule;
type name: NSR policy;
type name: NSR client;
type name: NSR jukebox;
type name: NSR label;
type name: NSR pool;
type name: NSR archive request;
type name: NSR migration;
Some servers will not have the staging feature, for example, and it will not show up in the type list. Any new feature may be administered by nsradmin, regardless of server version because of this. Most of the GUI's will as well, but finding where the resource is located can be a challenge (especially in the windows nwadmin, where everything is accessible only via right clicks...). Lastly, nsradmin can administer nsrexecd on the clients, and lgtolmd (the license manager) on the server. nsrexecd is the NetWorker agent: it is used more and more by the clients for firewall support, authentication, migration, storage nodes, etc.. Even so, nsrexecd is still just a RAP server, all of which nsradmin can administer: $ nsradmin -s server -v1 -p 390113
nsradmin> show type name
nsradmin> print type: type
type name: NSRLA;
type name: NSR system port ranges;
for example. Bulk configuration changes If you have a lot of configured "resources" and you want to change one or more attributes on all of these, you can do so with nsradmin. One example is to change browse and retention policies on all registered clients. To do so create a text file with the following contents; print type:NSR client update retention policy:Quarter update browse policy:Month Now just run "nsradmin -i <name of textfile>" and you're done. The method can be used with all kinds of NetWorker resources, just change the "print" and "update" commands. Well, all of you have investigated, that there are no "please-disable-autostart-for-ALL-groups-now,-because-i-want-to- fix-something-for-a-while" and "go-on-and-enable-these-disabled-groups-now" buttons in the gui or via comand-line. So i've written a little script that's doing a nsradmin query, writes a temp-file and updates the NSR Group "autostart" attribute. with another option you can enable these groups again. if anyone want's it, feel free to mail me. excuse my pretty bad english. Joerg |
||||||||||||||
| This page was last modified 08:27, 2 December 2006. | ||||||||||||||