VTL migration to tape/DR copypool

[towster]

We have recently gotten a new VTL for our TSM server. The VTL is pretty much setup but I need to modify daily maintenance for it.
There are several things I would like to accomplish with it.

1. Keep seven days of backups on the VTL (VTLPOOL)
2. Copy all backups to tape (TAPEPOOL)
3. duplicate tapes for offsite (DRCOPYPOOL)

I think I know what I should do but I wanted some confirmation (or criticism) of what I am doing.
Will these steps do what I want?
Is this the best way to do it?
If it is not the best way what is the best way and why is it better?


For #1 I think I need to set this:

update stgpool VTLPOOL migdelay=7

For #2 and #3 I should put the following into the mainenance script:

/* copy everything from VTLPOOL to TAPEPOOL and DRCOPYPOOL */
PARALLEL
backup stgpool VTLPOOL TAPEPOOL wait=yes
backup stgpool VTLPOOL DRCOPYPOOL wait=yes
SERIAL
/* migrate to TAPEPOOL */
migrate stgpool VTLPOOL lo=0 wait=yes
/* ensure everything is in DRCOPYPOOL */
backup stgpool TAPEPOOL DRCOPYPOOL wait=yes

Thanks in advance to all who respond..

[moon-buddy]

Yes - that would be the best way.

[marcel.tubini]

Hello,

You are making a mistake.

Reading your script I understood that TAPEPOOL is a PRIMARY storage pool, and the command "backup stgpool VTLPOOL TAPEPOOL" will not work.

Considering the environment below:

VTLPOOL -> TAPEPOOL (primary storage pools)
DRCOPYPOOL (copy storage pool)

You have to create this script:

backup stgpool VTLPOOL DRCOPYPOOL wait=yes
migrate stgpool VTLPOOL lo=0 wait=yes
backup stgpool TAPEPOOL DRCOPYPOOL wait=yes


You also can improve your environment configuring autocopy during migration process.

Regards,

[towster]

Reading your script I understood that TAPEPOOL is a PRIMARY storage pool, and the command "backup stgpool VTLPOOL TAPEPOOL" will not work.

Good catch. You are correct that both VTLPOOL and TAPEPOOL are primary storage pools. DRCOPYPOOL is a copy pool.

If I understand your script properly what TSM will do is:
copy everything in VTLPOOL to DRCOPYPOOL. (backup stgpool VTLPOOL DRCOPYPOOL)
copy anything older than 7 days in VTLPOOL to TAPEPOOL (migrate stgpool VTLPOOL)
copy everything in TAPEPOOL to DRCOPYPOOL (backup stgpool TAPEPOOL DRCOPYPOOL)

Is there some way to copy everything in VTLPOOL to TAPEPOOL even though it hasnt been in VTLPOOL for 7 days?


I didnt want to do autocopy at this time but plan on doing it soon.

[moon-buddy]

Good catch. You are correct that both VTLPOOL and TAPEPOOL are primary storage pools. DRCOPYPOOL is a copy pool.

If I understand your script properly what TSM will do is:
copy everything in VTLPOOL to DRCOPYPOOL. (backup stgpool VTLPOOL DRCOPYPOOL)
copy anything older than 7 days in VTLPOOL to TAPEPOOL (migrate stgpool VTLPOOL)
copy everything in TAPEPOOL to DRCOPYPOOL (backup stgpool TAPEPOOL DRCOPYPOOL)

Is there some way to copy everything in VTLPOOL to TAPEPOOL even though it hasnt been in VTLPOOL for 7 days?


I didnt want to do autocopy at this time but plan on doing it soon.

Yep, I did not see the 'backup' command.

As for moving the data from the VTLPOOL to the TAPEPOOL bfeore 7 days, you can do a migrate with the cache migrated data parameter turned ON in the VTLPOOL. However, when you want to move the data from the VTLPOOL to the TAPEPOOL, you need to ZERO out or set to a value lower than 7 the migration delay value specified on the the VTLPOOL.

[marcel.tubini]

Yep, I did not see the 'backup' command.

As for moving the data from the VTLPOOL to the TAPEPOOL bfeore 7 days, you can do a migrate with the cache migrated data parameter tunr ON in the VTLPOOL. However, when you want to move the data from the VTLPOOL to the TAPEPOOL, you need to ZERO out or set to a value lower than 7 the migration delay value specified on the the VTLPOOL.

Cache migrated data will work only for Randon Access devices (DEVC=DISK). If VTLPOOL is a Sequential access device (DEVC=FILE OR DEVC=LTO) CACHE parameter aren't available.
The best practice is ALWAYS backup all storage pools in the chain (VTLPOOL and TAPEPOOL). If you backup only VTLPOOL there is a risk that some data will be not duplicated on DRCOPYPOOL.

[moon-buddy]

Cache migrated data will work only for Randon Access devices (DEVC=DISK). If VTLPOOL is a Sequential access device (DEVC=FILE OR DEVC=LTO) CACHE parameter aren't available.
The best practice is ALWAYS backup all storage pools in the chain (VTLPOOL and TAPEPOOL). If you backup only VTLPOOL there is a risk that some data will be not duplicated on DRCOPYPOOL.

Not sure about your point. Migration works on Primary storage pools and the VTLPOOL is a primary pool. Although I have not tested this on my VTL, I am sure migration will work.

TSM documentation does not mention that the Primary pool be a random-access device.

See 'Help migrattion'

Here is an excerpt:

help migrate

3.34 MIGRATE STGPOOL (Migrate storage pool to next storage pool)

Use this command to migrate files from one storage pool to the next storage pool in the storage hierarchy.



This command can only be used with primary storage pools. The storage pool data format cannot be NETAPPDUMP, CELERRADUMP, or NDMPDUMP.

Only one migration or reclamation process for a given storage pool is allowed at any given time. If a migration or reclamation process is already running for the storage pool, you cannot start another migration process for the storage pool.

......

LOwmig

For random-access and sequential-access disk storage pools, specifies that the server stops migration when the amount of data in the pool is at or below this percentage of the pool's estimated capacity. The calculation for sequential-access disk storage pools includes the capacity of all the scratch volumes specified for the pool. For other types of sequential-access storage pools, this parameter specifies that the server stops migration when the ratio of volumes containing data to the total number of volumes in the storage pool is at or below this percentage. The total number of volumes includes the maximum number of scratch volumes. This parameter is optional. You can specify a number from 0 to 99. The default value is the LOWMIG attribute of the storage pool definition.

[marcel.tubini]

Not sure about your point. Migration works on Primary storage pools and the VTLPOOL is a primary pool. Although I have not tested this on my VTL, I am sure migration will work.

TSM documentation does not mention that the Primary pool be a random-access device.

See 'Help migrattion'

Here is an excerpt:

help migrate

3.34 MIGRATE STGPOOL (Migrate storage pool to next storage pool)

Use this command to migrate files from one storage pool to the next storage pool in the storage hierarchy.



This command can only be used with primary storage pools. The storage pool data format cannot be NETAPPDUMP, CELERRADUMP, or NDMPDUMP.

Only one migration or reclamation process for a given storage pool is allowed at any given time. If a migration or reclamation process is already running for the storage pool, you cannot start another migration process for the storage pool.

......

LOwmig

For random-access and sequential-access disk storage pools, specifies that the server stops migration when the amount of data in the pool is at or below this percentage of the pool's estimated capacity. The calculation for sequential-access disk storage pools includes the capacity of all the scratch volumes specified for the pool. For other types of sequential-access storage pools, this parameter specifies that the server stops migration when the ratio of volumes containing data to the total number of volumes in the storage pool is at or below this percentage. The total number of volumes includes the maximum number of scratch volumes. This parameter is optional. You can specify a number from 0 to 99. The default value is the LOWMIG attribute of the storage pool definition.

The point isn't about the migration process, (it work's for every primary storage pool), the point is about usability of "cache" in storage pools. You can enable cache only in Randon Storage Pools (DISK). If the VTL is setup to emulate a library or to use file device class it will not work.

But the main question of towster is about "backup storage pool". The best practice is backup all storage pools in the chain.

[towster]

Sorry I didnt reply right away.

I can confirm that VTLPOOL is type LTO.
I tried changing VTLPOOL to enable cache and tsm said that it was not valid for the device class.

So it sounds like there is no way that I can keep 7 days of data in VTLPOOL while still moving the
data to TAPEPOOL and DRCOPYPOOL prior to the 7 days. Or am I missing something?


Would it be valid to create another copy pool perhaps called ONSITECOPYPOOL and then do something
similar to my original procedure? One problem I see is that I would not be able to backup stgpool from
ONSITECOPYPOOL to DRCOPYPOOL. Is there some other means to make sure the data in both the on
and offsite copies is identical? Another possible problem is that when tapes are sent offsite via move
drmedia it would start ejecting the ONSITECOPYPOOL as well.

[marcel.tubini]

Sorry I didnt reply right away.

I can confirm that VTLPOOL is type LTO.
I tried changing VTLPOOL to enable cache and tsm said that it was not valid for the device class.

So it sounds like there is no way that I can keep 7 days of data in VTLPOOL while still moving the
data to TAPEPOOL and DRCOPYPOOL prior to the 7 days. Or am I missing something?


Would it be valid to create another copy pool perhaps called ONSITECOPYPOOL and then do something
similar to my original procedure? One problem I see is that I would not be able to backup stgpool from
ONSITECOPYPOOL to DRCOPYPOOL. Is there some other means to make sure the data in both the on
and offsite copies is identical? Another possible problem is that when tapes are sent offsite via move
drmedia it would start ejecting the ONSITECOPYPOOL as well.

Towster,

Why don't you use "MIGDELAY=7" on VTLPOOL, and execute "backup stgpool" for VTLPOOL and TAPEPOOL?
There is a requirement to have two copies on tape at the same time? Why can't you have one copy on VTLPOOL for seven days and another copy on DRCOPYPOOL for all files, regardless the retention period?
But, if you want't to create another copy storage pool you can setup copy storage pools managed by DRM using the command "Set DRMCOPYstgpool xxxx". Configuring it correct "move drmedia" will not process your ONSITECOPYPOOL.