On Sun, Dec 23, 2007 at 05:02:34PM -0500, George Sinclair wrote:
> I have a RedHat Linux client that is in two different groups. I want 
> group 1 to back up 'All', but I want it to avoid a specific file system.
> I want group 2 to *only* back up that file system, and I want to able to 
> browse the data, and I don't want to have to be forced
> to change the browse time to see it. Is there a way to exclude an actual 
> file system itself from the backups for one NSR client resource
> but include it for another?

Yeah, you're running into two items that make this difficult.

Directives are read only by save/savefs (in other words after the
filesystem has been discovered and scheduled for a backup.  The fact
that the directive may exclude files is not noticed by the scheduler.

Networker backups are shared between instances.  Unlike Netbackup which
tracks full/incr independently across policies.

> Both groups are members of the same pool, and indexing is turned on for 
> the pool. Both client resources have a one month browse policy.
> Since I want to be able to browse the backed up data, I'm using the 
> '+null' rather than a 'skip'. In my testing, I observed that if I run an
> incremental on group 2 before running group 1 then everything is fine. 
> However, if I add, modify or update the time on any data
> under /0/data/joe, and then I run group 1 before running group 2 then 
> when I subsequently run group 1, it backs up nothing. I also tested this 
> using
> savegroup estimates (savegrp -n -l incr group). If I run the backup for 
> group 1 first then an estimate for group 2 shows 0 KB; otherwise,
> if I run the estimate for group 2 before running the actual backup for 
> group 1 then it shows what I would expect.

Yes.  This is the same as loosening a directive and running another
level or incr backup.  NW will not back calculate and recognize that it
has been missed in the past but shouldn't be now.  All it does is go off
timestamps. 

> The only thing I can think is that maybe NetWorker interprets a file 
> system mount point in a directive differently versus a directory
> under that file system mount point? I've used the above technique before 
> without any problems, *BUT* I wasn't specifying
> an actual file system mount point. Instead, I was always specifying a 
> path at least one level further down, e.g.
> 
> << /0/data/joe/mydir >>
> +null: .?* *
> 
> and then the other client would use the save set:
> 
> 0/data/joe/mydir
> 
> If I perform the same tests by modifying data under 'mydir' then 
> everything works as expected. I would think that if it doesn't work
> when specifying a file system mount point then why would it work when 
> specifying a subdirectory path under that file system?

Nope.  Filesystem details are somewhat different.  However, I think you
would still run into the same problems with ordering.  If the "null"
instance is the first to back up a file, then running an incr on the
non-null instance should still skip it.

> Obviously, enumerating the individual file systems instead of using 
> 'All' would solve the problem because then I wouldn't have
> to use a directive, but I'd really prefer to use 'All'.

Yes, but that's the only way I can think of right now to avoid this.  In
some cases, I've run cron jobs on a client that allow a script to
createa a list of filesystems (allowing me to exclude some explicitly),
then upload that and push it into the configuration.  It allows
fileystems to be added dynamically (major benefit of 'all'), but still
let me exclude.  Unfortunately, such a solution is going to be more
brittle than having NW do it directly.

-- 
Darren Dunham                                           ddunham AT taos DOT com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

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