Oh - one last thing.  This script relies on the gnu date command to do some
calculations for various times-of-day.

I have that stored on my server as the command "gdate".  It's not stock
solaris but it's downloadable as a pre-compiled binary executable.  Google
is your friend on this - I forget where I got my copy.

-M

-----Original Message-----

Thought somebody might find this useful.

It's been posted to this list a lot that it'd be desirable to have a tool
that did more than detect if a backup failed but also if a backup simply
didn't run when expected.

I found myself in the need for this kind of information and so put this
script together over the past week.  My DBA's want to know more then just
"did the backup fail or succeed?" but also the answer to the question, "did
the backup fail to start?".

At first, I tried to generate a list of "expected future backups" using the
-predict function of bpsched but that turned out to be unwieldy.  That
command doesn't reply on a range of time, just reports what backup windows
are open at a specific point in time.  

This new script uses the windows & frequency settings in the policy and
looks back over time to see if a backup occurred within the expected
frequency from the close of the last backup window.

It only works for frequency-based schedules.  Exclude dates on a freq
schedule are ignored and pure-calendar schedules should also be ignored - if
I wrote this right, anyway.  Sorry - but implementing calendar schedules was
too complex and I don't use them anyway.

It starts with a list of active policies, builds a denormalized "database"
from them, then scans back to find if there's any missing backups within the
expected frequency-based windows.  If the backup window is in the future,
(like a 16:00 start and it's only 12:00) then the previous open window is
used.  If the window start is in the past but the duration says the window
is still open (like at 16:00 start with a 4 hour duration and it's 18:00),
then the previous window should be used again. However, in this second case,
a backup that succeeded in the current window will act to "pass" the check.

If a single-stream of a multi-stream backup failed, then this won't pick it
up, either.  It's simply pass/fail.  It answers the question, "Did you get
at least one good backup for this policy, schedule, & client during the last
backup cycle".

It seems to work for me.  Good luck with it.

-M