[lobbing armor piercing verbage]

 Oh ye of narrow vision and holder of golden horseshoe of hardware luck:

1.  Have you ever lost a stg pool disk?  And before you answer "well ya
just backup again"
2. SOME DATA IS IMPOSSIBLE TO BACKUP AGAIN!
3. I REPEAT!

Along with regular clients, I backup data from Sybase and Oracle via
SQLBACKTRACK.  Some of this data is an incremental.  In this case
incremental FROM WITHIN the db server.  IE point-in-time data of pages
that have changed.  Should that data be lost, there is no way to restore
beyond what was lost unless another FULL or complete backup has been
created, but it then could be the case that the full is too late a
point-in-time.

Yup, I already been down that road, and there isn't any good sights to
see.  Since then, I use raid-5 storage pools with floating hot spares
whereever I can.   I know I'm still open to hardware failure issues, but
the likelyhood of taking a hit is greatly reduced.  Performance hit?  Our
performance measurement guy saw almost not difference in throughput with
raid-5 versus non raid-5 in the TSM environment.  Basically says to me
that the ever famed bottleneck isn't visiting dasd land right now.  Also
keep in mind that NO storage layout/method/etc can protect against
corrupted data being written.

--
Al




"Stapleton, Mark" <stapleto AT BERBEE DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
02/07/03 08:51 AM
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: PMR 02528, 082


>>From Steven Schraer:
>>It looks like for storage pools are recommend for raid 0
>>(mirroring), raid
>>0+1 (mirroring & stripping) or raid 5 (distributed parity).
>>These are 0+safe
>>methods to protect the storage pool.  Do you know of any
>>companies that use just raid 1 (stripping) on their storage
>>pools?  Is there an issue of tsm loosing a storage pool and
>>the database having issues due to the lost storage pool data?

From: William Rosette [mailto:Bill_Rosette AT PAPAJOHNS DOT COM]
> Does any TSM gurus have any suggestions for our AIX admin

[donning my advocacy armor]
I still don't see any reason to create redundancy for the disk storage
pool. Unless you're not using a tape library, there's no reason for it.
The disk pool should get flushed to a more stable medium, and that flush
should take place fairly soon after the client backups to disk finish.
Why waste gobs of disk on something that's going to flushed clear every
day?

As far the db and log are concerned, just create volume copies with TSM
and make sure the copies are on disks that are on separate disks.

That's really all there is to it.

--
Mark Stapleton (stapleton AT berbee DOT com)