Actually you could do either according to the manual
We have over 1500 clients ourselves so for us it needs to be server side,
But if you can do it client side and have acces to the client yourselves( we
don't)
Then you should try that option
Under unix you need a .nsr file with the directives in
Under windows it need the name nsr.dir
Do see the manual it helped us on the way at least
-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of George Sinclair
Sent: Monday, July 30, 2007 5:28 PM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] Need help and advice on directives
backup wrote:
> 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.
>
Thanks! Actually, we have about ten folders under /0/exports that need
to be nullified and only a few that don't.
These could change at any time, so they need to be on the backups, but
they're handled by a special pool. Another
pool takes care of anything else that might get created under /0 (there
is some stuff under there but not much), including
other stuff under /0/exports that's outside the purview of these
folders. Based on your suggestion, I would need 10 exception
and ignore lines and one main line and accompanying '+null' line for a
total of 22 lines to handle the stuff under /0/exports.
Currently, I'm just specifying '+null' for each of the 10 paths so I
have 20 lines to handle /0/exports, but my server side directive
also includes entries for the other file system paths like
/1/exports/dir1 ... dir5, etc., so it's much longer.
Question: Were you suggesting that the directive would be created on the
client or server? If the server then it would be 2 lines longer
than what I'm doing now. If the client, then it would certainly be much
shorter. Would it be put under /0/exports?
I'm not opposed to using this method. That seems pretty slick, actually.
I just want to avoid running into any length problems with directives,
either on the client or server. If I understand this correctly, doing
this on the client seems like it would allow me to break those up into
separate directives wherein each directive would be under its respective
file system like /1/exports/.nsr, /2/exports/.nsr, etc. and each would be
shorter than the current combined server directive and would look like
what you showed.
Question: Does that sound right?
Question: If I use your sample directive as a client side directive what
will prevent the NSR client resource that handles the other stuff
from hitting the exceptions?
Does NW simply say that unless the named save set matches this name then
null it? So, in the case of the client resource that specifies 'All',
it would null everything since this one is gonna back up the /0 file
system, but in the case of the other resource that lists specific paths
like /0/exports/data1,
it will hit those since those names match the ignore lines? I just want
to make sure that the directive I use forces the resource that
handles 'All' to not back up the specified paths, but still allows it to
get everything else under the parent file system, and the resource that
handles the specific named paths won't be hampered by the directive.
Question: Just out of curiosity, what if I used something like
/0/exports/.nsr:
+null: data1
+null: data2
+null: data3
When the resource runs that uses 'All' would it null this stuff, but the
one that specifies paths further down (like /0/exports/data2)
would still back those up since the .nsr file is above that level?
George
> -----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
|
