Comment récupérer une base de données MySQL après la suppression de fichiers ou d’une partition sous Ubuntu : RAID 6 et LUKS2
-
Auteur:
Abdelhamid Balti
-
Éditeur:
Mykhailo Miroshnychenko
La suppression de fichiers ou d’une partition entière de disque sous Ubuntu peut entraîner une perte critique de données, en particulier si une base de données MySQL est en cours d’exécution sur le serveur. La situation devient beaucoup plus complexe lorsque le système de stockage est basé sur un ensemble RAID 6 et que les données sont en outre protégées par le chiffrement LUKS2. Dans de telles conditions, les outils de récupération standard ne produisent pas toujours le résultat attendu, et des actions imprudentes peuvent détruire définitivement les informations. Dans cet article, nous examinerons les scénarios possibles de perte de données, les spécificités du travail avec RAID 6 et LUKS2, ainsi que le processus de récupération d’une base de données MySQL après la suppression accidentelle de fichiers ou d’une partition de disque.
- Préparation de l’environnement de test et de la base de données MySQL
- Connexion des disques pour l’analyse
- Comment récupérer une base de données MySQL supprimée à partir de RAID 6 + LUKS2
- ÉTAPE 1. Détection automatique des partitions RAID 6 et LUKS
- ÉTAPE 2. Déverrouillage et récupération des fichiers supprimés
- ÉTAPE 3. Restauration de la base de données à partir d’un vidage SQL
- ÉTAPE 4. Restauration de la base de données à partir des fichiers physiques MySQL
- ÉTAPE 5. Restauration de la structure des tables à partir des fichiers ibd
- ÉTAPE 6. Attachement des fichiers ibd récupérés
- Conclusion
- Questions fréquemment posées
- Commentaires
Les fichiers de base de données MySQL et leurs sauvegardes sur un serveur Linux peuvent devenir inaccessibles pour diverses raisons : suppression accidentelle de fichiers, formatage ou suppression d’une partition, corruption du système de fichiers, défaillance de l’ensemble RAID, panne de disque ou défaillance du contrôleur RAID. La situation devient encore plus complexe si les données sont stockées sur une partition chiffrée LUKS2.
Hetman RAID Recovery permet de reconstruire les structures d’un ensemble RAID, de localiser les partitions perdues, de déverrouiller LUKS2 si le mot de passe est disponible, et de récupérer des fichiers de base de données ainsi que des vidages SQL.
Nous allons démontrer le programme sur un ordinateur exécutant Windows. Cependant, Hetman RAID Recovery est également disponible pour Linux et macOS.
Comment récupérer une base MySQL supprimée sur RAID 6 + LUKS2 (Ubuntu)
Préparation de l’environnement de test et de la base de données MySQL
Pour les tests, nous avons utilisé un serveur Dell PowerEdge R710 avec un contrôleur PERC H700.
| Paramètre | Spécification |
|---|---|
| Modèle de serveur | Dell PowerEdge R710 |
| Format | Rack 2U |
| Processeur | Jusqu’à 2 × Intel Xeon série 5500/5600 |
| RAM | DDR3 ECC, jusqu’à 288 Go (18 emplacements) |
| Contrôleur RAID | Dell PERC H700 |
| Type de RAID | RAID matériel |
| Niveaux RAID pris en charge | RAID 0, 1, 5, 6, 10, 50, 60 |
| Configuration de l’ensemble | RAID 6 |
| Interface des disques | SAS/SATA, jusqu’à 6 Gbit/s |
| Nombre de baies de disque | Jusqu’à 6 × 3,5″ ou 8 × 2,5″ selon la configuration |
| Cache du contrôleur RAID | 512 Mo ou 1 Go (selon le modèle) |
| Protection du cache | BBU — protection du cache par batterie |
| Système d’exploitation | Ubuntu Server |
| Chiffrement des données | LUKS2 (au niveau Linux, et non sur le contrôleur RAID) |
| Système de gestion de base de données | MySQL |
| Tolérance aux pannes de RAID 6 | Permet la défaillance simultanée de jusqu’à deux disques |
| Outils de diagnostic | Dell OpenManage, MegaCLI, StorCLI (si compatible) |
Pour fournir au système d’exploitation un accès direct à chaque disque physique, six ensembles RAID 0 à un seul disque ont été créés sur le contrôleur — un pour chaque disque. Ubuntu Server 24.04 a été installé sur l’un d’eux, et les quatre autres ont été combinés en un ensemble logiciel MD RAID 6 via Cockpit.
Une table de partitions GPT et trois partitions ont été créées sur l’ensemble, avec ext4 comme système de fichiers et le chiffrement LUKS2 sélectionné pour chacune d’elles.
Le répertoire mysql-data a été placé sur la troisième partition et contenait les données de la base de test company_db, les fichiers système et les journaux MySQL. La version MySQL 8.0.46 a été utilisée.
La base de données elle-même contenait les tables customers, products et orders, ainsi qu’une vue, une procédure stockée et une fonction.
La sauvegarde de la base de données a été créée dans MySQL Workbench sous forme de vidage SQL et enregistrée dans le répertoire mysql-backups.
Avant le test, les répertoires mysql-data et mysql-backups ont été copiés de la troisième partition vers la deuxième. Ensuite, la deuxième partition a été supprimée via Cockpit, et les fichiers de base de données ainsi que le vidage SQL ont été supprimés de la troisième partition à l’aide de Maj + Suppr, en contournant la Corbeille. Deux scénarios ont ainsi été préparés : la récupération de fichiers à partir d’une partition supprimée et la récupération de fichiers supprimés à partir d’une partition conservée.
Connexion des disques pour l’analyse
Dans notre cas, les disques participant au RAID 6 ont été connectés à un ordinateur Windows via une station d’accueil USB, et Hetman RAID Recovery a été lancé pour l’analyse.
En plus du travail avec des disques physiques, le programme prend en charge l’analyse d’images complètes de disque secteur par secteur. De telles images peuvent être créées directement dans Hetman RAID Recovery à l’aide de la fonction Enregistrer le disque et stockées sur un autre disque sain.
Ceci est particulièrement utile si le disque est instable, présente des secteurs défectueux ou génère des erreurs de lecture. La création d’une image préserve les données lisibles et permet d’analyser la copie ultérieurement, réduisant ainsi le nombre d’accès répétés au disque problématique.
Si les disques restent sur le serveur Linux et sont lisibles, ils peuvent être analysés à distance. Pour cela, connectez-vous au serveur via SSH dans Hetman RAID Recovery et obtenez l’accès à ses périphériques de bloc.
Comment récupérer une base de données MySQL supprimée à partir de RAID 6 + LUKS2
ÉTAPE 1. Détection automatique des partitions RAID 6 et LUKS
Dès le lancement, Hetman RAID Recovery a détecté automatiquement la configuration MD RAID 6 et en a reconstruit la structure pour l’analyse.
Le panneau de droite affiche les paramètres principaux de l’ensemble : type et état du RAID, ordre et taille des blocs, ainsi que la liste des disques participants avec leur séquence, leurs décalages et leurs tailles.
Sur l’ensemble assemblé, le programme a détecté trois partitions, y compris la deuxième, précédemment supprimée, et a identifié un chiffrement LUKS sur les trois. Avant la saisie du mot de passe, leurs systèmes de fichiers ne sont pas affichés — les partitions doivent être déverrouillées pour l’analyse ultérieure.
La deuxième partition est affichée dans l’interface comme un espace non alloué marqué LUKS. Cela signifie que le programme a reconnu les métadonnées du conteneur chiffré à l’emplacement de la partition supprimée.
ÉTAPE 2. Déverrouillage et récupération des fichiers supprimés
Pour lancer l’analyse, double-cliquez sur la partition requise. Comme elle est chiffrée avec LUKS2, le programme vous invitera à saisir un mot de passe ou à spécifier un fichier de clé. Saisissez le mot de passe et cliquez sur Déverrouiller.
Sélectionnez d’abord Analyse rapide. Attendez la fin de l’analyse, après quoi le programme ouvrira la structure des dossiers trouvés. Lors de notre test, l’analyse rapide a trouvé les fichiers nécessaires sur la partition supprimée.
Si les données requises ne sont pas trouvées dans votre cas, revenez à la sélection du type d’analyse et lancez Analyse complète, en spécifiant le système de fichiers EXT2/3/4.
Examinez les résultats de l’analyse. Dans notre cas, le programme a affiché le vidage SQL backup1.sql, le répertoire company_db et les fichiers de table MySQL avec l’extension .ibd. Le contenu du vidage SQL peut être vérifié dans la fenêtre d’aperçu.
Sélectionnez les fichiers et dossiers que vous souhaitez récupérer, puis cliquez sur Récupération. Choisissez une méthode d’enregistrement, indiquez un autre disque physique et laissez activée l’option de restauration de la structure des répertoires.
N’enregistrez pas les fichiers trouvés sur le même disque à partir duquel ils sont récupérés, afin d’éviter d’écraser d’autres données perdues.
ÉTAPE 3. Restauration de la base de données à partir d’un vidage SQL
La méthode la plus simple pour restaurer la base de données consiste à utiliser le vidage SQL récupéré. Il contient les commandes permettant de créer la structure de la base de données et de restaurer les données à l’état où la sauvegarde a été effectuée. Si les options d’export appropriées ont été sélectionnées, le vidage inclura également les vues, procédures et fonctions.
Lancez MySQL Workbench et connectez-vous au serveur MySQL. Ouvrez le menu Server — Data Import, sélectionnez Import from Self-Contained File et indiquez le fichier SQL récupéré.
Si l’intégralité du répertoire mysql-data avec les fichiers système MySQL a été perdue, vous devez d’abord restaurer le fonctionnement du serveur ou préparer une nouvelle instance MySQL. Ce n’est qu’ensuite que le vidage peut être importé via Workbench.
Sélectionnez le schéma cible ou créez une nouvelle base de données company_db, puis cliquez sur Start Import. Attendez la fin de l’opération et vérifiez le journal pour détecter d’éventuelles erreurs.
Actualisez la liste des schémas. La base de données doit maintenant contenir les tables customers, products et orders. Ouvrez-les et vérifiez les enregistrements.
ÉTAPE 4. Restauration de la base de données à partir des fichiers physiques MySQL
Si aucun vidage SQL approprié n’est disponible, mais que Hetman RAID Recovery a réussi à récupérer le répertoire de la base de données avec les fichiers de table, vous pouvez tenter une récupération physique.
Dans notre cas, le répertoire company_db a conservé les fichiers customers.ibd, products.ibd et orders.ibd. Chacun d’eux contient les données et les index de la table InnoDB correspondante.
Il ne suffit pas de copier simplement ces fichiers dans le répertoire MySQL. Le nouveau serveur ne possède pas encore les définitions des tables correspondantes dans le dictionnaire de données. La récupération se déroule donc en deux étapes : d’abord, il faut recréer la structure des tables, puis y attacher les fichiers .ibd récupérés.
Pour la récupération, préparez un serveur fonctionnel avec la même version de MySQL. Connectez-vous-y via Workbench et créez une base de données vide.
Si le script SQL d’origine contenant la structure est conservé, exécutez les commandes CREATE TABLE qu’il contient. Les tables doivent correspondre exactement aux tables d’origine, y compris les types de colonnes, les clés, les index, le tri et le format de ligne. Il n’est pas nécessaire d’exécuter les commandes d’insertion de données — à ce stade, les tables doivent rester vides.
ÉTAPE 5. Restauration de la structure des tables à partir des fichiers ibd
Si le script SQL d’origine n’est pas disponible, vous pouvez tenter de récupérer la structure des tables à partir des fichiers .ibd. Dans MySQL 8.0, ils contiennent SDI — les métadonnées du dictionnaire de données. L’utilitaire ibd2sdi sert à les lire.
Exécutez-le pour chaque fichier récupéré et enregistrez les résultats au format JSON. Dans notre cas, nous avons obtenu les métadonnées de customers.ibd, products.ibd et orders.ibd, puis utilisé jq pour examiner la définition de la table customers.
Les métadonnées peuvent inclure le nom de la table, la version de MySQL, le moteur de stockage, le tri et les paramètres du tablespace. Elles contiennent également les définitions des colonnes. Les informations relatives aux clés primaires et uniques, aux index secondaires et aux relations avec d’autres tables sont stockées séparément.
Le JSON obtenu peut être analysé manuellement dans un éditeur de texte. Sur la base des paramètres détectés, des scripts et convertisseurs spécialisés peuvent générer automatiquement des commandes préliminaires CREATE TABLE. Pour un grand nombre de tables, cela accélère considérablement la récupération de la structure.
ÉTAPE 6. Attachement des fichiers ibd récupérés
Dans Workbench, désactivez temporairement les vérifications des clés étrangères et exécutez la commande ALTER TABLE … DISCARD TABLESPACE pour chaque table créée. Cela détache le tablespace vide créé et prépare la table à l’attachement du fichier récupéré.
Ensuite, copiez les fichiers .ibd correspondants dans le répertoire de la base de données sur le serveur préparé. Après la copie, n’oubliez pas d’attribuer le propriétaire mysql aux fichiers et de définir les autorisations d’accès requises.
Retournez dans Workbench et exécutez ALTER TABLE … IMPORT TABLESPACE pour chaque table. Les avertissements concernant l’absence de fichiers .cfg ne sont pas critiques : MySQL poursuivra l’importation sans validation automatique de la structure. MySQL enregistrera les tablespaces récupérés et associera les données et les index aux définitions de tables créées précédemment.
Après une importation réussie, réactivez les vérifications des clés étrangères. Actualisez la liste des schémas et vérifiez le nombre et le contenu des enregistrements à l’aide de requêtes SELECT.
Les fichiers .ibd permettent de restaurer les tables, leurs données et leurs index. Toutefois, les vues, procédures et fonctions ne sont pas stockées sous forme de fichiers distincts dans le répertoire company_db. S’ils ne figurent pas dans le vidage SQL, ces objets doivent être recréés manuellement.
Après avoir vérifié la base de données restaurée, nous recommandons de créer une nouvelle sauvegarde au format SQL dump.
Conclusion
Grâce à Hetman RAID Recovery, il a été possible de reconstruire automatiquement la structure de Linux MD RAID 6 et de détecter puis déverrouiller des conteneurs LUKS2 à l’aide du mot de passe connu. Une analyse rapide a permis de trouver les fichiers requis aussi bien après leur suppression qu’après la suppression d’une partition entière.
Le vidage SQL récupéré peut être importé via MySQL Workbench, ce qui restaure la structure et les données de la base à l’état où la sauvegarde a été créée. Si aucun vidage approprié n’est disponible, des tables InnoDB individuelles peuvent être récupérées à partir de fichiers .ibd en recréant d’abord leur structure.
