Yes, Colin, thanks! Have turned on the experimental and run it on a 2.8 version. It does appear to be faster.
For folks that do this ... the routine doesn't change the extension of the backup file ... still .mbz. IF, however, you've learned about renaming the file to a zip extension then running unzip, that will fail ... duh! Well - yeah!
The file is now a tar.gz ... which means to un-compress/expand/extract contents, one must use
tar -zxvf nameofbackup.mbz
Am experimenting, right now, with what appears to be a 14Gig backup, with the command line backup.php script found in moodlecode/admin/cli/ to see if it checks for the experimental setting or not.
Still think there is an issue with the method by which large .mbz's are 'copied' from the moodledatadir/temp/backup/[hashiddirectory]/backup.zip to the designated area ... filedir, or alternative directory as given in auto_backups when manually run.
As root user on a system, it shows:
file size (blocks, -f) unlimited
So there's some setting for PHP ... maybe?
Have found what appears to be all of the xml files and their related folders in such a temp directory with what appears to be a backup.mbz that couldn't be copied. One could, however, manually 'mv' the file.
So there's a limit on 'cp' as well ... me thinks.
Wow ...
drwxrwxrwx. 258 root root 4096 Mar 19 15:36 files
-rw-rw-rw-. 1 root root 4285026 Mar 19 16:01 files.xml
Naturally, IF one can successfully create a valid backup file, that doesn't necessarily mean one will be able to restore it. Uploading via normal means not possible. File System repo only way to go.
Hmmmm ... feature request? Now that there is a backup.php for backing up courses, will there be, in the future, a restore.php? Hoping so.
'spirit of sharing', Ken