Rebuilt data from TSM to CMOD

[Neosta]

Hi,

I have a situation where I am retrieving document from CMOD client and its throwing error "server failed to retrieve document".

The CMOD application group is set to 60 cache and then TSM migration for data. Indices are present in cache only. So I can see the object (like 123FAA) present in the TSM, but while trying to access document I am facing this issue.

I tried to do arsadmin retrieve which again throw error "Unable to retrieve the object>123FAA<"

Tried with restore command in TSM, but throw error "ANR2000E Unknown command - RESTORE"

Is there a way I can restore the link between the indices and object or to restore the TSM data back to cache?

[Justin Derrick]

If I understand you correctly, and you are missing index data for documents in TSM, you have a VERY big problem that you need to resolve *before* trying to get documents back.  Pulling the compressed document objects won't save you.  Also, you can't restore through TSM, because they weren't backed up (as CMv8/CMEE does), they were archived, which is a different feature.

Can you give us more information on your configuration / version numbers (OS/DB/CMOD/TSM)?  What happened that is causing you to want to pull the documents from TSM back to Cache? 

Check the troubleshooting guide in the Wiki to get more information on the failures, and share that with us (and anonymize any information like server names / IP addresses / User names / passwords).  https://cmod.wiki/index.php?title=Troubleshooting_Content_Manager_OnDemand

-JD.

[Neosta]

Hi JD,

I do have the index data for the document and object is also present in TSM, it just while retrieving from cmod admin client or arsadmin retrieve its failing.

Please find environment details below:

OS : AIX 7.1
CMOD :  v8.5
DB : Oracle
TSM : 5.5

The issue is, Data from one of application group was migrated long back. We re-ran migration and expiration.
After completing expiration, we are not able to fetch the document. It is throwing error "server failed to retrieve document".

I checked the object and its present in TSM. I also have physical location of NAS drive where actual migrated BFS file is present. Also, we do read that library server maintains mapping between indices and its respective object. It maintains link with cache initially and when data is migrated to TSM, then it changes to primary node location.

So, is there a way we can built the mapping between metadata index and actual object (stored in TSM)?

[Justin Derrick]

When you went through the steps in the Wiki, what did you find?

-JD.

[Neosta]

I do find different details regarding CMOD components and process, but nothing specific to the given issue.

[Justin Derrick]

Just to be clear...  I didn't suggest the Troubleshooting page because it had the solution to your problem.  I recommended it because if you follow the process, it will lead you to more information about the problem.

The goal was for you to share this new information about the problem, so we could help you. 

-JD.

[Neosta]

Hi JD,

I tried to get more details about issue from wiki as well as from google, but didn't fine any explanation or help regarding my problem.
I could only confirm the archived file in TSM. The partition, that has file, is fine and got file archived with any error.

But unable to access this file.

[Michel de Kraker]

Hi Neosta

I still think your solution is arsadmin retrieve ( I sometimes have this issue also , and I am able to solve it with arsadmin retrieve) and then play around with the parameters:

-m location

Determines the location(s) of the storage objects that are processed by the storage manager. Possible locations are cache storage, the primary storage node, and the secondary storage node. The default value is 7, which specifies that the storage manager should process the storage objects for all of the locations that are specified in the application group. Specify 1 for cache storage, 2 for the primary storage node, or 4 for the secondary storage node. The values are additive; that is, if you specify a value of 3, then the storage manager processes the storage objects in cache storage and the primary storage node.

-n prinid-secnid

The primary and secondary storage node identifiers for the application group. Separate the identifiers with the - (dash) character.
Content Manager OnDemand stores the primary and secondary storage node identifiers in the database when you load data into an application group. Content Manager OnDemand includes the identifiers in the Load ID.
The values specified with the -n and -g parameters enable the ARSADMIN program to store data on or retrieve data from a specific Content Manager OnDemand object server.

This is the command I use:

Retrieve original file from CMOD

# arsadmin retrieve -d /tmp/test -g CS001 -h HOSTNAME -m2 -n 3-0 -p password -u a166999 782888FAA

[Justin Derrick]

Hi Michael.

Without knowing why CMOD fails on retrieve (my guess is that there's an issue in TSM that hasn't been found/resolved) it's not likely that the arsadmin retrieve command will work.

In the original post, it says:

I tried to do arsadmin retrieve which again throw error "Unable to retrieve the object>123FAA<"

Until they look at TSM and post the error messages for us to see, there's not a lot more we can do to help.

-JD.

[Michel de Kraker]

I agree Justin, but this issue I have sometimes in my QA envinmoments with AFP resources. They are not in the cache anymore but still in TSM , and I get them back in the Cache with arsadmin retrieve.

So I think it is worth a try.

I agree, I am also curious about the TSM logging.

Regards

Michel