Backup cycle lasting more than 24 hours

Backup cycle lasting more than 24 hours

by Rosario Carcò -
Number of replies: 4

I never had particular problems with my course-backups. They started some months ago, and I really have a medium sized site, over 15'500 users and more than 5'000 courses, nearly 600 GB of Moodle-Data, which includes the backup files of every course.

I know, I could save 300 GB of Data-Space if I would not create the backup-zip files and deleting them.

But it is really simpler to restore a single course if a teacher misses something than rewinding back the whole database and Moodle-Data Directory by a restore from tape.

On a dynamic system like Moodle, rewinding back is only good for a complete server loss.

I did already three migrations of the Moodle server onto newer hardware, which can be done in the same way you would do to recover the server from a total crash.

But I never experienced a total crash. So what I need is the automatic course-backups to restore single files or courses that have been messed up with Word-HTML or even Apple-Mac-HTML-Code, when users simply copy/paste from those programs directly into the HTML-Fields of Moodle. This is quick and does not interfere with the running system.

At the moment the backup procedure hangs at the cron-lock and finishes only a few courses at a time, despite max_memory and max_excution time having been risen in php.ini to phantastically high values.

As you can see in the open Tracker issue, the problems started when the whole backup cycle began to take/last more than 24 hours:

http://tracker.moodle.org/browse/MDL-11309

And at the moment being it lasts forever. An I have no clue why.

Any hints? Rosario

(Edited by Visvanath Ratnaweera - original submission Wednesday, 14 March 2012, 06:09 PM

Split from the thread "Cron Execution can last 5+ hours" http://moodle.org/mod/forum/discuss.php?d=114464 )

Average of ratings: -
In reply to Rosario Carcò

Re: Backup cycle lasting more than 24 hours

by Rosario Carcò -

Oooh, it took me until this week to SEE where the BUG was. In SLES 11 you have TWO php.ini files, one in /etc/php5/apache2, which was the one I tuned during the last 5 years.

Two years ago I had switched from calling Moodle's cron-job via apache to php-command-line. But everything worked fine until last year, when my backups began to last for ever and ever. Despite tuning max_memory and max_executiontime, I ended up with my backups not being finished at all and every backup showing an error.

Last week, to my surprise, I entered /etc/php5/cli and saw there was ANOTHER php.ini with installation defaults. So I tuned it with the same values 30 secs and 1024M memory and my backups began to run normally again. 12 hours actually to create backups of 280GB of data.

Rosario

Average of ratings: -
In reply to Rosario Carcò

Re: Backup cycle lasting more than 24 hours

by Rosario Carcò -

A week ago I had to change the data disk to offer more space. So I copied the whole data disk after having deleted all the backup-zip-files to gain time/speed for the whole data transfer (300 GB instead of 600 GB). Once the new data disk in place, I started the automated Moodle-Backup and it took only 3 hours. The second one took again more than 12 hours. So I suppose deletion/rotation of the existing zip-files could slow down the whole process. I will repeat the procedure this week deleting all backup-zip-files with a linux shell script, which takes about 10 minutes to complete. Then I will report back.

Rosario

Average of ratings: -
In reply to Rosario Carcò

Re: Backup cycle lasting more than 24 hours

by Rosario Carcò -

It definitively takes 12.5 hours, no matter whether I delete the zip-files with the shell.

Rosario

Average of ratings: -