I have fully tested this and have found this not to be the case. The
.nsr file seems to apply for files at that level but not for
directories. For example, if I have /pathname/.nsr with the following:
skip: dir1
skip: fname1
and I run a save either from the client or server against:
/pathname/dir1
then NetWorker will back this directory up and all of its contents. I
was able to recover it just dandy. Of course, if there's a .nsr file
under dir1, or further down, then it will control what gets backed up
under dir1. However, if I run a save against: /pathname/fname1 then the
aforementioned .nsr file will kick in and the backup will not do
anything. I find this very interesting that it works for a directory but
not for a file. So, it would seem that you either need to back up the
file before you add the skip or use the '-i' option to ignore the .nsr.
If running from the server, I always check the group control window to
ensure that the savesets really were backed up and are not reported as 0
KB. Also, I check that saveset recover shows an instance for the saveset
and not just a blank entry. If running from the client, I also check to
make sure that the command reports that it backed something up and not
something like "0 files".
George
Darren Dunham wrote:
>
> > man -s 5 nsr
> > [snip]
> > 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 catalog any
> > propagated directives.
>
> Oops. I meant to post the next paragraph also. It's a bit more
> explicit (and has fewer grammatical errors).
>
> The following algorithm is used to match files to the
> appropriate ASM specification. First the .nsr file in the
> current directory (if any) is scanned from top to bottom 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 specifica-
> tion with a leading "+" whose pattern matches the file name
> (for clarity, we recommend placing all propagating ("+")
> directives after all the non-propagating directives in a
> .nsr file). If no match is found, then the .nsr file found
> in the ".." directory (if any) is scanned from top to bottom
> looking for a match with an ASM specification that has a
> leading +. This process continues until the .nsr file in
> the "/" directory (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.
>
> Notice that this means that .nsr files are valid all the way up the
> directory tree of whereever it is currently mounted.
>
> --
> Darren Dunham ddunham AT taos DOT
> com
> Unix System Administrator Taos - The SysAdmin Company
> Got some Dr Pepper? San Francisco, CA bay area
> < This line left intentionally blank to confuse you. >
>
> --
> Note: To sign off this list, send a "signoff networker" command via email
> to listserv AT listmail.temple DOT edu or visit the list's Web site at
> http://listmail.temple.edu/archives/networker.html where you can
> also view and post messages to the list.
> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
