Which version of Moodle is this?
Make sure your cron is running. "Deleted" files are removed by a background process and - for some file types - it can take sever days.
How, exactly, did you find copies of courses in the file system? Given that (in 2.x anyway) Moodle doesn't store files in courses.
Hi Howard.
We're running Moodle 2.9
Cron is set to 0 * * * * (every hour on the hour).
Locating the files...I just went to the filedir directory in moodledata and sorted by date modified. I then scanned directories for files with hundreds of mb of data--and there they were--they were compressed versions of the courses that I had archived.
But my question is, if I delete these really big files (really big relative to the 80gb that I have at my disposal) will that impact my ability to restore the class from the archived copy that I'm storing elsewhere?
Hope you don't mind me adding 2 'sense' ...
If those backups are over a certain size, it might be questionable to restore them. Folks have been having issues with large course backups. That being said, if one were to setup automated backups and remove all options cept the ones to be able to restore a fresh course, that should reduce the size of the backup and thus greater chance that a restore will be successful.
Have had to 'deal' with this very same issue ... on one server, that had access to some other file storage boxen ... I created a mount point in /moodledata/repository/ ... like 'storedbackups'. Mounted the 'storedbackups' and then set autobackups to run manually. Chose options to basically 'reset' the course on the fly but did tell autobackups to save to the directory as opposed to the normal spreadout all over creation in filedir. Then ran from the command line (/moodlecode/admin/cli/) the autobackup.php script.
If a teacher desired to restore one of those, I'd go into teacher course and set up a file system repo pointed to that mount point. I would have to re-mount the mount point for them to see it.
So to answer your question, yes, if one thinks traditionally, then that does impact a teachers ability to restore a course from a backup. It doesn't, however, restrict you the true server administrator ... the OS server administrator ... not the Moodle UI Administrator.
'spirit of sharing', Ken
Thanks, Ken. Useful.
I don't have a zillion courses to backup, but knowing how to store them to the directory is helpful.
But I still don't have the answer to my question. If I download these courses to a storage facility for archiving, and then delete the backup from the directory, will that impact my ability to restore the course?
I've seen the issues that people are having with large files--mine are only 1/2gb. But my issue is this. With only 80gb to work with every time I'm archiving 1/2 gb that is impacting my ability to update moodle. I have got to get a handle on the amount of space that moodle is taking up on my server. The way that I see to do that is (a) do spring cleaning and (b) move moodledata to a mass storage facility. But to do the spring cleaning I need to know if there will be an adverse result to the cleaning.
The only thing I can say is yes, it might slow you down. But what choice do you have given 80G space limitation? I'd be foolish to promise you no adverse affects on a system un-known. As far as 'updating' ... one is NOT updating contents of moodledata, only the moodle code - if I understand you correctly. Additional space is not such that one should be concerned unless one is running 99% usage of that 80G!
Mount points come in handy. Can mount/un-mount them when needed. Those are network file systems ... don't actually exist on server but are available to file type activity.
Think you'll find one cannot run moodledata totally on an NFS ... found it best on one system/setup to use NFS for the filedir but not for such things as moodledata/temp or moodledata/sessions which need as FAST an access I can provide ... given setup.
'spirit of sharing', Ken
This is very useful, because I've been looking at some kind of NFS setup.
I don't remove my old moodle install until I've put in the upgrade. Last time I ended up going over my total ram and creating a real mess (that's why I now have 80gb--it was smaller before). I'm just concerned that I'll keep eating away at my available space and next upgrade I'll be in the soup again. If I get a handle on distributing moodledata now it won't be an issue later.
So, if I split up filedir from other sub-files in moodledata how will I point to that in config.php? My memory says that one gives a single path for where moodledata resides.
Assumes you are using Linux ... if other, investigate ...
on the one system I mentioned it's sorta like this:
/var/www/moodledata is in the config.php file.
/var/www/moodledata directory does exist on Moodle server
However, *in* /var/www/moodledata
filedir *moved* to the NFS server.
In /var/www/moodledata/ there is a mount point for filedir that links to the NFS server's filedir.
To Moodle, filedir looks/acts like a local directory.
Backups ... same kinda thing ...
On the NFS server a directory for course backups is created ... /home/coursebackups/
in /var/www/moodledata/repository there is a mount point that shows as coursebackups to Moodle but is really the /home/coursebackups/ on the NFS boxen.
For automated backups, set the directory to /var/www/moodledata/repository/coursebackups/
and run them manually. Can cron job it then using the
moodlecode/admin/cli/automated_backups.php script.
To restore a course, I use a System Admins category/course that only system admins can see/access and the course has the 'coursebackups' file system repo in it.
One might have to do the same type of setup for /var/www/moodledata/temp/backup depending on the size of courses you work with. That temp/backup directory is used to un-compress restores as well as build backups.
If you can, strongly suggest setting up a 'sandbox system' and tinker with what I've just described.
'spirit of sharing', Ken
cron is supposed to run every minute (there's now no huge advantage in running infrequently).
You might also want to investigate http://moosh-online.com/, in particular the commands for manipulating the file system.
Thanks for the info--what I got was that running cron too frequently would slow down the site.
Useful cmd for manipulating the file system.
And, I still have my original question. If I delete those compressed files will there be an impact on my restoring classes. What is not clear to me is why those files remain in the hfs after I've deleted them from the restore list? Is there some function that they serve other than idiot protection for people who delete the compressed files before downloading them to a mass storage facility?
Hi Steven,
Please excuse my skipping the rest of the replies - I thought it best to try and reply to your original question with a full answer rather than to each part independently.
From what I understand of the thread, you have made a backup of your course (a Moodle backup mbz file), downloaded that, and stored it offsite. You have then deleted the backup from within Moodle, but the file remains within the moodle sitedata directory.
To answer your original question: As long as you have that mbz file stored somewhere else outside of Moodle, and you backed up the course complete with all user content, you can restore the content safely, even once it has been removed from Moodle.
Normally when you remove all references to a file, it is moved to the trash folder. As others have pointed out, the Moodle cron system should remove unused files from the filesystem periodically. This normally happens once per day. It is possible to disable this, but it is unusual for this to be the case.
If a file is still somewhere within the nested filedir directory then that suggests that it is still in-use somewhere. This may be within another course, within a user's private files, or within a user's draft area. If it is in the draft area, then these file records are cleared about 4 days after that were last modified. Then they'll be moved to the trash directory, and removed shortly later.
Unfortunately, there is no easy way within the Moodle User Interface to find where references to a file are. I believe the Moosh tool has some functionality which can tell you; alternatively, you can run a database query along the lines of the following (you may need to change mdl_files to match your database prefix):
SELECT * FROM mdl_files WHERE contenthash = 'YourReallyLongContentHash';
If there are no records returned, then the actual file on the file system should be deleted within a few days. If there are records, then the file is still in use and will not be deleted.
As Howard mentions, we do recommend that you run cron more regularly than once per hour. Typically, we recommend once per minute to ensure timely delivery of all e-mail, reminders, updates, and notifications.
I hope this helps,
Andrew
Perfect! This is exactly what I needed to know. Thank you.