Accidental Unload of document

[jsquizz]

Folks,

I removed a loadID from our backup site that should have been our production site. I saved the load ID. Is there any way to get this back. It is quite old (2011).

Please tell me there is a way!

[Alessandro Perucchi]

 
Gosh...

Well, if you are lucky, maybe in TSM the objects are not yet deleted...
If that's the case, then you can retrieve the objects from TSM with the following command:

Let say that you load ID is the following:

Code: [Select]

arsadmin retrieve -h archive -u admin -p password -n <pri_nid>-0 -g applGroup index_Doc_NAME
Let say that you load-ID is   112233-2-0-1234FAA-218921-218921

Then it should be something like:

Code: [Select]

arsadmin retrieve -h archive -u admin -p password -n 2-0 -g applGroup 1234FAA1
Once you got the 1234FAA1, then decompress it:

Code: [Select]

arsadmin decompress -s 1234FAA1 -o 1234FAA1.txt
Once decompressed, you can look inside the file 1234FAA1.txt, and you will see the entries of your segment table in your database. You can use this file, with some "work" to insert the rows in a segment table, or to recreate a new generic index.
Also in this file, you will find the column DOC_NAME, and you need to get all the different DOC_NAME available.
Let say that you find the following list (uniq doc_name):

• 1234FAAA
• 1234FAAB
• 1234FAAB$
• 1234FAAC
• 1234FAAC$

Then remove all the entries with the "$"
So you get the final list:

• 1234FAAA
• 1234FAAB
• 1234FAAC

And then you can retrieve the objects in TSM with the following command:

Code: [Select]

arsadmin retrieve -h archive -u admin -p password -n 2-0 -g applGroup 1234FAAA 1234FAAB 1234FAAC
Now you should have the following files available:

• 1234FAA1
• 1234FAAA
• 1234FAAB
• 1234FAAC

Meaning that you can do many things with them. But at least you saved them, and you have time to rearchive them again in CMOD.

I will post a second entry on how to reinject in CMOD.

But at least you are in a situation, where you can decide in a more calm mood, what to do next...

IF the command "arsadmin retrieve" doesn't give you ANYTHING....

Well, in that case, you must hope that you have a backup of your cache for the objects of the load ID you deleted.
Or that you have somewhere a backup of TSM with the old data which contains your objects.

If you don't have them, and they are not retrievable anymore.... then you are f*cked up... *sorry for the bad word*.... because you might recover the database table for the indexes... but you have lost the documents behind forever...

[Alessandro Perucchi]

Ok, Now you have theses files:

• 1234FAA1
• 1234FAAA
• 1234FAAB
• 1234FAAC

Now you have 2 ways to reinject everything back to CMOD

• Completely manually
• semi automatic

Let's look first at the completely manual process:

You can reinject them directly in TSM with the following command:

Code: [Select]

arsadmin store -h archive -u admin -p password -n 2-0 -g appGroup 1234FAA1 1234FAAA 1234FAAB 1234FAAC

That way, CMOD will store the documents back to the storage manager (cache, TSM, OAM, ...).

BUT you don't have the entries in the database anymore... so for that, you will need to do inserts into the "original" segment, if you can find it again!
let say that your segment was BAS12 for example.
Then you will need from the file 1234FAA1.txt that you got previously, generate a lot of "INSERT INTO BAS12 VALUES (....)"
where the (....) is the values found in the file 1234FAA1.txt starting from the second line in a tab separated format. As you have probably seen, then line 1 is the header of all the indexes, except for the internal indexes from CMOD, like DOC_NAME, DOC_OFF, DOC_LEN, etc...

Once you have created your file with all your INSERT INTO, then you can run it.

BE CAREFUL, because you might need for some values, to add quotes(') in order to be valid... This should be part of your custom script to take care of these "details", if you are not sure, generate one INSERT, and test it, as long as it doesn't work!

And when this is done, you should test that you can see all documents in CMOD client... or arsdoc query....



Now the second method. This method, I have never really used it... so please really careful!! and test it carefully...

The idea is to redo an "ARSLOAD" of the data extracted.

And here is a theoretical way to do it:

• decompress each objects: 1234FAAA, 1234FAAB, 1234FAAC with the previous command "arsadmin decompress"
• With the index file 1234FAAA1.txt, regenerate a generic index using the user fields/values for the entries in GROUP_FIELD_NAME/GROUP_FIELD_VALUE, and from the internal cmod values, you need to do the following: DOC_OFF = GROUP_OFFSET, DOC_LEN = GROUP_LENGTH and DOC_NAME = GROUP_FILENAME (in this one you need to get the decompressed DOC_NAME, for example 1234FAAB.txt)
• When you got the index correctly generated, then you can try to archive the whole with the "arsload -X G ...." You must use the option -X G because it will force the generic indexer.

And it should work.

[Alessandro Perucchi]

Please be aware that what I've provided here, is a very simple recovery...
It doesn't take in account the AFP/PDF resources.
it doesn't take in account the Large Objects.

You cannot recover the modified indexes, in case the indexes where updated after the load.
You cannot recover the annotations...
You cannot recover all additional indexes added after the archiving
You cannot recover all the deleted indexes that were deleted from the archiving, in order to redeleted them again
You cannot recover Holds that were on these documents
... etc...
You can ONLY recover the state AT archive time ONLY.

If you want to recover the exact databases entries, because of many things... then the only way is to restore the segments in another database/schema/name, export the rows that you are interested, and reinject directly these rows from the backup.
And for the objects, then with the arsadmin store method, you are saved, and exactly at the same situation you need to be.

[jsquizz]

It's one file with three hits, line data. 

An error occurred.  Contact your system administrator and/or consult the System Log.  File=arsadmin.c, Line=1450
Unable to retrieve the object >1731FAA<

is what I am getting.

[Alessandro Perucchi]

It's one file with three hits, line data. 

An error occurred.  Contact your system administrator and/or consult the System Log.  File=arsadmin.c, Line=1450
Unable to retrieve the object >1731FAA<

is what I am getting.

Get the name of the DOC_NAME in the database, since you still have your entries in the database, and get your infra team to see if in their backup, they have the content of your cache.
I suppose you have the data (objects) in cache.
Do you use TSM? If yes, then ask the TSM people, if they can restore some files from old backups.
Because, if they cannot do that... then you can just forget it.

What to restore?

1) TSM object.
Let say that your database is called JOHN and the AGID_NAME of your application group is BAS, then the object is located here:

/JOHN/BAS/DOC/1731FAA

If your database is called ARCHIVE (that's the exception): then the file is located here:

/BAS/DOC/1731FAA

If the file has been restored in TSM itself, then perfect, if it has been restored in a filesystem for you, then you can reuse the command arsadmin store that I've provided you in some previous answer in the thread.

2) You don't have TSM, only cache. This is a bit tricky... but it needs to be done in two steps:

a) In your cache directory, you have the directory "retr", then ask the infra people to restore this link from the backups:

<cache_directory>/retr/BAS/DOC/1731FAA

Once this is restored, you can see where the original file was located, for example
<cache_directory>/18928/BAS/DOC1731FAA

b) Ask the infra people to restore the file found in a).


Again, if they tell you that they cannot do that, because XYZ reasons... then you are out of luck...

[jsquizz]

We are using a very old version of TSM along with platters and jukeboxes..does that mean I am out of luck as well?

from the cmod log:

Object >1731FAA1< in Application Group >HKF< not found in node >NODE<  Srvr->HOST 192.168.1.4 non-SSL<-

[Alessandro Perucchi]

We are using a very old version of TSM along with platters and jukeboxes..does that mean I am out of luck as well?

from the cmod log:

Object >1731FAA1< in Application Group >HKF< not found in node >NODE<  Srvr->HOST 192.168.1.4 non-SSL<-

As I said, if you have backups of your TSM data, or TSM database, then you might retrieve your data, but still... check with your TSM specialist... whoever it is...
If you don't have such TSM Backup, or TSM backup of data... you might have trouble...

[Justin Derrick]

The data is still on the platter.  You need a standalone system with an optical drive and the same version of TSM, plus a TSM database backup from before the deletion.

You're probably better off trying to find the load from the other system and reload it though.  Don't forget to close the current AG table with arstblsp before loading an old document though.

-JD.

[jsquizz]

Thanks JD, that's what I thought. The data on the platter but the platter is unaccessible. Need to work with my TSM colleague to figure this out.

[Justin Derrick]

Take an outage, back up TSM, restore an old TSM database backup, do the retrieve, then restore the latest database backup.  If the system isn't big, it won't take long.