Show Posts
1
MP Server / Ondemand - data restoration after removing app gr
« on: June 25, 2019, 01:54:42 AM »
Hi,
I have quite an interesting topic concerning data recovery due to the accidental removal of the application group.
As you are aware, removing an application group is not a common thing that admin does, but still it possible to remove application group quite easily after confirmation.
After that, all links to objects are removed from CMOD DB, and what's even worse, all objects are removed in a fly from cache/TSM in a fly. OnDemand sends delete filespace command to TSM. It removes the data on the primary and eventually the copy pools and there is no retention policies in effect at all at that point. The delete filespace command in TSM is under the understanding that you don't want the data anymore, so it is gone out of the TSM database.
It is still on the copy pool because the reuse delay on the data is a few days, but the only way to get it back it restoring the TSM database.
Restoring the TSM database to get a small piece of data back is not a good solution to this. I feel we shouldn't be restoring TSM databases for data retrieval unless it is a disaster recovery situation because it is a major undertaking to do it to another server.
I'm wondering why it is done like that. Why data is not marked for be removed after next run of arsmaint instead of removing all of it in a fly. I have a feeling that having it pushed through the general expiration policy would be a much more secure approach, letting you revoke the bad decision, but maybe there is something I'm not aware of.
What do you think about that? Have you ever deal with such issue before? Do you have any experience how to secure such scenario?
I'd appreciate getting some feedbacks on how is that solved on your end. I see no good approach here. I started a talk with IBM to understand what options we have and got a reply that it would require enhancement to the product. I'm not sure if this is in scope.
What is your point of view? Any comments highly appreciated
I have quite an interesting topic concerning data recovery due to the accidental removal of the application group.
As you are aware, removing an application group is not a common thing that admin does, but still it possible to remove application group quite easily after confirmation.
After that, all links to objects are removed from CMOD DB, and what's even worse, all objects are removed in a fly from cache/TSM in a fly. OnDemand sends delete filespace command to TSM. It removes the data on the primary and eventually the copy pools and there is no retention policies in effect at all at that point. The delete filespace command in TSM is under the understanding that you don't want the data anymore, so it is gone out of the TSM database.
It is still on the copy pool because the reuse delay on the data is a few days, but the only way to get it back it restoring the TSM database.
Restoring the TSM database to get a small piece of data back is not a good solution to this. I feel we shouldn't be restoring TSM databases for data retrieval unless it is a disaster recovery situation because it is a major undertaking to do it to another server.
I'm wondering why it is done like that. Why data is not marked for be removed after next run of arsmaint instead of removing all of it in a fly. I have a feeling that having it pushed through the general expiration policy would be a much more secure approach, letting you revoke the bad decision, but maybe there is something I'm not aware of.
What do you think about that? Have you ever deal with such issue before? Do you have any experience how to secure such scenario?
I'd appreciate getting some feedbacks on how is that solved on your end. I see no good approach here. I started a talk with IBM to understand what options we have and got a reply that it would require enhancement to the product. I'm not sure if this is in scope.
What is your point of view? Any comments highly appreciated