And ya know... this is why I just LOVE TSM !

you can do anything you want...

take one drawer of SSA and set it up as JBOD and put it all as a storage
pool for non-critical backups/archives

take another drawer of SSA and set it up in a raid of your choice for more
critical backups/archives

bleed either or both of those into tape pools that have copy pools or ones
that don't

do things like, with hsm, force a backup to exist prior to migration, make
the backups go to different storage pools than the migrated data,
yadayadayada...

Any level of protection I've ever been asked/required to provide, I've been
able to achieve with ADSM / TSM.

Dwight



-----Original Message-----
From: Allen Barth [mailto:allen.barth AT DB DOT COM]
Sent: Friday, February 07, 2003 11:41 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: PMR 02528, 082


[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)