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:[EMAIL PROTECTED]] Sent: Friday, February 07, 2003 11:41 AM To: [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 02/07/03 08:51 AM Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] 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:[EMAIL PROTECTED]] > 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 ([EMAIL PROTECTED])