At first I thought the /usr/openv/netbackup/db/images/<client>/STREAMS file
contained the dates of the last backup per policy & schedule:

1 1130406661 P_Unix_FS Monthly 0,0,1987200 0 0 /vol/d07
2 1130406662 P_Unix_FS Monthly 0,0,1987200 0 0 /vol/d06
3 1130406664 P_Unix_FS Monthly 0,0,1987200 0 0 /vol/vol0
1 1131015073 P_Unix_FS Cumu 4,0,172800 0 0 /vol/d07
2 1131015256 P_Unix_FS Cumu 4,0,172800 0 0 /vol/d06
3 1131015357 P_Unix_FS Cumu 4,0,172800 0 0 /vol/vol0
1 1131447191 P_Unix_FS Incr 1,0,86400 0 0 /vol/d07
2 1131447192 P_Unix_FS Incr 1,0,86400 0 0 /vol/d06
3 1131447193 P_Unix_FS Incr 1,0,86400 0 0 /vol/vol0

I was thinking the second column was the date of the last backup.  I then
found some weekly backups that seemed to fail one week & succeed the next
week that had the first attempt's time in them and not the successful second
attempt's time.  

I started thinking that this was the date of the previous successful backup
or previous "intended" backup - perhaps to keep backups from doing what I
call "schedule creep", ie, slowly creeping around the calendar as their
failures push the next schedule backup attempt out farther.

It's hard to explain...

This is all leading to trying to parse out filesystems/streams that have
failed in more than X-many frequency periods (field 7 above) to try to come
up with an alert mechanism for "fileystems in danger" for multistream
backups.

-M

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Mark Donaldson - Systems Administrator - 303-664-2040
 Corporate Express - Broomfield, Colorado
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Blah, Blah, Blah.  Yadda, Yadda, Yadda.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+