Move all data off of primary storage pool

[smp]

We are running TSM version 8.1.11.0 on rhel 8.4. We have a primary storage pool and a copy storage pool which are both on disk. The underlying storage for our primary storage pool will be out of support soon and I need to move all of the data in the primary storage pool to newly allocated storage and then reclaim all of the underlying storage that will be out of support.

Is this the most efficient method to accomplish this task with minimal impact on existing daily backups?
1. Allocate sufficient new storage for the primary storage pool to accommodate all of the existing data in the pool.
2. Change the device class for the primary storage pool to only include directories for the new storage.
3. Issue the "move data volume_name" command to move data to one of the new directories.
4. Wait until the reuse delay period for the storage pool has expired.
5. Reclaim all of the LUNs for the unsupported storage.

Are these steps correct and/or are there more efficient methods to replace the unsupported storage with new storage? I currently have about 150 TB of storage allocated on 5,000 TSM allocated volumes that would need to be moved to new storage.

 

[marclant]

That's likely the most efficient way.

You could also create a new pool as a nextpool to the current pool, and use migrate storage pool instead, and update the copygroups to point to the new pool. Migrate will not be faster in terms of bytes/seconds, but it will be more efficient in the amount of manual labour saved and you will have more control.

For example, if you only want to move data at certain time of day to not affect other tasks for example, you could have 2 admin schedules, one that sets the himig and lowmig to 0 to start migration, and later in the day have another that changes the himig to 100, and the lowmig to 99 to stop it. So that way, you can only migrate at certain time during the day if that's a concern.

You can also play with the number of migprocess to run simultaneously.

Once setup, you can basically just let it go until it's done. As with the move data command, you will have to issue a bunch of command, not more than X at a time, and then re-issue a bunch more, so it's more work.

 

[Sunhillow]

You could also create a new pool as a nextpool to the current pool, and use migrate storage pool instead

In similar cases I preferred this solution. It is a no-brainer as you don't have to care for each single volume, be it disk or tape.

 

[smp]

That's likely the most efficient way.

You could also create a new pool as a nextpool to the current pool, and use migrate storage pool instead, and update the copygroups to point to the new pool. Migrate will not be faster in terms of bytes/seconds, but it will be more efficient in the amount of manual labour saved and you will have more control.

For example, if you only want to move data at certain time of day to not affect other tasks for example, you could have 2 admin schedules, one that sets the himig and lowmig to 0 to start migration, and later in the day have another that changes the himig to 100, and the lowmig to 99 to stop it. So that way, you can only migrate at certain time during the day if that's a concern.

You can also play with the number of migprocess to run simultaneously.

Once setup, you can basically just let it go until it's done. As with the move data command, you will have to issue a bunch of command, not more than X at a time, and then re-issue a bunch more, so it's more work.

The "nextpool" option was much easier. Thank you so much for your help.