Question

Remove old Job Results folder

  • 5 January 2023
  • 9 replies
  • 518 views

Userlevel 1
Badge +6

Happy New Year!

 

We have recently offloaded the share job results folder for Office365 clients from one of our two Office365 Proxies to a shared storage in order to free up space on the proxy.

 

All seems to work well since the move. I am now trying to delete the old folders from the proxy. Windows looks like it’s deleting the content but all is still there after the deletion.

I suspect it might be the Commvault ransomware protection that prevents me, even though these content is not anymore configured in Commvault.

 

How can I remove this obsolete content?

 

Thank you,

Zoltan


9 replies

Userlevel 2
Badge +7

Any solution for this? i have same problem where the DM2CacheDir occupied so much space in web server. 

Userlevel 1
Badge +6

@Scott Reynolds , the diagnostics finished after about 2 days (luckily, the proxy server has SSD storage). The server is up and responsive again, browsing of the obsolete shared GeneratedPreview folder “froze” (explorer not responding) after 21’425’037 subfolders:

I believe the current shared JobResults folder (3rd location) contains the same subfolders due to the copy of the data when the settings are changed in Commvault.

 

Any idea why this many folders?

 

I will wait until I can delete the folders from the obsolete shared folder that impacts the normal functioning of Proxy 1.

Userlevel 1
Badge +6

No, we have dedicated

  • Web Servers
  • Media Agents
  • Index Servers

The two proxy servers are the proxies for all Office365-related tasks, nothing more is deployed on them.

Userlevel 6
Badge +14

DM2CacheDir  were these proxies acting as a webserver? Were they being used for other agents like mailbox backups or performing content indexing?

 

Userlevel 1
Badge +6

I ran some tests over the weekend and it looks like the GeneratedPreview folder inside JobResults\DM2CacheDir got corrupted.

The server’s Windows GUI was completely blocked. I tried booting from a Linux Live CD and mount the NTFS volume to correct the issue. Upon listing the contents of the GeneratedPreview folder, the output was that there is no “GeneratedPreview/@”.

 

I then restarted the server and started Windows in diagnostic mode. It’s been trying to repair disk errors for the last 20 hours or so..

Userlevel 1
Badge +6

Yes, backups are running fine since mid-December. There’s no new content in the \\Proxy1\JobResults \JobResults folder since that date.

This is the error I get when I try to rename the folder:

 

There’s 160GB free space available. Something is preventing me to delete or change the folder. There’s no reference in Commvault Configuration regarding these folders. Maybe I am missing something...

Userlevel 6
Badge +14

Understood so now backups are running fine with the new shared location in place?

You should be able to rename Jobresults folder from the old location:

\\Proxy1\JobResults\JobResults

Once renamed can confirm its not being used for anything else assuming a new DIR is not created then you should be able to safely delete it.

If there are still issue after that might be best to open a support case for a deeper review.

Userlevel 1
Badge +6

@Scott Reynolds , No, the shared job results folder. Previously, it was shared from Proxy1 with Proxy2 accessing it through the network using an AD account.

We moved the shared job results to a 3rd location but the original copy isn’t automatically removed by Commvault upon successfully copying the content to its new location. It is taking up a lot of space (that’s why we wanted to offload it from Proxy1.

The local job results are intact on both Proxy1 and Proxy2.

 

Previous setup:

\\Proxy1\JobResults\JobResults

 

Current setup:

\\sharedstorage\JobResults\JobResults

Userlevel 6
Badge +14

@Zoltan You can talking about local job results on the proxy machines? That location is still used when performing backups/restores as a temp export location during the backup.

I believe this might be the data you are referring too.

Reply