Networker

Re: [Networker] Need help and advice on directives

2007-07-30 11:30:51
Subject: Re: [Networker] Need help and advice on directives
From: George Sinclair <George.Sinclair AT NOAA DOT GOV>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Mon, 30 Jul 2007 11:27:57 -0400
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

<Prev in Thread] Current Thread [Next in Thread>