Reclaiming space on EVault/Centerra

 I agree with Joe.

Centera is a very different beast compaired to normal CIFS storage. If in basic mode then EV does all the management.

Normally deleting when a user does a shortcut delete is a bad idea and even if you did turn this option on the chances are that the data would not be deleted anyway at the moment the user deletes

Here is why


Centera turns the file or email into a BLOB (Binary Large Object) this is then stored within a C-Clip (C-Clip is a container for storing BLOB's)
there can be many BLOB's in a C-Clip. If you delete an item on EV and the policy is set to delete from storage what happens is the item is marked for deletion on the Centera

BUT

Seeing as Centera deletes C-Clips and not BLOB's the ite will remain on the Centera inside the C-Clip until all the items in that C-Clip are marked for deletion. Then and only then is the C-Clip deleted and the BLOBS that make up the contents of the C-Clip

This is all managed through your EV retention policies so if you set your Policy to Keep Forever then even if the user policy is set to delete, the item will not be deleted as long as the retention policy assigned to that vault is set to keep Forever.

if however you set it to 1 year and i only archived the item today then the item will not be marked for deletion for another 12 months because the retention policy wont allow the item to be deleted

Hi Joe - We currently are running centerra with no retention policy (can't remember the "mode" name - basically, we're keeping everything forever) as we are waiting for legal to define the data retention policies.

Thanks for the warning on HR/Legal issues - we're journaling everything as it is for discovery purposes.

Good explanation Liam - thanks!  We're currently set to forever (as I mentioned in Joe's reply).  I expect our policy to be 3 years once legal gets done gnashing their teeth over it but that remains to be seen.

I don't think we'll be doing any config changes on this - but I wasn't sure how to answer my boss.  Thanks again for your help, gents!

Happy to help
We were in the same boat as you waiting on legal to make a decision we are now set to a 6 year retention and we keep our retention set to keep forever until our yearly cleanup when we calculate our retention to the date we want to retain from then run a cleanup once a year to coincide with our documentation retention cleanup policy

Sometimes our cleanup takes so many items that we need to do it in phases. Our first cleanup took me 2 weeks to complete and we did one year at a time to bring us to a 6 year retention so each  day we changed our policy to one year less than before until we hit our goal of 6 years. we deleted 18 million items over that two week period


BTW if you have the solution to your question please mark the post as solved

Hey Liam,

How exactly are you going about your cleanup procedure?

The thoughts of the powers that be are that we should switch over to deleting the actual archived item whenever a stub is deleted from Exchange - for the purposes of saving space.  Since we journal everything, we'd still have it for legal discovery purposes.

So, if we were to turn on the policy so that deletions happen automatically, that would fix all future deletions.  What would we have to do about all the already "orphaned" objects that are out there (archived items whose related stub has been deleted from people's mailboxes)?

Thanks in advance for any more guidance.

Regards,
Chris

I assume you are sporing both mailbox archiving and journaling in the same pool on centera.

Given this only one copy of the items should be stored because centera does SIS.

That being the case then the mailbox archiving is not storing anything on Centera as the items are already there because of Journaling.

The way for you to allow the users to (seem) to delete from their mailbox is you set the mailbox archiving rule to delete the shortcut from the mailbox but not delete the item from storage.

On the Journal side you set the policy to store the items forever.

When a user deletes from their mailbox it is the shortcut that is deleted and the original item remains behind to be stored by the journal.

The cleanup in our case is that we have a 6 year retention. Our Journaling is set to keep forever. Once a year we do a retention cleanup where we pick a date, calculate the number of days back we want to keep (if we were to run expiry today and we wanted to keep everything from Jan1 2003 we set the policy to 2107 days), Set the retention category from keep forever to the number of days we calculated then we run expiry.

Please remember that expiry is run from the moment you click GO.
If you kick of expiry at noon today then the items 2107 days at noon or earlier will be deleted anything dated after noon will remain so if you want to expire all items before midnight you need to initiate expiry a few seconds before midnight

so you're saying that anything that is stored in the journal vault store is not actually archived due to SIS - I didn't think that is how ours is configured... if that is the case then really only our journal should grow as the archive stores should be pretty much only containing stuff that was in the exchange environment prior to Evault being deployed...

Sorry if I sound obtuse - you should hear what my wife calls me!

Chris

No what I'm saying is that anything that is stored by your mailbox archiving is not actually archived as the data already exists because of the journal except for items archived by the mailbox archiving task older than the date you started journaling the users mailboxes

Yes your Journal is what contributes mostly to the growth on the centera. The databases will grow and look like items are being added but in fact they are really pointing to items already stored by the journal. If you compare the Savesets between the journal and the mailbox databases the majority would probably match.