Migration of diskpool simultaneously to primary tape and copypool?

[Sunhillow]

Hi
I wonder if it is possible to write simultaneously to primary tape pool ans copy tape pool when migrating the disk pool with TSM 5.5.4. The only thing I can find is simultaneous write to primary and copy pool during backup, but not during migration.

 

[chad_small]

It is not supported for internal moves.

From the Admin Guide:

Notes:
Simultaneous write is not supported for data movements performed by the server, such as server migration, reclamation, moving data from one storage pool to another storage pool, or backing up a storage pool.

 

[Sunhillow]

Thanks Chad.
So would it make sense to run migration and backup from disk to copy pool simultaneously? Disk pools are on SAN

 

[sjl]

Thanks Chad.
So would it make sense to run migration and backup from disk to copy pool simultaneously? Disk pools are on SAN

No, you don't want to do that.

I have seen issues where the backup stgpool is trying to process a file at the same time as migration. If the backup stgpool finishes it first - all good. If not, (assuming that caching is turned off on the disk storage pool; there are issues that mean that I tend to keep it off unless there's a really good reason to turn it on) the backup stgpool can't finish, has to backtrack, and start a different file (rewinding the file, if I remember rightly.)

At least, that's my opinion, based upon extremely slow progress of the backup stgpool while the migration chugs along quite happily. I could be wrong; there isn't quite enough information in TSM to determine which files are being duplicated/migrated by a given process.

I prefer to let the backup stgpool run, then start migration once it's finished. There's also the question of performance; I'd rather have one process doing a sequential read and write, then another doing the same, than have two processes contending for the same source data/disks.

Simultaneous migration and copy pool duplication was introduced in 6.2 (look at the AUTOCOPY parameter, set on the storage pool), but you're running 5.5.4, which makes that a moot point. A useful feature - and long overdue - but I'm still of the opinion that you're better off sticking with 5.5, unless you have a compelling reason to upgrade (large database, log regularly filling, deduplication) - too many maintenance releases and patches pulled, although it's getting significantly better.

 

[chad_small]

Never migrate while backing up to a copy pool. Backing up the data from disk then migrating the disk is the recommended process. If you are having problems with timing then you would be better served simultaneously writing any data that backs up to tape directly to the copy pool. Then there will be little if any data needing to be copied from tape during daily maintenance. My current company is doing backups to Data Domain disk subsystems that we replicate to our alternate data center. So I'm lucky in that I don't have to handle daily processing of offsite.

 

[Ruthira]

Hi, TSM Administrator always recomm the migration should go to Tape and we have a option to take a backup diskstg & tapestg to copystg at same time.

(Keep in mind the tape is greatet than disk - this is the use of migration)

 

[Sunhillow]

sjl & Chad, thanks for your opinions!

I also gave up the idea of running migration and backup stg from the same diskpool simultaneously, there is no time gained.