That is correct: you can lose a couple of storage pool volumes (on a failed
disk) and still go on. The operation in progress writing to those volumes will
stall/fail (I don't know which, but I'm guessing retries probably save your
butt).
Kelly Lipp
CTO
STORServer, Inc.
485-B Elkton Drive
Color
Thank you for the reply; I should have been more precise with the disk failure
question.
Doesn't a disk failure affect the backup run, or are your pools on many
physicals so the loss of one is not fatal to the process?
I understand the data loss part; you have a short window of time for a low
Andy,
In your case, you probably have a good bit of cache in the controller and your
RAID sets are relatively small and you're using FC disks which are more
reliable, tolerant and faster than SATA so all is good. My data comes from the
SATA 7.2K world with six or eight drives per RAID5. Remem
I must be missing something? I cannot saturate my 15 FC 10k disks (3x 4+1
RAID5) with 2GB Ethernet and 110 concurrent clients (330+ sessions). The
Ethernet on the other hand is saturated.
Out of curiosity, what happens with a disk failure?
Andy Huebner
-Original Message-
From: ADSM: Di
It seems the perfect environment for the JBOD I suggested as you do not want
all those sessions banging a RAID5 array.
Of course work flow is an issue, but the moving a TB disk to disk or disk to
tape is a couple of hour process if you work it correctly into your daily
processing and probably i
On Tue, Aug 4, 2009 at 7:41 PM, Kelly Lipp wrote:
> You are exactly correct: modeling what will be rather than what is can be
> tricky. The problem really boils down to not having enough data to really
> play with it adequately.
>
> I can tell you from experience on probably 200 TSM servers (Win
Thanks! You made me a bit more confident and feel more assured about
my plan. And thanks for reminding about DB audit, it's a good
measuring stick indeed!
--
Warm regards,
Michael Green
On Tue, Aug 4, 2009 at 7:35 PM, Huebner,Andy,FORT
WORTH,IT wrote:
> What I did recently was to load a producti
You are exactly correct: modeling what will be rather than what is can be
tricky. The problem really boils down to not having enough data to really play
with it adequately.
I can tell you from experience on probably 200 TSM servers (Windows 2003 based,
which is just fine all of you AIX heads!)
What I did recently was to load a production DB on the test server and run my
series of tests. Then reloaded the DB, changed stuff and run again. It sounds
like you are setup to do that.
For comparison, I noted the run time for expiration on the production and test
systems to estimate an offs
