Sauvegarder MySQL ou MariaDB avec mysqldump sans se piéger

mysqldump reste l’un des outils les plus pratiques pour sauvegarder une base MySQL ou MariaDB lorsque l’on veut un fichier SQL portable, lisible et simple à restaurer. Il convient très bien aux sites, petits services, environnements de recette et migrations maîtrisées. En revanche, il ne remplace pas toujours une stratégie de sauvegarde complète.

Le bon réflexe consiste à savoir ce que vous voulez protéger, combien de données vous pouvez perdre et combien de temps vous acceptez de rester hors ligne. Une commande qui produit un fichier ne suffit pas : une sauvegarde fiable doit être restaurable, datée, protégée et testée.

Quand utiliser mysqldump

mysqldump exporte la structure et les données sous forme d’instructions SQL. C’est une sauvegarde logique : elle se transporte facilement, se relit, se versionne parfois et se restaure sur une autre instance compatible.

L’outil est adapté aux bases modestes, aux migrations, aux exports ponctuels, aux copies de recette et aux sauvegardes applicatives simples. Il devient moins confortable sur des volumes très importants, des bases fortement sollicitées ou des exigences de reprise très courtes.

Pour les grosses plateformes, les snapshots de stockage, les sauvegardes physiques ou les solutions dédiées peuvent être plus efficaces. La question n’est pas de choisir un outil “meilleur”, mais de l’aligner avec le besoin de reprise.

Commencez par fixer deux repères : le volume de données acceptablement perdu et le temps maximal d’indisponibilité. Si vous pouvez perdre quelques heures de données et restaurer tranquillement, un dump nocturne peut suffire. Si chaque minute compte, il faut compléter avec réplication, journaux binaires ou sauvegardes physiques.

Un dump logique garde un avantage précieux : il permet de relire ce qui va être restauré. Sur un incident applicatif, vous pouvez parfois extraire une table, comparer deux versions ou récupérer une portion de données. Cette souplesse disparaît si vous ne conservez qu’une image brute du stockage.

Le choix courant ressemble donc à ceci : mysqldump pour la portabilité, snapshot pour la vitesse, réplication pour réduire la perte de données, puis tests réguliers pour prouver que l’ensemble fonctionne. Un site ou un petit service peut très bien démarrer avec mysqldump, à condition de documenter ses limites.

La commande de base à connaître

Pour exporter une base, la forme la plus simple reste : mysqldump -u utilisateur -p nom_base > sauvegarde.sql. Cette commande demande le mot de passe, puis écrit le dump dans un fichier. Pour un premier test, c’est suffisant.

En production, ajoutez souvent --single-transaction pour les tables InnoDB. Cette option permet d’obtenir une vue cohérente sans bloquer durablement les écritures. Ajoutez aussi --routines, --triggers et --events si votre application utilise procédures, déclencheurs ou événements.

Une commande plus réaliste ressemble donc à : mysqldump --single-transaction --routines --triggers --events -u backup -p nom_base > nom_base.sql. Adaptez-la à votre version et testez-la avant de l’automatiser.

Sur des tables MyISAM ou des moteurs non transactionnels, --single-transaction ne garantit pas la même cohérence. Il faut alors vérifier le moteur utilisé et accepter, si nécessaire, un verrouillage plus intrusif. Beaucoup d’erreurs viennent d’une commande copiée sans regarder le type réel des tables.

Évitez aussi de mélanger trop d’options sans raison. --add-drop-table facilite une restauration destructive, mais ce n’est pas toujours souhaitable. --databases inclut les instructions de création de base, ce qui change la façon de restaurer. Chaque option doit avoir un effet attendu.

Avant d’écrire le script définitif, lancez la commande sur une copie ou une base peu critique. Mesurez la durée, le poids du fichier, la charge serveur et les messages d’erreur. Cette étape évite de découvrir en pleine nuit qu’un dump bloque trop longtemps ou remplit le disque.

Pour approfondir ce point, consultez tflops ps5, qui traite plus précisément de tflops ps5, comprendre le chiffre sans se faire piéger.

Sauvegarder une ou plusieurs bases

Pour une seule base, indiquez simplement son nom. Pour plusieurs bases, utilisez --databases base1 base2. Pour toute l’instance, --all-databases existe, mais il faut l’utiliser avec prudence : la restauration sera plus large et peut embarquer des éléments système.

Le nom du fichier doit aider à comprendre son contenu : application, base, date, heure, environnement. Un fichier nommé dump.sql devient vite dangereux. Préférez un format lisible, par exemple site_prod_2026-07-01_0200.sql.gz.

Compressez les dumps volumineux avec gzip ou un outil équivalent. La compression réduit le stockage et accélère parfois les transferts. Elle ne remplace pas le chiffrement si le dump contient des données clients, comptes ou informations sensibles.

Si vous hébergez plusieurs applications sur la même instance, séparez les dumps par projet quand c’est possible. Restaurer une seule application devient plus simple, la rotation est plus lisible et vous limitez le risque de manipuler un fichier trop large pour l’incident réel.

Gardez aussi une trace du contexte : version de MySQL ou MariaDB, hôte, base source, utilisateur de sauvegarde, taille finale, durée et somme de contrôle. Ces informations semblent secondaires le jour où tout marche. Elles deviennent utiles quand il faut comprendre pourquoi deux dumps n’ont pas le même comportement.

Restaurer sans casser la production

La restauration se teste d’abord hors production. Créez une base de recette, importez le dump, vérifiez les tables, le nombre de lignes, les vues, les routines et le comportement applicatif. C’est ce test qui transforme un fichier SQL en vraie sauvegarde.

La commande classique est : mysql -u utilisateur -p nom_base < sauvegarde.sql. Si le dump contient les instructions de création de base, vous pouvez restaurer différemment. Lisez toujours les premières lignes du fichier avant de l’injecter.

En production, ne restaurez jamais “pour voir”. Vérifiez le bon serveur, la bonne base, le bon fichier et le bon utilisateur. Une erreur de cible peut écraser des données actuelles. La restauration doit suivre une procédure écrite.

Un bon test de restauration ne se limite pas au message “import terminé”. Contrôlez les tables critiques, quelques requêtes métier, les comptes applicatifs, les index et la présence des objets non visibles au premier regard. Une application peut démarrer puis échouer sur une tâche planifiée oubliée.

Si vous restaurez après une suppression accidentelle, évitez de remplacer toute la base trop vite. Restaurez le dump dans une base temporaire, récupérez les lignes ou tables nécessaires, puis réinjectez uniquement ce qui manque. Cette méthode réduit le risque d’effacer des données plus récentes.

Préparez enfin le retour arrière. Avant une restauration destructive, prenez un dump de l’état actuel, même mauvais. Il servira de filet si le fichier choisi n’est pas le bon ou si l’incident a été mal diagnostiqué.

Gérer les mots de passe proprement

Évitez les mots de passe directement dans la ligne de commande. Ils peuvent se retrouver dans l’historique shell, les logs ou la liste des processus. Utilisez plutôt un fichier d’options protégé, un compte de sauvegarde dédié ou le mécanisme recommandé dans votre environnement.

Le compte de sauvegarde doit avoir les droits nécessaires, pas plus. Inutile de sauvegarder avec un superutilisateur si un compte limité suffit. En cas de compromission, le principe du moindre privilège limite l’impact.

Protégez aussi les fichiers produits. Un dump peut contenir des mots de passe hashés, des emails, des commandes, des tokens ou des données personnelles. Stocker ces fichiers en clair dans un dossier public serait une faute de sécurité.

Vérifiez les permissions du dossier de destination. Un dump créé par cron avec des droits trop ouverts peut exposer toute la base à un autre utilisateur système. Dans un hébergement partagé, ce point devient un contrôle prioritaire.

Pensez également aux transferts. Si le fichier part vers un stockage distant, utilisez un canal fiable et chiffrez ce qui doit l’être. La sauvegarde ne doit pas créer une nouvelle fuite de données sous prétexte qu’elle protège contre la panne.

Automatiser sans oublier la surveillance

Un cron qui lance mysqldump toutes les nuits est utile, mais il ne suffit pas. Il faut vérifier le code retour, la taille du fichier, la date de création, l’espace disque, la compression, le transfert et la rotation. Une sauvegarde silencieusement vide peut donner une fausse sécurité.

Conservez plusieurs générations. Un dump de la nuit dernière ne sert pas si la corruption date d’une semaine. Définissez une rétention simple : quotidien court terme, hebdomadaire moyen terme, mensuel si nécessaire. Adaptez selon le volume et le risque métier.

Envoyez une copie hors serveur : stockage objet, serveur de sauvegarde, espace chiffré ou autre site. Si le serveur principal est supprimé, chiffré ou compromis, une sauvegarde restée au même endroit peut disparaître avec lui.

Une surveillance utile envoie une alerte quand le dump échoue, mais aussi quand il réussit trop vite, devient anormalement petit ou n’a pas été transféré. Ces signaux faibles repèrent une base vide, un mauvais nom de base, un accès refusé ou un disque saturé.

Planifiez aussi une restauration de contrôle, par exemple chaque mois ou après une modification importante de l’application. Ce rendez-vous oblige à vérifier la chaîne complète : commande, fichier, stockage, documentation, droits et temps réel de reprise.

Construire une procédure de reprise

La meilleure commande ne suffit pas si personne ne sait quoi faire pendant l’incident. Écrivez une procédure courte : où sont les dumps, comment choisir le bon fichier, quelle base restaurer, qui valide la bascule et comment prévenir les utilisateurs.

Cette procédure doit distinguer restauration complète, restauration partielle et simple extraction de données. Les trois scénarios n’ont pas le même risque. Une base corrompue demande parfois un remplacement complet ; une table supprimée demande plutôt une récupération ciblée.

Indiquez aussi les commandes de vérification. Par exemple : lister les tables, compter les lignes principales, tester une connexion applicative, ouvrir une page clé, lancer une tâche planifiée. Plus les contrôles sont concrets, moins la reprise dépend de la mémoire de la personne disponible.

Après chaque test ou incident, corrigez la procédure. Si une option manquait, si un chemin était faux ou si le temps de restauration a doublé, notez-le. Une sauvegarde fiable est un processus vivant, pas une commande figée dans un wiki oublié.

Cas d’un site web ou d’un serveur de jeu

Sur un site web, la base contient souvent les comptes, commandes, commentaires, réglages et contenus dynamiques. Sur un serveur de jeu ou un outil communautaire, elle peut contenir inventaires, scores, permissions ou historiques. Dans les deux cas, le dump protège l’état réel du service.

Le piège courant consiste à sauvegarder seulement les fichiers. Un thème, un plugin ou une configuration se récupère parfois. Les données vivantes, elles, sont plus difficiles à reconstruire. Associez donc sauvegarde des fichiers et sauvegarde de la base dans le même plan.

Avant une mise à jour majeure, un changement de plugin, une migration d’hébergement ou une modification de schéma, lancez un dump manuel identifié. Ce point de retour évite de dépendre uniquement de la sauvegarde nocturne, qui peut être trop ancienne pour revenir proprement.

Pour une petite équipe, la bonne pratique est simple : un dump avant changement risqué, une sauvegarde programmée, une copie hors serveur et un test périodique. Ce n’est pas spectaculaire, mais c’est ce qui transforme une panne en opération maîtrisable.

Erreurs fréquentes à éviter

La première erreur est de ne jamais tester la restauration. La deuxième est d’oublier les routines, événements ou triggers. La troisième est de stocker le dump au même endroit que la base. La quatrième est d’automatiser sans alerte.

Autre piège : restaurer un dump ancien sur une base récente sans plan de retour arrière. Dans certains cas, il vaut mieux restaurer dans une nouvelle base, comparer, puis basculer seulement ce qui doit l’être. Cela évite la perte de données récentes.

Enfin, documentez les commandes. Le jour où la base tombe, ce n’est pas le moment de chercher dans l’historique terminal. Un fichier de procédure court, relu et testé vaut souvent mieux qu’un script complexe que personne ne comprend.

mysqldump est un excellent outil pour sauvegarder et restaurer MySQL ou MariaDB quand il est utilisé avec méthode. La commande compte, mais la vraie valeur vient du test de restauration, de la protection du fichier, de la surveillance et de la capacité à redémarrer calmement.

Si vos données sont critiques, traitez la sauvegarde comme un scénario de jeu difficile : vous ne gagnez pas parce que vous avez un objet dans l’inventaire, mais parce que vous savez quand et comment l’utiliser.

Pour approfondir ce point, consultez défauts entretien embauche, qui traite plus précisément de défauts en entretien d’embauche à présenter sans se piéger.