First, pardon the length of this ... answer is not so simple. :\
Second ... am by no means the foremost expert on the backup process, have just had to deal with it (like you) and have found what works for me ... your mileage might vary.
Before removing all files in moodledata/temp/backup/ it's worth the time to investigate what one finds there.
A successful backup leaves behind a 0 byte log file.
All commands below are from moodledata/temp/backup/ unless otherwise noted.
ls -l *.log
renders a list such as this one example:
-rw-rw-rw- 1 apache apache 0 Aug 27 15:36 a3afdfe6e44507913ed73609fbb1509b.log
Nothing in them so one can erase them:
From moodledata/temp/backup/
rm -fR *.log
That leaves one with only directories of failed backups. They are named with a contenthash.
ls -l ./*/*.mbz
To see if there is a moodle backup file (.mbz) contained in any of them.
If there is, that file could be a valid backup that couldn't be *copied* from the build area
to the destination as determined by the backup settings. Destination could be 'backup area' ... which is the moodle file system itself in moodledata/filedir/ ... or 'designated' ... which is a directory the op has to
create manually and set proper ownership/permissions upon so that Apache can write to it ... or 'both'.
Uhhhh ... a system that is having issues with auto backups probably shouldn't be using 'both'.
From what I've been able to determine, if there is a .mbz file in a temp directory, the failure occurred
at the very end of the backup process ... which is to 'copy' the .mbz to the location. Copy on systems
have a limitation on file size and the only way to increase it is to compile support for larger files
in the kernel. Uhhhh .... something most folks won't do.
However, one can use the 'move' command. It has no such limitation. So if you have found .mbz files
in any of the temp/contenthash directories, they might be good backups ... just couldn't be copied.
** Move them to a designated directory for testing later (testing is simple, see if you can un-tar-gz them).
Example:
mv *.mbz /pathtosomelargepartition/
Example of one failed backup below. The directory 58.... below contains a failed backup.
[root@moodle backup]# ls -l
drwxrwxrwx 6 apache apache 4096 Aug 24 14:06 5860eac2e0ff3537538cf5fcaa0a84b8
cd 5860eac2e0ff3537538cf5fcaa0a84b8
And then list files contained therein:
[root@moodle 5860eac2e0ff3537538cf5fcaa0a84b8]# ls -l
total 96
drwxrwxrwx 14 apache apache 4096 Aug 24 14:06 activities
-rw-rw-rw- 1 apache apache 79 Aug 24 14:06 completion.xml
drwxrwxrwx 3 apache apache 4096 Aug 24 14:06 course
drwxrwxrwx 28 apache apache 4096 Aug 24 14:06 files
-rw-rw-rw- 1 apache apache 31251 Aug 24 14:06 files.xml
-rw-rw-rw- 1 apache apache 215 Aug 24 14:06 gradebook.xml
-rw-rw-rw- 1 apache apache 86 Aug 24 14:06 groups.xml
-rw-rw-rw- 1 apache apache 0 Aug 24 14:06 moodle_backup.log
-rw-rw-rw- 1 apache apache 17684 Aug 24 14:06 moodle_backup.xml
-rw-rw-rw- 1 apache apache 83 Aug 24 14:06 outcomes.xml
-rw-rw-rw- 1 apache apache 83 Aug 24 14:06 questions.xml
-rw-rw-rw- 1 apache apache 294 Aug 24 14:06 roles.xml
-rw-rw-rw- 1 apache apache 79 Aug 24 14:06 scales.xml
drwxrwxrwx 15 apache apache 4096 Aug 24 14:06 sections
In the example above, NO .mbz file so even though it began to build, failure for some reason. Note the moodle_backup.log file is 0 bytes. No help there. But, you can see files.xml is rather large - those .xml
files, BTW, are like 'controllers' for their respective directories.
In the above example, it's in-complete and probably could not be used in a restore, but ...
for the sake of attempting recovery o
f something .... we'll make a backup file manually.
To get the course name, from the moodle_backup.xml file:
fgrep '<original_course_fullname' moodle_backup.xml
In this example, the command above renders:
<original_course_fullname>Freshman Leadership</original_course_fullname>
Now we know what to name the backup we are creating manually.
From the 5860eac2e0ff3537538cf5fcaa0a84b8 directory:
tar zcvf /somelargepartition/freshmanleadershipmanualbackup.mbz ./*
Now it might not be a good backup ... test later.
Since I'm using a system that did have such a course as a failed backup, will continue using
the above example.
We need to find out if that course is still there.
In the moodle_backup.xml there is a line:
<original_course_id>244</original_course_id>
That's the id number - 244 - I'll use that below.
Now let's see if we can back it up via command line. Must have that ID number.
Before we leave the temp area, let's remove any all files/folders in there.
From moodledata/temp/backup/
rm -fR *
Ok to test backing up that one course via command line.
cd /pathtomoodlecode/admin/cli/
There is a backup.php script. It will use parameters from the setup of course backups
in Site Admin -> Courses -> Backups -> General backup defaults.
IF one is including users, backups will take longer. IF excluding users, the backup
file name will contain 'nu' (no users) in the file name.
On a failed course backup, I'll set that to no users one time and run the command line
backup to see if that will complete. Then I'll change the setting back to include
users and try again. Obviously, including users should result in user data being included
AND the backup will take longer and BE larger.
Issued like:
php backup.php --courseid=244 --destination=/home/clibackups/
where 244 if the course ID and in this case I have a directory called clibackups on the
largest partition of this system called /home.
I'd work in two terminal sessions at this point.
One terminal session (#1) where the command is issued and runs.
The other (#2) in /pathtomoodledata/temp/backup/
Once you issue the command in #1 switch to #2 and see what contenthash directory
has been created to build the backup. In #2 issue:
watch "ls -lR;df"
and that watch command will show what Moodle is doing as it builds the backup.
The command line backup script, won't display much:
== Performing backup... ==
Writing /home/clibackups/backup-moodle2-course-244-fl-20150829-0809-nu.mbz
Backup completed.
IF successful.
[root@moodle cli]# ls -l /home/clibackups/backup-moodle2-course-244-fl*
-rw-rw-rw- 1 root root 4275819 Aug 29 08:09 /home/clibackups/backup-moodle2-course-244-fl-20150829-0809-nu.mbz
-rw-rw-rw- 1 root root 4282650 Aug 29 08:19 /home/clibackups/backup-moodle2-course-244-fl-20150829-0819.mbz
You can see the nu backup is smaller.
But your #2 terminal session window will show when/where it fails.
What to do at this point, I couldn't tell you. But, it might point to something
or provide a clue.
I'd set auto backups to run manually.
As far as discovering what courses are the largest, thus the ones that would/might give grief, there
is a a report for courses sizes one could install. Once installed and run, you can ID which courses
to try out the command line backup upon.
To get control over it all, one might have to create the command line scripts that
go through a list of smaller course ID's and runs the command line version of backup.
And another script that runs through a list of larger courses on another day - the least used
time frame. Those scripts can be setup with cron.
One might consider putting the site in maintenance mode when running the larger courses backup script as those backups ARE resource intensive.
I can provide examples later.
Ken