Forum Discussion

Paul_E's avatar
Paul_E
Level 5
13 years ago
Solved

Journal Items not expiring

I've just been checking some old Journal Partitions which had been set to expire items after 1 year, however I can see thousands of items that are still present and have passed the year mark by a few months.

Is there a way of checking why these havent expired yet and better yet forcing them to expire as they are swallowing up a lot of disk space.

Thanks

  • HI Paul,

    Certainly your figures are going to be skewed, but you could use EV Reporting to give you an idea of how much space is stored in each, along with the single instance storage reduction.

    See : http://www.symantec.com/docs/DOC5455

    You could aggregate them, but be careful of aggregating too much data together. The way you have it sounds potentially better performance for archiving and also for the backup than having it all on one disk. Depends how many disks and how many partitions we are talking about, and the size you are considering aggregating to. I try to stay to 500GB per disk so restore times stay reasonable.

    moving a partition : http://www.symantec.com/docs/TECH35742

     Absolutely do NOT expire data during backups of the closed partitions (if you can help it). The database will be changing significantly during this period and data will be stripped from the partition, so apart from contention issues, you will not be sure what you have in a restore. Granted this is less important for the ingestion of new data, but still would not be best practice. Expiry does tend to slow down archiving so for journaling you may want to run it at periods of lower journaling rates - i.e outside the hours of 8am-6pm, or if that isnt possible, 10-3 (the busiest period in most single country organisations)

    Regards,

    Jeff

     

     

6 Replies

  • Have you verified your Storage Expiry schedule? 

    Also, do you have any Legal Holds in place from Discovery Accelerator?

  • Do you have sharing turned on? If items are shared with mailbox archiving then the retention is extended until the last of the sharers is expired, and typically a mailbox item will be archived some time after the journal - therefore you end up with items persisting in the journal partitions.

    Also, storage expiry can be quite an intensive process. If you are not performing maintenance on SQL, or you are not giving the storage expiry window enough time to process (or it is in report mode ;)  ) then you will not be expiring everything in time and therefore run a backlog.

    Regards,

    Jeff

     

     

  • Thanks for the replies.

    No Discovery Accelerator so no legal holds.

    I had completely forgotten about Sharing as we'd enabled it after our last upgrade from 2007 to 9.1 where we are now. That would explain it and I guess makes our current way of splitting drives based on Journal and User Archives a bit pointless !

    We'd always done it that way so we'd get a rough idea how large the rolling 1 year Journal was comapred to user Archiving.

    I guess I could now go about creating a much larger drive to house everything and move the partitions one by one to the new drive and put them all in together ?

    In regard to the Storage Expiry Schedule what is best practise for the window ? Are we trying to avoid it running during backups ?

    Thanks for the help

    Paul

  • HI Paul,

    Certainly your figures are going to be skewed, but you could use EV Reporting to give you an idea of how much space is stored in each, along with the single instance storage reduction.

    See : http://www.symantec.com/docs/DOC5455

    You could aggregate them, but be careful of aggregating too much data together. The way you have it sounds potentially better performance for archiving and also for the backup than having it all on one disk. Depends how many disks and how many partitions we are talking about, and the size you are considering aggregating to. I try to stay to 500GB per disk so restore times stay reasonable.

    moving a partition : http://www.symantec.com/docs/TECH35742

     Absolutely do NOT expire data during backups of the closed partitions (if you can help it). The database will be changing significantly during this period and data will be stripped from the partition, so apart from contention issues, you will not be sure what you have in a restore. Granted this is less important for the ingestion of new data, but still would not be best practice. Expiry does tend to slow down archiving so for journaling you may want to run it at periods of lower journaling rates - i.e outside the hours of 8am-6pm, or if that isnt possible, 10-3 (the busiest period in most single country organisations)

    Regards,

    Jeff

     

     

  • Thank you very much Jeff.

    We have about 8 old Journal drives at the moment which are empty give or take 30-100mb so I think I'll consolidate all of those first.

    I followed Tech 35742 tonight for the 1st "empty" drive and all went ok and looks fine now but I got this warning which I chose to ignore, I assume I did the right thing !

    I've also double checked our Storage Expiry to make sure it doesnt clash with backups.

  • EV8+ adds an administrative share to each partition location, when you move it that share will be removed
    as long as you have updated the Partitions path in the database correctly, when the storage service starts up next, it will automatically create the hidden share