I'd check the size of the database and confirm you use the Simple recovery model for backups or you verify you truncate the logs frequently.

Then look at the folder \web\Portals\_default\logs and check if there's any substantially big files in there.

And also use a utility that can tell you where the space is being used. A very simple one can be found her http://steffengerlach.de/freeware/

You definitely need to investigate this to determine the root cause.  As mentioned earlier, this is most commonly the result of your log files getting loaded with errors/messages.  That's not normal though.  It's usually the cause of a poorly implemented or built extension or hacking attempts.  

Whenever I need to investigate file system growth issues, I use WinDirStat, it's free.  :)  

thanks for the comments, all is helpful. In the end I abandoned trying to restart the DNN instance, nothing worked and every additional volume space on the VM was absorbed. So never found out why, but run away logs seem to feel right and the VM set up seemed to have a different folder structure. So who knows.

The next step was to move to Azure, and having never completed a DNN install before in my life (see this community for previous requests), it just happened as it should. I admit to being impressed.   If anyone knows about email sever connect I have another query open - ever the optimist!

thanks all

Postscript:

the problem was an extension that carried on producing backups every minute even when the portal was damaged. 

Very simple.

Posted By KenT on 23 Aug 2019 09:20 AM

Postscript:

the problem was an extension that carried on producing backups every minute even when the portal was damaged. 

Very simple.

Thanks for following up with the solution.  How did you manage to find the culprit this time?