Automatic backup fills up disk on daily basis.

Automatic backup fills up disk on daily basis.

by dejan grahek -
Number of replies: 3

Hello, 

first lets discuss the environment: Centos 7 OS with virtualmin. On this OS 2 virtual hosts for moodle. Both moodle instances were migrated from an external hosting to the schools server

I was in charge of that it went pretty well for most part. With migration i did upgrades from 2.3 version to the latest. Everything is working 99% of data was retained so we are all happy.


Now for the scenario: both moodle installs are version 3.5.2 now the first (smaller one) works like a charm no problems whatsoever.


The second installation (bigger one) worked the same for like a month but now there is some weird behavior with automatic backups.

All of sudden the disk was full one day and website was down. I found out moodledata/temp/backups was full of folders. Read the forums as much as i found and then i deleted those folders, truncated backup_controller, backup_courses and backup_logs, before i did that i obviously disabled automatic backups and scheduled task. I left the cron job running. First time i deleted those unfinished backups it was ok for 2 days, now it happens daily at variable times of day so i never know when to expect it.


Checking those folders there is almost all the time the same course or section of course that seems to fail, tried to go to course and do manual backup and it worked. Because i am not that experienced with moodle i am turning to this forum for any additional help or pointers on what to try to fix this.


Regards,



Average of ratings: -
In reply to dejan grahek

Re: Automatic backup fills up disk on daily basis.

by Mark Sharp -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers

Yeah the backups can take an awful lot of space. They're basically zips of all your course content. You may be able to mitigate the amount of space by reducing the number of backups for each course, and not backing up courses that haven't been updated.

We fiddled a lot with these, but it never got to a level our ops guys were particularly happy with. In the end, for us, ops do a daily snapshot of the server, and we rely on trash mechanism in Moodle to recover short-term deletions.


In reply to dejan grahek

Re: Automatic backup fills up disk on daily basis.

by dejan grahek -
Hello,


haven`t had time to post further, but if it happens to anyone else it might help. I discovered yesterday that it was not really backups that caused the problems well how could they they were disabled. The problem lied with gradebook. As i stated i previous post moodle was migrated and upgraded in the process, from a 2.3 version to latest. And one of the teachers wanted to delete an activity which had grading set up, and something went wrong. In gradebook settings there was a deletion in progress that did not happen. And this caused that buildup in the temp/backup folder.


What i tried was running cron job (found suggestions on other forum posts with similar issues) but cron job completed successfully and nothing changed. Tried basically everything i could think of but sadly it did not work. 


What stopped those folder buildup and breaking the server with full disk was to truncate mdl_tasks_adhoc and the we created a new course where we moved files from the old one and then delete the whole course altogether. This is basically like reseting the course but with that error resetting is not really and option anymore.


Regards

In reply to dejan grahek

Re: Automatic backup fills up disk on daily basis.

by Mark Sharp -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers

oh the mdl_tasks_adhoc table can be a real pain. If issues aren't spotted, it can fill up really quickly. There should be an alert for overfull tasks table.

Edit: Just found this plugin that might be useful: https://moodle.org/plugins/tool_adhoc It's not been updated for a while, but I don't see why it wouldn't work to monitor the adhoc table.