space management writes another copy to tape (in addition to backup?)

[afrankel]

Hello,

We are running both backups and space management on our GPFS filesystem. The space management is GPFS policy drive, which means essentially that we use selective dsmmiggrate commands to migrate files to TSM. However, all the files that we select for migration have previously been backed up.

From the abnormal growth of our tape usage with respect to the amount of backups we do, I have a feeling that the migrated copies are being written to tape yet again.

Here is our setup :

tsm: TSM1>q mgmt SHARE-PD ACTIVE ROBOT-MC f=d

Policy Domain Name: SHARE-PD
Policy Set Name: ACTIVE
Mgmt Class Name: ROBOT-MC
Default Mgmt Class ?: No
Description:
Space Management Technique: Automatic
Auto-Migrate on Non-Use: 0
Migration Requires Backup?: Yes
Migration Destination: NROBOT_DISK
Last Update by (administrator): IBM
Last Update Date/Time: 09/21/2012 17:31:33
Managing profile:
Changes Pending: No

tsm: TSM1>q stg NROBOT_DISK f=d
Storage Pool Name: NROBOT_DISK
Storage Pool Type: Primary
Device Class Name: NROBOT_FILE-DISK
Estimated Capacity: 149,998 G
Space Trigger Util: 97.2
Pct Util: 3.3
Pct Migr: 3.3
Pct Logical: 100.0
High Mig Pct: 90
Low Mig Pct: 70
Migration Delay: 2
Migration Continue: No
Migration Processes: 2
Reclamation Processes: 3
Next Storage Pool: ROBOT_TAPE
Reclaim Storage Pool:
Maximum Size Threshold: No Limit
Access: Read/Write
Description:
Overflow Location:
Cache Migrated Files?:
Collocate?: No
Reclamation Threshold: 60
Offsite Reclamation Limit:
Maximum Scratch Volumes Allowed: 1,000
Number of Scratch Volumes Used: 34
Delay Period for Volume Reuse: 0 Day(s)
Migration in Progress?: No
Amount Migrated (MB): 509,221.46
Elapsed Migration Time (seconds): 2,693
Reclamation in Progress?: No
Last Update by (administrator): AFRANKEL
Last Update Date/Time: 02/25/2014 08:34:33
Storage Pool Data Format: Native
Copy Storage Pool(s):
Active Data Pool(s):
Continue Copy on Error?: Yes
CRC Data: No
Reclamation Type: Threshold
Overwrite Data when Deleted:
Deduplicate Data?: No
Processes For Identifying Duplicates:
Duplicate Data Not Stored:
Auto-copy Mode: Client
Contains Data Deduplicated by Client?: No

tsm: TSM1>q stg ROBOT_TAPE f=d

Storage Pool Name: ROBOT_TAPE
Storage Pool Type: Primary
Device Class Name: LTO5
Estimated Capacity: 910,148 G
Space Trigger Util:
Pct Util: 85.5
Pct Migr: 93.7
Pct Logical: 100.0
High Mig Pct: 90
Low Mig Pct: 70
Migration Delay: 0
Migration Continue: Yes
Migration Processes: 2
Reclamation Processes: 1
Next Storage Pool:
Reclaim Storage Pool:
Maximum Size Threshold: No Limit
Access: Read/Write
Description:
Overflow Location:
Cache Migrated Files?:
Collocate?: No
Reclamation Threshold: 100
Offsite Reclamation Limit:
Maximum Scratch Volumes Allowed: 600
Number of Scratch Volumes Used: 562
Delay Period for Volume Reuse: 0 Day(s)
Migration in Progress?: No
Amount Migrated (MB): 0.00
Elapsed Migration Time (seconds): 0
Reclamation in Progress?: No
Last Update by (administrator): AFRANKEL
Last Update Date/Time: 02/25/2014 11:34:33
Storage Pool Data Format: Native
Copy Storage Pool(s):
Active Data Pool(s):
Continue Copy on Error?: Yes
CRC Data: No
Reclamation Type: Threshold
Overwrite Data when Deleted:
Deduplicate Data?: No
Processes For Identifying Duplicates:
Duplicate Data Not Stored:
Auto-copy Mode: Client
Contains Data Deduplicated by Client?: No

Thanks,

Andras

 

[marcinek]

Does TSM mount volumes from NROBOT_DISK/TAPE pools during backup? TSM is supposed to do it if files were migrated before backup. It means it's smart enough not to recall files for backup. It is simply copying between "migdestination" pool and "backup" pool.
If the situation I described, happens in your case, it looks like TSM ignores "migration requires backup" setting which in my opinion deserves a PMR.

 

[afrankel]

I opened up a PMR with IBM, and they finally shed some ligh on this. Data written to backup and two HSM is really two completely different processus altogether with Tivoli. So TSM "restore" from a copy of a file, and "recalls" from another copy of the same files.

IMHO, the MigDestination of the management class and the Copy Destination of the copy group command should be two different storage groups, so these two copies are not mixed up within the same storage group. That was my mistake.

The "Migration Requires Backup", parameter of the Maqnagement CLass is important, it should be set to Yes, and it is being honoured.

Andras