It looks to me like you should use the example of the legato manual
<< /0/exports/ >>
+null: .?* *
<</0/exports/data(exception) >>
ignore
This will null all directories below exports except
0/exports/data(exception)
and I have a feeling in your case those are way less than the number of
folders that need to be nullified.
-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of George Sinclair
Sent: Sunday, July 29, 2007 9:43 PM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: [Networker] Need help and advice on directives
Hi,
I have a question on server side versus client side directives. We have
a server side directive for a Unix client, but it's getting fairly long
and unwieldy. Declaring these on the server side seems to have the
advantage in that it's easier to maintain since you only have to look in
once place, so it's more centralized. Makes sense when you have several
directories that need to be skipped or nulled for a given client, *BUT*
I have heard that when a directive gets too long it can cause problems.
Not sure if this is still the case, however. Maybe this was only true in
older releases? We're using NW 7.2.2 on our Solaris primary backup
server. I'm concerned about this because the paths that need to be
nulled only continues to grow for this client so I was thinking to
switch to client side directives to avoid any possible issues.
Here's the way I do it now from the server. The directive actually lists
more paths than this, but this is the basic idea:
<< /0/exports/data1 >>
+null: .?* *
<< /0/exports/data2 >>
+null: .?* *
<< /0/exports/data3 >>
+null: .?* *
<< /1/exports/data1 >>
+null: .?* *
So the first NSR client resource (a) backs up 'All' but uses this server
side directive, and we have another client resource (b) that backs up
only these specific paths with no directive. Both client resources
backup their data to separate pools, but both pools have indexing turned
on, so all save sets are browsable. As file systems fill up, we just
create new ones, and I add them to the server side directive. If I
switch things to use client side directives then resource (a) will no
longer need to specify the server side directive. How do I set up the
client side directives?
Do I (1) create a single '.nsr' file under each of the parent
directories, so, say, /0/exports/.nsr would contain:
<< data1 >>
+null: .?* *
<< data2 >>
+null: .?* *
<< data 3 >>
+null: .?* *
and /1/exports/.nsr would contain similar syntax and then ditto for the
other file system paths?
Or, do I (2) create a '.nsr' file under each of the above directories
with the following syntax:
+null .? * *
Wherein I don't specify the name of the path, just "+null .? * *". I'm
thinking option 2 would be a complete disaster because then nothing
would get backed up unless the path specified something further down,
e.g. /0/exports/dir1/other, but it won't so I'd be like those tourists
in those AMEX commercials. So, option 1 might be the only cure. Clearly,
option 1 will force me to create several .nsr files, but none of them is
going to be as long as the combined server side directive. Is this
reasonable and the best I can do? Will this work?
Thanks.
George
--
George Sinclair - NOAA/NESDIS/National Oceanographic Data Center
SSMC3 4th Floor Rm 4145 | Voice: (301) 713-3284 x210
1315 East West Highway | Fax: (301) 713-3301
Silver Spring, MD 20910-3282 | Web Site: http://www.nodc.noaa.gov/
- Any opinions expressed in this message are NOT those of the US Govt. -
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type
"signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
