I know this is a little late, but here is what we did. I changed from copying my primary pool from 9840's to 3592. I then let attrition whittle down the 9840 pool until such time as I thought the copy might get done in a reasonable amount of time, then did a copy and deleted the rest of the 9840 pool.
On Thu, 14 Oct 2004, David Moore wrote: > Hello List - > > We're running TSM 5.2.3 on z/OS 1.2. Current 9840 tape breakdown: TAPECOL = about > 400, TAPENON = about 200, TAPEARCHIVE = 22. > > Due to competing resources, I was told to convert TSM to use the 3592 tapes (300GB > capacity) rather than the 9840 tapes (20 GB capacity) that we have exclusively > utilized since TSM was installed at my site. Currently we have only 4 3592 drives, > so my plan was to convert only my COPYPOOL to 3592's at this time; then, follow with > my primary pools when I have more drives at a later date. > > I created the TSM device and the new copy storage pool. Then, I kicked off a backup > of the TAPEARCHIVE storage pool to my new 3592 COPY POOL and quickly found that it > was doing a complete copy to the new pool (of all 22 tapes), rather than just > copying the most recent changes (apparently, TSM 'knows' the new copy pool doesn't > have any of the data yet, so it sends it all). > > This instantly made my life more difficult. These tapes are copying over at a rate > of about 1 per hour. Not really a problem for 22 tapes, but a huge problem for 400 > and for 200. Now that I've described the problem, does anyone have any suggestions? > > Is there a faster way to copy the data from one storage pool to another? > Should I buy more drives and convert my primary pools before the copy pool? Will > this even buy me an advantage or will TSM 'know' that the new primary pool doesn't > have any of the data, so it will send it all from my 185 nodes? > Should I phase in a conversion of my primary pools to the 3592's, copying them to > the new 3592 copy pool? > > Any suggestions would be welcome. > > Thanks, in advance. > > Dave. > > > >
