General help

For the first issue, I think you are going to need to have a look at PHP and web server logs. It appears to be stopping after only 5 seconds? The other thing to try is temporarily enabling debugging when you run the backup and see if any additional information/debugging comes up.

For the second issue: you have probably already done this but it is worth a mention. Go to Site Admin > Notifications and make sure you don't see a message that "cron is not running normally" or something to that effect. If you do see such a message then your main Moodle cron is not running at all or is not running at intervals that Moodle requires. 

If Moodle cron is running normally, and you are capturing the output of your Moodle cron, then take a look at this cron output. You should be able to search through that output for a string like "backup". This can help you realize whether the automated backup is getting executed or if there were errors along the way causing it to fail completely. 

Jamie

It might be this problem:

https://docs.moodle.org/27/en/Backup_and_restore_FAQ#I_have_a_very_large_course.2C_over_2GB.2C_and_the_backup_process_stops.

We've also had problems with backing up large courses (manually) and the moodle server or our internet network timing out, so you may want to check that too.

Causes for this behavior could be multiple ...

Things to check:   PHP settings for max times for script to run, memory a script can consume, and extra memory to use (backups will use extra memory already ... hit's hard coded into the backup scripts).   All those can or should be seen in the Site Admin - Server - PHPInfo screen.

From what you've described (and pic of progress) it could be that the course backup has reached a size (physical size - not processing 'size' (there's a difference) OR the combination of both - physical as well as processing (as evidenced by your description of breaking apart the backup into 4).

When a backup gets to the very end the very last process in the whole routine is to copy the backup that uses moodledata/temp/backup/[longdirectoryofnumbersandletters]/ as a build area to the destination to archive.   The destination could be (more than likely is the first): file area [which is moodledata/filedir/ in the new file system somehere) or a designated directory (which system admin has to create manually).    In either case, the routine uses  a 'copy' command to accomplish.

If running a RedHat family based OS, there is a known limitation in the operating system with *copy* command being used for files 4G* ... am assuming, of course, your server is a true server x86x64 (64bit).

If this is the case, upgrading Moodle, BTW, will not fix.

So ... use whatever you have to inspect/browse files and look into:

moodledata/temp/backup/[thatlongletternumberdir]/ that was being used to build the backup.

Is there a backup.mbz file present?   If there is, then it's  a *copy* issue.

Also look at moodledata/temp/backup/ for a .log file (which is ascii/txt) that has the same filename as the backup directory being used to build a backup.   That log file has some info in it ... providing stages of the plan to back the course up ... they are provided as numbers.    A successful backup will reach a 1000 and completes.   A failed backup might have a reference to the last successful stage - less than 1000.   What is that reference? (might give us a clue).

Inspection of the course ... one of the heaviest processing (therefore 'large') modules is quiz.   How many quizzes (test/assessments) are there in the course?

If the course will not backup manually via GUI, then it will certainly fail when part of autobackups.

There is something to try that gets beyond limitations/issues ... in admin/cli/ of the code there are command line scripts that one could run from ssh session.   Two of interest ... backup.php - which takes preferences for backups from the Moodle Admin UI.   It is for a single course.

And there is automated_backups.php - obvious what it does.

The backup.php script takes your Apache web server restrictions/config limitations out of the loop in a backup.  Takes two parmeters ... course ID to backup and destination.

I have a 2.8 sandbox and a script in it's admin/cli/ that does this:

php backup.php --courseid=$1 --destination=/var/www/unifsrepo/m28/

The $1 is a variable and I can pass to my script the course ID to backup.   In your case, provide the command the course ID of your troubled course.    I suggest using the destination option whose directories will not be created by the script so you'll have to create them.

That keeps the backup out of moodledata/filedir/ ... can find it ... can see it ... can inspect it's contents from the command line.

I'll stop at this point cause autobackups (while seemingly related) has some special considerations of it's own.    Would suggest turning off autobackups for now, until this single course backup issue is resolved - no way to exclude this troubled course from autobackups and it could be the culprit in autobackups failing.

'spirit of sharing', Ken