HSM best practices?

[scotteiktsm]

I am doing preliminary testing of TSM HSM for Windows. I haven't found any technotes on best practices. But in testing, I am finding that you must create an offsite copypool of your storage class containing migrated files. Otherwise, anyr DR restore may only be a stub file if the original version has expired.

Is this the case or is there a recommended policy that will maintain the original for DR purposes. -versions exist = 2 -retain version = no limit ???

If the copypool is recommended, it will create a duplication (4 versions actually) of the original file until expiration leaves only the stubbed backup.

Does anyone have a good technote or redpaper/redpiece on the best practices and gotchas of using HSM?

Thanks

 

[PJ]

I don't know about any best practice for HSM Win - however I would strongly advice to hold copies of the migrated data for DR purposes. The only way around that (setting verexist and verdel to at least 2 and retainextra to unlimited) will yield more data and provide less recoverability because you could not restore an entire fileserver from the DR without providing its entire capacity as diskspace.

PJ

 

[tmcquaig]

You will find no documentation currently.


That said. You have outlined the best solution. Duplicate the migrated data (which is in an archive object) to an offsite copypool. You are doing this because eventually you will only have a stub in your primary tapepool for the backup object. Unless you have retain extra = no limit and ver data exist 2 or more.

Your DR will be fun as you will need to use your offsite copypool to rebuild your hsm archive pool.

I am using a seperate nodename (node_hsm) and policy domain for my HSM client so that I can have the migrated data go into a hsm specific (read: cheap disk) diskpool for archive. I have my baclient nodes archives go into a tapepool.


To solve the problem of possible data loss for people who do not create an offsite copy of their archive object in their hsm domain. I have been asking for TSM to add a feature that will allow 2 active files, if and only if one of them is a stub. They also need to have HSM use the space management object rather than archive object. However my main concern is the 2 active with 1 stub feature so that I am not duplicating my HSM data until it expires from my ba data. Which for me is 35 days. My library is small enough already