Video Screencast Help

Clarification on Centera Deletion process

Created: 08 Jul 2013 • Updated: 09 Jul 2013 | 6 comments
Bruce Crankshaw2's picture
This issue has been solved. See solution.

Hi All

This post is similar to the one I posted a while ago but I just need more specific information around the way Centera deletes items. This query is for the same customer in the link below

In summary the customer wants to free up more data on there Centera through deletions, the Centera is running in Basic mode. The question I have is

  • This customer has 2 separate VS for Journal data and Mailbox archiving and 2 separate EV servers. But they have 2 different Retention Categories for these types of archive data. A particarly attachment is archived to the Centera first through Mailbox archiving, with a 3 year Retention Period, and later the same attachement is archived through Journaling with a 7 year Retention Period. I now delete the Archive manually through the VAC. I understand the Index data and references to the item in the Mailbox  VS should be removed but what happens to the item on the Centera as there is now conflicting Retention Periods? The Centera will use its own form of SIS to store one copy of the item but how does it know that there are 2 separate Retention Periods associated with the item? Or will it remove the item but this means that the Journal copy would be removed before its Retention Period. In the past we have deleted hundreds of older unused  user Archives and there were no errors logged. Only later I thought about what this meant, was EV now deleting data that was also associated with the Journal VS?

I hope this makes sense, in summary how does the Centera through its own process of SIS deal with items that have different Retention Periods when you delete them? Or rather what does EV do when you try to delete an item that is stored once on the Centera but has multiple references to it through different VS

Discussion Filed Under:

Comments 6 CommentsJump to latest comment

Advisor's picture

OK let me try.. Considering Centera in Basic mode, there are no Centera retention classes. But we do have Centera sharing enabled. I will consider that Centera collection is disabled as you have not mentioned it here.

We will take an example where we have archived same email in Mailbox and Journal vaults.

When the email was archived using mailbox archiving, it stamps 3 years retention on it. Next when Journaling archives same email, Centera sharing will consider its sharebale part and will just refer the original content address of the blob which was created using the mailbox archiving.

Now upto this part, we would have 2 clips on centera. One which was created by mailbox archiving and other by journal archiving.

The First clip which was created will contain, 1 CDF file and 1 blob (which is shareble). CDF will have the tags for saveset and its attributes such as retention category ID (i.e. 3 Years) used and ofcourse the content address for the blob where the actual data stored.

The Second clip which was created by Journal archiving, will contain only 1 CDF file. Why? Because there is no need to create a blob due to shareble part. Hence CDF will have content address of blob created in first clip. Important: This CDF file will contain tags for saveset and attibutes along with retention stamped on saveset, in our case its 7 Years.

Now when you delete the mailbox archive, the deletion will remove the reference from EV SQL Databases and when it will check for saveset deletion, it will delete the reference from CDF of first clip. So now the blob's reference has been deleted from CDF but other CDF from second clip still have reference to this blob which was shared. Hence the blob will remain on centera and will have reference in second clip's CDF file along with retention of 7 years stamp.

So to answer to your question is, centera will not delete the blob unless all the CDF references are removed.

I hope this helps..

Bruce Crankshaw2's picture

Hi Advisor

This has been an extremely informative response and makes sense, you know your EV stuff :)

So the Content Descriptor File (CDF) keeps track of the Retention Category for the same item. This customer is using Collections but this shouldn't change the way the Centera deletes items as this just means that multiple savesets are combined into a single Clip so the principle of the CDF file would still apply?

Advisor's picture

Thanks for your compliments :)

Yes thats correct the principle is same.

In case of Centera collections, when emails are archived, the storagearchive will dump savesets to staging location and then collection will write them to centera. What is the use of this? Multiple savesets are stored in one single clip. So when collection write savesets to the clip, it checks the retention of the savesets and writes same retention files to that clip. If there are 10 emails in the stagging area whose retention is 7 years, then all of them will be written to single clip. What if retention is different of all those 10 files? Collection will have to create 10 different clips.

This principle is needed because when in future, customer buys the compliance/governance model license and maps the retention category of EV to retention class of centera, the storage deletion becomes simple.

I hope I was clear and did not confuse you with the collection and sharing combination.

Bruce Crankshaw2's picture

No you answered my question nicely.

The customer was basically asking me why they aren't seeing the storage recovery they expect  on the Centera despite the fact they are deleting mailbox archives. But as you explained the blob won't get removed as there are still references to it. This is the correct and expected behavior in my opinion

Its similar to EV OSIS where even though you are deleting data through Storage Expiry an item won't be necessarily removed from the VS partition  as there may be reference to it from another VS.

Once again thanks for the feedback :)

Advisor's picture

Cheers!! I am glad that your queries are solved.

EV_Ajay's picture

Hi Advisor,

Thanks for clarification. It's very useful.