Ed, I 100% agree with what you've said below. For my traditional and
small environment (only about 550 servers), what I've outlined is
extremely useful, especially since it works for both Netbackup and
Backup Exec clients in a similar manner. And no, a single report will
never be able to get you all the information you need (for example,
there a second NBU specific report that gets at least a little closer to
giving accurate results on what you describe below in interpreting
schedules and report on backup success, believe they call it
client_sla_summary_report or something).
These reports don't replace one of my major functions, which is to
follow-up and design a lot of those said one-offs. I certainly wouldn't
want to be without the reports though, now that I know the value of
them. My single biggest concern is the interpretation of these reports,
and being able to explain without a doubt why an entry is or isn't in
them.
Thanks for the comments Ed.
Cheers,
Jon
-----Original Message-----
From: Ed Wilts [mailto:ewilts AT ewilts DOT org]
Sent: Tuesday, July 24, 2007 5:19 PM
To: Dyck, Jonathan; veritas-bu AT mailman.eng.auburn DOT edu
Subject: RE: [Veritas-bu] retentions
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.
This message may contain privileged and/or confidential information. If
you have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate or distribute it; do not open any attachments,
delete it immediately from your system and notify the sender promptly by e-mail
that you have done so. Thank you.
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
