Background:
We added a new NAS storage array to CommVault, and marked the old ones mount points ‘Disabled for Write’. Time has passed and data has aged off, but the only thing left on the old storage (seen via right click on the storage mount path in the CV Java UI, choosing “View Contents”) is a handful of Index related data (with names of “<storage_policy>_IndexServer”, and from iDataAgent “Big Data Apps”) that has data retention dates “Retain Until” from last year back to 2019 ... but it will not age off.
I asked support about it while cleaning up some other CommVault data on these old filers and they indicated that if we upgraded to the “latest greatest” (we’re on 11.24.56), then these index files are treated differently in a later version and will all clean up after the upgrade.
Poking around in the forums, I find there’s an “Index Server Load” report in the web UI with a “Run load balance” feature (Load Balance Index Servers: Precautions, impact to running | Community (commvault.com)…and the report indicates in my environment “You can run load balance to distribute 2 index databases and save 847 MB”
A few questions:
- Does anyone know the version/hotfix I would need to update to that would likely be “the version where the index files are treated differently”? I know I could just update to the latest, I was just wondering if I had to.
- Is it possible the “Run load balance” feature in the “Index Server Load” report might move some of these indexes to the new storage, then they will age off?
- Is there a way to track down what’s keeping the each of the indexes from ageing off? previously we had a lot of data not ageing off because (for example) subclients were turned off and there were incrementals left behind, but for those we could track down the subclient and investigate/decommision completely/etc. and it aged off.
