--=_mixed 0013C78386257007_=
Content-Type: multipart/alternative; boundary="=_alternative 0013C78486257007_="
--=_alternative 0013C78486257007_=
Content-Type: text/plain; charset="us-ascii"
David,
I do notice you are a vendor's shill.
What are your error rates for backup jobs?
Abbott Laboratories has daily error rates for all backup jobs less
than 0.4% for all jobs run, including all error code 41, 54, and 196
failures.
Hope to see you next week if you are in Chicago.
Michael F. Lavelle Abbott Labs,
Sr. Storage Engineer, CIT 100 Abbott Park Rd, AP14B-1
Phone: 847.937.1195 (Fx:935.9725) Abbott Park IL 60064-6042
David Rock <dave-bu AT graniteweb DOT com>
Sent by: veritas-bu-admin AT mailman.eng.auburn DOT edu
05/19/2005 10:00 PM
Please respond to David Rock
To: veritas-bu AT mailman.eng.auburn DOT edu, veritas-bu-admin AT
mailman.eng.auburn DOT edu
cc:
Subject: Re: [Veritas-bu] What are you NOT backing up?
* Michael F Lavelle <Michael.F.Lavelle AT abbott DOT com> [2005-05-18 18:28]:
> David,
> Even if your backup policies are set to backup a certain
directory
> tree or filesystem, the goodies' coverage script will not tell you
> anything about frequency of backups or retention.
> More importantly, no 3rd party tool will inform you about
> dependencies an application has on all data, binaries, configuration
> files, device drivers, etc... That is still something you and your
> customers have to define and prove thru DR testing.
Well, duh!
You will notice I didn't claim anything about frequency or retention, or
dependencies between applications and data. If you _are_ relying on
someone else to tell you how to do your job or how to run your
business, you're crazy. I was simply pointing out that I saw something
that has the potential to fill a gap that is a pain point for us and
thought sharing would be a good thing.
Storage Console _does_ help you see information about frequency
(indirectly) by making it obvious if something has not been backing up
for a while (displays last successful backup). As for retention, even SC
has a ways to go with policy management reporting. I've posted my own
version of policy reporting that includes vault information. last I
checked, no one else, commercial or otherwise, has attempted to
reconcile the polices to the vault profiles.
You have to remember we are talking about backup reporting here, and
ways to make that easier. Veritas certainly doesn't give you crap to do
that. Their tech couldn't even get Command Central _installed_, let
alone working after three weeks during our eval process. So you have
three choices; live with the sub-standard reporting in NBU, write your
own stuff and maintain it forever (which I am), or buy something to do it.
I'm not the only customer that likes Storage Console, either. Seems to
me that I have heard only good things from other people on this list
about it. It's _not_ a magic bullet. If it was, there wouldn't be other
products out there, but it's damn good at what it does. we looked at a
half a dozen products over 6 - 8 months before buying it because it was
the best one out there for us. It might not be the right solution for
you.
So before labeling me as a shill, try to keep in mind that I'm an
overworked, underpaid NBU admin like the rest of the poor saps on this
list. We all have the same problems with NBU, we've all been there at
crunch time trying to explain why a file wasn't recoverable. backups
suck, plain and simple. No one cares about it until it's too late, and
then it's YOUR head because some moron neglected to mention that new
mountpoint. I have 6 Master servers with 18 media servers backing up
1400 client machines in 3 different geographic locations. Ever try
running 6 Java GUI's at the same time?
I'm simply stating that a product that *I* recommended my company
purchase, because it will make our awareness of our environment better
so our customers' data is protected, has come out with a new feature
that makes it that much better. I _still_ recommend anyone that needs a
good NBU reporting tool really should take a look at Aptare's product.
--
David Rock
david AT graniteweb DOT com
--=_alternative 0013C78486257007_=
Content-Type: text/html; charset="us-ascii"
<br><font size=2 face="Arial">David,</font>
<br><font size=2 face="Arial"> I do notice you are a
vendor's shill.</font>
<br>
<br><font size=2 face="Arial"> What are your error
rates for backup jobs?</font>
<br><font size=2 face="Arial"> Abbott Laboratories
has daily error rates for all backup jobs less than 0.4% for all jobs run,
including all error code 41, 54, and 196 failures.</font>
<br>
<br><font size=2 face="Arial"> Hope to see you next
week if you are in Chicago.</font>
<br><font size=2 face="Arial"><br>
<br>
Michael F. Lavelle
Abbott Labs, <br>
Sr. Storage Engineer, CIT
100 Abbott Park Rd, AP14B-1<br>
Phone: 847.937.1195 (Fx:935.9725) Abbott Park IL
60064-6042<br>
<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>David Rock <dave-bu AT graniteweb DOT
com></b></font>
<br><font size=1 face="sans-serif">Sent by: veritas-bu-admin AT
mailman.eng.auburn DOT edu</font>
<p><font size=1 face="sans-serif">05/19/2005 10:00 PM</font>
<br><font size=1 face="sans-serif">Please respond to David Rock</font>
<br>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To:
veritas-bu AT mailman.eng.auburn DOT edu, veritas-bu-admin
AT mailman.eng.auburn DOT edu</font>
<br><font size=1 face="sans-serif"> cc:
</font>
<br><font size=1 face="sans-serif"> Subject:
Re: [Veritas-bu] What are you NOT backing up?</font></table>
<br>
<br>
<br><font size=2 face="Courier New">* Michael F Lavelle <Michael.F.Lavelle
AT abbott DOT com> [2005-05-18 18:28]:<br>
> David,<br>
> Even if your backup policies are set to backup
a certain directory <br>
> tree or filesystem, the goodies' coverage script will not tell you <br>
> anything about frequency of backups or retention.<br>
> More importantly, no 3rd party tool will
inform you about <br>
> dependencies an application has on all data, binaries, configuration <br>
> files, device drivers, etc... That is still something you and your
<br>
> customers have to define and prove thru DR testing.<br>
<br>
Well, duh!<br>
<br>
You will notice I didn't claim anything about frequency or retention, or<br>
dependencies between applications and data. If you _are_ relying on<br>
someone else to tell you how to do your job or how to run your<br>
business, you're crazy. I was simply pointing out that I saw something<br>
that has the potential to fill a gap that is a pain point for us and<br>
thought sharing would be a good thing.<br>
<br>
Storage Console _does_ help you see information about frequency<br>
(indirectly) by making it obvious if something has not been backing up<br>
for a while (displays last successful backup). As for retention, even SC<br>
has a ways to go with policy management reporting. I've posted my own<br>
version of policy reporting that includes vault information. last I<br>
checked, no one else, commercial or otherwise, has attempted to<br>
reconcile the polices to the vault profiles.<br>
<br>
You have to remember we are talking about backup reporting here, and<br>
ways to make that easier. Veritas certainly doesn't give you crap to do<br>
that. Their tech couldn't even get Command Central _installed_, let<br>
alone working after three weeks during our eval process. So you have<br>
three choices; live with the sub-standard reporting in NBU, write your<br>
own stuff and maintain it forever (which I am), or buy something to do it.<br>
<br>
I'm not the only customer that likes Storage Console, either. Seems to<br>
me that I have heard only good things from other people on this list<br>
about it. It's _not_ a magic bullet. If it was, there wouldn't be other<br>
products out there, but it's damn good at what it does. we looked at a<br>
half a dozen products over 6 - 8 months before buying it because it was<br>
the best one out there for us. It might not be the right solution for<br>
you.<br>
<br>
So before labeling me as a shill, try to keep in mind that I'm an<br>
overworked, underpaid NBU admin like the rest of the poor saps on this<br>
list. We all have the same problems with NBU, we've all been there at<br>
crunch time trying to explain why a file wasn't recoverable. backups<br>
suck, plain and simple. No one cares about it until it's too late, and<br>
then it's YOUR head because some moron neglected to mention that new<br>
mountpoint. I have 6 Master servers with 18 media servers backing up<br>
1400 client machines in 3 different geographic locations. Ever try<br>
running 6 Java GUI's at the same time?<br>
<br>
I'm simply stating that a product that *I* recommended my company<br>
purchase, because it will make our awareness of our environment better<br>
so our customers' data is protected, has come out with a new feature<br>
that makes it that much better. I _still_ recommend anyone that needs a<br>
good NBU reporting tool really should take a look at Aptare's product.<br>
<br>
-- <br>
David Rock<br>
david AT graniteweb DOT com<br>
</font>
<br>
<br>
--=_alternative 0013C78486257007_=--
--=_mixed 0013C78386257007_=
Content-Type: application/octet-stream; name="att3657h.dat"
Content-Disposition: attachment; filename="att3657h.dat"
Content-Transfer-Encoding: base64
LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjIuNiAoR05V
L0xpbnV4KQ0KDQppRDhEQlFGQ2pWTE1Nck80L1liL3h3WVJBb0toQUtDem53RFFIdU85TW5NZzRv
TnZvdkg4TUtDRE9nQ2VJTjEyDQprYTB6M296SXA2Znk3dEx4ZVI1UGllUT0NCj11Y0pNDQotLS0t
LUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg==
--=_mixed 0013C78386257007_=--
|