FAQ de sauvegarde
- Sauvegardes du site
- Les sauvegardes du site, comme il est expliqué dans la mise à jour de Moodle, sont recommandées, afin de pouvoir restaurer toutes les données avec le maximum de confiance et dans les plus brefs délais.
- Sauvegardes de cours
- Les sauvegardes de cours, configurées sur la page sauvegarde, coûtent davantage en terme de temps et d'utilisation du processeur. Le temps de restauration est également plus élevé pour retrouver votre site complètement fonctionnel. Les sauvegardes de cours sont utiles pour obtenir une copie fraîche de cours à réutiliser ou à distribuer individuellement. Elles ne devraient cependant pas être utilisées comme système de sauvegarde principal (à moins que votre hébergement ne vous permette pas d'autres solutions). Afin d'effectuer des sauvegardes planifiées, vous devrez configurer un cron à lancer périodiquement. Jetez un coup d'oeil à Mettre en place un cron pour de plus amples informations.
Comment sauvegarder la totalité de mon site ?
Il y a deux choses principales à copier : la base de données et les fichiers déposés. Les scripts de Moodle sont moins importants, puisque vous pouvez toujours en télécharger une copie, si nécessaire.
De nombreuses façons de procéder sont possibles pour effectuer de telles sauvegardes. Voici un bref descriptif d'un script que vous pouvez lancer sur Unix ou Mac OS X pour sauvegarder la base de données (c'est une bonne idée d'avoir un tel script qui tourne quotidiennement à l'aide d'un cron) :
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
Pour les fichiers, on peut utiliser rsync pour copier régulièrement sur une autre machine les fichiers ayant été modifiés depuis la dernière copie :
rsync -auvtz --delete -e ssh mysshusername@example.com:/my/server/directory /my/backup/directory/
Encodage des caractères
Lors de l'exportation de l'intégralité de la base de données de Moodle, les administrateurs doivent minutieusement contrôler si d'éventuels problèmes d'encodage de caractères surviennent. Dans quelques cas, les sauvegardes créées par le programme mysqldump ou par phpmyadmin n'encodent pas correctement toutes les données, ce qui entraîne l'affichage d'une quantité de caractères bizarres.
Une solution possible est l'ajout de l'option
--default-character-set=latin1
ou de
--default-character-set=utf8
à la commande mysqldump donnée ci-dessus. Une autre solution est l'utilisation du programme mySQL Administrator 1.1 ou d'un autre outil permettant l'exportation des données dans l'encodage UTF-8.
Quelles données ne sont pas comprises dans les sauvegardes de cours ?
En cochant toutes les options lors de la création de la sauvegarde, vous y inclurez presque toutes les données du cours. Il y a cependant quelques éléments qui ne sont pas sauvegardés :
- les questions d'une catégorie (module Test) ne sont sauvegardées que si au moins une question de leur catégorie a été ajoutée à un test du cours ;
- les barèmes ne sont sauvegardés que s'ils sont utilisés au moins dans une activité.
Error: An error occurred deleting old backup data
Cette partie de la procédure de sauvegarde (ou de restauration) essaie de supprimer des anciennes informations, utilisées lors de lancements précédents de la sauvegarde, en effectuant les tâches suivantes :
- suppression des anciens enregistrements de la table backup_ids : vérification que la table existe, réparation éventuelle et nouvel essai ;
- suppression des anciens enregistrements de la table backup_files: vérification que la table existe, réparation éventuelle et nouvel essai ;
- suppression des anciens fichiers du dossier moodledata/temp/backup : suppression de la totalité du dossier et nouvel essai.
Il y a plusieurs façons de réparer les tables, notamment en utilisant le programme MySQL Admin.
XML error: not well-formed (invalid token) at line YYYY
Ce problème peut survenir à n'importe quelle étape de la restauration. Il survient lorsque l'analyseur XML détecte dans le fichier de sauvegarde quelque chose d'incorrect qui empêche un fonctionnement normal de l'opération. Il s'agit habituellement de caractères non valides ajoutés au cours original par un couper/coller de texte contenant ces caractères spéciaux (caractères de contrôles, etc.).
La meilleure méthode pour traiter ce problème est la suivante :
- décompresser le fichier de sauvegarde problématique dans un dossier vide ;
- ouvrir le fichier moodle.xml dans Firefox ; ceci vous montrera le caractère exact où se situe le problème ;
- ouvrir le fichier moodle.xml dans un éditeur de texte compatible avec l'encodage UTF-8, supprimer les caractères non valides et enregistrer les modifications ;
- tester la validité du fichier moodle.xml en le rouvrant avec Firefox, en répétant l'opération ci-dessus jusqu'à ce qu'aucune erreur ne survienne ;
- recompresser le tout (tout le contenu du dossier, mais pas le dossier lui-même) ;
- restaurer le cours, et tout devrait se passer normalement.
Il est également vivement recommandé de résoudre le problème dans le cours original dans Moodle. Une fois le problème corrigé dans le Moodle, cette erreur n'arrivera plus lors de la création future d'autres fichiers de sauvegarde.
Certains de vos cours n'ont pas été sauvegardés !!
Il y a trois causes possibles à ce problème :
1. une erreur, qui arrive lorsque la procédure de sauvegarde a rencontré une erreur et n'a pas terminé la sauvegarde d'un cours. Ce sont des erreurs contrôlées et la sauvegarde continue avec le cours suivant ;
2. une interruption, qui arrive lorsque la procédure de sauvegarde se termine abruptement et anormalement. Lorsque le cron est lancé plus tard, il détecte que la dernière exécution s'est mal passée et continue en sautant le cours qui a causé la terminaison anormale. Une solution possible pourrait être l'élévation des limites de votre installation PHP/Apache (mémoire, durée d'exécution, etc.). En étudiant vos tables d'historiques, vous devriez voir si le crash arrive à des moments précis (il s'agit probablement dans ce cas d'un problème avec la variable php max_execution_time) ou si les sauvegardes se plantent à un endroit précis de chaque cours (indice d'un problème avec les bibliothèques internes de zip ; essayez avec les programmes externes).
3. un saut, qui arrive lorsqu'un cours n'est pas visible pour les étudiants et qu'il n'a pas été modifié depuis 31 jours. Pour économiser du temps de processeur, ces cours sont sautés à dessein. Ce n'est pas une erreur, mais une fonctionnalité particulièrement utile aux sites comportant beaucoup d'anciens cours invisibles, qu'il n'y a plus beaucoup de sens à sauvegarder.
Restauration de sauvegardes non-ISO-8859-1 (versions pre 1.6) vers Moodle 1.6 - Unicode
Les fichiers de sauvegarde ayant du contenu qui n'est pas à 100% encodé en ISO-8859-1 poseront problème lors de leur restauration vers les versions de Moodle 1.6 et ultérieures, qui tournent en Unicode. En cas de problèmes, veuillez plutôt essayer la procédure suivante :
- installez un Moodle 1.5.x tout neuf (la dernière version disponible) ;
- restaurez tous vos cours dans ce Moodle (cela devrait fonctionner sans problème, si la sauvegarde fonctionnait sur votre Moodle) ;
- mettez à jour ce site vers Moodle 1.6 et lancez le script de migration UTF-8 ;
- sauvegardez à nouveau vos cours.
Cette façon de faire produira un nouveau jeu de fichiers de sauvegarde 100% encodés en UTF-8, et vous serez alors en mesure de les importer sans aucune difficulté dans Moodle 1.6.
Voir aussi
- Discussion Backup and Restore (en anglais) sur Using Moodle
- Téléchargements Moodle : Intégrations, MySQL Admin à télécharger
Lien externe
- Repairing Database Corruption in MySQL (en anglais)