03-15-2012 01:12 AM
HI,
We have 4 journaling servers in our enviroment. We have a partition rollover.
However when it goes to the next partition it doesn't clear the old partition after a while. resulting in us having to keep expending our storage.
does anyone know why the "out of date" partitions are not cleared?
Solved! Go to Solution.
04-23-2012 11:06 PM
Issue has been resolved. box for delete on expiry was unmarked.
03-15-2012 02:17 AM
03-15-2012 03:11 AM
we have setup our environment so that items in the journal server partition get deleted after 182 days.
But for some reason this proces stopped
03-15-2012 03:17 AM
Are you getting any errors/warnings in the event log in regards deletion?
03-15-2012 04:46 AM
Rob has an issue with Storage Expiry.
This is specifically on their journal-archives. Those have a retention of 182 days. It used to work, but they seem to have problems now with expiry on those. Investigations are on the way. They are on 8sp2 afaik.
03-15-2012 05:21 AM
That's exactly the situation
03-15-2012 05:22 AM
03-15-2012 05:35 AM
We are not using collections. Do you think that's going to save space. I always thought collections are to reduce the back up windows
03-15-2012 05:58 AM
Hi Rob,
Do not use collections on the Journal Partitions.
FYI JW
They do use collections on mail-archiving, but that has retention set to 'keep forever'. Those cabfiles are migrated to SAN. Mail and Journal VSG's are seperated, so do not share FP databases.
There is only retention on Journal archives. That data has to be kept for 182 days. From experience, expiry has been running well for that for years... Been there, done that. Literally.
Rob, you might want to explain further what excactly the issue is.
03-15-2012 06:30 AM
Can you share what version you are currently? Also, on which version did you notice it not working as it used to?
03-15-2012 06:44 AM
EV8SP2
04-20-2012 10:21 AM
SO if I understand you correctly... you have sharing between your Journal and mailbox vault stores and the mailbox are using collections and retaining the items for ever.
If this is the case, in theory ... all original items would be archived by the journal and the mailbox archiving would share the original item. The original item would be stored in teh Journal Vault store (VS) and the Mailbox archiving would generate SIS parts that shared the originals.
AND... if this is the case the journal items that are shared (most if not all of them) would be retained for ever while the mailbox items sharing the original items were being retained.
In other words... you would not ever reduce in size as long as you maintained your shared mailbox parts.
I may have missed something here... but that is what I got from your description.
EDITED:
Ok I did miss something. you are not sharing between your vault stores. I can tell you there was a slew of fixes between EV 8 SP2 and EV 8 SP5. IMHO EV8SP5 is the only EV 8 I would feel pretty comfortable on. Is updating you to the latest SP out of the question? I know in EV 9 there were expiry issues resolved... Specifically in your version two issues come to mind. One is if you had items on legal hold it would kill expiry threads and the second was related to collections and archive attrbutes ... but the details elude me for the moment. I know both were fixed in later SPs. I would suggest going to the latest SP and seeing if you still have an issue. If it is a dying thread thing... those can be VERY challenging to identify ... and it may result in you getting told to update your SP anyhow.
04-23-2012 01:46 AM
I'll look into that
04-23-2012 05:18 AM
There could be any number of things going on here over and above the requirement for potential fixes, so foremost a couple of things to check:
1. Is storageexpiry at the Site level set to be in Report mode?
2.What is your schedule window - is it perhaps to small?
3. Are the individual archives perhaps set to be excluded from expiry?
4.Are you only using one retention category for your journals, does it allow items to be deleted from it, how long is it for sure (182 days???)
Without a dtrace of storagedelete (which you can obtain as well by running expiry manually) it would be difficult to confirm whether you are being affected by one of the other fixes that may have been addressed in later releases, however its always a good idea to move up to get them all and see whether your issue is still around.
What does the StorageExpiry report logged to the Event log indicate after a run?
04-23-2012 11:06 PM
Issue has been resolved. box for delete on expiry was unmarked.