Comment sauvegarder une base de données MySQL avec MySQL Workbench

MySQL Workbench est un outil d’administration de bases de données visuel et multiplateforme qui inclut un utilitaire intégré d’exportation de données capable de générer des sauvegardes logiques complètes des bases de données MySQL et MariaDB sous forme de fichiers dump .sql portables. Une sauvegarde logique produite de cette façon capture à la fois le schéma DDL et les données DML sous forme d’instructions SQL simples, la rendant lisible par l’homme, compatible avec la gestion de versions, et restaurable sur n’importe quelle instance MySQL compatible, quel que soit le système d’exploitation ou le moteur de stockage.

Ce guide parcourt chaque étape du processus de sauvegarde — de la configuration initiale de la connexion jusqu’à la configuration de l’exportation, la vérification et l’automatisation — tout en couvrant les compromis architecturaux qui déterminent si l’outil d’exportation de MySQL Workbench est le bon choix pour votre environnement.

Pourquoi les sauvegardes logiques sont importantes (et quand elles ne suffisent pas)

La fonction d’exportation de données de MySQL Workbench encapsule l’utilitaire mysqldump dans une interface graphique. Cela signifie que la sortie est une sauvegarde logique : un ensemble séquentiel d’instructions SQL (CREATE TABLE, INSERT INTO, etc.) qui reconstruisent la base de données depuis zéro lors de leur exécution. Cela contraste avec les sauvegardes physiques (copies brutes des fichiers de données produites par des outils comme Percona XtraBackup ou MySQL Enterprise Backup), qui copient directement les fichiers tablespace InnoDB.

Pour les bases de données de quelques gigaoctets sur un Hébergement VPS ou un environnement partagé, une sauvegarde logique via MySQL Workbench est tout à fait pratique. Pour les bases de données de production de plusieurs centaines de gigaoctets, vous devriez considérer l’exportation Workbench comme un outil complémentaire ou dédié aux environnements de développement, et vous appuyer sur des sauvegardes physiques ou basées sur les journaux binaires pour les objectifs RPO/RTO de production.

Étape 1 : Installer MySQL Workbench et vérifier la compatibilité

Téléchargez MySQL Workbench depuis la page officielle de téléchargements MySQL. Le programme d’installation est disponible pour Windows, macOS et les paquets Linux Ubuntu/Debian/Fedora.

L’alignement des versions est important. MySQL Workbench 8.0.x doit être utilisé avec des serveurs MySQL 8.0.x. L’utilisation d’un client Workbench significativement plus ancien avec un serveur plus récent (ou vice versa) peut amener l’assistant d’exportation à omettre silencieusement des objets qu’il ne peut pas analyser, tels que les colonnes générées, les index fonctionnels ou les clauses de validation de schéma JSON introduites dans les versions ultérieures.

Après l’installation, confirmez que la version du client correspond à celle de votre serveur :

SELECT VERSION();

Exécutez cette requête immédiatement après la connexion pour vérifier la version du serveur avant de procéder à toute exportation.

Étape 2 : Créer et tester une connexion au serveur

Lancez MySQL Workbench. Sur l’écran d’accueil, localisez le panneau Connexions MySQL et cliquez sur l’icône + pour ouvrir la boîte de dialogue de configuration de la connexion.

Remplissez les champs suivants :

• Nom de la connexion — une étiquette descriptive (ex. prod-db-01)
• Nom d’hôte — l’adresse IP ou le FQDN du serveur
• Port — la valeur par défaut est 3306 ; modifiez-la si votre serveur utilise un port non standard
• Nom d’utilisateur — le compte utilisateur MySQL
• Mot de passe — stockez-le dans le coffre Workbench ou saisissez-le au moment de la connexion

Cliquez sur Tester la connexion. Un test réussi confirme l’accessibilité TCP et la validité des identifiants. Si le test échoue, les causes courantes incluent :

• Le paramètre bind-address du serveur MySQL est défini sur 127.0.0.1, bloquant les connexions distantes
• Une règle de pare-feu bloquant le port 3306
• Le compte utilisateur ne dispose pas du privilège PROCESS ou SELECT requis pour l’exportation

Privilèges minimaux requis pour une exportation complète :

GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES, EVENT, PROCESS ON *.* TO 'backup_user'@'%';

N’utilisez jamais le compte root pour les opérations de sauvegarde de routine. Créez un utilisateur de sauvegarde dédié en lecture seule et accordez uniquement ce qui est nécessaire.

Étape 3 : Ouvrir l’outil d’exportation de données

Une fois connecté, naviguez vers Serveur > Exportation de données dans la barre de menu supérieure. Cela ouvre le panneau d’exportation de données, qui est l’interface graphique de mysqldump.

Le panneau est divisé en deux sections principales :

• Volet gauche — liste toutes les bases de données visibles par l’utilisateur connecté
• Volet droit — affiche le format d’exportation, la destination de sortie et les options avancées

Étape 4 : Sélectionner les bases de données et les tables

Dans le volet gauche, cochez la case à côté de chaque base de données que vous souhaitez inclure dans la sauvegarde. En développant un nœud de base de données, vous révélez les tables individuelles, vous permettant d’effectuer des exportations partielles — par exemple, sauvegarder uniquement une table users ou une table orders sans exporter les grandes tables de journalisation ou d’analyse qui peuvent être régénérées.

Conseil pratique : Si vous utilisez un CMS comme WordPress ou une application personnalisée sur un Hébergement Web Partagé, vous avez généralement une seule base de données d’application. Sélectionnez-la entièrement. Si vous gérez une application multi-locataires avec des dizaines de bases de données sur un Serveur Dédié, envisagez de scripter des exportations par base de données plutôt que de tout exporter via l’interface graphique en une seule fois.

Étape 5 : Configurer les options d’exportation

Cette étape contient les décisions les plus importantes de tout le processus.

Type de contenu d’exportation

Sous Objets à exporter, choisissez ce que le dump contiendra :

• Exporter la structure et les données — exporte à la fois le DDL (CREATE TABLE, CREATE VIEW, procédures stockées, déclencheurs, événements) et toutes les données de lignes. C’est le bon choix pour une sauvegarde complète et restaurable.
• Exporter les données uniquement — exporte uniquement les instructions INSERT. Utilisez ceci lors de la migration de données dans un schéma déjà existant.
• Exporter la structure uniquement — exporte uniquement le DDL. Utile pour répliquer un schéma vers un environnement de staging sans copier les données de production sensibles.

Destination de sortie

• Exporter vers un dossier de projet dump — crée un fichier .sql par table dans un répertoire. Utile lorsque vous devez restaurer des tables individuelles de manière sélective, mais produit des dizaines de fichiers pour les grandes bases de données.
• Exporter vers un fichier autonome — écrit l’intégralité de l’exportation dans un seul fichier .sql. C’est le choix standard pour la plupart des scénarios de sauvegarde, car il produit un seul artefact facile à compresser, transférer et stocker.

Cliquez sur Parcourir pour définir le chemin de sortie. Choisissez un emplacement en dehors de la racine web et, idéalement, sur un volume séparé du répertoire de données de la base de données.

Options avancées (critiques pour la cohérence)

Cliquez sur Options avancées pour exposer les indicateurs mysqldump sous-jacents. Portez une attention particulière à :

• --single-transaction — encapsule l’intégralité de l’exportation InnoDB dans une seule transaction à lecture répétable, produisant un instantané cohérent sans verrouiller les tables. C’est essentiel pour les bases de données de production en direct utilisant InnoDB. Activez-le.
• --routines — inclut les procédures et fonctions stockées. Désactivé par défaut dans certaines versions de Workbench.
• --events — inclut les événements planifiés.
• --triggers — inclus par défaut ; vérifiez qu’il est coché.
• --hex-blob — exporte les colonnes BLOB, BINARY et VARBINARY sous forme de chaînes hexadécimales, évitant la corruption d’encodage lors de la restauration sur des systèmes avec des paramètres de jeu de caractères différents.

Si vous exportez une base de données qui utilise des clauses DEFINER liées à un utilisateur spécifique (courant avec les vues et les procédures stockées), sachez que la restauration du dump sur un serveur différent échouera si cet utilisateur n’existe pas. Supprimez ou remplacez les clauses DEFINER avant la restauration :

sed 's/DEFINER=[^ ]* //g' original_dump.sql > cleaned_dump.sql

Étape 6 : Exécuter l’exportation

Cliquez sur Démarrer l’exportation. MySQL Workbench affiche un journal de progression en temps réel montrant chaque objet au fur et à mesure de son traitement. Pour les grandes bases de données, cela peut prendre de plusieurs minutes à plusieurs heures selon le volume de données, le nombre de tables et la capacité d’E/S du serveur.

Surveillez attentivement la sortie du journal. Les avertissements tels que Access denied for table ou Table doesn't exist indiquent des lacunes de privilèges ou des incohérences de schéma qui produiront une sauvegarde incomplète. Ne les ignorez pas comme étant cosmétiques — une sauvegarde incomplète n’est pas une sauvegarde.

À la fin, le journal affichera Export completed avec un horodatage.

Étape 7 : Vérifier le fichier de sauvegarde

Naviguez vers le répertoire de sortie et confirmez que le fichier .sql existe et a une taille non nulle. Ensuite, ouvrez le fichier dans un éditeur de texte ou effectuez une vérification rapide d’intégrité :

head -50 your_backup.sql
tail -20 your_backup.sql

Un dump valide commence par un bloc de commentaires contenant la version mysqldump et la version du serveur, suivi d’instructions SET pour le jeu de caractères et les vérifications de clés étrangères. Il se termine par un commentaire final -- Dump completed on YYYY-MM-DD HH:MM:SS. Si le fichier est tronqué ou se termine abruptement, l’exportation a été interrompue et la sauvegarde est inutilisable.

Pour plus de confiance, effectuez une restauration de test dans une base de données hors production :

mysql -u root -p test_restore_db < your_backup.sql

Puis vérifiez les comptages de lignes par rapport à la source :

SELECT COUNT(*) FROM test_restore_db.your_critical_table;

Une sauvegarde qui n’a jamais été testée est une hypothèse, pas une garantie.

Étape 8 : Compresser et sécuriser le fichier de sauvegarde

Les dumps .sql bruts se compressent extrêmement bien en raison de leur structure textuelle répétitive. Compressez immédiatement après l’exportation :

gzip -9 your_backup.sql

Cela réduit généralement la taille du fichier de 70 à 90 %. Pour les bases de données contenant des données clients sensibles, chiffrez l’archive compressée avant de la stocker ou de la transférer :

openssl enc -aes-256-cbc -salt -pbkdf2 -in your_backup.sql.gz -out your_backup.sql.gz.enc -k 'your-strong-passphrase'

Stockez la phrase secrète séparément du fichier de sauvegarde — jamais dans le même répertoire ou dépôt.

Si votre application utilise HTTPS (appliqué par un Certificat SSL), appliquez la même discipline aux transferts de sauvegarde : ne déplacez jamais des dumps de base de données non chiffrés via HTTP simple ou FTP non chiffré.

Automatiser les sauvegardes MySQL sans l’interface graphique de MySQL Workbench

MySQL Workbench n’a pas de planificateur natif. Pour les sauvegardes récurrentes, invoquez mysqldump directement depuis un script shell et planifiez-le avec cron ou un minuteur systemd.

Script shell pour les sauvegardes quotidiennes automatisées

#!/bin/bash

DB_USER="backup_user"
DB_PASS="your_password"
DB_NAME="your_database"
BACKUP_DIR="/var/backups/mysql"
DATE=$(date +%F_%H-%M-%S)
FILENAME="${BACKUP_DIR}/${DB_NAME}_${DATE}.sql.gz"

mkdir -p "$BACKUP_DIR"

mysqldump 
  --user="$DB_USER" 
  --password="$DB_PASS" 
  --single-transaction 
  --routines 
  --triggers 
  --events 
  --hex-blob 
  "$DB_NAME" | gzip -9 > "$FILENAME"

# Retain only the last 14 days of backups
find "$BACKUP_DIR" -name "*.sql.gz" -mtime +14 -delete

Planifiez ce script pour s’exécuter quotidiennement à 02h00 :

crontab -e

Ajoutez la ligne suivante :

0 2 * * * /usr/local/bin/mysql_backup.sh >> /var/log/mysql_backup.log 2>&1

Note de sécurité : Stocker le mot de passe dans un script shell n’est acceptable que si le script a des permissions chmod 700 et appartient à l’utilisateur exécutant la tâche cron. Une approche plus sécurisée consiste à utiliser un fichier d’options MySQL :

# /root/.my.cnf — permissions must be 600
[client]
user=backup_user
password=your_password

Ensuite, supprimez entièrement les indicateurs --user et --password du script ; mysqldump lira automatiquement les identifiants depuis .my.cnf.

Pour les équipes gérant plusieurs bases de données sur plusieurs serveurs, envisagez d’associer cette automatisation à un VPS avec cPanel, qui inclut un gestionnaire de sauvegardes planifiées intégré gérant la rétention, les destinations de stockage distantes et les notifications par e-mail sans script manuel.

Restaurer une sauvegarde créée avec MySQL Workbench

La restauration à partir d’un dump généré par Workbench est simple mais nécessite une attention à quelques détails.

Créez la base de données cible si elle n’existe pas :

CREATE DATABASE restored_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Restaurez depuis le fichier dump :

mysql -u root -p restored_db < your_backup.sql

Si le dump a été créé avec les indicateurs --databases ou --all-databases (qui intègrent des instructions CREATE DATABASE et USE), ne spécifiez pas de base de données cible sur la ligne de commande — le dump le gère en interne. L’exportation d’une seule base de données par Workbench n’inclut pas ces instructions par défaut, vous devez donc créer et spécifier manuellement la base de données cible.

Pour les dumps compressés :

gunzip -c your_backup.sql.gz | mysql -u root -p restored_db

Surveillez la sortie de restauration pour détecter les erreurs. Les violations de contraintes de clés étrangères lors de la restauration sont généralement causées par l’ordre d’importation des tables. Si cela se produit, désactivez temporairement les vérifications de clés étrangères :

SET FOREIGN_KEY_CHECKS = 0;
-- run restore
SET FOREIGN_KEY_CHECKS = 1;

Matrice de décision : quand utiliser chaque méthode de sauvegarde

Liste de contrôle des points techniques clés

• Utilisez un utilisateur de sauvegarde dédié avec les privilèges SELECT, SHOW VIEW, TRIGGER, LOCK TABLES, EVENT et PROCESS — jamais root.
• Activez toujours --single-transaction pour les tables InnoDB afin d’éviter le verrouillage et d’assurer un instantané cohérent.
• Incluez les indicateurs --routines, --triggers et --events ; Workbench peut ne pas tous les activer par défaut.
• Vérifiez que le fichier dump se termine par le commentaire -- Dump completed avant de le considérer comme valide.
• Testez les restaurations dans une base de données hors production à intervalles réguliers — au minimum, mensuellement.
• Compressez les dumps immédiatement avec gzip et chiffrez les archives sensibles avec AES-256 avant le transfert ou le stockage hors site.
• Supprimez ou remplacez les clauses DEFINER si vous restaurez sur un serveur avec un ensemble d’utilisateurs différent.
• Pour les bases de données de plus de ~10 GB, évaluez les outils de sauvegarde physique ; les sauvegardes logiques à cette échelle introduisent des temps de restauration inacceptables pour la plupart des SLA.
• Stockez les sauvegardes sur un volume séparé ou un emplacement distant — une sauvegarde sur le même disque que la base de données qu’elle protège n’est pas une sauvegarde.

Foire aux questions

MySQL Workbench verrouille-t-il les tables pendant l’exportation ?

Pour les tables InnoDB avec l’option --single-transaction activée, aucun verrou de table n’est acquis. L’exportation utilise un instantané de lecture cohérent. Pour les tables MyISAM, mysqldump acquiert des verrous de lecture car MyISAM ne prend pas en charge la cohérence transactionnelle. Si votre base de données mélange des moteurs de stockage, l’exportation verrouillera les tables MyISAM tandis que les tables InnoDB sont lues transactionnellement.

Puis-je sauvegarder un serveur MySQL distant avec MySQL Workbench ?

Oui. MySQL Workbench se connecte via TCP à tout serveur MySQL accessible. Configurez la connexion avec l’IP ou le nom d’hôte du serveur distant et assurez-vous que le port 3306 (ou votre port personnalisé) est ouvert dans le pare-feu. Pour les serveurs sans accès public direct, Workbench prend en charge le tunneling SSH nativement — configurez-le sous l’onglet SSH dans la boîte de dialogue de connexion.

Quelle est la différence entre « Exporter vers un dossier de projet dump » et « Exporter vers un fichier autonome » ?

L’option dossier de projet crée un fichier .sql par table, ce qui permet des restaurations sélectives au niveau de la table mais produit de nombreux fichiers. L’option fichier autonome écrit tout dans un seul fichier .sql, qui est plus simple à gérer, compresser et transférer. Pour la plupart des cas d’utilisation, le fichier autonome est le bon choix.

Quelle sera la taille de mon fichier de sauvegarde .sql par rapport à la taille réelle de la base de données ?

Un dump .sql brut est généralement 1,5 à 3 fois plus grand que la taille réelle de la base de données sur disque, car les données de lignes sont sérialisées sous forme d’instructions INSERT verbeuses. Après compression gzip, le dump se réduit généralement à 10–30 % de la taille originale de la base de données, rendant les sauvegardes logiques compressées très efficaces en termes de stockage pour les ensembles de données à forte teneur en texte.

MySQL Workbench peut-il sauvegarder les vues, les procédures stockées et les déclencheurs ?

Oui, mais uniquement si les options correspondantes sont explicitement activées. Dans le panneau Options avancées, vérifiez que --routines (pour les procédures et fonctions stockées) et --events sont cochés. Les déclencheurs sont inclus par défaut. Les vues sont incluses dans le cadre de l’exportation du schéma lorsque « Exporter la structure et les données » ou « Exporter la structure uniquement » est sélectionné.