This is fixed in 6.5.2, but the other known problems in that release may 
prevent you from wanting to upgrade. I've tested it and it works. From 
the release notes:

Etrack Incident = ET1167175
Associated Primary Etrack = ET1165582
Titan cases: 240-665-067 281-261-075 290-875-726

Description:
A Zeta file system (ZFS) filesystem is not backed up when the
ALL_LOCAL_DRIVES directive is used.

Bryan

Mark Glazerman wrote:
>
> 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.
>
> We have a number of Sun boxes which have various test and development 
> oracle instances which are housed inside ZFS file systems. We blew 
> away one of these test instances the other day (after doing a full OS 
> backup and the required RMAN backups) but when we went to restore the 
> data from the ZFS filesystems, NBU didn’t have anything under the 
> uppermost directory. A quick check of other systems with ZFS showed 
> the same issue.We spent the better part of 2 days playing around with 
> the include_list’s and exclude_list’s but nothing worked.
>
> In order to backup ZFS file systems you must explicitly add the ZFS 
> directories into the backup selections of the backup policy. This 
> “fix” was also confirmed by Symantec support who were also happy to 
> tell me that ZFS isn’t officially supported by NBU yet.
>
> This on its own should work great if you have a single policy backing 
> up a single server with all it’s ZFS under the same parent directory. 
> However, if like us, you have a backup policy which backs up multiple 
> servers, each with their own uniquely named ZFS file systems, you need 
> to get a bit creative.
>
> 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. Now when the policy runs, it sees each directory (as 
> listed in the backup selection) on each server and doesn’t moan about 
> anything. Perhaps not the neatest of fixes but it works.
>
> Apologies for the wordy post, just thought I’d put this info out there 
> in case anyone else is moving towards ZFS.
>
> *Mark Glazerman*
>
> *Enterprise Storage Administrator*
>
> *Spartech Corporation*
>
> Desk: 314-889-8282
>
> Fax: 314-854-8282
>
> Cell: 618-520-3401
>
> *mark.glazerman AT spartech DOT com* <mailto:mark.glazerman AT spartech DOT 
> com>
>
> *http://www.spartech.com* <http://www.spartech.com/>
>
> P please don't print this e-mail unless you really need to
>
> This e-mail and any files transmitted with it are confidential, are 
> intended solely for the use of the addressee, and may be legally 
> privileged. If you have received this email in error please notify the 
> sender immediately, and do not copy or forward it.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>   
_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu