Note: You are currently viewing documentation for Moodle 1.9. Up-to-date documentation for the latest stable version is available here: Backup and restore FAQ.

Backup and restore FAQ

From MoodleDocs
Revision as of 11:02, 31 January 2011 by Helen Foster (talk | contribs) (→‎How do I backup a course?: Automated backup setup link)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

How do I backup a course?

See Course backup and Automated course backup or Automated backup setup in Moodle 2.0 onwards.

How do I restore a course?

See Restore.

How do I backup my site?

See Site backup.

What is new in backup and restore in Moodle 2.0?

See Backup 2.0.

Backup stops at Zipping backup

Moodle 1.9 and lower use a PHP library to zip files that isn't very efficient and struggles to zip/unzip large files. You can use an external Zip binary to use a different process to handle your files - you can set this in Admin > Server > System Paths Moodle 2.0 uses new PHP zip functions so that specifying an external Zip binary isn't necessary see System_paths#Path_to_zip for help configuring an external zip binary.

What are the pros and cons of course versus site backups?

Site backups are recommended in order to have all data saved with the best confidence and the shortest recovery time.

For a site administrator, automated course backups are more expensive in terms of time, CPU usage and storage. The recovery time to have a site running again takes longer than a site backup. However, teachers and site administrators might find a course backups as a way to create a "fresh" copy of a course that can be re-used (in older versions of Moodle, in newer versions see Import course data) or as a method to distribute a course(s) to other Moodle sites.

What data is not contained in course backups?

By selecting all the options when setting up the backup you can include almost all the data in the course. However you should be aware of the fact that some things are not backed up:

  • Quiz questions are only backed up if at least one question from their category has been added to a quiz.
  • Scales are only backed up if they are used by at least one activity.

The process ends with: "Error: An error occurred deleting old backup data". What should I do?

This part of the backup (or restore) procedure tries to delete old info, used in previous executions, performing the following tasks:

  1. Delete old records from "backup_ids" table: Check the table exists, repair it and try again.
  2. Delete old records from "backup_files" table: Check the table exists, repair it and try again.
  3. Delete old files from "moodledata/temp/backup": Delete the dir completely and try again.
Backup error message

For points 1 & 2, there are various ways of repairing tables, including using MySQL Admin.

For point 3 see below:

The error message states that the "directory not empty" and gives the path to that directory. If you go there with an FTP program you can see what is there and clean up. It could be just some empty subfolders that were leftover. Deleting these has been able to help. One can also delete the dir "moodledata/temp/backup" completely. That can take a bit longer but may solve several problems at once.

The process ends with: "XML error: not well-formed (invalid token) at line YYYY". What can I do?

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 not the folder itself!).
  • Restore the course. It should work now.
  • Restore still not working? See the next question.

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.

The process ends with: "moodle xml not found at root level of zip file". What can I do?

If you are restoring from a zip file backup make sure the moodle.xml file is at the root level. To ensure this:

  1. Unzip the backup file of the course (example:
  2. Once the file is unzipped, open the folder (example: mycourse).
  3. Select the folders within the mycourse folder AND the moodle.xml file and create a zip of those item (example:
  4. Upload the new zip file (example: and restore from that.

If the backup file is guaranteed to be correct, check paths to external files (zip, unzip). Incorrect settings also lead to this error message (see the Using Moodle forum discussion moodle.xml not found in root... and MDL-14812).

The process ends with: "An error occurred while copying the zip file..."

This problem is most likely caused by a permissions issue in the destination directory. Backup files are copied to "XXX/backupdata" under your dataroot directory (where XXX is the id of the course being backed up).

On Windows systems, if you have configured Moodle to use an external zip program then the IIS IUSR_computername user needs to have Execute access to cmd.exe so that it can run the zip program. See the Note in Path to zip for more details.

The problem could also be caused by a disk being full, though this is far less likely.

To obtain precise information about what's happening, you can enable debug messages in Administration > Server > Debugging (select the maximum level - DEVELOPER) and/or check the web server error logs.

I Still get an XML error. How can I clean the borked XML file?

In some cases XML backup files may contain characters causing the restore process to abort, even after the steps described in the previous question. In such cases you may want to try the following:

  • Unzip the problematic Moodle backup file under one empty folder. Moodle will create the course file folders as long as the unclean moodle.xml file. Please unzip using the Moodle unzip feature.
  • Rename the unclean moodle.xml file to moodle-unclean.xml.
  • If you don't have access to your Moodle server's command prompt, using the Moodle zip feature, zip the moodle-unclean.xml file only, download the zip file locally and unzip it. It is very important to download the xml file in zipped format to avoid unwanted character encoding when transferring from an operating system to another.
  • Move the downloaded Atlassian XML Cleaner Utility in the same folder where is your moodle-unclean.xml file.
  • Issue the following command from the command prompt:
java -jar atlassian-xml-cleaner-0.1.jar moodle-unclean.xml > moodle.xml
  • If you launched the utility on your local computer, zip the just created (and hopefully cleaned) moodle.xml file and upload it in the same place from where you downloaded the moodle-unclean.xml file. Once uploaded, unzip it using the Moodle unzip feature.
  • Zip everything again (all the folder contents but the folder itself!).
  • Restore the course. It should work now.

What does "Some of your courses weren't saved!!" mean?

There are three 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).
  3. Skipped - this happens when a course is unavailable to students and has not been changed in the last month (31 days). This isn't an error situation - it's a feature, especially useful for sites with many unavailable old courses, saving process time.

How can I restore pre 1.6 non-ISO-8859-1 backups to Moodle 1.6 (Unicode)?

Any backup files with contents which are not 100% ISO-8859-1 will be a problem to restore to Moodle 1.6 (and upwards) running under Unicode. Instead, please try the following:

  1. Make a clean install of Moodle 1.5.x (the latest version available)
  2. Restore all your courses there (they should work if they were working originally)
  3. Upgrade your site to Moodle 1.6 and run the UTF-8 migration script
  4. Backup your courses again

This will produce a new set of backup files that will be 100% UTF-8 and you will be able to use them with Moodle 1.6 without any problems.

Restoring a course results in broken HTML tags. What can I do?

Summary: Upgrade your libxml2 and PHP and you should be fine. It has been confirmed that the recent versions of libxml2 (2.7.3) and PHP (5.2.10) no longer have this problem.

Background: (may be obsoleted) This problem is due to a PHP bug in libxml2 2.7.1 (the same bug reported with version 2.7.2 and 2.7.3). All HTML entities, such as >, < and " are removed when a course is restored.

To resolve the problem, you should use a different version of libxml2 such as 2.7.0 or 2.6.32 or compile PHP against libexpat instead of libxml2 or finally use PHP version >= 5.2.9 that solves this compatibility issue over the newer libxml2.

At Gentoo servers, you can use

echo ">dev-libs/libxml2-2.6.32" >> /etc/portage/package.mask

Update: This was fixed for libxml2 version 2.7.3 in PHP snapshot on 11/01/2009. You can use the following patch:

--- php-5.2.8/ext/xml/compat.c 2008/12/31 11:12:38 1.52
+++ php-5.2.8/ext/xml/compat.c 2009/01/11 12:00:30 1.53
@@ -482,6 +482,10 @@
parser->parser->charset = XML_CHAR_ENCODING_NONE;

+#if LIBXML_VERSION >= 20703
+ xmlCtxtUseOptions(parser->parser, XML_PARSE_OLDSAX);
parser->parser->replaceEntities = 1;
parser->parser->wellFormed = 0;
if (sep != NULL) {

See the discussion Restoring makes webpages and labels in code for further information.

Why are some courses being skipped?

From 1.6 onwards, course backups automatically skip courses which are unavailable to students and have not been changed in the last month.

The Hide courses excluded from automatic backup discussion in the Using Moodle forum describes a way that you can disable or override this thirty day check. This could be useful if, for example, you wanted to change the period from thirty days to six months.

Why does restore stop, rather than completing?

Attempting to restore a course to an older version of Moodle than the one the course was backed up on can result in the restore process failing to complete. To ensure a successful restore, make sure that the version of Moodle you are restoring the course to is the same, or newer, than the one the course was backed up on.

If it stop unexpectedly with no errors shown try again with Debugging switched on. Any errors you now see can help experts in the support forums diagnose your problem. You can also check the discussion links in the See also section below for further advice.

How can I improve restore robustness and execution times?


To improve restore robustness and execution times, particularly for medium to large course backups, try enabling the setting experimentalsplitrestore in Administration > Miscellaneous > Experimental. (This setting is available in Moodle 1.9.5 onwards.)

MDL-18468 contains information about this Experimental Split Restore functionality and the improvements to course restore robustness and execution times that it introduced, particularly for medium to large course backups. It also explains why this is an 'Experimental' feature in Moodle 1.9.

How can I backup and restore a course from a 1.9 site to a 2.0 site?

The backup and restore process has been completely rewritten for Moodle 2.0. It is not currently possible to backup a course on a 1.9 site and restore it to a 2.0 site, however the functionality should be available in Moodle 2.1 (see MDL-22414).

In the meantime, a workaround is to upgrade a copy of the 1.9 site to 2.0.

Restore stops with the message "Trying to restore user xxxx from backup file will cause conflict"

Error message in Moodle 2.0

This message is displayed when:

  1. Your target site has one xxxx user (xxxx being the username)
  2. The backup being restored also has one xxxx user
  3. After various comparisons, Moodle has detected that the xxxx user in 1. and the xxxx user in 2. aren't the same user.

If 1, 2 and 3 above happens, restore stops before performing any action as far as restoring that user will end associating "things" (create activities, posts, attempts... whatever...) to the xxxx user in the target site, when those "things" weren't performed by the same user at all.

Those checks and behaviour were introduced in Moodle 1.9.x and continue being valid under 2.0. Usually the xxxx user in the messages is the "admin" user (that exists in practically all Moodle installations).

There are two possible solutions to make both xxxx users in 1 and 2 to match (and avoid the conflict):

a) Modify the backup's users.xml file and make the email or firstaccess fields match with the ones in target site.
b) Modify the target site and set the user email or firstaccess fields to match with the ones in backup's user.xml file.

Method a) is recommended so the restore process will match both xxxx users and every "thing" in the backup file belonging to xxxx will be associated to the already existing xxxx user in the target site.

Why are certain course links broken in a restored course?

Inter-activity links must be full URLs e.g. in order to be processed properly during backup and restore.

Any absolute or relative URLs e.g. /mod/resource/view.php?id=xxx, ../resource/view.php?id=xxx or view.php?id=xxx will result in broken links when the course is restored.

This applies for all versions of Moodle including 2.0.

See also

Moodle Docs:

Using Moodle forum discussions: