SSAM and arsload

[Michel de Kraker]

Hi all,

Question about CMOD in combination with SSAM (System Storage Archive Manager)

At the moment we are not using SSAM but the regular TSM server.

When i store a document with arsload it can happen that part of the store fails.
Because we use the parameter -f with arsload it will unload the data from db2 , but will it also delete the already stored documents in the regular TSM storage pool? And when we use SSAM (will install this in a few weeks time) what is the behaviour with failed loads?

thx , Michel.

[Justin Derrick]

The behavior is the same if you were relying on Write-Once optical disks.  If segments of the data are written out to disk, then the load fails, you've just wasted that space for the duration of the retention period configured in SSAM.

Hopefully most of your failures occur during indexing, which means there would be no loss of storage.

-JD.

[Michel de Kraker]

Thx JD.

In our current TSM setup (non-SSAM) we use a regular disk storage pool. Does the rules which you are referring to also apply for these kind of storage pools?

Michel.

[Michel de Kraker]

JD ,

regarding your answer of jan 25th.

So , SSAM and TSM act no different when using arsload -f ?

What is the main advantage of having SSAM? I know you cannot delete archived documents before their retention period.
Are there other differences?

The reason i ask is because at the moment we are using TSM but it should be SSAM (we have a DR550 environment).
My customer and myself are trying to found out if it is worth the time and money to move to SSAM.

Thx. Michel.

[Justin Derrick]

Well, to start with, TSM and SSAM are really the exact same thing.  The only difference is licensing and a configuration switch.

When 'ArchiveRetentionProtection' is enabled on the TSM server (ie, TSM becomes SSAM), you cannot delete archived documents before their expiration period from within TSM.  SSAM on the DR550 goes a little further by preventing you from deleting files at the operating system level as well -- but you can get identical functionality by combining TSM (with Archive Retention Protection on) and a write-once technology like SnapLock or Centera.

So, the same situation applies as before -- if arsload begins providing files to TSM/SSAM, and half way through, the load fails for some reason, that space is lost until the documents naturally expire.  For problematic Application Groups, I recommend storing in Cache for 1 day before migrating to your DR550/WORM storage.  You're exposed for that 24 hours (from a data security perspective) so you need to weigh the benefits and risks and come to a compromise your management can live with.

-JD.

[Michel de Kraker]

Thx JD,

Can you be more specific on "SSAM on the DR550 goes a little further by preventing you from deleting files at the operating system level as well" .

regards, Michel.