What's your settings on Clean backup tables and logs in scheduled task?
and or other scheduled task that might have affect on Auto backups?
'spirit of sharing', Ken
re: What's your settings on Clean backup tables and logs in scheduled task?
Left at default of every 10 minutes.
Not sure how this setting or others affect the schedule, sure wish I could backup all the courses in 1 run though. I'ld like to restrict it to one long run in the evening during our slow time. My backup of 750 courses took over 2 days while running at a pattern of 1 hr on followed by 2 hr off.
Haven't really tested/research this, but there was another poster that had a 'timing' issue with autobackups and the new task. At that time, thought it might have been a bug ... clean up started while autobackup was running ... that clean up involved the very directory that autobackups (or manual) uses to build the backups ... moodledata/temp/backup/ Poster reported finding in-complete backup builds ... directories were there but didn't have moodle_backup.xml or other parts ... and no backup.mbz temp files. (which is how ti wroks, from viewing/watching it realtime ... ie, a backup.mbz file is created ... and the very last step in the process is to "copy" that backup.mbz to the destination chosen in config (file system or alternative directory) while changing the name of the file according to options chosen in making backups ... like use course short name, ID number, etc..
That last process of "copy" hits limitations in operating systems - 32bit vs 64bit and other limits to copy. (move command, however, works with any size)
I too have had issues with autobackups ... and I finally ended up: turning off the clean up task, setting autobackups to go to a file system repo (so they could be seen by courses set to use that file system repo), and creating my own script running the commands found in moodlecode/admin/cli/ tied to a cron job ... that I could schedule for off peak times.
To regain control of it all had to truncate tables related the the scheduling of autobackups first. Set autobackups to manual, but did choose options in backups such that they were full course backups ... users, logs, etc.
The script is bash shell and runs through a text file listing of courses - courses1.txt would contain nothing but the course ID's:
2
6
33
50
I had to use two scripts ... one pointed to small courses and one pointed to the large ones - largecourses.txt.
This way ... I could either trust my manually created cron jobs to run or I could, if I desired to do so, run the scripts myself at any time.
Know this is not what you wanted to hear, but ....
'spirit of sharing', Ken
re: That last process of "copy" hits limitations in operating systems -
32bit vs 64bit and other limits to copy. (move command, however, works
with any size)
I didnt think it was a server limitation issue as the process stops on the automated course backups schedule. I'll retest this in our development environment by changing the minute of the hour this task runs. We are on 32bit php and will probably go to 64 bit in the near future though.
To further complicate things my development environment runs 2hr on, 2hr off, with the same automated course backup schedule. This dev machine is M2.8 while production is M2.7. I notice one difference between the two versions in Scheduled Task defaults for Legacy log table cleanup, its once an hour in M2.8 and every minute of the fourth hour in M2.7, the M2.7 doesn't like correct but also doesnt look like its influencing my auto course backups either.
Thanks for the details on your manual work around. I'll look into the admin cli side of things, its looking a little more complicated than I hoped, do you think it would be easier to upgrade to Moodle 3 in the hopes its refined auto course backup schedules?
Am not aware that 3.x specifically addressed the issue ... for that matter not sure there ever was an official tracker bug reported with directions on how to reproduce the error. One would have to have a sandbox clone of a production site that had the issues and purposely wreck/disable/putz to get consistent behavior, me thinks. This to say, don't think I've ever been able to say .... xyz is cause in every case.
To many variables involved ... recently investigated a shared hosting environment where op had option to increase package restrictions that appeared to be the culprit ... cap on how much extra memory could be called by a Moodle script. A standalone or even a virtual where op had full control that wouldn't have been an issue .. or the 'fix' could have been applied.
Fingers crossed that and upgrade wouldn't make it worse! ;)
'spirit of sharing', Ken