How does the expoiry process work?
Does anyone know where I can find information on how the storage expiry process exactly works?
We have recently enabled expiry on Journal Archives. We expect millions of items to be expired (long story).
We do see the index-locations dropping in size, indicating removal. We do see event 7085 in the eventlog of the Journal Archiving servers. (Number of vaults processed: 1 , Number of vaults enabled for expiry: 1 , Total number of expired items deleted: 6124314)
We do not however see the storage location dropping in size. We think that the storage expiry will only happen after it has processed all indexes. Is that true?
What I am looking for is a technote (or explanation) that when you enable storage expiry, it will first process the complete index, put items in the journaldelete table (or watchfile or whatever), and when the index is processed, it will start deleting items from the storage locations. Or whatever the process in itself is supposed to do.
Reason for the slowness might be (but that is a wild guess) is that items have been journal-archived since 2005, with a retention of 2 years, but we have only actually enabled expiry last month. This means it has to expire items of 6 years worth of journal archiving. We expire based on 'modified date'. Is there also a need to have the expiry schedule setup with 'gaps', or can it be 24*7?
Thanks, as usual.