Respaldo FAQ

Nota: Pendiente de Traducir. ¡Anímese a traducir esta página!. ( y otras páginas pendientes)

Copias de seguridad del sitio: Se recomienda realizar copias de seguridad del sitio, tal como se explica en Actualización de Moodle, para que se guarden todos los datos de la forma más fiable y con el menor tiempo de recuperación posible.

Copias de seguridad de curso: Las copias de seguridad de un curso, configuradas en la página de configuración del backup, son más costosas en términos de tiempo y de utilización de la CPU. Además, el tiempo necesario para restaurar el sitio a su estado anterior es también mayor. Las copias de seguridad de cursos son útiles para obtener una copia "fresca" de cursos que vayan a ser reutilizados o distribuidos de forma individual, pero en ningún caso deberían utilizarse como principal sistema de copia de seguridad de un sitio (a menos que su hosting no permita realizar copias completas del sitio) Para realizar copias de seguridad programadas, deberá configurar el CRON para que se ejecute periódicamente. Por favor, consulte las instrucciones sobre el cron.

¿Cómo realizo una copia de seguridad de todo mi sitio Moodle?

Existen dos elementos de los que necesita hacer una copia: la base de datos y los ficheros subidos al servidor. Los scripts de Moodle en sí son menos importantes, ya que siempre podrá bajarse una copia reciente si lo necesitase.

Hay muchas formas de llevar a cabo esas copias ded seguridad. He aquí unos apuntes de un pequeño script que puede ejecutarse en Unix para hacer una copia de la base de datos (es buena idea ejecutar dicho script a diario mediante un cron programado):

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

En cuanto a los ficheros, puede usar rsync de forma regular para copiar a otro servidor únicamente los archivos que hayan sufrido cambios:

rsync -auvtz --delete -e ssh mysshusername@example.com:/my/server/directory /my/backup/directory/

Codificación de caracteres

Cuando realicen copias de la base de datos completa de un sitio Moodle, los administradores deben tener cuidado y vigilar que no se produzcan problemas con la codificación de caracteres. En algunos casos, las copias de seguridad creadas con mysqldump o con phpmyadmin puede que no codifiquen adecuadamente todos los datos, dando como resultado la inclusión de caracteres A bastardos. Una solución es usar mySQL Administrator 1.1 u otra herramienta que fuerce una codificación de los datos UTF-8.

How do I restore a backup of my whole Moodle site?

If you have followed the above instructions and created a backup of a moodle site, you may need to know how to restore the site backup you created. Here is a set of basic steps that make up the restore process.

1. Rename the original moodledata directory to something different (so you still have it) and copy the backed up moodledata directory in its place.

2. Rename the original moodle directory to something different (so you still have it) and copy the backed up moodle directory or a newly downloaded moodle directory in its place.

3. If you are running mysql, a backup of the database should be a .sql, .gz or .tar.gz file. If it is .tar.gz or .gz you need to extract it until it is an sql file.

tar -xzvf moodlesqlfile.tar.gz

4. If you are running mysql, import the sql file back into a newly created database on the mysql server. Be careful here, some backups try to import right back into the same working database that moodle is connected to. This causes database problems that damage a moodle installation. The best thing to do is make a new database, restore the backed up database into it, and change the moodle config.php file to connect to this new database (this way you still have the original database).

once you have created the new database:

mysql -p new_database < moodlesqlfile.sql

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.

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.

Restore still not working? See the next paragraph.

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.

Still XML error: how to clean xml borked file

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

Download the Atlassian XML Cleanr Utility from the 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 charachter 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.

Some of your courses weren't saved!!

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.

Restoring 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:

Make a clean install of Moodle 1.5.x (the latest version available)
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 any problems.

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.

External links

Repairing Database Corruption in MySQL

Documentation