02-04-2011 09:47 PM
I have a unix client where backups selection is set as ALL_LOCAL_DRIVES... with enabled multi streams...
this client have one encypted file system where root even can not access.... and no need to take the backup even.. so we kept that file in the exclude_list..
but as it is multistreaming backup.. bpfis is identifying that file system and starting the new stream.. and the new stream if failing with 71. . (because root also can not access the FS)
could any one tell me .. how to skip that to start the new stream...
Solved! Go to Solution.
02-05-2011 06:18 AM
alongside multiple data streams, then an exclude_list for a drive almost becomes "irrelevant" at the start of processing.
NB will create the streams first, before referencing the exclude_list entries. Subsequently, you end up with a child job for each drive and, in the case of excluded drives, you can then end up with EC=71's.
This is by design!?! I'm 99.9% sure that there is a T/N explaining this behaviour (for certain NB releases?) and that the EC=71's are "normal" (altho' not required by us!), but I'll be d****d if I can find it on the KB now!
The only T/N I can find is the following:
http://www.symantec.com/business/support/index?page=content&id=TECH6524
"...The first is due to the order of operations in processing the backup request. Regardless of the source of the backup request (manual, scheduled or command line) when the process discovers the ALL_LOCAL_DRIVES parameter in the files list, an interrogation of the client results to determine the number of local drives or mount points. Each of these becomes a separate NetBackup job. These jobs are then sent to the queue for processing.
At this point, even if there is an exclude_list on the client, excluding one or more drives or mount points, there is, and should be a job for that drive or mount point...."
02-05-2011 12:01 AM
NBU would normally spawn a job for each filesystem/drive letter, and then backup the 'empty' mount point.
You did not mention your NBU version?
It almost sounds as if the exclude list is ignored (unless even the top level of the mount point is inaccessible). There are known issues with NBU7 where exclude lists are ignored. Check bpbkar log on this client to see if exclude list is honoured.
02-05-2011 06:18 AM
alongside multiple data streams, then an exclude_list for a drive almost becomes "irrelevant" at the start of processing.
NB will create the streams first, before referencing the exclude_list entries. Subsequently, you end up with a child job for each drive and, in the case of excluded drives, you can then end up with EC=71's.
This is by design!?! I'm 99.9% sure that there is a T/N explaining this behaviour (for certain NB releases?) and that the EC=71's are "normal" (altho' not required by us!), but I'll be d****d if I can find it on the KB now!
The only T/N I can find is the following:
http://www.symantec.com/business/support/index?page=content&id=TECH6524
"...The first is due to the order of operations in processing the backup request. Regardless of the source of the backup request (manual, scheduled or command line) when the process discovers the ALL_LOCAL_DRIVES parameter in the files list, an interrogation of the client results to determine the number of local drives or mount points. Each of these becomes a separate NetBackup job. These jobs are then sent to the queue for processing.
At this point, even if there is an exclude_list on the client, excluding one or more drives or mount points, there is, and should be a job for that drive or mount point...."
02-07-2011 02:33 PM
its NBU 6.5.6
and even top level of the mount point also inaccessible.....
and exclude list is working for the other entiries... ....
02-20-2011 11:52 AM
I removed the multistream to stop the failures.. for time being...
still checking for solution
02-20-2011 11:56 PM
If you want multiple data streams then all I can suggest is you only specify the file systems that you want to backup in the policy as opposed to utilising ALL_LOCAL_DRIVES & exclude_lists.