HSM Windows 5.5 and SKIPMIGRATED

[rore]

Folks,
Planning the HSM migration from 5.4 to 5.5 I read the following:

The integration between the HSM for Windows client and |the backup-archive client ensures |the backup-archive client, independent |from HSM for Windows client, always |maintains a copy of the complete file in the backup pool, whether this file |is migrated or not. In other words, for migrated files there are two identical |versions of the file on the Tivoli Storage Manager server: one is in the |HSM archive, created by the HSM client; and one is the backup copy in the |backup pool, created by the backup archive client.

This is true if you don't configure SKIPMIGRATED parameter or if you set 'no' to it. In the other hand if it is 'yes':

If the option is checked (yes), the backup-archive client does |not process any HSM for Windows client stubs. |Thus, no file is recalled, and the stubs are not backed up

This is a bit non-sense for me. Kinda wasting space having the same data in HSM and backup pools. What I want is to backup all non-migrated files and the stubs of all migrated.

That way you protect all non-migrated by the backup and for all migrated you have the stub protected. If you can recover the stub, you can recover the contents from HSM.

The stub takes a minimal space in the backup pool.

Do you see my point? Any experience to share?

Thanks,

Rudy

 

[rore]

Hello,
I am bringing back this old post because I saw some few members that are TSM Developers posting lately. Also v5.4 is becoming old. Can you guys provide any comment/suggestion? (please see the challenge above)
I didn’t have the time to check what HSM v6 changes are yet. I will do it soon. Any experience that can you share? thanks,

Rudy

 

[michael_s]

Is it really wasted storage capacity when having two identical versions for files on the TSM server, one migrated and one backed up?

The answer is "No"!

Since this question indicates concern about efficient storage utilization on the TSM server I am implying that reconciliation is configured for the HSM file system.
If then for example a user deleted some migrated files (stubs) from the file system by mistake, a subsequent reconciliation run will delete these on the TSM server's archive (Windows HSM) or spacemg (UNIX/Linux HSM) pool.
These files are lost then, unless you have valid backup copies!

This is a bit simplified, on Linux/UNIX HSM it needs two reconcile runs until these files are deleted, but after the first run the files can not be recalled any more without assistance of TSM L2/L3 support. And beginning with HSM for Windows 6.1.3 you can define an event based retention: after the stubs have been deleted in the file system, the TSM server keeps them for a specified number of days depending on the archive copy group setting (RETVER and RETINIT parameters).

There are many other circumstances which can lead to an unintentional deletion of the migrated version when reconciliation is configured.

 

[rore]

Hi,
I am glad that finally I got feedback on this subject. Thanks.

Is it really wasted storage capacity when having two identical versions for files on the TSM server, one migrated and one backed up?

The answer is "No"!

Why "No"!? Arguments please.

Since this question indicates concern about efficient storage utilization on the TSM server I am implying that reconciliation is configured for the HSM file system.

As you know, HSM v5.4 doesn't have reconciliation.

If then for example a user deleted some migrated files (stubs) from the file system by mistake, a subsequent reconciliation run will delete these on the TSM server's archive (Windows HSM) or spacemg (UNIX/Linux HSM) pool.
These files are lost then, unless you have valid backup copies!

Again, since there is no reconciliation in v5.4 if a stub is deleted I can easily restore the stub. The stub is protected by our retention policies. With the stub, the contents of the file can be recalled from HSM pool. Even if the stub backup copy expires we can recall the file from HSM as it was not touched by the deletion of the stub.
If we ever migrated to HSM v5.5 or v6 we will not use reconciliation because the data is supposed to stay for several years, so same scenario.

This is a bit simplified, on Linux/UNIX HSM it needs two reconcile runs until these files are deleted, but after the first run the files can not be recalled any more without assistance of TSM L2/L3 support. And beginning with HSM for Windows 6.1.3 you can define an event based retention: after the stubs have been deleted in the file system, the TSM server keeps them for a specified number of days depending on the archive copy group setting (RETVER and RETINIT parameters).

Nice feature but it doen't provide any value to our environment.

There are many other circumstances which can lead to an unintentional deletion of the migrated version when reconciliation is configured.

No reconciliation -> no worries.

Thanks again for your feedback. From your response I can assume that the possibility to backup just the stubs in new BA/HSM releases is far from being a reality? I think it would not be a major change, just a new option. I may be wrong.

Regards,

Rudy