NAME

nsr − NetWorker directive file format

DESCRIPTION

This man page describes the format of .nsr directive files.  These files are interpreted by save(8) and Application Specific Module (ASM) programs as files are being saved.  This format is also used in the directive attribute of the nsr_directive(5) resource. 

Directives control how particular user files are to be saved, how descendent directories are searched, and how to process subsequent directives.  For each file saved, any ASM information needed to recover that file is also saved.  This allows recover(8), or any ASM directly invoked, to correctly recover a file, even if the current directives for saves have changed.  See uasm(8) for a general description of the various ASMs and their individual manual pages. 

The .nsr directive file in each directory is parsed before anything in that directory is saved.  Each line of a .nsr directive file, and each line of the directive attribute, contains one directive.  Any text after a # until the end of the line is treated as a comment and discarded.  Directives have one of three forms:

[+] ASM [args ...] : pattern ...
save environment
<< dir >>

The three forms are referred to as ASM specifications, save environment directives and << dir >> directives, respectively.  Each form is explained below. 

The ASM name (and any arguments), specifies how files or directories matching pattern are to be saved.  When pattern matches a directory, the specified ASM is responsible for handling the directory and everything contained within that directory.  A pattern or other ASM arguments requiring use of special control or white space characters should be quoted using double quotes ("). 

A colon (:) is used as the separator between the ASM specification (and any arguments) and the pattern specification list.  The pattern list for each ASM specification consists of simple file names or patterns.  The pattern cannot be ".." and must not contain any / characters (all names must be within the current directory).  The string "." can be used to match the current directory.  Standard sh(1) file pattern matching (∗, [...], [!...], [x-y], ?)  can be used to match file names.  If a + precedes the ASM name, then the directive is propagated to subdirectories.  When a directory is first visited, it is searched for a .nsr file.  If one is found, it is then read.  Each .nsr file is only read once.  When starting a save at a directory below /, any .nsr files on the normalized path of the current working directory are read before any files are saved to remember any propagated directives. 

The following algorithm is used to match user files to the proper ASM specification.  First the .nsr file in the current directory (if any), is scanned from top to bottom looking for an ASM specification without a leading “+” whose pattern matches the file name.  If no match is found, then the .nsr in the current directory is re-scanned for an ASM specification with a leading “+” whose pattern matches the file name (for clarity, we recommend putting all propagating (“+”) directives after all the non-propagating directives in a .nsr file).  If no match is found, then the .nsr file found in .. (if any) is scanned from top to bottom looking for a match with an ASM specification that had a leading +.  This process continues until the .nsr file in / (if any) is scanned.  If no match is found (or a match is found with an ASM specification whose name is the same as the currently running ASM), then the currently running ASM will handle the save of the file. 

The save environment directives can be used to change how ASM specifications already seen and future .nsr files are actually used.  The save environment directives do not take any file patterns.  They affect the currently running ASM and subsequent ASMs invoked below this directory.  There are three different possible save environment directives that can be used:

forget Forget all inherited directives (those starting with a + in parent directories). 

ignore
Ignore subsequent .nsr files found in descendent directories. 

allow Allow .nsr file interpretation in descendent directories. 

The << dir >> directive can be used to specify a directory where subsequent ASM specifications from the current .nsr file should be applied.  This directive is intended to be used to consolidate several .nsr files’ contents to a single location.  When using this directive, dir must resolve to a valid directory at or below the directory containing this directive or the subsequent ASM specifications will be ignored.  While absolute path names can be used for dir, it is recommended that relative path names be used when using this notation in a .nsr file.  This makes interpretation of the subsequent ASM directives consistent even if this directory is mounted in a different absolute part of the filesystem. 

There must be a << dir >> as the first directive in a directive file use with the −f option to save(8), savefs(8) or with an ASM program.  Also, when << dir >> directives are used in this manner, whether first or later in the file, absolute path names should be used to insure proper interpretation.  Absolute path names should also be used for each directory specified within the directive attribute of the NSR directive resource (see nsr_directive(5)). 

When a << dir >> directive is used, subsequent directives are parsed and kept for later use.  When the directory specified by dir is actually visited, any save environment directives already specified for that directory (e.g., allow, ignore, and forget) are processed first.  Then if the ASM is not currently ignoring .nsr files and a local .nsr file exists, the file is read and processed.  Finally, any of the non save environment save directives already specified for that directory are handled as if they where appended to the end of a .nsr file in that directory.  If there are multiple << dir >> specifications that resolve to the same directory, then the corresponding save directives are logically handled in “last seen first” order. 

EXAMPLES

Having a /usr/src/.nsr file containing:

+skip: errs ∗.o
+compressasm: .

would cause all files (or directories) in /usr/src named errs or ∗.o (and anything contained within them) to be skipped.  In addition, all other files contained in /usr/src will be compressed during save and will be set up for automatic decompression on recover. 

Having a /var/.nsr file containing:

compressasm: adm .nsr
null: ∗ .?∗

would cause all files (or directories) in /var (and anything contained within them), except for those files in /var/adm and the .nsr file itself to be skipped, although all the names in the directory would be backed up.  In addition, since compressasm is a walking directive (see uasm(8)), the files contained in /var/adm will be compressed during save and will be set up for automatic decompression on recover. 

Here is an example of using the /.nsr file as a master save directive file for the entire filesystem by using << dir >> directives to consolidate the various ASM save directives to one place:

# Master NetWorker directive file for this machine
<< ./ >>
# /mnt and /a are used for temporary fs mounting
# and need not be saved
skip: mnt a
+skip: core errs dead.letter ∗% ∗~
# Don’t bother saving anything within /tmp
<< ./tmp >>
skip: .?∗ ∗
<< ./export/swap >>
swapasm: ∗
# Translate all mailboxes. Also, use mailasm to save each
# mail file to maintain mail file locking conventions and
# to preserve the last file access time.
<< ./usr/spool/mail >>
xlateasm: .
 mailasm: ∗
# Allow .nsr files to be interpreted in /nsr, even if we
# are currently ignoring .nsr files. NetWorker
# applications (such as nsrindexd) set up their own private
# .nsr files which save index files more intelligently.
<< ./nsr >>
allow
# We can rebuild any .o files in /usr/src
# from sources except those in /usr/src/sys.
<< ./usr/src >>
+skip: ∗.o
<< ./usr/src/sys >>
forget

FILES

.nsr save directive file in each directory

SEE ALSO

sh(1), nsr_directive(5), nsrindexasm(8), nsrmmdbasm(8), recover(8), save(8), savefs(8), uasm(8). 

NetWorker 4.1.2  —  Last change: May 1995