Reading the discussion made me think.
with scripting it is fairly easy to produce a list of groups.
each group has a status field for auto run.
building a list would be easy and comparing it to say yesterdays list or
the list or groups that must run every day is also easy, changes in the
list of groups to run can be put in a version controls system (cvs,
subversion) and combined with cfenfine to report changes.
Just my ideas , as I will have to make someting similar also
Maarten Boot
Howard, Patrick wrote:
>>>From the responses I have seen, it seems that there is really no "good"
> method in a large environment to "easily" verify that all of the backups
> that should have ran, actually ran. It also seems that everyone fears
> the same thing I do...(a group is set to not auto start and it doesn't
> get documented or communicated that it was done, and it gets
> "forgotten") I guess it's nice to know that others are fearful of the
> same thing.
>
> Seems as though Legato should be able to have something to check for
> that. I know by saying that I will get a million responses as to how I
> could write a little script or command that goes out and checks for
> groups set to auto start=no...
>
> I welcome all feedback on this topic, and given the responses so far, it
> seems to be a subject that is near and dear to a bunch of people.
>
> It seems as though I do bits and pieces of what everyone has said.
> 1. I get emailed on failed backups
> 2. A public folder gets Emailed the successful completion report
> 3. Our Operators monitor the messages / NetWorker Admin
> 4. But I still don't know if all of my backups that should have kicked
> off, actually did.
>
> We are kicking around the idea of getting everything kicked off by our
> job scheduler (Tivoli Workload Scheduler). Not sure if that will
> complicate things further (I think it probably will).
>
> Of course another problem we face is we have backups that span a 24hour
> period (Our Exchange Cluster).
>
> So, my take away seems to be that it's a manual process any way you
> slice it. Obviously a goal would be to have a checklist, but for us,
> that would mean decreasing our "groups" to a level that we could
> actually manage doing that and be able to keep up with everything else
> we have to do.
>
> Hasn't anyone else gone thru an audit whereby they had to be able to
> prove that they could verify that all of their backups for a given night
> actually ran?
>
> Thanks - Patrick
>
>
>
>
> -----Original Message-----
> From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU]
> On
> Behalf Of Teresa Biehler
> Sent: Saturday, March 24, 2007 7:49 AM
> To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
> Subject: Re: [Networker] Backup - Log / Checklist
>
> We have a home-grown script that creates a webpage for our operators
> with simple red/yellow/green coding. The script parses the completion
> text (retrieved via nsradmin) for each group. This is essentially the
> same information that is displayed in the group details on the GUI
> (v7.2.2).
>
> We also have checklists based on groups, not clients. In addition to
> the groups, they also have checklists for remembering to check for
> things like errors on the library operator panel, pending tape loads,
> other strangeness in the NetWorker GUI, etc.
>
> We looked at packaged products. At the time we looked at them, the
> status displayed for each client was the status that NetWorker reports.
> So, if for example, files change during the backup, NetWorker still
> reports this as successful. Well, if files changing size during backups
> is truly a failure/indication of a problem (if, for example, an
> application needs to be down for a consistent state of all application
> files), then this should be flagged by the tool as a problem. Our
> in-house script does this sort of parsing on the completion text. It
> also allows us to follow-up on new, unexpected messages from NetWorker.
>
>
> Here's our problem, though. It's my understanding that in v7.3.x,
> nsradmin goes away (if this is wrong, someone please let me know!).
> With all our operations tasks built around using a script which get info
> from nsradmin, this will be a HUGE upgrade for us. Has anyone scripted
> checking backup status with v7.3.x?
>
> Thanks.
> Teresa
>
>
>
> -----Original Message-----
> From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU]
> On
> Behalf Of Howard, Patrick
> Sent: Friday, March 23, 2007 5:46 PM
> To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
> Subject: [Networker] Backup - Log / Checklist
>
> Greetings all:
>
> We are going thru an internal audit right now, and a question was asked
> of us, that I am confident I will hear more on. (and not in a good
> way).
>
> We have hundreds of Clients and approx 200 groups.
>
> I have Operations staff that monitor the backups, however they don't
> have a checklist that says X Group should kick off at X time, etc. etc.
>
> Some of our backups are kicked off by Legato, others are kicked off by
> Tivoli Workload Scheduler.
>
> Can anyone share with me their method to verify that the backups that
> should ran, has actually ran etc. I gave the analogy, that if we were
> working on a group and decided to not have it auto start, and forgot to
> put it back to auto start, there would be no way for the staff to know.
> Would love to hear how others are dealing with this.
>
> Failures are not an issue, the team is all over that, it's just a matter
> of ensuring that all of the backups have been run. I know you are going
> to say, put a check list together, etc. etc. Again, it's HUNDREDS of
> clients...If that's the only way, then I guess that's what we'll have to
> do.
>
>
> <http://www.anntaylor.com/>
>
> Patrick S. Howard
> Ann Taylor
> 476 Wheelers Farm Road
> Milford, CT 06461
> (203) 283-8772 direct
> (646) 660-0426 mobile
> patrick_howard AT anntaylor DOT com
> www.anntaylor.com <http://www.anntaylor.com/>
>
>
>
>
>
> ______________________________________________________________________
> The information in this email (including any attachments) is
> confidential and may be legally privileged. Access to this e-mail by
> anyone other than the intended addressee is unauthorized. If you are not
> the intended recipient of this message, any review, disclosure, copying,
> distribution, retention, or any action taken or omitted to be taken in
> reliance on it (including any attachments) is prohibited and may be
> unlawful. If you are not the intended recipient, please reply to or
> forward a copy of this message to the sender and delete the message, all
> attachments, and any copies thereof from your system and destroy any
> printout thereof.
>
> To sign off this list, send email to listserv AT listserv.temple DOT edu and
> type "signoff networker" in the body of the email. Please write to
> networker-request AT listserv.temple DOT edu if you have any problems with
> this
> list. You can access the archives at
> http://listserv.temple.edu/archives/networker.html or via RSS at
> http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
>
> To sign off this list, send email to listserv AT listserv.temple DOT edu and
> type "signoff networker" in the body of the email. Please write to
> networker-request AT listserv.temple DOT edu if you have any problems with
> this
> list. You can access the archives at
> http://listserv.temple.edu/archives/networker.html or via RSS at
> http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
>
> ______________________________________________________________________
> The information in this email (including any attachments) is confidential and
> may be legally privileged. Access to this e-mail by anyone other than the
> intended addressee is unauthorized. If you are not the intended recipient of
> this message, any review, disclosure, copying, distribution, retention, or
> any action taken or omitted to be taken in reliance on it (including any
> attachments) is prohibited and may be unlawful. If you are not the intended
> recipient, please reply to or forward a copy of this message to the sender
> and delete the message, all attachments, and any copies thereof from your
> system and destroy any printout thereof.
>
> To sign off this list, send email to listserv AT listserv.temple DOT edu and
> type "signoff networker" in the body of the email. Please write to
> networker-request AT listserv.temple DOT edu if you have any problems with
> this list. You can access the archives at
> http://listserv.temple.edu/archives/networker.html or
> via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
>
>
>
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
