Been dealing with such issues recently ... end of year ... courses are VERY large ... automatted backups are failing ... what to do to keep it up and running till students are finished ... kinda thing.
Turn automated backups to **manual** (assumes version 2 that has this option).
This means those won't run via cron job unless a server admin runs the moodle/admin/cli/automated_backups.php script from command line.
The failed backups, IF they in-deed complete, are in moodledata/temp/backup/ by long folder/directory names (like ef87skfhjasd;4939034asd). Inspection of those directories will give clues - so noted below:
* the moodle_backup.xml file does contain the name of the course and the course ID. Top 20 lines or so.
So now one could go inspect the course itself via Moodle UI to see things like assignments, links to files, etc.. Check to see if there are archived backups in the course. Remove those backups OR find a way to extract them an archive before removing. This might reduce the size of the backup.
* does the temp directory contain a .mbz file? If so, it failed to *copy* (which is how Moodle moves the backup from the temp area to the area for archiving backups ... by default, that's into the moodle file system ... spread out over moodledata/filedir/. Those files are *probably* good backups and can be moved from the directory in which it resides to some other location on a drive that has space enough to hold them. Once those are moved out, one can safely remove the entire [longnameddirectory].
* if the temp directory does NOT contain an .mbz file one doesn't know where it stopped. More than likely, even if one attempted to manually create a MBZ (which you could do via command line), it might not work when attempting to restore.
Things that affect backups ... php settings for max memory allowed for scripts, php settings for max time a script can run. Those need to be increased ... whatever they are. Those are found in php.ini. Making changes there, require restart of apache services for the changes to take affect.
Here's what I've had to do about disk space - dependent upon platform, etc. - am talking Linux here but Wonder would be similar.
Originally, the moodledata folder on the web server was really a mount point to an NFS box. The entity had already determined that made Moodle extrememly slow. So they cheated on the setup. moodledata existed on web server (*not* a mount point) and they then then created mount points for certain directories to be NFS - filedir and trashdir the main ones. The other directories were true directories on the web server.
Now what causes the 'crash' ... the version of Moodle and the PHP version running makes a difference ... the servers which i help maintain that have the issue are 2.6.highest (they won't let me upgrade them until after this school year ends) and running PHP 5.3.highest with APC opcache.
On all systems I have installed a 'crash' app that when such events occurs, it does a core dump to a directory with all the related info. Investigate of that does indicate a PHP issue - which can only be resolved by upgrading PHP - something they don't want me to do until the close of school. :\
The OS/PHP versions issues are indeed issues outside of Moodle. One thing that helps the command line backups of those large courses - which do complete - is to inspect those courses. Now I know some courses, due to their nature, will always be large ... but teachers might see their way through helping out here ... example: Digital Photography class. Files will be large ... period. But, teacher in this instance, had several assignments requiring the students to upload 6 photos of 3 types (that's 18 photos per student per assignment). Photos right off a digital camera are large ... students won't/don't do any thing to make them 'web ready', just raw. So one students uploads (18 files) might total near 600-900 Megs - depending.
Ok that's my problem not yours, but some of your courses might also be doing something similar.
One more item ... if your version is 2.8 there is a CLI backup.php script in moodlecode/admin/cli/ which allows one to backup individual courses. I use this to troubleshoot those troublesome courses.
Script takes two parameters ... the first is the course ID and the second is the destination. Command for me looks like:
backup.php --courseid=340 --destination=/mnt/bigdrive/backup/
Where /mnt/bigdrive/ is a mount point to a NFS boxen that has 1TB free space into a backup folder there.
The course ID numbers acquired from inspecting failed backups moodle_backup.xml file.
I can, eventually, be successful using cli backup of those courses for now.
I have successfully used the backup.php script from a M2.8 in a M2.7 and as low as a M2.6. Simply put a copy of the backup.php script from a M2.8 into admin/cli/ location of a M2.7 and a M2.6.
Your situation/success might vary.
One other thing I have discovered ... or appears to help ... make sure the cron job is run (*several times*) before attempting to work with such troubled backups. The cron job does PHP garbage collection and removes trash files, etc..
'spirit of sharing', Ken
