Un site Joomla qui tombe parce que la base de données a été corrompue lors d'une mise à jour, ça arrive. Et quand ça arrive, la question n'est plus « comment sauvegarder ? » mais « quand ai-je fait ma dernière sauvegarde, et où est-elle ? ». Si la réponse est « hier soir, à la main, dans un dossier sur le serveur », vous avez un problème.
La base de données, c'est le cœur de votre Joomla : articles, menus, utilisateurs, extensions, configuration. Les fichiers du site, on peut souvent les retrouver dans une archive. La base, non. Et pourtant, c'est systématiquement ce qu'on oublie d'automatiser.
Points clés à retenir
- La base de données contient tout le contenu éditorial : sans elle, votre Joomla est une coquille vide.
- L'automatisation passe par deux voies : une extension (Akeeba Backup) ou un cron serveur avec mysqldump.
- Une sauvegarde qui reste sur le même serveur que le site ne protège de presque rien.
- La fréquence minimale décente est quotidienne, et impérativement juste avant une mise à jour.
- Une sauvegarde non testée n'est pas une sauvegarde, c'est un pari.
Pourquoi automatiser la sauvegarde de votre base de données Joomla (et pourquoi le manuel ne tiendra jamais)
J'ai animé pendant un an un site sous Joomla pour une association. Tout était fait à la main, une fois par semaine, le vendredi. Un vendredi, j'ai oublié. Le lundi suivant, une extension mal codée avait inséré des lignes vides dans la table des articles. Résultat : 340 articles affichés en double sur le front. J'avais une sauvegarde vieille de huit jours, et quatre jours de publications parties en fumée.
Voilà le vrai argument pour l'automatisation : ce n'est pas la flemme, c'est la régularité que l'humain ne tient pas. Une sauvegarde planifiée à 3 h du matin ne rate pas son rendez-vous. Elle ne part pas en week-end. Elle ne se dit pas « je le ferai après cette réunion ».
Faut-il sauvegarder la base seule ou tout le site ?
Les deux, mais pas au même rythme. La base change tous les jours dès que vous publiez. Les fichiers du site, eux, ne bougent que lors d'une installation ou mise à jour d'extension. Un rythme correct : base en quotidien, fichiers complets en hebdomadaire.
Une base Joomla pèse rarement plus de quelques dizaines de Mo, souvent moins. L'archive complète d'un site avec ses images et ses extensions peut grimper à plusieurs centaines de Mo, voire plusieurs Go. Ce déséquilibre justifie à lui seul deux fréquences distinctes.
Deux voies pour automatiser : extension ou cron serveur
Il n'y a pas de « meilleure » méthode dans l'absolu. Il y a celle qui correspond à votre niveau technique et à votre hébergement. Je vais être franc : pour 80 % des utilisateurs Joomla, la voie de l'extension est la bonne. Pour les autres, le cron est plus propre et plus léger.
La voie Akeeba Backup : planifier depuis l'administration
Akeeba Backup reste la référence sur Joomla. Sa version gratuite permet déjà de planifier des sauvegardes automatiques, sans passer par l'interface de l'hébergeur. Concrètement :
- Créer un profil de sauvegarde dédié (par exemple « base seule, quotidien ») avec le type de contenu restreint à la base de données.
- Dans l'onglet Planification du profil, activer la sauvegarde automatique et choisir la fréquence (quotidienne, généralement).
- Configurer la rétention : combien d'archives conserver avant suppression des plus anciennes. Trois à cinq suffisent.
- Renseigner un stockage distant : dossier FTP, espace S3, Google Drive. C'est l'étape que tout le monde saute, et c'est l'erreur.
La planification Akeeba repose sur le déclenchement système de Joomla, qui nécessite que quelqu'un visite le site pour se réveiller, sauf si vous ajoutez un vrai cron sur ce dernier. Beaucoup l'ignorent, et se retrouvent avec des sauvegardes « planifiées » qui ne partent que lorsque le site reçoit du trafic. Sur un site à faible audience, la sauvegarde peut ainsi sauter plusieurs jours sans que personne ne s'en aperçoive.
La voie cron + mysqldump : la plus fiable si vous avez un accès shell
Une commande, une ligne de crontab, et c'est réglé. La commande de base ressemble à ceci :
mysqldump --single-transaction --routines --triggers -u monuser -pMonMotDePasse mabase | gzip > /home/user/backups/joomla_$(date +\%Y\%m\%d).sql.gzTrois options méritent qu'on s'y arrête :
- --single-transaction : verrouille la base de façon cohérente pendant l'export, sans bloquer les écritures. Indispensable sur un site en production.
- --routines et --triggers : sans ces options, vos procédures stockées et déclencheurs ne sont pas exportés. Rare sur Joomla, mais ça arrive avec certaines extensions métier.
- La compression gzip : divise le poids d'un fichier SQL par cinq à dix. Un dump de 200 Mo tombe à 25 Mo.
Le mot de passe en clair dans la crontab, c'est moyen. Le réflexe propre : créer un fichier .my.cnf dans le home, y mettre les identifiants, le passer en chmod 600, et appeler mysqldump --defaults-extra-file=/home/user/.my.cnf. La commande ne contient alors plus aucun secret.
Configurer le cron chez l'hébergeur
Si vous êtes sur cPanel, OVH, Plesk ou équivalent, vous avez une interface de tâches planifiées. Vous y collez la commande, vous choisissez la fréquence, terminé. Les pièges : le chemin absolu vers mysqldump (souvent /usr/bin/mysqldump ou /usr/local/mysql/bin/mysqldump), et les variables d'environnement absentes dans le contexte cron.
Un conseil que j'ai appris à la dure : faites un test en planifiant la commande à une minute dans le futur, attendez, et vérifiez que le fichier existe vraiment. Un cron qui affiche « exécuté » dans l'interface ne garantit rien. La première fois que j'en ai configuré un, la tâche tournait bien, mais écrivait dans un dossier différent de celui que je surveillais. J'ai cru pendant une semaine que rien ne fonctionnait.
Comparaison des deux approches
Le tableau ci-dessous vaut ce qu'il vaut, mais il résume mon expérience sur une dizaine de sites.
| Critère | Akeeba Backup | Cron + mysqldump |
|---|---|---|
| Niveau technique requis | Faible | Moyen à élevé |
| Sauvegarde de la base seule | Oui, via profil restreint | Oui, nativement |
| Fiabilité de la planification | Dépend du trafic ou d'un cron ajouté | Totale |
| Poids de l'extension | Quelques Mo installés | Aucun |
| Envoi vers stockage distant | Intégré (S3, Drive, FTP) | À scripter (rclone, aws cli) |
| Restauration simple | Interface graphique | Import manuel du .sql |
Le point qui fait basculer le choix : la restauration. Restaurer une base via phpMyAdmin sur un dump de 150 Mo peut dépasser le temps d'exécution maximum autorisé par PHP et échouer en pleine import. L'outil en ligne de commande mysql n'a pas cette limite. Si vous avez déjà le shell, faites tout en shell.
Les trois règles qui font la différence entre une vraie et une fausse sauvegarde
Sortir les sauvegardes du serveur
Une sauvegarde stockée dans /home/user/backups sur le même serveur que le site ne protège que d'une chose : une erreur humaine sur le site. Elle ne protège ni d'une panne matérielle, ni d'une suppression de compte hébergeur, ni d'un piratage qui aurait les droits du compte.
Au minimum, un transfert quotidien vers un espace distant. Un simple rclone copy vers un bucket S3 ou un Drive fait très bien le travail, à condition de ne pas oublier d'ajouter cette commande dans le même cron, juste après le dump.
Faire tourner les fichiers
Cent sauvegardes quotidiennes d'une base de 40 Mo, ça fait 4 Go de dumps qui dorment, plus le coût de stockage distant. La rotation est simple : une commande find /home/user/backups -name "*.sql.gz" -mtime +14 -delete lancée chaque jour garde les quatorze derniers jours et supprime le reste.
Tester la restauration
C'est la partie ennuyeuse. C'est aussi celle qui compte. Une sauvegarde jamais restaurée est une promesse non vérifiée. Le test minimal : créer une base vide sur le serveur, importer le dernier dump, vérifier que Joomla démarre avec une configuration pointant dessus.
J'ai découvert sur un projet que mes dumps étaient corrompus depuis trois semaines parce que le disque était plein et que gzip écrivait des fichiers tronqués sans erreur visible. Personne ne s'en était rendu compte. Trois semaines de fausses sauvegardes quotidiennes, zéro alerte.
Quelle fréquence, et le cas particulier des mises à jour
Quotidien est un bon défaut. Mais il y a un moment où il faut une sauvegarde à la demande, sans attendre le cron : avant chaque mise à jour de Joomla ou d'une extension. Une mise à jour qui casse une table, ça se répare vite si vous avez un point de restauration pris cinq minutes plus tôt.
Sur ce point, Akeeba gagne largement : son bouton « sauvegarde avant mise à jour » est justement conçu pour ça. Avec mysqldump, c'est une commande manuelle à lancer. Ni l'un ni l'autre ne vous dispense d'un minimum de discipline.
Ce qui reste, au fond : l'automatisation couvre la routine, pas l'accident. Le vrai travail, c'est de s'assurer que le mécanisme tourne vraiment, que les fichiers arrivent vraiment ailleurs, et qu'un jour vous avez vraiment réussi à les remettre en place. Le reste, c'est du confort.
Et si vous ne deviez retenir qu'une chose : la sauvegarde de votre base Joomla n'a de valeur que le jour où vous en avez besoin. Ce jour-là, ce n'est pas la configuration qui vous aidera, c'est le fichier. Assurez-vous qu'il existe, qu'il est récent, et qu'il est intact. Vérifier ça une fois, tranquillement, un mardi matin, vaut mieux que de le découvrir à 22 h un soir de mise à jour ratée.
