IRIX 6.5 » Man Pages
find in page
NSR - introduction and overview of NetWorker
NetWorker facilitates the backup and recovery of files on a network of
computer systems. Files and filesystems may be backed up on a scheduled
basis. Recovery of entire filesystems and single files is simplified by
use of an on-line index of saved files.
NetWorker uses a client-server model to provide the file backup and
recover service. At least one machine on the network is designated as
the NetWorker server, and the machines with disks to be backed up are
NetWorker clients. Five daemons provide the NetWorker service, control
access to the system, and provide index and media support. On the
clients, there are special programs to access the file systems and
communicate with the NetWorker server.
The NetWorker system has several parts. Commands and files are only
briefly mentioned here; see the appropriate reference manual page for
more detailed information. Each command has a manual page entry in
section 1M. The files and their formats are explained in section 4
The Legato NetWorker Administrator's Guide provides information on
configuring and administering a NetWorker system. It includes many
examples and rationales for setting up and running a successful backup
How NetWorker is installed varies depending on the architecture of the
machine upon which you're installing. See the Legato NetWorker
Administrator's Guide for detailed installation instructions.
nsr_ize(1M) The NetWorker installation script. The script will install
both clients and servers. The nsr_ize script can also be
used to de-install NetWorker.
nsr_layout(4) Describes where NetWorker programs, files, and manual pages
NetWorker uses a client-server model to provide a backup and recover
service. The following daemons encompass the server side of NetWorker.
nsrd(1M) The main NetWorker daemon. nsrd handles initial
communication with clients, and starts and stops the other
NetWorker server daemons.
ansrd(1M) The agent nsrd process, spawned by nsrd in response to a
backup, recovery, or other session. Ansrd is invoked on an
as-needed basis and is only present when there are sessions
active to the NetWorker server.
This server daemon provides access to the NetWorker on-line
index. The index holds records of saved files. The index
allows clients to selectively browse and choose files to
recover without having to access the backup media.
nsrmmdbd(1M) The media management database daemon provides an index of
save sets and media. Nsrmmdbd provides a much coarser view
of the saved files than does nsrindexd, and therefore the
resultant index is usually much smaller.
nsrmmd(1M) The media multiplexor daemon provides device support for
NetWorker. When more than one client is saving files, the
data from each client is multiplexed. During recovery
operations, the data is demultiplexed and sent back to the
requesting clients. When the concurrent device support
module is used, several of these daemons may be active
NetWorker is administered via resources and attributes. Every resource
has one or more attributes associated with it. For example, a device is
a NetWorker resource type; an attribute of devices is the device type,
for example, 4mm or 8mm. The NetWorker resource format is documented in
nsr_resource(4). There is also a manual page for each NetWorker resource
in section 4 of the manual.
Resource files are not normally edited by hand. Rather, a NetWorker tool
(usually nwadmin(1M) or nsradmin(1M)) is used to modify resource files
dynamically so that values can be checked and changes can be propagated
automatically to the interested programs.
nwadmin(1M) Monitors the activity of and administers NetWorker servers.
Nwadmin is an X Window System application, using a Motif
look and feel. Nwadmin is most users' primary interface to
nsradmin(1M) A curses(3) based tool for the administration of NetWorker
nsrwatch(1M) A curses(3) based tool to monitor the activity of NetWorker
nsrmm(1M) Media manager command. Nsrmm is used to label, mount,
unmount, delete and purge volumes. Mount requests are
generated by nsrmmd, and displayed by nwadmin or nsrwatch.
The size of the on-line user file indexes may be controlled
by deleting and purging volumes.
nsrjb(1M) NetWorker's jukebox-controlling command. When dealing with
a jukebox, nsrjb, rather than nsrmm, should be used to
label, load, and unload the volumes contained within a
nsrim(1M) Automatically manages the on-line index. Usually run
periodically by savegroup.
mminfo(1M) Provides information about volumes and save sets.
nsrck(1M) Checks and repairs the NetWorker on-line index. It is run
automatically when nsrd starts up if the databases were not
closed cleanly due to a system crash.
A shell script used to safely shut down the local NetWorker
server. Nsr_shutdown can only be run by the super user.
NetWorker supports both scheduled and manual saving of files and
filesystems. Each client may be scheduled to save all or part of its
filesystems. Different clients may be scheduled to begin saving at
group of files. Save may be run manually by users and
administrators, or automatically by savefs.
nwbackup(1M) A Motif-based tool for backing up files. Nwbackup is the
graphical equivalent of save.
Used to initiate the backup of a group of client machines.
Usually started automatically by the NetWorker server.
The agent savegroup process, spawned by savegroup.
Asavegroup monitors the progress of individual save sets.
nsrclone(1M) The NetWorker save set/volume cloning command. Using
nsrclone, clones, or exact replicas, of save sets or entire
volumes can be made. Clone data is indistinguishable from
the original data, except for the NetWorker media volumes
upon which the data reside.
nsrexecd(1M) NetWorker-specific remote execution service which runs on
NetWorker clients. Used by savegroup to start savefs on
savefs(1M) Starts the appropriate save(1M) command to back up a
Generates a back up of a client's on-line file index. When
backing up a NetWorker server, a bootstrap save set is also
NetWorker maintains an on-line index of user files that have been saved.
Users may browse the index and select files for recovery. NetWorker then
locates the correct volume and recovers the requested files.
recover(1M) Browses the on-line user file index and selects files and
filesystems to recover.
nwrecover(1M) A Motif-based tool for recovering files. Nwrecover is
the graphical equivalent of recover.
mmrecov(1M) Recovers on-line file indexes, including the special
bootstrap index used during disaster recovery.
scanner(1M) Verifies correctness and integrity of NetWorker volumes.
Can also recover complete save sets and rebuild the on-
line file and media indexes.
nsr_crash(1M) A man page describing crash recovery techniques.
APPLICATION SPECIFIC MODULES
In order to process user files in an optimal manner, NetWorker provides
the ASM mechanism. Pattern matching is used to select files for
processing by the different ASMs. The patterns and associated ASMs are
described in nsr(4). Save keeps track of which ASMs were used to process
a file so that recover may use the same ASMs to recover the file.
uasm(1M) UNIX filesystem specific save/recover module. The uasm
man page documents the general rules for all ASMs.
Compresses files' pages using Lempel-Ziv coding.
mailasm(1M) Supports UNIX mailbox conventions.
Processes the on-line user file indexes.
nsrmmdbasm(1M) Processes the media index.
swapasm(1M) Handles diskless client swap files.
xlateasm(1M) Implements a simple encryption/decryption scheme on files.
On large networks there may be several NetWorker servers installed. Each
NetWorker client command must select a server to use.
For server selection, the client commands are classified into two groups:
administration and operation. The administration commands include
nwadmin, nsrwatch, and mminfo. The operation commands include save,
savefs, and recover. Both groups of commands accept a -s server option
to explicitly specify a NetWorker server.
When a server is not explicitly specified, the operation commands use the
following steps to locate one. The first server found is used.
1) The machine where the current directory is actually located is
determined. This will either be an NFS server or the local machine.
If that machine is a client of a NetWorker server as determined by a
RAP query, then that NetWorker server is used. Some commands will
actually do a broadcast RAP query if there is no local RAP agent;
broadcasts can take up to a minute to perform. If more than one
server backs up the current directory, one server will be picked,
and an informational message will be printed showing the other
2) The machine where the current directory is actually located is
examined to see if it is a NetWorker server. If it is, then it is
3) The local machine is examined to see if it is a NetWorker server.
If it is, then it is used.
4) If a NetWorker server has still not been found, then the machine
with the hostname ``nsrhost'' is used.
The administrative commands start with step number 3, and follow it with
steps 1, 2 and finally 4. When either set of commands fail to find a
NetWorker server, an error message is printed. The nsradmin command
(when not given a -s server option), can be used with all servers in the
RAP area if a rapd daemon is running on the local machine, or the host
named ``nsrhost''. Otherwise, the local machine is used if it is a
server, or the host named ``nsrhost''. The nsrmm command always uses the
local server, unless given the -s server option. Some commands now use a
broadcast to locate servers.
When there is only one NetWorker server on the network, or to designate a
``primary'' server, add a ``nsrhost'' alias for the appropriate machine
to your host table. For example, edit the file ``/etc/hosts'' if you are
using a file for your host table. When running the Network Information
System (NIS, formerly called Yellow Pages or YP), add the ``nsrhost''
alias on the master and push the ``hosts'' map. Otherwise, add the
``nsrhost'' alias to the /etc/hosts file for every client and the server.
See ypfiles(4) and ypmake(1M).
Before a save is allowed, there must be an NSR client resource created
for the given client. Before a recovery is allowed, the server validates
client access by checking the remote access attribute in the NSR client
resource (see nsr_client(4)). The server will only accept connections
that are initiated from a reserved port. Reserved ports can only be
opened by root, so most NetWorker programs run by the super-user, or
set-uid to root. This access control is similar to that used by the
rsh(1) command except that instead of using the /.rhosts file, NetWorker
uses the remote access list in the NSR client resource.
Once a connection has been established, the client programs: save(1M),
savefs(1M), and recover(1M), set their effective uid to the uid of the
user who initiated the program so that all local filesystem and system
call access is done as that user. This prevents users from recovering
files to which they should not have access. The exception to this rule
is that the user name ``operator'' and users in the group ``operator''
receive filesystem access privileges of the super-user. This allows the
administrator to set up a user name or group for the operators who will
initiate saves and recovers on behalf of other users, without giving the
operators root access to client machines.
Access control for the client programs can be further tightened by
turning off the set-uid bit. This will restrict the use of these programs
to root only on the client machines. To allow access by root and
operator, but not by other users, change the group ownership of these
programs to ``operator'', and set the mode bits to allow execution by
owner and group, but not by others.
The savegroup(1M) command initiates the savefs(1M) command on each client
machine in an NSR group by using the nsrexecd(1M) remote save execution
service. See the nsrexecd(1M) man page for details. For backward
compatibility with older versions of NetWorker, savegroup(1M) will fall
back on using the rsh(1) protocol for remote execution if nsrexecd is not
running on a particular client.
Access to the NSR resources through the nsradmin(1M) or nwadmin(1M)
commands is controlled by the administrator attribute on each resource.
This attribute has a list of names of the users who have permission to
administer that resource. Names that begin with an ampersand (&) denote
netgroups (see netgroup(4)). Also names can be of the form user@host to
authorize a specific user on a specific host.
NAMING AND AUTHENTICATION
As described above, the NSR server only accepts connections initiated
from a secure port on the machines listed as clients or listed in the
remote access list (for recovering). Since machines may be connected to
more than one physical network and since each physical network connection
may have numerous aliases, the policies below are used as a compromise
between security and ease of use. For further information about naming
in the UNIX environment, refer to gethostent(3), or other documentation
on name services.
A client determines its own name as follows. First the client's UNIX
system name is acquired via the gethostname(2) system call. The UNIX
system name is used as a parameter to the gethostbyname(3) library
routine. The client declares its name to be the official (or
``primary'') name returned by gethostbyname. This name is passed to the
NetWorker server during connection establishment.
A server authenticates a client connection by reconciling the
connection's remote address with client's stated name. The address is
mapped to a list of host names via the gethostbyaddr(3) library function.
Next, the client's stated name is used as a parameter to gethostbyname to
acquire another list of host names. The client is successfully
authenticated if and only if there exists a common name between the two
The NetWorker server maps a client's name to an on-line index database
name by resolving the client's name to the official name returned by
gethostbyname. This mapping takes place both at client creation time and
at connection establishment time.
To ensure safe and effective naming, the following rules should be
1) The NetWorker clients and servers should access consistent host name
databases. NIS (YP) and the Domain Name System (DNS) are naming
subsystems that aid in host name consistency.
2) All hosts entries for a single machine should have at least one
common alias among them.
3) When creating a new client, use a name or alias that will map back
to the same official name that the client machine produces by
backward mapping its UNIX system name.
rsh(1), gethostname(2), gethostent(3), netgroup(4), nsr(4),
nsr_layout(4), nsr_resource(4), ypfiles(4), ypmake(4), mminfo(1M),
mmrecov(1M), nsr_crash(1M), nsr_ize(1M), nsr_shutdown(1M), nsradmin(1M),
nsrck(1M), nsrclone(1M), nsrd(1M), nsrexecd(1M), nsrim(1M),
nsrindexd(1M), nsrjb(1M), nsrls(1M), nsrmm(1M), nsrmmd(1M), nsrmmdbd(1M),
nsrwatch(1M), nwadmin(1M), nwbackup(1M), nwrecover(1M), rap(1M),
rapd(1M), recover(1M), save(1M), savefs(1M), savegroup(1M),
saveindex(1M), scanner(1M), uasm(1M).
The Legato NetWorker Administrator's Guide
what's new |