Set Retention to 1 day but never run Storage Expiry

[aschnarrs]

Hello all. 

I have an EV 9.05 environment currently only using the mailbox archiving feature.  Backend storage is good old fashion NTFS partition (sas disk). About 75TB+ of archive data.  And the retention is set to retain items forever.  Users do have access to delete from the vault.  Users utilize vault cache/virtual vault.

We recently introduced a hitachi HCP worm device.  Shortly after users started to notice that they can no longer delete items from the vault.  if they delete an item from Vault cache the next time the Vault cache syncs the item reappears.  if they delete it from archive explorer they get a "The deletion of the item is not currently permitted".

Reference - https://www-secure.symantec.com/connect/forums/ev-905-deletion-item-not-currently-permitted

We found out the problem is the HCP device does not allow a user to delete items from the vault if the item has a current retention on it. (from hitachi support)

We need to allow users to delete from the vault as it was working prior to the Hitachi HCP worm device installation.  it has been suggested (from hitachi support) to change the EV retention from the current setting of "forever" to 1 day.  Hitachi would then pickup the retention change and any items that have expired the user would be then free to delete the item from virtual vault or archive explorer.

Question is as follows...

Knowing we want to keep items forever if we set the retention from "forever" to "1" day and never run storage expiry, what are the ramifications of this change from a performance perspective on EV and SQL, DA, EV indexes, etc.  I am trying to think of gotchas, etc.  I realize the data would not be deleted until storage expiry runs, but having almost 100% of the EV data marked as expired does that have any drawbacks from any other processes?

Thanks in advance.

[TonySterling]

Setting the retention to 1 day won't affect other processes but you better be sure your backups are working just in case.  You might consider setting it to 2 or 3 days to give yourself a chance to get everything backed up.

Just curious, if you are allowing deletes why go with a WORM storage device designed to enforce retentions?  Seems a bit strange. :)
 

[AndrewB]

a) i'm wondering the same thing as Tony - sounds like you dont need WORM capabilities

b) are you talking about retention based on modified date (aka sent date) or archived date? what's your mailbox archiving policy set to?

in any case, i'd be terrified of having all my data with such a short retention. maybe match the retention period to your mailbox archiving settings? for example, if you archive anything older than 60 days, you could set your retention to 60 days.

[TonySterling]

I suppose you could check the option on the Retention Category to Prevent automatic deletion of expired items with this category.  That would mean if Storage Expiry was to run nothing would be deleted.  It would also mean you could never expiry anything without adjusting the retention periods.  Not the greatest of solutions....

[aschnarrs]

Thank you all for the input.  I don't know exact why the HCP device was implemented however I believe it was due to the large amout of time EV backups were taking.  Backing up 50TB+ of EV data (opened and closed partitions) in a single region was taking days.  Backups were so delayed that they were almost unreliable. 

I am not a hitachi expert by any means but I believe the selling point was not having to backup EV partition data once its on the hitachi device was the driving factor and not so much the retention features.  I assume the hitachi device works almost like a centera in that ev backups are not required except the indexes and local OS/application.

The hitachi HCP was already implemented and working as expect except this conflicting retention issue causing users not to be able to delete items.  The purposed fix or recommendation is to set the EV retention to something so low (like 1 day) any item older than 1 day would be allowed to be deleted by users because the forever retention in the hitachi doesn't conflict with the forever retention in EV.

I like Tony's idea about modifying the EV retention catagory so that incase the storage expiry was run by accident items still would not be deleted. and I agree it doesn't seem like a great design solution.

Can either of you think of any negative EV or SQL DB performance issues as a result of implementing a 1 day or 60 day retention but never actually ever deleting anything?

[AndrewB · Accepted solution]

i have plenty of customers who have retention set to expire data but dont actually run expiry or in other words, have their expiry schedule set to never. same goes for retention categories and even archives that have the box checked to not allow items to be expired/deleted automatically. no performance issues directly related to those settings.

[aschnarrs]

Thanks Andrew.  i assumed that was the case.