Backup and restore FAQ: Difference between revisions
No edit summary |
Helen Foster (talk | contribs) m (Reverted edit of Jopan, changed back to last version by Helen) |
||
Line 3: | Line 3: | ||
;Course backups | ;Course backups | ||
:Course backups, configured on the [[admin/backup|backup]] page, are more expensive in terms of time and CPU usage. The recovery time to have your site running again is longer. Course backups are useful for obtaining | :Course backups, configured on the [[admin/backup|backup]] page, are more expensive in terms of time and CPU usage. The recovery time to have your site running again is longer. Course backups are useful for obtaining "fresh" copies of courses to be re-used or distributed individually, however they should never be used as a primary backup system (unless your hosting doesn't allow the preferred site backups). | ||
===How do I backup my whole Moodle site?=== | ===How do I backup my whole Moodle site?=== | ||
Line 24: | Line 24: | ||
This part of the backup (or restore) procedure tries to delete old info, used in previous executions, performing the following tasks: | This part of the backup (or restore) procedure tries to delete old info, used in previous executions, performing the following tasks: | ||
* Delete old records from | * Delete old records from "backup_ids" table: Check the table exists, repair it and try again. | ||
* Delete old records from | * Delete old records from "backup_files" table: Check the table exists, repair it and try again. | ||
* Delete old files from | * Delete old files from "moodledata/temp/backup": Delete the dir completely and try again. | ||
There are various ways of repairing tables, including using MySQL Admin. | There are various ways of repairing tables, including using MySQL Admin. | ||
Line 34: | Line 34: | ||
===XML error: not well-formed (invalid token) at line YYYY=== | ===XML error: not well-formed (invalid token) at line YYYY=== | ||
This problem can appear at any point in the restore process. It's caused when the XML parser detects something incorrect in the backup file that prevent correct operation. Usually, it's caused by some | This problem can appear at any point in the restore process. It's caused when the XML parser detects something incorrect in the backup file that prevent correct operation. Usually, it's caused by some "illegal" characters added in the original course due to some copy/paste of text containing them (control characters, or invalid sequences...). | ||
The best method to handle this issue is: | The best method to handle this issue is: | ||
Line 50: | Line 50: | ||
* Restore the course. It should work now. | * Restore the course. It should work now. | ||
Also, if possible, it's highly recommended to solve those problems in the original course too from Moodle itself. Once | Also, if possible, it's highly recommended to solve those problems in the original course too from Moodle itself. Once "repaired" there, problems will be out if you create new backup files in the future. | ||
=== Some of your courses weren't saved!! === | === Some of your courses weren't saved!! === | ||
Line 56: | Line 56: | ||
There are two possible causes of this problem: | There are two possible causes of this problem: | ||
1. Error - this happens when the backup procedure has found an error and so hasn't finished the backup of a particular course. These are | 1. Error - this happens when the backup procedure has found an error and so hasn't finished the backup of a particular course. These are "controlled" errors and the scheduled backup continues with the next course. | ||
2. Unfinished - this happens when the backup procedure dies without knowing why. When the cron is next executed it detects that the last execution went wrong, and continues skipping the problematic course. A possible solution would be to raise the PHP/Apache limit in your installation (memory, time of execution...). By taking a look to your log tables you should be able to see if the | 2. Unfinished - this happens when the backup procedure dies without knowing why. When the cron is next executed it detects that the last execution went wrong, and continues skipping the problematic course. A possible solution would be to raise the PHP/Apache limit in your installation (memory, time of execution...). By taking a look to your log tables you should be able to see if the "crash" is happening at exact time intervals (usually a problem with the max_execution_time php's variable), or if there is some exact point were all the courses are breaking (generally internal zip libraries, try to switch to external executables instead). | ||
== See also == | == See also == | ||
Line 71: | Line 71: | ||
[[Category:Administrator]] | [[Category:Administrator]] | ||
[[Category:FAQ]] | [[Category:FAQ]] | ||
Revision as of 06:46, 20 December 2005
- Site backups
- Site backups, as explained in upgrading Moodle, are recommended in order to have all data saved with the best confidence and the shorter recovery time.
- Course backups
- Course backups, configured on the backup page, are more expensive in terms of time and CPU usage. The recovery time to have your site running again is longer. Course backups are useful for obtaining "fresh" copies of courses to be re-used or distributed individually, however they should never be used as a primary backup system (unless your hosting doesn't allow the preferred site backups).
How do I backup my whole Moodle site?
There are two main things you need to make a copy of - the database and the uploaded files. The Moodle scripts themselves are less important, since you can always download a fresh copy if you have to.
There are many ways to do such backups. Here is an outline of a little script you can run on Unix to backup the database (it works well to have such a script run daily via a cron task):
cd /my/backup/directory mv moodle-database.sql.gz moodle-database-old.sql.gz mysqldump -h example.com -u myusername --password=mypassword -C -Q -e -a mydatabasename > moodle-database.sql gzip moodle-database.sql
For the files, you can use rsync regularly to copy only the changed files to another host:
rsync -auvtz --delete -e ssh mysshusername@example.com:/my/server/directory /my/backup/directory/
Error: An error occurred deleting old backup data
This part of the backup (or restore) procedure tries to delete old info, used in previous executions, performing the following tasks:
- Delete old records from "backup_ids" table: Check the table exists, repair it and try again.
- Delete old records from "backup_files" table: Check the table exists, repair it and try again.
- Delete old files from "moodledata/temp/backup": Delete the dir completely and try again.
There are various ways of repairing tables, including using MySQL Admin.
XML error: not well-formed (invalid token) at line YYYY
This problem can appear at any point in the restore process. It's caused when the XML parser detects something incorrect in the backup file that prevent correct operation. Usually, it's caused by some "illegal" characters added in the original course due to some copy/paste of text containing them (control characters, or invalid sequences...).
The best method to handle this issue is:
- Unzip the problematic backup file under one empty folder.
- Open the moodle.xml with Firefox. It will show you where (exact char) the problem is happening.
- Edit the moodle.xml file with some UTF8-compatible editor and delete such characters. Save changes.
- Test the moodle.xml file again with Firefox until no error was displayed.
- Zip everything again (all the folder contents but the folder itself!).
- Restore the course. It should work now.
Also, if possible, it's highly recommended to solve those problems in the original course too from Moodle itself. Once "repaired" there, problems will be out if you create new backup files in the future.
Some of your courses weren't saved!!
There are two possible causes of this problem:
1. Error - this happens when the backup procedure has found an error and so hasn't finished the backup of a particular course. These are "controlled" errors and the scheduled backup continues with the next course.
2. Unfinished - this happens when the backup procedure dies without knowing why. When the cron is next executed it detects that the last execution went wrong, and continues skipping the problematic course. A possible solution would be to raise the PHP/Apache limit in your installation (memory, time of execution...). By taking a look to your log tables you should be able to see if the "crash" is happening at exact time intervals (usually a problem with the max_execution_time php's variable), or if there is some exact point were all the courses are breaking (generally internal zip libraries, try to switch to external executables instead).
See also
- Using Moodle: Backup and Restore
- Moodle Download: Integrations - MySQL Admin for download