Pardon intrusion ... just spotted something ...
Issue: which php
as root via command line.
That should point to /usr/bin/php
You want to use the php that's command line ... not php-cgi me thinks.
The php-cgi (cgi=common gateway interface) is using web server.
That's why you are seeing 'Content-type: text/html' in the output of the command
you issued. That's calling apache. The idea is to use php which will talk
to the DB only ... leaves apache out of the loop thus consumes less memory and faster.
Overall, there are some dates that are just outta whack ... and from
looking at them, don't think they'll ever complete/do.
In order to re-gain control of the situation, you **might** have to truncate
the tables for backups - leaving the tables and their fields ... just remove all the data contained in them.
The next run of automated command line backups run manually will/should backup all courses that are not hidden. That does take the backup preferences from the GUI config of backups.
I'd also set to designated directory ONLY and not do copies into the new file system.
Tons of courses ... there's a plugin for course sizes that might help see just how large some courses are. When the automated backups kick in, settings do NOT include 'do largest' first or last ... or skip large course over XGig ... you could have some courses failing simply because they are over 4Gig (limitation of OS).
There is another script in same location as auto_backups called 'backup.php'. Running thusly from moodlecode/admin/cli/
php backup.php
with no parameters passed the script will bring up the help on using it.
Think, as a test, I'd pick one of those courses that has been failing, get it's course ID number, then try the backup.php script giving it the course ID and have it save to a designated directory outside of filedir to see if that course will backup.
php backup.php --courseid=[IDNUMOFCourse] --destination=/path/to/directory/outside/of/filedir/
That might give some clues ... if it fails.
'spirit of sharing', Ken