just spent an hour or two with a troublesome course backup and thought I'd share a 'discovery'. Have bolded the key/important part below.
RHEL 6.5 - 16Gig mem. Plenty of space remaining.
Backup of a large course failed - temp file backup (.mbz) that was being written
disappeared. The log file that remained shows:
[root@elearning backup]# cat 19977830a7faa33f05211b8873975a50.log
[Thu 16 Jan 2014 08:18:57 PM GMT] [error] backup_auto_failed_on_course SS K-12
[Thu 16 Jan 2014 08:18:57 PM GMT] [error] Exception: error_zip_packing
Yet in moodledata/temp/backup/[tempfoldername] all the folders and files created for the construction of the .mbz where there including the key moodle_backup.xml file.
head moodle_backup.xml to acquire the name as Moodle would have given it.
Then while in that directory:
zip -r backup-moodle2-course-24-ss_k-12-20140116-1945.mbz *
One could give a path in front of the .mbz file.
which will 'expand' into:
zip -r backup-moodle2-course-24-ss_k-12-20140116-1945.mbz activities completion.xml course files files.xml gradebook.xml groups.xml moodle_backup.xml outcomes.xml questions.xml roles.xml scales.xml sections users.xml
zip will create a temp name in that directory ...
-rw-------. 1 root root 14650963476 Jan 16 20:57 ziXqv59d
this one did finish:
-rw-r--r--. 1 root root 15558171441 Jan 16 20:58 backup-moodle2-course-24-ss_k-12-20140116-1945.mbz
One **cannot copy it** but one can *move* it. Say like to the designated directory when doing automated backups and saving to only that designated directory. Think the PHP routine attempts to copy rather than move.
Wonder IF PHP an do a move rather than copy?
Then clean up that [tempdirectory]:
rm -fR 19977830a7faa33f05211b8873975a50
Also noticed, the zip command from CLI deflates files which is nothing new for cli. Wonder if the PHP routine does that?
adding: files/38/38f70e63a58bc7f4b233888a9351382887070866 (deflated 11%)
adding: files/38/38958315323edc507e1ce3b17df03cdcee0c08c9 (deflated 31%)
adding: files/38/38762eecd19f4ed552605a807f05815bfe17893e (deflated 3%)
adding: files/38/38ce0a5921f0d7595392cf24d08f04813bd73256 (deflated 10%)
May not get much deflation for digital content like videos, but for other types of documents there
is (sometimes) lots of 'air' that can be removed.
All this to say, if a backup fails, all may NOT be lost! Work is required, however! :\
Restoring, however, now necessitates the use of file system repo for such large backups - and some re-tweaking of php settings (maybe) before one attempts a restore.
This does assume the .mbz files created are valid zips. But in checking zip appears to be able to read/list files.
This is for what it's worth ... worked for me ... hope it works for anyone/everyone that finds themselves in a similar situation.
'spirit of sharing', Ken