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

Backup and restore FAQ: Difference between revisions

From MoodleDocs
(removing What happens if I restore a backup containing an assignment from Moodle 2.2 and older?)
 
(158 intermediate revisions by 38 users not shown)
Line 1: Line 1:
{{FAQ}}
{{Backup}}
;Site backups
==How do I backup a course?==
:Site backups, as explained in [[Upgrading_Moodle#Backup_important_data|upgrading Moodle]], are recommended in order to have all data saved with the best confidence and the shortest recovery time.


;Course backups
See [[Course backup]] and [[Automated backup setup]].  
: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). In order to make scheduled backups, you have to setup CRON to run periodically. Have a look at [[Installing Moodle#Set_up_cron|Set up cron]] for details.


===How do I backup my whole Moodle site?===
==How do I restore a course?==


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.
See [[Course restore]].


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):
==How do I backup my site?==


cd /my/backup/directory
See [[Site backup]].
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:
==What are the pros and cons of course versus site backups?==


rsync -auvtz --delete -e ssh mysshusername@example.com:/my/server/directory /my/backup/directory/
[[Site backup|Site backups]] are recommended in order to have all data saved with the best confidence and the shortest recovery time.


'''Character Encoding'''
For a site administrator, [[Automated course backup|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.


When dumping the entire Moodle database, Administrators should be careful to watch for possible character encoding issues. In some instances, backups created with mysqldump or phpmyadmin may not properly encode all of the data resulting in spurious A characters. One solution is to use mySQL Administrator 1.1 or another tool that will force a utf-8 dump of the data.
==Why is my automated course backup much smaller in size than my manual course backup?==


===What data is not contained in course backups?===
This is an intentional design decision. Because of the way files are stored in Moodle 2.x, there is no need to include the files in the backup if you are planning to restore them to the same Moodle site. Leaving them out saves huge amounts of disk space and makes the backup procedure much faster.
 
==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:
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.
* 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.
* Scales are only backed up if they are used by at least one activity.
* Users' passwords are not backed up when the "Include enrolled users" option is selected.
* Glossary data
* Badges - if they have not been awarded to at least one user and users are not included in the course backup.


===Error: An error occurred deleting old backup data===
==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:
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_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.


* Delete old records from "backup_files" table: Check the table exists, repair it and try again.
[[Image:BackupProblem.gif|thumb|Backup error message]]
For points 1 & 2, there are various ways of repairing tables, including using MySQL Admin.


* Delete old files from "moodledata/temp/backup": Delete the dir completely and try again.
For point 3 see below:


There are various ways of repairing tables, including using MySQL Admin.
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.


===XML error: not well-formed (invalid token) at line YYYY===
==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...).
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...).
Line 57: Line 60:
* Test the moodle.xml file again with Firefox until no error was displayed.
* Test the moodle.xml file again with Firefox until no error was displayed.


* Zip everything again (all the folder contents but the folder itself!).
* Zip everything again (all the folder contents but not the folder itself!).


* Restore the course. It should work now.
* 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.
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!! ===
==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:
#Unzip the backup file of the course (example: mycourse.zip)
#Once the file is unzipped, open the folder (example: mycourse).
#Select the folders within the mycourse folder AND the moodle.xml file and create a zip of those item (example: mycourse_new.zip)
#Upload the new zip file (example: mycourse_new.zip) 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 [http://moodle.org/mod/forum/discuss.php?d=140355 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).
 
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:
 
* Download the [https://confluence.atlassian.com/jira/files/12079/atlassian-xml-cleaner-0.1.jar Atlassian XML Cleaner Utility] from the [http://confluence.atlassian.com/display/JIRA/Removing+invalid+characters+from+XML+backups JIRA Atlassian site].
 
* 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:
There are three possible causes of this problem:
# 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.
# 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.
# 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.


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.
==Why are some courses being skipped?==


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).
[[Image:autobackup_skip_settings.png|thumb|AutoBackup '''skip''' settings]]Moodle's ''Course backups'' routines are instructed to automatically skip courses based on three settings in ''Administration > Site administration > Courses > Backups > Automated backup setup.'' The Moodle administrator(s) use those settings to specify whether to ''Skip hidden courses'' (set by default to 'Yes'), ''Skip courses not modified since'' (set by default to '30 days'), and ''Skip courses not modified since previous backup'' (set by default to 'No'). A course which meets any of the enabled criteria will be skipped during the next run of ''Course backups''.


3. Skipped - this happens when the course isn't visible to your students and it hasn't been modified in the last month (31 days). To save process time this type of courses are skipped on purpose. This isn't an error situation but a feature one, specially useful under sites with a lot of invisible old courses where it has no too much sense to backup them always.
==Why does restore stop, rather than completing?==


=== Restoring pre 1.6 non-ISO-8859-1 backups over Moodle 1.6 - Unicode ===
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 you have some backups files whose contents aren't 100% ISO-8859-1, you'll run under problems if you try to restore them to any Moodle 1.6 (and upwards) running under Unicode. But there is one workaround to solve this:
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.


# Make a clean install of Moodle 1.5.x (the latest version available).
==Restore stops with the message "Trying to restore user xxxx from backup file will cause conflict"==
# Restore all your courses there (they should work if they were working originally).
# Upgrade your site to Moodle 1.6 and run the UTF-8 migration script.
# 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 problems at all.
This message is displayed when:
 
# The target site has a user xxxx (xxxx being the username) - often the admin user
# The backup archive being restored also contains a user xxxx (same username)
# After various comparisons, Moodle has determined that the target site user xxxx and the backup user xxxx aren't the same person.
 
If 1, 2 and 3 are all true, the restore process stops in order to prevent the backup user xxxx's activities (forum posts, quiz attempts, assignment uploads, etc) from being associated with the target site user xxxx.
 
Here are the possible methods to make the xxxx users match (and resolve the conflict):
 
a) Modify the backup archive '''users.xml''' file and make the ''email'' or ''firstaccess'' fields match the ones in target site. Note that  the ''moodle-filename-backup.'''mbz''''' is a zip file and can be renamed to ''moodle-filename-backup.'''zip''''' and unzipped. When editing is complete, re-zip and then rename using the original file name with the "*.mbz" extension.
 
b) Modify the '''target site''' and set the user ''email'' or ''firstaccess'' fields to match the ones in backup archive users.xml file.
 
c) In Moodle 3.0.3 onwards and for admin user conflicts only, enable the setting 'Allow admin conflict resolution' in ''Site admin > Courses > Backups > General import defaults''. This will result in the username in the backup file being renamed to 'admin_xyz'.
 
==Why are certain course links broken in a restored course?==
 
Inter-activity links must be absolute (full) URLs e.g. <code><nowiki>http://site.com/mod/resource/view.php?id=xxx</nowiki></code> in order to be processed properly during backup and restore.
 
Any relative URLs e.g. <code>/mod/resource/view.php?id=xxx</code>, <code>../resource/view.php?id=xxx</code> or <code>view.php?id=xxx</code> will result in broken links when the course is restored.
 
==Restoring a course results in broken HTML tags. What can I do?==
This has been known to be caused by older versions of   libxml2 and PHP  - try updating them to the latest versions.
 
==How can I extract original files from a Moodle backup file?==
If you really want to get original files from the backup file (an ".mbz" file) you downloaded (using the backup and restore feature), you can do so in much the same way as is suggested above.
 
The backup file can actually be opened with any zip/unzip program you can download. Once you open the file, you need to extract:
 
    The files.xml file.
    The files directory (folder).
 
Next step would be to open the "files.xml" file in a text editor, and:
 
    Search for the name of each file you want to get.
    Take note of the value of the corresponding contenthash tag.
    In the "files" folder you extracted, locate the file whose name is the same as the value of the contenthash and which will always be located in a folder whose name corresponds to the two first characters of the file name.
 
For example, let's assume there is a "backup_courses-120730.mbz" file of which the "files.xml" file and the "files" folder have been extracted. There is a PDF file named "Leadership.pdf" that is required for another purpose.
 
Open the files.xml file and:
 
1. Search for the string "Leadership.pdf", which in this case is found under the following &lt;file id...&gt; group tag:
 
  &lt;file id="12345"&gt;
  &lt;contenthash&gt;fb6cf43a9b2d432403c70a2cb4c340dbb6225631&lt;/contenthash&gt;
                :
  &lt;filename&gt;Leadership.pdf&lt;/filename&gt;
                :
  &lt;license&gt;allrightsreserved&lt;/license&gt;
  &lt;sortorder&gt;1&lt;/sortorder&gt;
  &lt;/file&gt;
 
2. Take note of the corresponding contenthash value: fb6cf43a9b2d432403c70a2cb4c340dbb6225631.
 
3. As the first two characters of the contenthash are "fb", open the "fb" folder inside the "files" directory (which was previously extracted), and there is a file named "fb6cf43a9b...". Rename that file as "Leadership.pdf", and then move it to another location. Repeat this for all the files required, using the correct contenthash value of course.
 
==MySQL dmlwriteexception error when restoring a course==
 
If you obtain a  dmlwriteexception error when restoring a course, it is recommended that InnoDB tables are converted to the Barracuda file format. See the section 'Converting InnoDB tables to Barracuda' in [[Administration via command line]] for details of why this is recommended plus information on a tool for converting tables.
 
==Any further questions?==
 
Please post in the [http://moodle.org/mod/forum/view.php?f=128 Backup and restore forum] on moodle.org.


== See also ==
== See also ==


*[http://moodle.org/mod/forum/view.php?f=128 Using Moodle: Backup and Restore]
* [[Site backup]]
*[http://download.moodle.org/modules/integrations.php Moodle Download: Integrations] - MySQL Admin for download
* [[Moodle migration]]
 
== External links ==


*[http://www.databasejournal.com/features/mysql/article.php/10897_3300511_2 Repairing Database Corruption in MySQL]
Moodle forum discussions:
*[https://moodle.org/mod/forum/discuss.php?d=345466 Backing up and restoring course eliminates gradebook categories and items]


[[Category:Administrator]]
[[Category:FAQ]]
[[Category:FAQ]]


[[es:FAQ Backup]]
[[es:Respaldo y restauración FAQ]]
[[pl:Backup FAQ]]
[[fr:FAQ de sauvegarde]]
[[ja:バックアップFAQ]]
[[pt:FAQ sobre cópias de segurança]]
[[de:Sicherung und Wiederherstellung FAQ]]

Latest revision as of 21:28, 13 December 2018

How do I backup a course?

See Course backup and Automated backup setup.

How do I restore a course?

See Course restore.

How do I backup my site?

See Site backup.

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.

Why is my automated course backup much smaller in size than my manual course backup?

This is an intentional design decision. Because of the way files are stored in Moodle 2.x, there is no need to include the files in the backup if you are planning to restore them to the same Moodle site. Leaving them out saves huge amounts of disk space and makes the backup procedure much faster.

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.
  • Users' passwords are not backed up when the "Include enrolled users" option is selected.
  • Glossary data
  • Badges - if they have not been awarded to at least one user and users are not included in the course backup.

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: mycourse.zip)
  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: mycourse_new.zip)
  4. Upload the new zip file (example: mycourse_new.zip) 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).

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.
  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.

Why are some courses being skipped?

AutoBackup skip settings

Moodle's Course backups routines are instructed to automatically skip courses based on three settings in Administration > Site administration > Courses > Backups > Automated backup setup. The Moodle administrator(s) use those settings to specify whether to Skip hidden courses (set by default to 'Yes'), Skip courses not modified since (set by default to '30 days'), and Skip courses not modified since previous backup (set by default to 'No'). A course which meets any of the enabled criteria will be skipped during the next run of Course backups.

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.

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

This message is displayed when:

  1. The target site has a user xxxx (xxxx being the username) - often the admin user
  2. The backup archive being restored also contains a user xxxx (same username)
  3. After various comparisons, Moodle has determined that the target site user xxxx and the backup user xxxx aren't the same person.

If 1, 2 and 3 are all true, the restore process stops in order to prevent the backup user xxxx's activities (forum posts, quiz attempts, assignment uploads, etc) from being associated with the target site user xxxx.

Here are the possible methods to make the xxxx users match (and resolve the conflict):

a) Modify the backup archive users.xml file and make the email or firstaccess fields match the ones in target site. Note that the moodle-filename-backup.mbz is a zip file and can be renamed to moodle-filename-backup.zip and unzipped. When editing is complete, re-zip and then rename using the original file name with the "*.mbz" extension.

b) Modify the target site and set the user email or firstaccess fields to match the ones in backup archive users.xml file.

c) In Moodle 3.0.3 onwards and for admin user conflicts only, enable the setting 'Allow admin conflict resolution' in Site admin > Courses > Backups > General import defaults. This will result in the username in the backup file being renamed to 'admin_xyz'.

Why are certain course links broken in a restored course?

Inter-activity links must be absolute (full) URLs e.g. http://site.com/mod/resource/view.php?id=xxx in order to be processed properly during backup and restore.

Any 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.

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

This has been known to be caused by older versions of libxml2 and PHP - try updating them to the latest versions.

How can I extract original files from a Moodle backup file?

If you really want to get original files from the backup file (an ".mbz" file) you downloaded (using the backup and restore feature), you can do so in much the same way as is suggested above.

The backup file can actually be opened with any zip/unzip program you can download. Once you open the file, you need to extract:

   The files.xml file.
   The files directory (folder).

Next step would be to open the "files.xml" file in a text editor, and:

   Search for the name of each file you want to get.
   Take note of the value of the corresponding contenthash tag.
   In the "files" folder you extracted, locate the file whose name is the same as the value of the contenthash and which will always be located in a folder whose name corresponds to the two first characters of the file name.

For example, let's assume there is a "backup_courses-120730.mbz" file of which the "files.xml" file and the "files" folder have been extracted. There is a PDF file named "Leadership.pdf" that is required for another purpose.

Open the files.xml file and:

1. Search for the string "Leadership.pdf", which in this case is found under the following <file id...> group tag:

 <file id="12345">
 <contenthash>fb6cf43a9b2d432403c70a2cb4c340dbb6225631</contenthash>
               :
 <filename>Leadership.pdf</filename>
               :
 <license>allrightsreserved</license>
 <sortorder>1</sortorder>
 </file>

2. Take note of the corresponding contenthash value: fb6cf43a9b2d432403c70a2cb4c340dbb6225631.

3. As the first two characters of the contenthash are "fb", open the "fb" folder inside the "files" directory (which was previously extracted), and there is a file named "fb6cf43a9b...". Rename that file as "Leadership.pdf", and then move it to another location. Repeat this for all the files required, using the correct contenthash value of course.

MySQL dmlwriteexception error when restoring a course

If you obtain a dmlwriteexception error when restoring a course, it is recommended that InnoDB tables are converted to the Barracuda file format. See the section 'Converting InnoDB tables to Barracuda' in Administration via command line for details of why this is recommended plus information on a tool for converting tables.

Any further questions?

Please post in the Backup and restore forum on moodle.org.

See also

Moodle forum discussions: