Why moodledata Fills Up Around Backups, and How to Control It

A Moodle site runs out of disk and the culprit is moodledata: the trash directory, automated backup files, or the recycle bin has grown unchecked. It is tempting to blame “trashdir not emptying,” but on a current Moodle the real causes are usually elsewhere. This guide explains what actually consumes the space and the settings that control each one.

What trashdir actually is

moodledata/trashdir is the trash for Moodle’s file storage pool (filedir), not for backups. When a stored file is dereferenced (no activity points at its content any more), Moodle moves the underlying content file into trashdir. A scheduled task, coretaskfile_trash_cleanup_task, empties it. In Moodle 4.5 that task runs every six hours.

So if trashdir is large, the question is whether that cleanup task is running. Check it under Site administration > Server > Tasks > Scheduled tasks (look for the file trash cleanup task) and review Task logs for failures. If cron itself is not running, this task is not running either, and trashdir grows. Confirm cron is alive:

sudo -u www-data php admin/cli/cron.php

A correctly functioning site empties trashdir on schedule. If yours is not, the problem is cron or that specific task, not a missing setting.

What automated backups do (and the safeguard you may not know about)

A common assumption is that a misconfigured or unreachable backup destination causes files to pile up in moodledata until the disk fills. On Moodle 4.5 the opposite is true: there is an explicit safeguard against exactly that. When the automated backup task cannot use the configured external destination (it is missing, not a directory, or not writable), Moodle logs an error, skips the copy, and deletes the backup file rather than leaving it behind. The code comment states the intent directly: it is there to prevent moodledata from filling up when the destination is misconfigured.

That means a broken destination gives you failed backups and error logs, not a slow disk-fill. If moodledata is genuinely filling from backups, look at the settings that govern retention instead.

The settings that actually control backup disk use

Under Site administration > Courses > Backups > Automated backup setup:

• Automated backup storage (backup_auto_storage) decides where automated backups are kept: in course backup areas (inside moodledata), in a specified external directory, or both. If this is set to keep them inside moodledata, that is where your space is going.
• Maximum number of backups kept (backup_auto_max_kept) caps how many backups are retained per course. If this is high (or effectively unlimited) and you back up frequently, old backups accumulate. Lowering it lets Moodle prune the surplus.
• Delete backups older than (backup_auto_delete_days) prunes by age. Combined with max-kept, these two settings are the real levers for backup disk consumption.

Set these to match your actual retention policy. Most sites do not need to keep every automated backup forever inside moodledata.

The recycle bin: the other quiet consumer

Moodle’s recycle bin (the tool_recyclebin admin tool) retains deleted courses and deleted activities so they can be restored. Those retained items live in moodledata and can be substantial, a deleted course holds its entire backup. Two scheduled tasks (cleanup_course_bin and cleanup_category_bin) purge expired items, governed by the expiry settings:

• tool_recyclebin / coursebinexpiry and categorybinexpiry set how long deleted items are kept before automatic purging.

If these expiry periods are long (or set to never expire) and people delete and re-create courses regularly, the recycle bin can quietly become one of the largest consumers of moodledata. Check its retention settings under Site administration > Plugins > Admin tools > Recycle bin.

Diagnosing where the space has actually gone

Before changing settings, measure. From the moodledata directory:

du -sh trashdir filedir backup
du -sh * | sort -rh | head -20

This tells you whether the space is in trashdir (cleanup task issue), filedir (real content, or dereferenced content awaiting trash), backup areas (retention settings), or elsewhere. Treat the largest directory first rather than assuming it is trashdir.

Clearing trashdir manually, safely

If trashdir has grown and you need space back immediately while you fix the underlying cron/task issue, it can be emptied by hand, because by definition it only holds dereferenced content-pool files:

find moodledata/trashdir -type f -delete

This is what the cleanup task does anyway. Using find rather than rm -rf moodledata/trashdir/* avoids argument-list limits on directories with very many files, and leaves the directory itself in place. It does not touch live files, backups, or the recycle bin. Still, take the usual care: confirm the path, and make sure you are operating on trashdir and not filedir.

The short version

trashdir is emptied by a scheduled task every six hours; if it is full, fix cron, not a setting. A broken backup destination does not fill moodledata on 4.5 (there is a safeguard). The real backup disk levers are the storage location, max-kept, and delete-after-days settings. And do not overlook the recycle bin, which retains deleted courses in moodledata until its expiry settings purge them. Measure with du before acting.