> Incase anyone is considering implementing any ZFS in their
> environment which they want to back up using NetBackup we
> found out yesterday that ALL_LOCAL_DRIVES as the backup
> selection does NOT cover ZFS filesystems. [...]
> 
> In order to backup ZFS file systems you must explicitly
> add the ZFS directories into the backup selections of the
> backup policy.  

Catching up on mail; apologies if these bits have already been
addressed.

As others have pointed out, 6.5.2 has the fix for A_L_D and ZFS.  I got
an engineering binary for bpmount (depends on the Solaris version, IIRC)
for your clients that works just fine.  You may need to blow away the
STREAMS file to deal with auto-discovered streaming mode.


> The policy in question backs up 15 Sun boxes  with a total
> of 6 differently named ZFS file systems spread amongst them.
> If you just list the file systems in the backup selections,
> NBU looks for each of those different filesystems on each
> server and spits out an error code 71 (None of the files in
> the file list exist) for every directory it can't find.  The
> only way we could work out to avoid these errors (and there
> were a lot of them) was to create every missing directory on
> every server and then touch a tiny file inside each of these 
> directories.  [...]

Others pointed out that turning off allow_multiple_data_streams avoids a
stat 71, but you need simultaneous backups rather than going through all
the filesystems on a client sequentially.  Been there, done that.  This
may strike you as a kludge, but for situations where A_L_D isn't what I
need, but a single policy has to handle servers with different selection
list entries, the simplest way is to put all the selections in the
policy and frame each with NEW_SERVER and a file guaranteed to be on the
host (/etc/hosts or c:/windows/system32/drivers/etc/hosts).  Allow
multiple streams and you're good without having to create anything on
the clients.

Now, adding the dummy file to a stream works just fine, but if you have
to manually edit hundreds of mount points and you're going to get that
EEB in a day or two, it may be an option to just keep A_L_D and let the
stat 71s happen.  Depending on your procedures, of course, unless your
environment has chronic 71 problems (how rare is _that_?), significant
numbers of failure statuses which need investigation/remediation nightly
or you have automated systems that generate unpleasantness for every
non-success status, Operations can filter the 71s, be sure they are from
these systems and ignore them for a day or so.


_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu