Backup and restore

Hrmmm... more interesting stuff to note.

I verified with the development guys that nobody has changed the backup*.php files, and what version of Moodle and PHP we're on (Moodle 1.7, PHP 5.1.6). The dev guys said we have made efforts to not change anything in Moodle other than cosmetic/HTML stuff, so that future upgrades wouldn't be too painful - so this is a fairly stock install.

I may have to retract my thoughts on it being an infinite loop. Some further use of strace and a few grep -v statements, gets me the debug output you'll see below (and to spare you having to read all of it to see what I find interesting: note that the ID changes each time - so we're not looking at an infinite loop apparently; as the data it's working on changes with each run through the loop).

A bit more grep, and I see that the loop we're in is the backup_log_info() function in backuplib.php. Apparently looping from either line 1286 or line 1293. While the code below may not indicate it (because I've grep'ed out the stuff that's reloading the various backuplib.php files), it is having to reload the backuplib.php file for EACH LINE of the below output which is going to the moodle.xml file that's being generated...

Here's the debug output, just for refernce..

write(60, " <ID>625061</ID>\n", 24) = 24
write(60, " <TIME>1170623267</TIME>\n", 32) = 32
write(60, " <USERID>439</USERID>\n", 29) = 29
write(60, " <IP>x.x.x.127</IP>\n", 31) = 31
write(60, " <MODULE>quiz</MODULE>\n", 30) = 30
write(60, " <CMID>2353</CMID>\n", 26) = 26
write(60, " <ACTION>close attempt</A"..., 39) = 39
write(60, " <URL>review.php?attempt="..., 43) = 43
write(60, " <INFO>1010</INFO>\n", 26) = 26
write(60, " </LOG>\n", 13) = 13
write(60, " <LOG>\n", 12) = 12
write(60, " <ID>625062</ID>\n", 24) = 24
write(60, " <TIME>1170623273</TIME>\n", 32) = 32
write(60, " <USERID>439</USERID>\n", 29) = 29
write(60, " <IP>x.x.x.127</IP>\n", 31) = 31
write(60, " <MODULE>quiz</MODULE>\n", 30) = 30
write(60, " <CMID>2353</CMID>\n", 26) = 26
write(60, " <ACTION>review</ACTION>\n", 32) = 32
write(60, " <URL>review.php?id=2353&"..., 55) = 55
write(60, " <INFO>1010</INFO>\n", 26) = 26
write(60, " </LOG>\n", 13) = 13
write(60, " <LOG>\n", 12) = 12
write(60, " <ID>625083</ID>\n", 24) = 24
write(60, " <TIME>1170623665</TIME>\n", 32) = 32
write(60, " <USERID>439</USERID>\n", 29) = 29
write(60, " <IP>x.x.x.127</IP>\n", 31) = 31
write(60, " <MODULE>quiz</MODULE>\n", 30) = 30
write(60, " <CMID>2353</CMID>\n", 26) = 26
write(60, " <ACTION>view</ACTION>\n", 30) = 30
write(60, " <URL>view.php?id=2353</U"..., 36) = 36
write(60, " <INFO>1010</INFO>\n", 26) = 26
write(60, " </LOG>\n", 13) = 13
write(60, " <LOG>\n", 12) = 12


Again, all help welcome and appreciated.

Sorry to keep replying to myself, but my time to edit keeps running out.

In ./school/backup/backuplib.php line 1750, function backup_encode_absolute_links

follow on down to line 1774, and see if we don't see the code that's causing the issue here.

Best as I can tell, "include_once" is causing the file not to be reloaded every time, but PHP is going so far as to lstat64() the file (and every directory along the way in the path to the file - each as a separate call to lstat64()), and the file is being opened before it is being not loaded because of the include_once use.

I also note this from php.net - code was added to normalize the path to work-around Windoze: "This behaviour changed in PHP 5 - the path is normalized first so that C:\PROGRA~1\A.php is realized the same as C:\Program Files\a.php and the file is required just once."

I am strongly suspicious that this 'path normalizing' code in PHP5.1.x is the cause of the exorbiant amount of lstat64() calls (one for each directory in the path to backuplib.php - which in my case is quite a few). Each call to lstat64 causes disk I/O, and doing a gazillion disk I/O calls in a short period of time causes exorbiant system overhead to be generated.

So, guys (and gals) - now I have a more serious developer question: Me not knowing anything of significance about what is being done here - can someone point me to a good way to not have to do this include_once() call a few gazillion times during every backup run? And perhaps such changes might want to become part of Moodle proper - as I can't imagine I'm the only one running into this.

Thanks,

How large is your install? Moodle backups are not particularly scalable -- a solution you can use instead is to backup your DB (mysqldump or pg_dump) and your moodledata directories to tape or whatever you use for backup media.

When you get a request to restore just one course - run the restore to a temporary Moodle installation, and then you can let the teacher export the Moodle backup zipfile for just that course, and restore it onto the "production" Moodle system. Much more reliable and complete. And if you need a full restore, you have it.

Another good thing to do is to avoid using curl and hitting the cron script directly from the commandline PHP binary.

Hope that helps.

Work-around available - see here: http://tracker.moodle.org/browse/MDL-8700

Thanks,