Backups MediaWiki : stratégie + restauration testée (PRA)

Backups MediaWiki : stratégie + restauration testée (PRA)

Quand un wiki tombe (erreur humaine, disque plein, mise à jour ratée), ce n’est pas le moment d’improviser. Une sauvegarde MediaWiki utile, c’est une sauvegarde restaurable, testée et répétable.

Dans cet article : quoi sauvegarder, à quelle fréquence, comment automatiser, et surtout comment valider une restauration.

Ce qu’il faut sauvegarder (et pourquoi 1 seul dump ne suffit pas)

MediaWiki stocke vos données critiques dans deux endroits :

1. La base de données

• pages, historiques, comptes, droits, journaux, paramètres…

1. Les fichiers qui évoluent

• images/ (uploads)
• LocalSettings.php (configuration)
• extensions/ et skins/ (si vous avez du custom)

Si vous ne sauvegardez que la base, vous perdez les médias. Si vous ne sauvegardez que les fichiers, vous perdez le contenu.

Pour l’installation en conteneurs, vous voulez au minimum :

• un dump SQL (compressé)
• une archive des volumes (ou des dossiers bind-mount)
• une procédure de restauration exécutée au moins une fois sur un environnement isolé

Objectifs RPO / RTO : choisir une fréquence réaliste

Deux notions simples pilotent votre stratégie :

• RPO (perte de données acceptable) : 24h ? 1h ? 15 min ?
• RTO (temps de retour en service) : 2h ? 30 min ?

Exemples usuels :

• wiki interne « documentation » : RPO 24h, RTO 2–4h
• wiki client / support : RPO 1h, RTO 1h

Sur adgents.cloud, vous pouvez aller jusqu’à des backups horaires et choisir une rétention longue (jusqu’à 10 ans), ce qui simplifie beaucoup la vie côté conformité et reprise.

➡️ Si vous hébergez MediaWiki : découvrez la page application MediaWiki sur adgents.cloud.

Mettre le wiki en lecture seule le temps du dump

L’objectif est d’éviter un dump incohérent (écritures en cours). La méthode classique consiste à activer temporairement le mode lecture seule :

// LocalSettings.php
$wgReadOnly = 'Maintenance en cours — merci de réessayer dans quelques minutes.';

Dès que la sauvegarde est finie, retirez cette ligne.

Sauvegarde SQL : commande fiable (MySQL/MariaDB)

Sur un setup Docker Compose, vous faites souvent le dump depuis un conteneur (ou via un réseau Docker). Exemple (à adapter) :

# Variables (exemples)
DB_HOST=127.0.0.1
DB_NAME=wikidb
DB_USER=wikiuser
BACKUP_DIR=/backups
DATE=$(date +%Y-%m-%d_%H%M)

mysqldump \
  --host="$DB_HOST" \
  --user="$DB_USER" -p \
  --single-transaction --no-tablespaces \
  "$DB_NAME" | gzip -9 > "$BACKUP_DIR/${DB_NAME}_${DATE}.sql.gz"

Pourquoi ces options :

• --single-transaction : snapshot cohérent (InnoDB)
• --no-tablespaces : évite des erreurs de droits sur certains MySQL

Sauvegarde des fichiers : ce qu’il faut archiver

Au minimum (en gardant les droits) :

cd /var/www/mediawiki
DATE=$(date +%Y-%m-%d_%H%M)
tar --numeric-owner -czf "/backups/wiki_files_${DATE}.tgz" \
  LocalSettings.php images extensions skins

Si vous gérez les données via des volumes Docker, assurez-vous de sauvegarder les bons volumes (uploads, éventuellement data de services annexes).

Automatiser : script + exécution planifiée

Une approche simple :

• dump SQL quotidien
• archive fichiers quotidienne (ou hebdo si volumineux)
• copie hors site (un autre stockage)

Gardez un dossier par date, et supprimez automatiquement au-delà de votre rétention.

Restauration : procédure courte et testable

Le vrai test d’une sauvegarde, c’est la restauration. Voici une séquence typique :

1) Restaurer la base

# Exemple : restaurer un dump SQL compressé
gunzip -c /backups/wikidb_2026-03-19_0200.sql.gz | mysql -u wikiuser -p wikidb

2) Restaurer les fichiers

# Exemple : restaurer l’archive des fichiers
tar -xzf /backups/wiki_files_2026-03-19_0200.tgz -C /var/www/mediawiki

3) Mettre à niveau le schéma si nécessaire

Si vous restaurez sur une version plus récente de MediaWiki, exécutez :

php maintenance/run.php update

4) Vérifier fonctionnellement

Checklist rapide :

• connexion admin
• recherche
• création/édition d’une page
• affichage d’une image existante
• upload d’un nouveau média

Deux pièges fréquents (et comment les éviter)

Piège 1 — Oublier images/

Sans images/, votre wiki « marche » mais tous les médias sont cassés. Sauvegardez et restaurez systématiquement ce dossier.

Piège 2 — Restaurer sans LocalSettings.php

LocalSettings.php contient les réglages (DB, cache, extensions, chemins). Gardez-le en lieu sûr et, si possible, versionnez-le dans un dépôt privé.

Vidéo (FR) : mysqldump, sauvegarde et restauration

Pour revoir la logique du dump SQL, voici un tutoriel en français :

Aller plus loin : performance et sécurité

• Pour une mise en place complète en conteneurs : Installer MediaWiki avec Docker Compose (prod)
• Pour réduire le risque d’incident : Sécuriser MediaWiki en production
• Pour garder un wiki réactif : MediaWiki performance : cache, DB, index, CDN

Héberger MediaWiki avec des backups simples à piloter

Si vous voulez une infra où le backup n’est pas une corvée :

• déploiement en 1 clic
• backups automatiques (jusqu’à 1 par heure)
• rétention longue
• scaling CPU/RAM

➡️ Voir MediaWiki sur adgents.cloud.