Comment restaurer une base de données MySQL à partir d’une sauvegarde à l’aide de MySQL Workbench

Restaurer une base de données MySQL à partir d’une sauvegarde avec MySQL Workbench signifie importer un fichier dump .sql (ou un export basé sur un répertoire) dans un schéma cible via l’assistant Data Import/Restore de l’interface graphique, qui exécute en interne des commandes client mysql contre votre serveur. Le processus prend moins de cinq minutes pour les bases de données de petite à moyenne taille et nécessite trois éléments : une instance de serveur MySQL en cours d’exécution, un fichier de sauvegarde valide et un compte utilisateur disposant de privilèges suffisants (CREATE, DROP, INSERT, ALTER et INDEX au minimum).

Ce guide couvre chaque étape, de la configuration de la connexion à la vérification post-restauration, y compris les cas particuliers — incompatibilités de jeux de caractères, restaurations partielles, délais d’attente pour les fichiers volumineux et erreurs de privilèges — que la documentation officielle passe sous silence.

Prérequis et liste de vérification de l’environnement

Avant de toucher à MySQL Workbench, confirmez les points suivants :

• MySQL Workbench 8.0+ est installé. La disposition de l’interface décrite ici correspond à la version 8.0.x. Les anciennes versions 6.x ont un chemin de menu différent.
• Le format du fichier de sauvegarde est compatible. L’assistant d’importation de données de MySQL Workbench accepte les fichiers .sql produits par mysqldump, l’exportation de données de MySQL Workbench, ou tout outil qui génère du SQL DDL/DML standard. Il n’importe PAS nativement les fichiers .xbstream (Percona XtraBackup) ni les fichiers binaires .frm/.ibd — ceux-ci nécessitent un processus de restauration physique distinct.
• Version du serveur MySQL cible. Restaurer un dump de MySQL 8.0 dans un serveur MySQL 5.7 échouera si le dump utilise une syntaxe spécifique à la version 8.0 (par exemple, colonnes invisibles, index fonctionnels). Faites toujours correspondre les versions majeures ou restaurez vers une version plus récente.
• Privilèges utilisateur. Exécutez cette requête pour vérifier que votre compte dispose de ce dont il a besoin :

SHOW GRANTS FOR 'your_user'@'localhost';

• Paramètre max_allowed_packet. Pour les dumps volumineux contenant des colonnes BLOB ou de longues instructions INSERT, le paramètre max_allowed_packet du serveur doit être suffisamment grand. Vérifiez-le et augmentez-le temporairement si nécessaire :

SHOW VARIABLES LIKE 'max_allowed_packet';
SET GLOBAL max_allowed_packet = 1073741824; -- 1 GB

• net_read_timeout et net_write_timeout. Les restaurations volumineuses sur des connexions lentes peuvent atteindre les seuils de délai d’attente. Définissez les deux à au moins 3600 secondes avant de commencer.

Si vous gérez un serveur distant, assurez-vous que votre instance VPS Hosting a le port 3306 de MySQL accessible depuis votre poste de travail, ou utilisez un tunnel SSH (décrit ci-dessous).

Étape 1 : Lancer MySQL Workbench et se connecter à votre serveur

Ouvrez MySQL Workbench. Sur l’écran d’accueil, vous verrez vos connexions enregistrées sous MySQL Connections.

Connexion à un serveur local : Cliquez sur la tuile de connexion. Entrez votre mot de passe lorsque vous y êtes invité.

Connexion à un serveur distant via un tunnel SSH : Si votre serveur MySQL se trouve sur un hôte distant et que le port 3306 n’est pas exposé publiquement (la posture de sécurité recommandée), utilisez le tunnel SSH intégré de Workbench :

1. Cliquez sur l’icône + à côté de « MySQL Connections ».
2. Définissez la méthode de connexion sur Standard TCP/IP over SSH.
3. Renseignez le nom d’hôte SSH, le nom d’utilisateur SSH et le chemin du fichier de clé SSH.
4. Définissez le nom d’hôte MySQL sur 127.0.0.1 et le port sur 3306.
5. Cliquez sur Tester la connexion pour confirmer que le tunnel fonctionne avant de continuer.

C’est l’approche correcte pour tout serveur de production — n’exposez jamais MySQL directement à l’internet public.

Étape 2 : Préparer le schéma de base de données cible

Vous avez besoin d’un schéma de destination avant d’importer. Vous avez deux options :

Option A : Restaurer dans un schéma existant

Si la sauvegarde a été effectuée depuis un schéma qui existe toujours sur le serveur (par exemple, vous effectuez un retour arrière après une migration échouée), le schéma est déjà visible dans le panneau Navigator > Schemas à gauche. Aucune action n’est nécessaire ici — vous le sélectionnerez lors de la configuration de l’importation.

Avertissement critique : L’importation dans un schéma existant ne supprime PAS automatiquement les tables existantes au préalable, sauf si votre fichier dump contient des instructions DROP TABLE IF EXISTS. Si votre dump a été créé avec mysqldump --add-drop-table (par défaut), les tables existantes seront supprimées et recréées. Si ce n’est pas le cas, vous risquez d’obtenir des données en double ou des violations de contraintes. Inspectez les 50 premières lignes de votre fichier .sql pour confirmer :

head -50 /path/to/your_backup.sql

Option B : Créer un nouveau schéma

Si vous restaurez vers un nouveau schéma (migration, nouvel environnement, reprise après sinistre), créez-le d’abord. Allez dans Fichier > Nouvel onglet de requête et exécutez :

CREATE DATABASE `database_name`
  CHARACTER SET utf8mb4
  COLLATE utf8mb4_unicode_ci;

Spécifiez toujours CHARACTER SET utf8mb4 explicitement. Si vous créez le schéma avec le jeu de caractères par défaut du serveur et que votre dump a été effectué depuis une base de données utf8mb4, vous risquez une corruption silencieuse de l’encodage des caractères sur les colonnes de type chaîne. Après l’exécution, cliquez sur l’icône d’actualisation (flèche circulaire) dans le panneau Schemas pour rendre le nouveau schéma visible.

Étape 3 : Ouvrir l’assistant d’importation de données

Naviguez vers Server > Data Import dans la barre de menu supérieure. Le panneau Data Import/Restore s’ouvre dans l’espace de travail principal.

Vous verrez deux modes d’importation :

Pour la grande majorité des opérations de restauration, sélectionnez Import from Self-Contained File.

Cliquez sur Parcourir et naviguez jusqu’à votre fichier de sauvegarde .sql. Workbench affichera le chemin complet dans le champ.

Étape 4 : Configurer le schéma cible et les options d’importation

Sélection du schéma cible par défaut

Sous Default Schema to be Imported To, ouvrez le menu déroulant et sélectionnez le schéma cible que vous avez identifié ou créé à l’étape 2.

Quand laisser ce champ vide : Si votre fichier dump contient ses propres instructions CREATE DATABASE et USE (courant lorsque mysqldump a été exécuté avec l’option --databases ou --all-databases), vous pouvez laisser le champ du schéma cible vide. Workbench laissera le script SQL piloter la sélection du schéma. Cependant, cela signifie que le dump tentera de créer la base de données lui-même — si elle existe déjà, vous pourriez obtenir une erreur, sauf si le dump inclut CREATE DATABASE IF NOT EXISTS.

Quand vous devez sélectionner un schéma cible : Si le dump a été créé avec mysqldump database_name > backup.sql (sans --databases), le fichier ne contient aucune instruction CREATE DATABASE ou USE. Vous DEVEZ sélectionner le schéma cible ici, sinon l’importation échouera avec ERROR 1046: No database selected.

Structure du dump vs. données

Si vous avez utilisé l’export en dossier de projet de Workbench, vous verrez des cases à cocher pour importer sélectivement :

• Dump Structure and Data — restauration complète (par défaut, recommandé pour la reprise après sinistre)
• Dump Data Only — repeuple les tables sans recréer le schéma ; utile lorsque le schéma correspond déjà
• Dump Structure Only — recrée les tables/vues/procédures sans insérer de lignes

Étape 5 : Exécuter l’importation

Cliquez sur Start Import dans le coin inférieur droit du panneau.

Workbench lance un processus en arrière-plan qui achemine votre fichier .sql via le client en ligne de commande mysql. L’onglet Import Progress et le panneau Logs se mettent à jour en temps réel. Surveillez :

• La barre de progression verte atteignant 100% — achèvement réussi.
• ERROR 1044 — accès refusé ; votre utilisateur manque de privilèges sur le schéma cible.
• ERROR 1005 / ERROR 1215 — échec de contrainte de clé étrangère ; les tables sont créées dans le mauvais ordre ou une table référencée est manquante. Cela se produit parfois avec des dumps partiels.
• ERROR 2006: MySQL server has gone away — le seuil max_allowed_packet ou de délai d’attente a été atteint. Augmentez les deux valeurs comme indiqué dans la section Prérequis et réessayez.
• Packet too large — même cause principale que ci-dessus.

Pour les grandes bases de données (dumps de plusieurs Go), l’interface graphique de Workbench peut sembler figée. Ce n’est pas le cas — le processus mysql sous-jacent est toujours en cours d’exécution. Ne fermez pas la fenêtre. Si vous avez besoin de plus de contrôle sur les restaurations volumineuses, l’approche en ligne de commande est plus fiable :

mysql -u your_user -p --max_allowed_packet=1G database_name < /path/to/backup.sql

Étape 6 : Vérifier la base de données restaurée

Un message d’importation réussie n’est pas une confirmation suffisante. Effectuez toujours une vérification active.

Vérification au niveau du schéma

Dans le panneau Navigator, faites un clic droit sur Schemas et sélectionnez Refresh All. Développez la base de données restaurée et confirmez visuellement :

• Toutes les tables attendues sont présentes
• Les vues, procédures stockées et déclencheurs sont listés sous leurs nœuds respectifs

Vérification ponctuelle du nombre de lignes

Ouvrez un nouvel onglet de requête, sélectionnez votre base de données restaurée et exécutez :

SELECT
  table_name,
  table_rows,
  ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.tables
WHERE table_schema = 'database_name'
ORDER BY table_rows DESC;

Comparez ces nombres de lignes avec votre système source ou un manifeste de sauvegarde précédent. table_rows dans information_schema est une estimation pour InnoDB — pour des comptages exacts sur les tables critiques, exécutez SELECT COUNT(*) FROM table_name directement.

Vérification de l’intégrité des données

Pour les tables InnoDB, effectuez une vérification rapide de cohérence :

CHECK TABLE your_table_name EXTENDED;

Si vous avez des relations de clés étrangères, vérifiez que l’intégrité référentielle n’a pas été compromise lors de l’importation :

SET FOREIGN_KEY_CHECKS = 1;
-- Then attempt a JOIN across related tables to confirm linkage
SELECT COUNT(*) FROM orders o JOIN customers c ON o.customer_id = c.id;

Vérification de l’encodage des caractères

Si votre application stocke du contenu multilingue, vérifiez que les caractères spéciaux n’ont pas été altérés :

SELECT column_name FROM table_name WHERE column_name LIKE '%ü%' LIMIT 5;

Si les résultats sont vides alors qu’ils ne devraient pas l’être, vous avez probablement une incompatibilité de jeu de caractères entre le dump et le schéma cible.

Gestion des fichiers de sauvegarde volumineux et considérations de performance

Pour les bases de données dépassant quelques centaines de mégaoctets, l’interface graphique de Workbench devient peu pratique. Envisagez ces approches :

Diviser le dump par table : Si vous n’avez besoin de restaurer que des tables spécifiques, extrayez-les du dump :

grep -n "Table structure for table" /path/to/backup.sql

Cela affiche les numéros de ligne pour chaque bloc de table, vous permettant d’extraire une plage spécifique avec sed ou awk.

Utiliser mysqlimport pour les restaurations basées sur CSV : Si votre sauvegarde est au format CSV (exportée via SELECT ... INTO OUTFILE), mysqlimport est significativement plus rapide que le traitement des instructions SQL ligne par ligne.

Désactiver les index pendant l’importation : Pour les très grands ensembles de données, désactiver temporairement les mises à jour d’index peut réduire le temps d’importation de 50 à 80 % :

ALTER TABLE large_table DISABLE KEYS;
-- (import data)
ALTER TABLE large_table ENABLE KEYS;

Pour InnoDB spécifiquement, définissez innodb_autoinc_lock_mode = 0 et foreign_key_checks = 0 dans votre session avant d’importer :

SET SESSION foreign_key_checks = 0;
SET SESSION unique_checks = 0;

Si vous exécutez MySQL sur un Serveur Dédié avec un débit I/O élevé, vous pouvez également augmenter temporairement innodb_buffer_pool_size pour accélérer l’importation en conservant davantage de données en mémoire plutôt qu’en les vidant constamment sur le disque.

Importation de données MySQL Workbench vs. restauration en ligne de commande : comparaison

Pièges courants et comment les éviter

Restaurer un dump qui inclut des clauses DEFINER : Les procédures stockées et les vues contiennent souvent DEFINER='original_user'@'original_host'. Si cet utilisateur n’existe pas sur le serveur cible, l’importation réussira mais l’exécution de ces objets échouera avec ERROR 1449. Supprimez ou remplacez les clauses DEFINER avant d’importer :

sed 's/DEFINER=[^ ]* / /g' original_backup.sql > cleaned_backup.sql

Incompatibilités de fuseau horaire : Si votre application stocke des valeurs DATETIME et que les serveurs source et cible sont dans des fuseaux horaires différents, les données apparaîtront décalées. Confirmez toujours que @@global.time_zone correspond entre la source et la cible avant de restaurer.

Restauration dans un environnement répliqué : Si le serveur MySQL cible est un primaire de réplication, les instructions d’importation seront écrites dans le journal binaire et répliquées vers tous les réplicas. C’est généralement souhaité pour une restauration complète, mais cela peut poser des problèmes si les réplicas sont déjà en avance ou en retard. Mettez en pause la réplication sur les réplicas avant une opération de restauration majeure.

Gonflement du journal binaire : Les importations volumineuses génèrent d’énormes fichiers de journal binaire. Si l’espace disque est limité, désactivez temporairement la journalisation binaire pour la session :

SET SQL_LOG_BIN = 0;
-- (perform import)
SET SQL_LOG_BIN = 1;

Remarque : cela nécessite le privilège SUPER ou BINLOG ADMIN et ne doit être fait que sur des serveurs autonomes, jamais sur des primaires de réplication dont les réplicas dépendent du journal binaire.

Mise en place de sauvegardes automatisées pour prévenir les pertes de données futures

Une procédure de restauration n’est efficace que si la sauvegarde qui l’alimente l’est aussi. Si vous gérez votre propre serveur MySQL — que ce soit sur un VPS avec cPanel ou un VPS Linux nu — automatisez vos sauvegardes avec une tâche cron :

# Daily mysqldump backup with timestamp, retained for 7 days
0 2 * * * /usr/bin/mysqldump -u backup_user -p'StrongPassword' 
  --single-transaction 
  --routines 
  --triggers 
  --hex-blob 
  --default-character-set=utf8mb4 
  your_database | gzip > /backups/db_$(date +%F).sql.gz 
  && find /backups -name "db_*.sql.gz" -mtime +7 -delete

Explication des options clés :

--single-transaction — prend un instantané cohérent des tables InnoDB sans les verrouiller, essentiel pour les bases de données en production
--routines — inclut les procédures et fonctions stockées (omises par défaut)
--triggers — inclut les déclencheurs (inclus par défaut, mais explicite vaut mieux)
--hex-blob — exporte les colonnes BLOB sous forme de chaînes hexadécimales, évitant la corruption des données binaires

Stockez les sauvegardes hors du serveur. Une sauvegarde sur le même disque que la base de données qu’elle protège n’est pas une sauvegarde — c’est un faux sentiment de sécurité. Utilisez un stockage distant, un stockage d’objets ou un serveur secondaire. Si votre environnement d’hébergement prend en charge les panneaux de contrôle VPS, la plupart des panneaux incluent des fonctionnalités de sauvegarde planifiée intégrées qui peuvent envoyer automatiquement des copies vers des destinations distantes.
Liste de contrôle technique des points essentiels
Avant d’effectuer toute restauration MySQL, parcourez cette matrice de décision :

[ ] Confirmer que le type de fichier de sauvegarde est .sql (dump textuel) — pas au format binaire XtraBackup
[ ] Faire correspondre les versions majeures du serveur MySQL entre la source et la cible
[ ] Vérifier que l’utilisateur dispose des privilèges CREATE, DROP, INSERT, ALTER, INDEX sur le schéma cible
[ ] Vérifier max_allowed_packet et les variables de délai d’attente ; les augmenter si le dump contient des BLOBs ou est volumineux
[ ] Inspecter les 50 premières lignes du dump pour déterminer si des instructions CREATE DATABASE / USE sont présentes
[ ] Décider : restaurer dans un schéma existant (risque de fusion de données) ou dans un nouveau schéma (table rase)
[ ] Supprimer les clauses DEFINER si la restauration est effectuée vers un serveur différent avec des comptes utilisateurs différents
[ ] Confirmer que les jeux de caractères correspondent entre le dump et le schéma cible (utf8mb4 recommandé universellement)
[ ] Pour les restaurations en production : désactiver la réplication, désactiver la journalisation binaire si approprié, prendre un instantané avant la restauration
[ ] Après l’importation : vérifier le nombre de lignes, exécuter CHECK TABLE, tester la connectivité de l’application
[ ] Pour les bases de données de plus de 500 MB : contourner l’interface graphique de Workbench et utiliser directement la CLI mysql

FAQ

Q : MySQL Workbench peut-il restaurer directement un fichier de sauvegarde .sql.gz compressé ?

Non. L’assistant d’importation de données de MySQL Workbench n’accepte pas les fichiers compressés gzip. Décompressez d’abord le fichier avec gunzip backup.sql.gz ou redirigez-le directement via la CLI : gunzip -c backup.sql.gz | mysql -u user -p database_name.

Q : Pourquoi mon importation se termine sans erreurs mais certaines tables sont manquantes ?

La cause la plus courante est que le dump a été créé avec --no-tablespaces ou était un export partiel qui excluait certaines tables. Ouvrez le fichier .sql et recherchez CREATE TABLE table_name pour confirmer si les tables manquantes ont jamais été incluses dans le dump.

Q : Quelle est la différence entre « Import from Self-Contained File » et « Import from Dump Project Folder » dans Workbench ?

Un fichier autonome est un fichier .sql monolithique unique contenant tout le DDL et le DML pour l’ensemble de la base de données. Un dossier de projet dump est une structure de répertoires où le schéma et les données de chaque table sont stockés dans des fichiers séparés — ce format est produit lorsque vous utilisez l’exportation de données de Workbench avec l’option « Export to Dump Project Folder ». Le format dossier de projet permet des restaurations sélectives au niveau des tables plus facilement.

Q : Ma restauration échoue avec ERROR 1215: Cannot add foreign key constraint. Comment y remédier ?

Cela se produit lorsque les tables sont créées dans un ordre qui viole les dépendances de clés étrangères — une table parente référencée n’existe pas encore lorsque la table enfant est créée. La solution consiste à désactiver les vérifications de clés étrangères pour la session d’importation. Ajoutez SET FOREIGN_KEY_CHECKS=0; en haut de votre fichier .sql et SET FOREIGN_KEY_CHECKS=1; en bas, puis relancez l’importation.

Q : Est-il sûr de restaurer une sauvegarde directement sur une base de données de production en ligne sans prendre d’instantané au préalable ?

Non. Prenez toujours une sauvegarde actuelle de la base de données en production avant de l’écraser. Même si vous avez confiance dans le fichier de sauvegarde, une opération de restauration qui échoue à mi-chemin peut laisser le schéma dans un état partiellement modifié. Utilisez mysqldump --single-transaction pour capturer l’état actuel en quelques secondes sans interruption de service, puis procédez à la restauration.