Manuel:Faire la sauvegarde d'un wiki

This page is a translated version of the page Manual:Backing up a wiki and the translation is 97% complete.
Outdated translations are marked like this.

Il est important d'effectuer régulièrement la sauvegarde de votre wiki (données et fichiers). Cette page donne un aperçu du processus de sauvegarde d'un wiki MediaWiki standard ; vous aurez probablement à cœur de concevoir vos propres scripts de sauvegarde ou de les planifier en fonction de la taille de votre wiki et de vos propres besoins.

Aide:Export est une manière rapide et facile de sauvegarder toutes les pages sur votre wiki.

Présentation générale

MediaWiki stocke les données importantes à deux endroits :

la base de données
les pages et leur contenu, les utilisateurs et leurs préférences, les métadonnées, l'index pour la recherche, etc.
le système de fichiers
les fichiers de configuration logicielle, les habillages personnalisés, les extensions, les images (y compris les images effacées), etc.

Pensez bien à passer le wiki en mode « lecture seule » avant de créer la sauvegarde - voir $wgReadOnly . Ceci permet d'assurer la cohérence de toutes les parties de votre sauvegarde (certaines des extensions que vous avez installées peuvent éventuellement écrire des données).

Transfert de fichiers

Vous devrez choisir une méthode de transfert des fichiers à partir du serveur où ils se trouvent :

  • Données non-privées : vous pouvez simplement publier sur archive.org et.ou dans un répertoire dumps/ de votre serveur web.
  • SCP (ou WinSCP), SFTP/FTP, autres méthodes, il y en a toute une liste sur Wikipédia.
  • l'hébergeur professionnel peut aussi mettre à votre disposition une interface de gestion de fichiers utilisable dans un navigateur web, vérifiez auprès de votre interlocuteur.

Base de données

La plupart des données critiques d'un wiki sont stockées dans la base de données. Si votre wiki est actuellement déconnecté sa base de données peut être sauvegardée simplement en copiant le fichier de base de données.

Si vous utilisez par défaut un serveur MySQL ou MariaDB, la base de données peut être vidée sous forme de dump dans un fichier script qui peut être utilisé ultérieurement pour recréer la base de données avec tout son contenu à partir d'une base vide.

MySQL

Automysqlbackup

Voir le paquet sous Debian :

$ apt show automysqlbackup
[...]
Description: automysqlbackup creates backup every day, week and month for all of your MySQL database, to a configured folder. There's nothing to do but to install this package, and you'll rest assured that you have a way to go back in the history of your database.
[...]

Installer le paquet :

# apt install automysqlbackup

Toutes vos bases de données seront sauvegardées dans /var/lib/automysqlbackup/:

$ find /var/lib/automysqlbackup/
/var/lib/automysqlbackup/
/var/lib/automysqlbackup/weekly
/var/lib/automysqlbackup/weekly/my_wiki
/var/lib/automysqlbackup/weekly/my_wiki/my_wiki_week.18.2016-05-07_15h32m.sql.gz
/var/lib/automysqlbackup/monthly
/var/lib/automysqlbackup/daily
/var/lib/automysqlbackup/daily/my_wiki

Sauvegarde manuelle:

# automysqlbackup

Restaurer une base de données:

gunzip < /var/lib/automysqlbackup/weekly/my_wiki/my_wiki_week.18.2016-05-07_15h32m.sql.gz|mysql -uUSER -pPASSWORD my_wiki

Pour les autres distributions, voir sur Sourceforge.

Mysqldump en mode ligne de commande

Le plus pratique pour créer un fichier dump de la base de données que vous souhaitez sauvegarder consiste à employer l'outil MySQL standard mysqldump en ligne de commande. Assurez-vous d'avoir bien initialisé les paramètres, sinon la restauration de la base de données risque d'être problématique. Mysqldump peut prendre un temps considérable, tout dépend de la taille de la base de données.

D'abord insérez cette ligne de code dans LocalSettings.php

$wgReadOnly = 'Dumping Database, Access will be restored shortly';

On peut la retirer une fois que le dump est terminé.

Exemple de commande à exécuter dans une interface shell Linux/UNIX :

mysqldump -h hostname -u userid -p --default-character-set=charset dbname > backup.sql

En remplaçant hostname, userid, whatever, et dbname comme il convient. Tous les quatre peuvent se trouver dans votre fichier (LSP) LocalSettings.php . hostname peut être trouvé sous $wgDBserver ; par défaut il vaut localhost. userid peut être trouvé sous $wgDBuser , whatever peut être trouvé sous $wgDBTableOptions , où il est listé après DEFAULT CHARSET=. Si whatever n'est pas spécifié mysqldump est sensé utilisé utf8 par défaut, ou latin1 sur une version plus ancienne de MySQL. Alors que dbname peut être trouvé sous $wgDBname . Après avoir exécuté la ligne de commande, mysqldump va demander le mot de passe du serveur (qui peut se trouver sous Manuel:$wgDBpassword dans LSP).

Lire mysqldump pour une liste complète des paramètres en ligne de commande.

Le résultat de mysqldump peut être préférentiellement gzippé, dans le but d'obtenir un fichier de plus petite taille, ainsi :

mysqldump -h hostname -u userid -p dbname | gzip > backup.sql.gz

Certaines des versions récentes de MySQL peuvent afficher une erreur avec les tablespaces et le privilège PROCESS. MédiaWiki n'utilise pas les tablespaces. La solution est d'ajouter l'option --no-tablespaces à la commande :

mysqldump --no-tablespaces -h hostname -u userid -p dbname | gzip > backup.sql.gz

Une commande mysqldump similaire peut être utilisée pour obtenir un fichier XML à la place, en incluant le paramètre --xml.

mysqldump -h hostname -u userid -p --xml dbname > backup.xml

et pour compresser le fichier sous la forme gzip avec un pipe '|'

mysqldump -h hostname -u userid -p --xml dbname | gzip > backup.xml.gz

Vous trouverez ci-après les options supplémentaires à prendre en compte pour l'utilisation de mysqldump pour faire une sauvegarde.

Options Mysqldump supplémentaires
Option Description
--default-character-set spécifier l'ensemble de caractères par défaut
--no-tablespaces ne pas écrire de déclarations CREATE LOGFILE GROUP ou CREATE TABLESPACE dans la sortie
--single-transaction générer une déclaration BEGIN SQL avant de vider les données du serveur
--triggers déclencheurs de vidage pour chaque table vidée
--routines vider les routines stockées (procédures et fonctions) de bases de données vidées
--events évènements de vidage de bases de données vidées
--add-drop-table ajouter une déclaration DROP DATABASE avant chaque déclaration CREATE DATABASE
--create-options inclure les options de table spécifiques à MySQL dans les déclarations CREATE TABLE
--extended-insert utiliser la syntaxe INSERT sur plusieurs lignes

Si vous n'utilisez pas la transaction --single vous devez vous servir des options des tables --lock et des verrous --add.

A cause d'une modification inattendue dans les versions 5.7.41 et 8.0.32 de MySQL en février 2023, l'option de transaction --single oblige que l'utilisateur qui fait la sauvegarde ait les droits RELOAD ou FLUSH_TABLES. Ce problème a été résolu dans les versions 5.7.42 et 8.0.33 de MySQL. Voir MySQL bogue 109685 et Ubuntu bogue 2003866 pour plus de détails.

Rappelez-vous d'archiver les composants supplémentaires du système de fichiers utilisé par le wiki et qui pourraient être indispensables pour une récupération, comme les images, le logo, les habillages et les extensions.

Exécuter mysqldump sous Cron

Cron est le planificateur de tâches des systèmes d'exploitation informatiques dérivés d'Unix. Cron permet aux utlisateurs de planifier des tâches (commandes ou scripts shell) à exécuter de manière répétée à certains moments ou à certaines dates.

Voici un exemple de commande que vous pouvez utiliser dans la crontab :

nice -n 19 mysqldump -u $USER --password=$PASSWORD $DATABASE -c | nice -n 19 gzip -9 > ~/backup/wiki-$DATABASE-$(date '+%Y%m%d').sql.gz

La commande nice -n 19 abaisse la priorité du processus.

Utilisez des valeurs valides pour $USER, $PASSWORD, et $DATABASE. Ça écrira un ficher de sauvegarde avec le jour de la semaine dans le nom du fichier, de sorte à disposez d'un ensemble de roulement des sauvegardes. Si vous désirez également sauvegarder les fichiers et les extensions, vous pouvez utiliser celui-ci.

  Avertissement : N'essayez pas de sauvegarder votre base de données Mediawiki en utilisant mysqlhotcopy. Le format des tables utilisé par Mediawiki ne peut pas être sauvegardé avec cet outil, et l'échec est silencieux !

Si vous voulez ajouter cette tâche dans le Cron via Cpanel alors vous devez protéger le caractère « % » en l'échappant

/usr/bin/mysqldump -u $USER --password=$PASSWORD $DATABASE -c | /bin/gzip > ~/backup/wiki-$DATABASE-$(date '+\%Y\%m\%d').sql.gz

sinon vous aurez une erreur :

/bin/sh: -c: line 0: unexpected EOF while looking for matching `''
/bin/sh: -c: line 1: syntax error: unexpected end of file

Exécuter mysqldump avec Systemd

Systemd unifie les configurations et le contrôle des services. Les minuteries (timers) sont des fichiers unitaires de systemd qui contrôlent les fichiers de service ou les événements. Les temporisations peuvent être utilisées comme une alternative à cron. Un exemple de fichiers unitaires et de script de sauvegarde systemd est présenté ci-dessous.

wiki-backup.timer

La minuterie suivante lance le service de sauvegarde du wiki chaque matin à 5H10.

$ cat /etc/systemd/system/wiki-backup.timer

[Unit]
Description=Run the backup service once a day
Documentation=...

[Timer]
OnCalendar=*-*-* 05:10:00
RandomizedDelaySec=600
Persistent=true

[Install]
WantedBy=timers.target
wiki-backup.service

Le service est invoqué lorsque la temporisation de sauvegarde du wiki expire. Le service exécute un script situé dans /sbin.

$ cat /etc/systemd/system/wiki-backup.service

[Unit]
Description=Run the backup service once a day
Documentation=...

[Service]
Type=oneshot
User=root
ExecStart=/sbin/wiki-backup
wiki-backup script
$ cat /sbin/wiki-backup

#!/usr/bin/env bash

# Systemd adds random paths at times. Take full control of PATH.
PATH=/bin:/sbin:/usr/bin:/usr/sbin
export PATH

# Read the backup password from conf or ini Failed
wiki_password=...

# Fix the wiki tables just in case. This step produces a lot of noise,
# so send stdout to /dev/null.
if MYSQL_PWD="${wiki_password}" \
   mysqlcheck my_wiki --auto-repair --user=mwuser 1>/dev/null;
then
    echo "Repair wiki database ok"
else
    echo "Failed to repair wiki database"
    echo "Continuing anyways"
fi

# Disable the connection from Apache to MySQL for the dump
if ! systemctl stop apache2.service ;
then
    echo "Failed to stop Apache service"
    echo "Continuing anyways"
fi

# Lock option choice due to MySQL change at versions 5.7.41 and 8.0.32 in
# February 2023. See https://bugs.mysql.com/bug.php?id=109685 and
# https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/2003866.
if mysql --version 2>&1 | grep -q -E 'mysql[[:space:]]+Ver 8\.0\.32'; then
   echo "Using MySQL --lock-tables --add-locks options"
   mysql_lock_opt="--lock-tables --add-locks"
else
   echo "Using MySQL --single-transaction option"
   mysql_lock_opt="--single-transaction"
fi

if MYSQL_PWD="${wiki_password}" \
   mysqldump --no-tablespaces \
     ${mysql_lock_opt} \
     --events --triggers --routines \
     --add-drop-table --create-options \
     --extended-insert \
     --default-character-set=utf8 \
     -u mwuser -h localhost my_wiki | gzip -q -v9 > /backup/wiki-backup.sql.gz ;
then
    echo "Dump wiki database ok"
else
    echo "Failed to dump wiki database"
    echo "Continuing anyways"
fi

# Re-enable connection from Apache to MySQL for the dump
if ! systemctl start apache2.service ;
then
    echo "Failed to start Apache service"
    echo "Continuing anyways"
fi

exit 0

Tables

Certaines tables que vous videz ont différents degrés de temporalité. Donc pour économiser de l'espace disque (en plus de compresser par gzip), bien que ces tables doivent être présentes dans un vidage plus propre, leur données n'ont pas besoin de l'être. Néanmoins, sous certaines circonstances le désavantage d'avoir à reconstruire toutes ces données peut contre-balancer l'économie d'espace disque (par exemple, sur un grand wiki où la vitesse de restauration est cruciale).

Voir le fil de la liste de diffusion mysql5 binary schema (schéma binaire mysql5) relatif au sujet.

Conversion de Latin-1 à UTF-8

Voir la section relative de la page de mise à jour pour toute information concernant le processus. Voir aussi la page de discussion pour davantage d'informations sur l'utilisation des alphabets en général.

PostgreSQL

Vous pouvez utiliser l'outil pg_dump pour sauvegarder une base de données PostgreSQL de MediaWiki. Par exemple :

pg_dump mywiki > mywikidump.sql

videra la base de données mywiki dans mywikidump.sql.

Pour restaurer la sauvegarde :

psql mywiki -f mywikidump.sql

Vous pouvez aussi vider les informations globales, par exemple les utilisateurs de la base de données :

pg_dumpall --globals > postgres_globals.sql

SQLite

Si votre wiki n'est pas actuellement en ligne, sa base de données peut être sauvegardée simplement en copiant le fichier de base de données. Sinon, vous devez utiliser le script de maintenance : php maintenance/SqliteMaintenance.php --backup-to <backup file name>, qui assurera que l'opération est atomique et qu'il n'y a pas d'incohérences. Si votre base de données n'est pas très grande et n'est pas surchargée, les utilisateurs qui modifient le wiki ne s'apercevront de rien à part d'une faible latence. Les utilisateurs qui ne font que la lecture ne s'appercevront de rien dans tous les cas.

phpMyAdmin

Mettez votre wiki en mode lecture-seule en ajoutant $wgReadOnly = 'Site Maintenance'; à votre fichier LocalSettings.php.

Chercher la base de données du wiki dans LocalSettings.php. Exemple de l'apparence dans LocalSettings.php :

## Database settings
$wgDBtype           = "mysql";
$wgDBserver         = "localhost";
$wgDBname           = "sashtmax_mw19999";
$wgDBuser           = "sashtmax_mw19999";
$wgDBpassword       = "S7[88p]jJJ";
  1. Ouvrez le navigateur de votre lien phpadmin, connectez-vous et sélectionnez la base de données du wiki.
  2. Sélectionnez Exporter. Assurez-vous que tous les éléments de Exporter sont sélectionnés, et que Structure est aussi sélectionné (il est important de maintenir la structure de la table). Facultatif : cochez Ajouter DROP TABLE pour effacer les références existantes lors de l'importation. Assurez-vous que Data est coché.
  3. Sélectionnez compressé.
  4. Puis cliquez sur GO et sauvegardez le fichier de backup.[1]
  5. Retirez $wgReadOnly = 'Site Maintenance'; de votre fichier LocalSettings.php

N'oubliez pas non plus de sauvegarder les composants du système de fichiers qui pourraient être nécessaires, par exemple les images, le logo et les extensions.

Liens externes

HeidiSQL (alternative to phpMyAdmin)

HeidiSQL est similaire à phpMyAdmin, mais sans aucune restriction de la version libre de phpMyAdmin. HeidiSQL nécessite une connexion directe à la base de données, pour lesquels certains hôtes n'offrent seulement que des interfaces web (phpMyAdmin) vers les bases de données via proxy.

Système de fichiers

MediaWiki enregistre les autres composants du wiki dans le système de fichiers.

Les plus importants de ceux-ci sont :

  • LocalSettings.php
  • les fichiers téléversés dans le répertoire images/ (y compris les fichiers supprimés, les vignettes, et les formules mathématiques générées ainsi que les images SVG, selon le cas).

La meilleure méthode pour les sauvegarder est de les placer dans un fichier archive , en tant que fichier .tar , qui peut ensuite être compressé si vous le désirez. Sous Windows, vous pouvez utiliser les applications telles que WinZip ou 7-zip.

Pour les variantes Linux, en supposant que le wiki est rangé dans /srv/www/htdocs/wiki

tar zcvhf wikidata.tgz /srv/www/htdocs/wiki

Vous devriez pouvoir sauvegarder le répertoire « wiki » entier dans « htdocs » en utilisant XAMPP.

Fichiers de configuration

LocalSettings.php est le plus important d'entre eux, mais un wiki pourrait aussi avoir des choses comme .htaccess ou d'autres fichiers de configuration de serveur web qui devraient être sauvegardés.

Fichiers téléversés

Les fichiers téléversés dans le wiki sont par défaut rangés dans le répertoire images/ et séparés en sous-dossiers comme images/8/8f. Il existe aussi d'autres répertoires comme images/archive/ et images/deleted/. Ils devraient tous être sauvegardés.

Le images/thumb/ peut être sauvegardé avec le reste, mais il est possible de l'exclure facultativement pour économiser de la place. Ce répertoire stocke les vignettes dérivées des images et autres fichiers; en général, il y a plusieurs vignettes par fichier du wiki. Après une restauration à partir d'une sauvegarde, ces vignettes seront recréées si nécessaire (bien que, selon $wgGenerateThumbnailOnParse , il puisse s'agir d'un processus manuel).

Sauvegarder le contenu du wiki (vidage XML)

Il est bon aussi de créer un vidage XML en plus du vidage de la base de données. Les vidages XML contiennent le contenu du wiki (les pages du wiki et toutes leurs versions), sans les données relatives du site (elle ne contiennent pas les comptes utilisateurs, les méta-données des images, les journaux, etc). [2]

Les vidages XML sont moins sensés causer de problèmes avec l' encodage des caractères, que de pouvoir transférer de grandes quantités de contenu rapidement, et peuvent facilement être utilisés par des outils tiers, qui font que les vidages XML sont une bonne solution de repli si la sauvegarde principale de votre base de données venait à devenir inutilisable.

Pour faire un vidage XML, utilisez l'outil en mode ligne de commande dumpBackup.php , situé dans le répertoire maintenance de votre installation MediaWiki. Voir Manuel:DumpBackup.php pour plus d'informations.

Vous pouvez aussi créer un vidage XML pour un ensemble particulier de pages en ligne, en utilisant Special:Export, bien qu'essayer de vider de grandes quantités de pages via cet interface risque de se terminer par un dépassement du temps limite autorisé pour l'opération.

Pour importer un vidage XML dans un wiki, utilisez l'outil de commande en ligne importDump.php . Pour un petit nombre de pages, vous pouvez aussi utiliser la page Special:Import via votre navigateur (par défaut, cette fonction est restreinte au groupe sysop).

Voir Manuel:Importer les dumps XML pour plus d'information.

Sans accès au shell du serveur

MediaWiki Dump Generator

Si vous n'avez pas d'accès au shell, utilisez le script dumpgenerator de MediaWiki Dump Generator des Outils clients de MediaWiki. Il est exécuté depuis la ligne de commande dans un terminal.

Le vidage XML peut inclure l'historique complet, ou seulement celui des pages les plus récentes. Le vidage des images contiendra tous les types de fichiers avec les descriptions associées. Les fichiers siteinfo.json et SpecialVersion.html contiendront des informations à propos de fonctionnalités de wiki comme les extensions installées et les habillages. Les informations des comptes utilisateur ne seront pas conservées.

Les instructions complètes se trouvent dans le dépôt GitHub MediaWiki Dump Generator des outils des clients MédiaWiki.

Voir aussi Meta:Data dumps.

Scripts

  Avertissement : Utilisez-les à votre propre risque. Vérifiez dans LocalSettings.php de votre wiki, l'ensemble correct des caractères à utiliser, parce que vous pourriez avoir à corriger le script pour cette valeur.
  • Script de sauvegarde non officiel de Flominator; crée une sauvegarde de tous les fichiers et de la base de données, avec une rotation optionnelle sur les sauvegardes. Shell script, last updated 2012.
  • Un autre script de sauvegarde qui: vide la base de données, les fichiers (par défaut juste les images, option pour inclure tous les fichiers de l'installation), et XML; met le site en mode lecture seule; sauvegardes horodatées; dans LocalSettings il trouve la famille des caractères utilisés. Le script n'a pas besoin d'être modifié pour chaque site à sauvegarder. Ne fait pas (encore) de rotation sur les sauvegardes. Utilisation : backup.sh -d backup/directory -w installation/directory. Fournit également un script pour restaurer une sauvegarde restore.sh -a backup/directory/dated_archive.tar.gz -w installation/directory. Script shell, dernière mise à jour en 2013.
  • User:Darizotas/MediaWiki Backup Script for Windows - un script pour sauvegarder une installation MediaWiki de Windows. Note: il n'y a pas pas de fonction de restauration. Script shell, dernière mise à jour en 2015.
  • script non officiel de sauvegarde par User:Duesentrieb. Script shell, dernière mise à jour en 2016.
  • Script pour faire des sauvegardes périodiques mw_backup. Ce script fait des sauvegardes de votre base de données et du répertoire d'images de manière quotidienne, hebdomadaire, ou mensuelle lorsqu'il est lancé en tant que tâche de cron journalière. Script PHP, dernière mise à jour en 2017.
  • Un autre script de sauvegarde MediaWiki pour Windows non officiel par Lanthanis qui exporte les pages des espaces de noms spécifiés en tant que fichier XML; vide les tables spécifiées de la base de données; et ajoute les répertoires supplémentaires et les fichiers spécifiés à un ficher ZIP de sauvegarde. Peut être utilisé avec le planificateur de tâches de Windows. Dernière mise à jour en 2019.
  • outils WikiTeam - si vous n'avez pas accès au serveur (par exemple votre wiki fait partie d'une ferme libre de wikis), vous pouvez générer un vidage XML et un vidage des images en utilisant l'outil dumpgenerator des outils WikiTeam (Python 2). Voir certains wikis sauvegardés. Script Python 2.
  • MediaWiki Dump Generator - si vous n'avez pas accès au serveur (par exemple votre wiki fait partie d'une ferme ouverte de wikis), vous pouvez générer un vidage XML et un vidage des images en utilisant l'outil dumpgenerator des outils Client MediaWiki, script Python 3, dernière mise à jour en 2023.

Extensions

  • Extension:DumpsOnDemand – Permet aux utilisateurs de générer et de télécharger les vidages de bases de données
  • Extension:DataDump – Permet aux utilisateurs de générer et de télécharger le XML et le fichier ou l'image

Voir aussi

Références

  1. Manual talk:Backing up a wiki#Ubuntu 10.10 - Step by Step Instructions
  2. Les vidages XML sont indépendants de la structure de la base de données, et peuvent être importés dans les versions futures (et mêmes les anciennes) de MediaWiki.