Jeff,

You won't be able to get a file list in the method you have attempted.
 Once the backup fails, NBU removes the information from the catalog.

A couple of items for you...

1. You may want to enable the checkpoint restart feature (at the
policy) so that you could resume the backup from the point at which it
failed.
2. There is a way to run bpbkar on the client to see if it's a problem
just reading the files.

/usr/openv/netbackup/bin/bpbkar -nocont <path> > /dev/null 2><output file>
eg:
bpbkar -nocont / > /dev/null 2>/tmp/file_list.txt

Then examine the file_list.txt to see the file names.

3. There's also a way to enable the logging of files at the client
when the backup occurs.
a. Make sure you have the /usr/openv/netbackup/logs/bpbkar directory in place.
b. touch /usr/openv/netbackup/bpbkar_path_tr
c. perform backup
d. examine the log.mmddyy file created in the above dir

CAUTION... if there are a large number of files (as you indicate i
likely), it's possible that this log file or output file could grow
REALLY large... If that's a problem, just run the bpbkar command and
don't redirect stderr (omit the 2>file)

Point 2 and 3 come from my notes and I don't readily find references
on the Symantec web-site, but I'm sure they are there.

HTH
-Tim

On 1/4/08, Jeff Cleverley <jeff.cleverley AT avagotech DOT com> wrote:
> Greetings,
>
> I have a file system that has started to fail full backups on a regular
> basis.  The incremental backups run fine.  This file system is on a hpux
> 11.11 server,  There is only 228 gig of used data, but it does have
> ~5.5m inodes in use.  The backup fails with a status 41.  This server
> has other file systems on it with more used inodes and more used space,
> and they don't have this problem.  I've run the backup at various times
> when I know the  network and file system load is low, but it doesn't change.
>
> The current backup environment is 5.1 mp2.  It was supposed to be
> retired by now which is why it hasn't been upgraded.
>
> The reason I want to see what files it is backing up before it fails is
> that all of the backups seem to backup just over 195 gig before they
> fail.  The file counts vary quite a bit.  I'm expecting that I may have
> a very poorly laid out structure with hundreds of thousands of files in
> one directory that is causing this problem.  This may also be caused by
> some timeout if it does hit this, but I haven't been able to find it in
> any of the log files.
>
> I was able to recovery an image from the tape listing by running
> bpmedialist -mcontents -m bk7159.  That returns image
> massey_1199305335.  I've tried doing the following bpflist command and
> get the no entity found
>
> bpflist -backupid massey_1199305335 -d 01/02/2008 -e 01/03/2008 -client
> massey
>
> I also tried running the bpflist this way and get no entity found
> again.  This format works when I give it a different client name and
> pattern, so I know I have the syntax correct.
>
> bpflist -client massey -st FULL -d 01/02/2008 00:00:00 -rl 1 -pattern
> /mnt/wizard
>
> I'm guessing some of this isn't working because the backup did not
> complete and there isn't a valid image for it.
>
> Any help you can provide that will show me where the backup is failing
> would be greatly appreciated.
>
> Thanks,
>
> Jeff
>
> --
>
> Jeff Cleverley
> Unix Systems Administrator
> 4380 Ziegler Road
> Fort Collins, Colorado 80525
> 970-288-4611
> jeff.cleverley AT avagotech DOT com
>
> _______________________________________________
> 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