Could someone please advise what might be causing this issue?
Thanks in advance, Harshavardhan
Best answer by Onno van den Berg
@naraharsha for future cases it would help to add some environmental information like version that you are running and for example contextual information related to the issue. In this case I assume you hit an issue with your cloud storage platform. I've submitted your post to Arlie and it also came back with something that might be related. Please check and if this is not the case than I would recommend to open a ticket.
I personally am interested to learn how you discovered the present issue.
The error in your SIDBPrune.log:
Cannot delete folder [...] error [0xEC02AC0E:{CVBaseRemoteFile::GetLastMMErrorCode(1507)/MM.44046-CVBaseRemoteFile::DeleteFolder - folder not empty - folder ... still has the folder .../CHUNK_META_DATA_221331127.FOLDER}]
indicates that pruning is failing because the folder is not empty—specifically, the CHUNK_META_DATA_221331127.FOLDER subfolder remains, preventing deletion of the parent chunk folder. This is a common issue when using cloud storage with a hierarchical namespace enabled.
Root Cause
Cloud storage with hierarchical namespace enabled (such as Azure Data Lake Storage Gen2) does not allow deletion of a folder if it contains any subfolders or files.
Commvault expects to be able to delete chunk folders after removing their contents, but if any subfolder (like CHUNK_META_DATA_*.FOLDER) remains, the deletion fails.
This leads to a backlog in the MMDeletedAF table, causing the amount of data pending pruning to increase.
Resolution Steps
Check Cloud Storage Configuration
If you are using Azure, ensure that the storage account's hierarchical namespace is disabled. Hierarchical namespace is not recommended for Commvault backup workloads, as it causes issues with folder deletions during pruning.
For Azure, the recommended service host is dfs.core.windows.net only if hierarchical namespace is required, but for Commvault, it's best to use a storage account without hierarchical namespace.
Remediate Existing Storage
If possible, create a new storage account with hierarchical namespace disabled and migrate your data to this new account.
Update your MediaAgent controllers to point to the new storage account.
Short-Term Workaround
As a quick fix, you can change the service host to dfs.core.windows.net on both MediaAgent controllers, but this is not a long-term solution. The best practice is to use a storage account without hierarchical namespace for Commvault workloads.
Monitor Pruning
After making the changes, monitor the SIDBPrune.log and the MMDeletedAF table to ensure that pruning resumes and the backlog starts decreasing.
@naraharsha for future cases it would help to add some environmental information like version that you are running and for example contextual information related to the issue. In this case I assume you hit an issue with your cloud storage platform. I've submitted your post to Arlie and it also came back with something that might be related. Please check and if this is not the case than I would recommend to open a ticket.
I personally am interested to learn how you discovered the present issue.
The error in your SIDBPrune.log:
Cannot delete folder [...] error [0xEC02AC0E:{CVBaseRemoteFile::GetLastMMErrorCode(1507)/MM.44046-CVBaseRemoteFile::DeleteFolder - folder not empty - folder ... still has the folder .../CHUNK_META_DATA_221331127.FOLDER}]
indicates that pruning is failing because the folder is not empty—specifically, the CHUNK_META_DATA_221331127.FOLDER subfolder remains, preventing deletion of the parent chunk folder. This is a common issue when using cloud storage with a hierarchical namespace enabled.
Root Cause
Cloud storage with hierarchical namespace enabled (such as Azure Data Lake Storage Gen2) does not allow deletion of a folder if it contains any subfolders or files.
Commvault expects to be able to delete chunk folders after removing their contents, but if any subfolder (like CHUNK_META_DATA_*.FOLDER) remains, the deletion fails.
This leads to a backlog in the MMDeletedAF table, causing the amount of data pending pruning to increase.
Resolution Steps
Check Cloud Storage Configuration
If you are using Azure, ensure that the storage account's hierarchical namespace is disabled. Hierarchical namespace is not recommended for Commvault backup workloads, as it causes issues with folder deletions during pruning.
For Azure, the recommended service host is dfs.core.windows.net only if hierarchical namespace is required, but for Commvault, it's best to use a storage account without hierarchical namespace.
Remediate Existing Storage
If possible, create a new storage account with hierarchical namespace disabled and migrate your data to this new account.
Update your MediaAgent controllers to point to the new storage account.
Short-Term Workaround
As a quick fix, you can change the service host to dfs.core.windows.net on both MediaAgent controllers, but this is not a long-term solution. The best practice is to use a storage account without hierarchical namespace for Commvault workloads.
Monitor Pruning
After making the changes, monitor the SIDBPrune.log and the MMDeletedAF table to ensure that pruning resumes and the backlog starts decreasing.
I have no idea but I assume you will have to disable the NFS capability on the bucket and start data aging afterwards to see what happens. If you can'’t enable the future on existing bucket then there is only solution, I think, which is creating a new bucket and start a data migration to the new bucket. But I would for sure contact support to see if they have a verified solution for you.
