- Not enough space pointing to temp folder backup full#
- Not enough space pointing to temp folder backup free#
So then the drilling down to the folder again that was filling up. In addition to that, considering the size of my backups for that NDMP Client I was then recommended to run the workflow “Enable Subclient Index” that basically converts the indexing from a backupset level to the subclient level making it the browse/restore requests to only (if necessary) rebuild indexing for the particular subclient.ĭuring that process for the workflow it also requires the rebuild a certain number of cycles which then led me to fill up the disk once again and never completed the workflow. The folder for that particular index agent had to be (pause MA services first) deleted and restarting the services on the MA was necessarity as well. So the ability to browse and even some other backup jobs for that MA were failing. So with the index disk out of space and Browse/Restore never completed or failed. So causing the media agent to fill up the entire index cache disk.
Not enough space pointing to temp folder backup free#
Basically whena Browse/Restore is kicked off (in my case on a NDMP) since my client has a huge index, the browse/restore has to reconstruct the index for that client which was well over 1.4TB (1.4TB being the free space on my index cache) not enough. The actual problem is a lot deeper than that and I actually think it should be reviewed by Dev. This could be why the index restores are kicking off - as the index on the MA is possibly damaged.
I had a quick look at your commcell health / index report and see three possibly broken indexes for NAS clients - not sure if its the same clients you are looking at but you should be able to access the report here. Typically index databases are built at the backupset level, but with NAS that can grow too big.
There was a proposed change (I think it happened already) where the index was going to be subclient based for NAS to make it more granular, and allow it to load balance better across index space on multiple MAs (which became a problem for HyperScale since one large NAS client could exhaust the space on 1 node in the grid). The initial implementation always kept the index for jobs still in retention - I do not believe that changed, but I have been out of the game for a bit so it is possible. It should not be doing index restores unless it is damaged.
Not enough space pointing to temp folder backup full#
V2 should be keeping the full index on disk for the entire dataset. So looking for suggestions, experiences with the same issue and whatever is helpful. Tried load balance workflow which was not helpful. Used the key mentioned and restarted the services and still nothing. So I closed that browse operation yet the Index Restore kept going. So I currently have a media agent that its all of space for a Browse that was initiated days ago and didnt even actually let me browse due to the operation of restoring the index. When I look at the three size, I can see the client GUID which just gives us a little bit more info as to which client / confirm the client that cause the problem. So, I then, I cancel my browse request, but it is too late now, the background tasks will continue to a point where it fill up the disk. (always with NDMP (V2) that are massive). The index kicks in, and thats when the operation starts to fill up the disk.
Long story short, any time I request a browse from a job that is available on disk but is fairly old, the media agent kicks off a Index Restore, since those indexes are not on media agent anymore.
In this case, particular case, i have done both and still wont release the space. This is not the first time this happens to me and every time it is an issue since it fills up the disk and it wont release the space until (at least) I either reboot the media agent or add a advsetting key ( CLEANUP_TEMP_DB_DAYS = 0).
0 kommentar(er)
