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.
>
>
>
>
|
