So... thru most of this thread, the upshot is to consider: 1. Avoid cache=yes, rather use large disk pool with migdelay=1 *and* avoid offsite reclamation -- maybe defer the offsite reclamation to weekends, after clearing out the disk pools. 2. Use not one, but TWO tape technologies -- 3590 (J or K) or 9940A's for onsite; then LTO or 9940B's for offsite ?!? (I don't see many customers going for that -- two different types of tapes, where most just want to simplify, K.I.S.S. it for the sake of operator procedures!) 3. Larger arrays of ATA-drives, 1 TB for under $10K -- holy cow, we gotta find a way to deal with that... how's about large FILE libraries on disk (with or without SANergy), so disk pools migrate to FILE on disk, recently expanded to allow more than 100 volumes for SANergy support,,, so, exploit it as onsite, primary sequential pool. 4. If we truly want to configure (random) disk pool sufficiently large to hold two days worth of data, for fast restore, then we must avoid reclamation during that period... ah-ha, with this large array of ATA drives configured for FILE (sequential) pool as nextstg, that would seem to relieve the offsite-reclamation *and* the tape contention for primary pools.
All the earlier posts of advice still leaves us with slow DR recovery (due to my server's data spread across many more tapes than would be with collocation -- but wait, the truly mission-critical stuff usually comes in 3 flavors: the dbf's for the data base, the logs to recover up to most recent sweep of redo-logs, and the binaries & config files (the OS flat files); the dbf's are full backups daily, so it's really just tracking down the collocated logs & dbf's, and non-collocated OS backups. What's a person to do? Collocation is not a good answer; I suspect grouping nodes into app-based pools (not critical vs. prod. vs. dev/qa) so the critical data gets spread among enough tapes so that restores of multiple, critical nodes don't experience tape contention (due to non-critical nodes' data separating them out). Don France Technical Architect -- Tivoli Certified Consultant Tivoli Storage Manager, WinNT/2K, AIX/Unix, OS/390 San Jose, Ca (408) 257-3037 mailto:don_france@;att.net Professional Association of Contract Employees (P.A.C.E. -- www.pacepros.com) -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@;VM.MARIST.EDU]On Behalf Of Rushforth, Tim Sent: Thursday, October 31, 2002 8:04 AM To: [EMAIL PROTECTED] Subject: Re: Tape drive recomendations And the issue is still there if you don't use CACHE=YES but don't completely clear your backup pool. We have more disk in our storagepool than is required for one night's incremental - so we thought keeping some backups on disk was a good thing (why migrate to tape if you don't need the space). Tim Rushforth City of Winnipeg -----Original Message----- From: Bill Boyer [mailto:bill.boyer@;VERIZON.NET] Sent: October 31, 2002 9:01 AM To: [EMAIL PROTECTED] Subject: Re: Tape drive recomendations Be careful of your copypool reclamations with the disk cache turned on!! There is a BIG performance hit on reclamation when the primary copy of the file is on a DISK direct access storage pool. Then the MOVESIZETHRESH and MOVEBATCHSIZE values are thrown out the window and the files are processed one at a time. What I've done to relieve the restore times is to not MIGRATE the disk pools until the end of the day. That way restoring from last night is quick. I had a client where they wanted CACHE=YES on a 60GB disk pool. The offsite copypool reclamation ran for 2-days! Changed it so that migration started at 5:00pm and nobody complained about restore times. Bill Boyer DSS, Inc. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@;VM.MARIST.EDU]On Behalf Of Steve Schaub Sent: Thursday, October 31, 2002 5:59 AM To: [EMAIL PROTECTED] Subject: Re: Tape drive recomendations This is one reason I am looking into some of the new, cheaper ATA-based disk arrays. 98% of restores come from the last few versions, so if you can size the diskpool large enough (and turn caching on) that you rarely need to go to tape, restores scream. Some of the initial prices I am seeing are < $10k per TB. It's not SSA, but for a diskpool it might be fast enough. -----Original Message----- From: [EMAIL PROTECTED] Sent: Wednesday, October 30, 2002 10:15 PM To: UFL.EDU.asr; VM.MARIST.EDU;.ADSM-L Subject: Re: Tape drive recomendations 2 => On Wed, 30 Oct 2002 16:42:14 -0600, "Coats, Jack" <[EMAIL PROTECTED]> said: > From my fox hole, LTO works great, but in some ways it is 'to big'. > The spin time on the tapes is measured as about 3 minutes to rewind > and unmount a tape. Meaning if you have to scan down a tape to > restore a file it can be a while. Very fast tapes tend to be small, > so it is a real tradeoff. > Speed of restore is starting to be a factor here and I have seen > several posts where that is becoming more of an issue at many sites. > But the architecture of TSM that makes it great, also gets in the way > of high speed restores, unless you have lots of slots in a large > library for a relatively small number of clients (co-location and/or > backup sets - for theses many smaller tapes might be better, but I > digress). Our call on this is congealing: Use the LTO for less-often-read storage. i.e.: copy pools. If we can have primary pools on 3590s, we can get up to 60G raw on the -K volumes. That seems plenty at the moment. We can use the 200G-raw (coming soon!) LTO volumes for copies, and read from them correspondingly less often. LTO drives are, at the very least, a cheap way to increase your drive count. - Allen S. Rout
