This doesn't really address all of the issues.  In order for this to work,
you have to know what the schedule of the jobs are supposed to be.  We've
got a ton of backups that only run monthly and another ton that only run
semi-annually.  Unless I sit down with a calendar, telling when the last
full backup was and comparing that to what it should be is not going to be
trivial.

What's important to know is not when the last backup was, but when the last
backup was *supposed to be*.  To do that, you need to dig into the scheduler
and that is where it gets tough.  For one client having a weekly full is
supposed to be normal.  For another, I may not try to back it for 6 months
and that's perfectly normal.

Reports like this are great if you have a simple environment and everybody
does your standard daily/weekly/monthly style backups.  Not everybody does
their weekly fulls on a weekend and incremental during the week and calls it
a day.  Any backup software can do that.

I've got similar issues with Aptare's projections for tape consumption.  In
our environment it's absolutely useless since it's based on the day of the
week and not on the NetBackup schedules.  If it really wanted to a fantastic
job (hint, hint), dig into the policies and schedules, its own historical
database, and realize that the 2TB backup I did 6 months ago will be done
again.  I've got about 100TB of storage on a semi-annual backup schedule.
To be able to get accurate estimates of those jobs coming up would be
sweet...

Again, there's no point in telling me when the last backup was.  What I want
to know is if the backups are getting done when they're supposed to be done.
This gets even more complicated when you've got multiple policies for the
same client - something that in some cases you *have* to do.

Backup reporting and auditing is hard.  StorageConsole does a good job at
what it's attempted to bite off but it could still get better.  And yes, I
realize that our environment is non-traditional and that sometimes we're
just not going to get a solution unless we write it ourselves.

        .../Ed

--
Ed Wilts, Mounds View, MN, USA
mailto:ewilts AT ewilts DOT org
I GoodSearch for Bundles Of Love:
http://www.goodsearch.com/?charityid=821118 

> -----Original Message-----
> From: veritas-bu-bounces AT mailman.eng.auburn DOT edu [mailto:veritas-bu-
> bounces AT mailman.eng.auburn DOT edu] On Behalf Of Dyck, Jonathan
> Sent: Tuesday, July 24, 2007 2:37 PM
> To: Wayne T Smith; veritas-bu AT mailman.eng.auburn DOT edu
> Subject: Re: [Veritas-bu] retentions
> 
> Just to chime in on the Aptare reports...
> 
> They have an automated report ("out of the box", but not really) you
> can
> cron/windows schedule to run that will give you the following details
> on
> full backups...
> (hope your screens large enough to make out the headings...).   Great
> way to stop sys admins bugging you about last successful backups.
> 
> 
> 
>                                                        LATEST FULL
> BACKUP     LAST 60 DAYS
> CLIENT                             SERVER              LAST FULL
> MBYTES       FILES  AVG MBYTES   AVG FILES
> ------                             ------              ---------
> ------       -----  ----------   ---------
> 
> 
> 
> With a little fiddling, you can get something that looks like the
> following all in one email...
> 
> 1) Missing Backups (from last window any scheduled backup that has yet
> to run or has failed)
> 2) Last successful full backup attempt
> 3) Any skipped files during last backup
> 
> Get the right person on a DL for an email, and you're laughing.
> 
> Cheers,
> Jon
> 
> 
> 
> -----Original Message-----
> From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
> [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Wayne T
> Smith
> Sent: Friday, July 20, 2007 12:29 PM
> To: veritas-bu AT mailman.eng.auburn DOT edu
> Subject: Re: [Veritas-bu] retentions
> 
> I, too, agree the 2-week retention should be addressed ... quite risky.
> 
> A few thoughts ...
> 
> I recently tested Aptare StorageConsole and one of its out-of-the-box
> displays is close what you're looking for, I think.  When we obtain a
> license, I'll be discarding many scripts ... one of which sort of
> applies here.  The script  looks at all full images for all clients and
> reports the most recent full backup for each client, ordered by oldest
> first.  Look at the top of the list for clients in distress.
> 
> This is simple and works great for clients with one image holding
> everything.  It isn't nearly good enough for clients using multiple
> streams or clients that also have Exchange/Oracle/etc images in
> addition
> to file system images.  I've started more than once to approximate
> "proof" we are successfully backing up at least what we intend.  So far
> I have a bunch of failed attempts that would have worked for simple
> cases, but failed miserably in multitudes of ways.
> 
> The best answer for us has always seemed to be getting accurate,
> succinct information in front of the eyes of someone who understands it
> and cares.  But even that is not enough sometimes.  Your idea of
> keeping
> the last full has promise, but you'll need a process to get rid of the
> images once you really don't want them ... plus, if your data is on
> tape, you'll probably require more media, as tape occupancy goes down
> due to the retention-extended images living alone.
> 
> cheers, wayne
> 
> Brandon Zermeno wrote, in part,  on 2007-07-19 6:50 PM:
> >
> > We had an issue where was server was down for over 2 weeks and the
> > last full backups expired. The retention for this environment is 2
> > weeks. After the tapes expired the App team decided they wanted to
> > restore. Now management wants Veritas to extend the retention period
> > automatically if a full is not successfully run. I do not know of any
> > company that has this capability so I am looking for ideas. I do not
> > think it would be possible for a person to manually track all the
> > servers and their last full and then manually bpexpdate the images. I
> > have pushed back with the question of why was this server allowed to
> > be down for 2 weeks but nobody is answering.

_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu