Table des matières de l'article :
C'était un matin comme les autres dans notre bureau, lorsque le téléphone a sonné avec insistance. De l’autre bout du fil, une voix excitée nous parvint. C'était un développeur PHP qui avait décidé de gérer son environnement de production sur un VPS hébergé par un fournisseur italien bien connu. Il avait choisi Plesk pour sa simplicité d’utilisation, convaincu que cela lui donnerait une autonomie totale dans la gestion du serveur sans avoir à dépendre d’un administrateur système. Mais la réalité était tout autre : le système de gestion de son entreprise était soudainement tombé en panne et, avec lui, l’ensemble du flux de travail de l’entreprise était paralysé.
"Nous avons un serveur avec Plesk, nous ne pouvons pas comprendre ce qui s'est passé, mais la base de données ne démarre pas !" dit-il sur un ton oscillant entre panique et désespoir.
Nous avons commencé à poser quelques questions préliminaires. Y a-t-il eu des mises à jour récentes ? Quelque chose d'inhabituel dans les journaux ? Après quelques minutes de conversation, le premier indice : « Le disque était presque plein… et puis, soudain, tout s’est arrêté. »
Lorsque le disque est plein : effets sur Plesk et MariaDB
Une partition de disque pleine peut avoir des conséquences dévastatrices sur un serveur, surtout s'il héberge une base de données MariaDB ou MySQL. Si le système manque d'espace pour écrire, les services commencent à échouer de manière imprévisible, les processus se bloquent et la base de données peut être corrompue lors de la tentative de terminer les opérations interrompues. C’est exactement ce que nous craignions.
En nous connectant au serveur via SSH, nous avons immédiatement confirmé la gravité de la situation : la partition principale était à 100 % d'utilisation. Cela signifiait que MariaDB n'avait plus de marge de manœuvre pour effectuer des opérations critiques, telles que la sauvegarde des journaux ou la gestion de l'annulation des transactions incomplètes. Dans de tels cas, le plus grand risque est que le moteur InnoDB reste bloqué dans un état incohérent, rendant impossible le démarrage de la base de données sans interventions de récupération manuelle.
La seule action immédiate possible était libérer de l'espace pour donner un peu de répit au système. Après une analyse rapide, nous avons localisé et supprimé les anciennes sauvegardes laissées dans /var/lib/psa/dumps/, des fichiers journaux surdimensionnés et d’autres données temporaires inutiles. Avec quelques gigaoctets récupérés, nous avons essayé de redémarrer MariaDB dans l'espoir que le problème se résolve de lui-même.
Mais non, le service n’arrêtait pas de tomber en panne.
À ce moment-là, nous avons commencé à creuser plus profondément. Après avoir analysé les journaux système et les journaux MariaDB, nous avons fait une découverte alarmante : le répertoire /var/lib/mysql/ il était complètement vide et sans aucune base de données. Il n'y avait aucune trace des fichiers .ibd, .frm o .MYD qui constituent normalement une base de données MySQL/MariaDB.
C'était une situation critique : Sans ces fichiers, il n’y avait pas de base de données à récupérer. Un serveur MySQL sans données est comme une voiture sans moteur. Mais la question était : où sont passés ces fichiers ? S'agissait-il d'une action automatique de Plesk ? MariaDB les a-t-elle supprimés lors d'une tentative de restauration échouée ?
En l’absence de sauvegardes disponibles, le problème est devenu encore plus grave. Par mesure de sécurité, nous avons immédiatement demandé au client si un service était actif. Sauvegarde automatique ou instantané du VPS. La réponse nous a fait frémir : aucun service de sauvegarde ou de capture instantanée n'avait été souscrit.
Sans sauvegarde récente, la récupération est devenue une course contre la montre. Nous vous suggérons ensuite de contacter le support de l'hébergeur pour vérifier si, par puro caso, il y avait un instantané non documenté de la machine. Bien que le service de snapshot ne soit pas inclus dans le plan, certaines sociétés d'hébergement conservent des copies temporaires pour un usage interne, en cas de panne ou d'accident.
L'hébergeur n'a donné aucune garantie, mais a promis de vérifier. En attendant, nous avons continué l’analyse technique, déterminés à découvrir où sont allés les fichiers de la base de données et s'il y avait un moyen de récupérer.
Plesk et MariaDB : un problème de gestion
L’une des premières choses que le développeur a essayé de faire a été de se connecter à Plesk pour vérifier l’état de la base de données et comprendre ce qui s’était passé. Mais là, il se retrouve confronté à un nouveau problème : Plesk lui-même n'était pas accessible. La raison ? Le panneau de gestion Plesk utilise une base de données appelée psa, qui réside sur MariaDB. Si la base de données ne parvient pas à démarrer, l'interface Web de Plesk devient également inutilisable, vous laissant sans aucun point de contrôle pour gérer le serveur.
Cette situation peut être particulièrement frustrante pour ceux qui ont choisi Plesk précisément pour son interface conviviale, convaincus qu'elle rendrait la gestion du serveur simple et immédiate. Cependant, si MariaDB plante, toute l'administration du serveur s'arrête, y compris la gestion des comptes, des domaines et des bases de données elles-mêmes. De plus, vos services Web et de messagerie électronique pourraient également être affectés, en particulier si vos configurations d’hébergement dépendent des informations stockées dans votre base de données. psa.
À ce stade, la seule possibilité d’intervenir est Connectez-vous en SSH avec les privilèges root et corrigez le problème manuellement à partir de la ligne de commande. Cela signifie devoir effectuer des diagnostics avancés, analyser les journaux système, identifier la cause du problème et appliquer les correctifs nécessaires sans l'aide d'une interface graphique.
Pour ceux qui ne sont pas familiers avec la gestion avancée de Linux, cela peut être une situation intimidante, et tenter de résoudre le problème sans les compétences adéquates peut entraîner des dommages supplémentaires. Des erreurs dans l'application des commandes, des tentatives de réinstallation incorrectes ou des modifications incorrectes des fichiers de configuration peuvent compromettre davantage le serveur, nécessitant une action de récupération après sinistre ou, dans le pire des cas, une réinstallation complète du VPS.
La découverte inattendue : le dossier mysql.repair-innodb.*.d
En regardant le répertoire /var/lib/mysql, nous avons trouvé une anomalie inquiétante : c'était complètement vide. Cela signifiait que si nous ne trouvions pas de copie des données ailleurs, la base de données serait irrémédiablement perdue. Cependant, nous savions que Plesk implémente certains mécanismes de récupération automatique en cas de problèmes avec InnoDB, nous avons donc commencé à chercher des indices.
Après quelques minutes d'analyse, nous avons découvert quelque chose d'intéressant dans le dossier. /var/lib/psa/dumps/: un répertoire appelé mysql.repair-innodb.20250320-093623.d. Ce nom indiquait clairement une tentative de réparation automatique effectuée par Plesk. Lorsque MariaDB détecte une corruption grave dans les tables InnoDB et ne parvient pas à démarrer, Plesk peut tenter de déplacer les données vers un répertoire de récupération, empêchant ainsi la base de données corrompue d'empêcher le service de redémarrer. Cependant, le processus de réparation automatique ne réussit pas toujours et, dans ce cas, il semble avoir été interrompu, laissant les fichiers bloqués à cet endroit.
À ce stade, la mission était claire : récupérer manuellement la base de données. Nous avons déplacé tout le contenu du dossier mysql.repair-innodb.20250320-093623.d de retour /var/lib/mysql, en restaurant l'emplacement d'origine des fichiers de données. Le cœur serré, nous avons tenté de redémarrer MariaDB.
Le service a démarré, signe qu'au moins la structure des données avait été reconnue, mais nous nous sommes vite rendu compte que certaines tables étaient signalées comme corrompues. Cela peut être dû au fait que la tentative de déplacement et de réparation précédente n'a pas abouti. Nous n'avons pas paniqué et nous sommes immédiatement passés à l'étape suivante : vérifier et réparer les tables pour restaurer complètement l'intégrité de la base de données.
Réparation et optimisation de bases de données
Nous avons lancé mysqlcheck --repair --all-databases, une commande fondamentale pour vérifier et tenter de réparer toutes les tables de la base de données. Cet outil, intégré à MariaDB, permet d'effectuer des contrôles d'intégrité sur les fichiers de données et de corriger toute corruption dans les tables. L'opération a pris plusieurs minutes : le serveur était sous stress en raison du manque d'optimisations récentes et de l'accumulation d'erreurs dues à la saturation du disque.
Nous avons surveillé attentivement la sortie du terminal, en attendant de voir des signaux positifs. Après quelques instants de suspense, les premiers messages encourageants ont commencé à apparaître : plusieurs tables ont été réparées avec succès. Certaines nécessitaient plusieurs tentatives, tandis que d’autres nécessitaient des opérations de récupération de données internes plus approfondies. Heureusement, aucune des tables principales n’était complètement irrécupérable, évitant ainsi le risque d’une perte d’informations catastrophique.
À ce stade, la base de données était de nouveau opérationnelle, mais nous ne nous sommes pas arrêtés là. Pour assurer une stabilité et des performances optimales, nous avons également effectué une opération d'optimisation avec la commande :
mysqlcheck --optimize --all-databases
Cette étape était cruciale car, après une réparation, les fichiers de table peuvent devenir fragmentés et occuper plus d’espace que nécessaire, ralentissant ainsi les requêtes. L'optimisation a consolidé les données, défragmenté les index et amélioré l'efficacité de la base de données.
Une fois cette opération terminée, nous avons effectué un dernier contrôle. Le service MariaDB était stable, les requêtes répondaient sans erreur et le système de gestion fonctionnait à nouveau correctement. Après trois jours d'inactivité, l'entreprise de notre interlocuteur a enfin pu reprendre son travail.
À l’autre bout du fil, nous avons entendu un long soupir de soulagement. « Je ne sais pas comment te remercier, je pensais avoir tout perdu ! » dit-il avec gratitude. Nous, en revanche, savions bien qu’avec une bonne expérience et une méthode structurée, même les situations les plus critiques peuvent souvent être résolues.
Pourquoi Plesk a déménagé /var/lib/mysql in /var/lib/psa/dumps/?
Lorsqu'une base de données MariaDB/MySQL présente des problèmes critiques liés à Tables InnoDB corrompues o fichiers de données corrompusPlesk peut activer automatiquement un mécanisme tentative de réparation d'urgence. Ce processus est démarré lorsque le service MariaDB ne parvient pas à démarrer correctement en raison d'erreurs d'intégrité sur les fichiers de base de données.
L’une des approches adoptées par Plesk dans ces scénarios est la déplacement temporaire de tout le contenu du répertoire /var/lib/mysql/ dans une zone sûre, qui se trouve généralement sous /var/lib/psa/dumps/. Ici, un dossier est créé avec un nom comme celui-ci :
/var/lib/psa/dumps/mysql.repair-innodb.AAAAMMJJ-HHMMSS.d
Ce dossier est conçu pour conserver une copie des fichiers de base de données dans leur état d'origine avant de tenter toute opération de réparation. L'idée derrière cette procédure est d'éviter que MariaDB reste dans un État corrompu irréversible, permettant à l'administrateur de tenter une récupération manuelle des données si nécessaire.
Quand Plesk décide de déménager /var/lib/mysql?
Le déplacement des fichiers de base de données vers un répertoire sécurisé peut se produire dans divers scénarios, notamment :
-
Saturation des partitions de disque – Si le serveur manque d’espace, MariaDB peut planter lors de l’écriture des fichiers journaux ou des données, laissant certaines tables InnoDB dans un état incohérent. Plesk peut alors tenter de déplacez les fichiers pour libérer de l'espace et essayez un démarrage propre.
-
Corruption de table InnoDB – Si MariaDB détecte des tables corrompues au démarrage, le moteur InnoDB peut refuser de démarrer pour éviter d’autres dommages. Dans de tels cas, Plesk peut intervenir en déplaçant les données vers une zone séparée pour isoler le problème et tenter une réparation.
-
La restauration automatique a échoué – Dans certains cas, Plesk peut essayer de démarrer MariaDB avec une option par défaut. récupération forcée (Comme
innodb_force_recovery), mais si l'opération échoue, elle peut laisser les fichiers dans/var/lib/psa/dumps/pour empêcher une base de données endommagée d'empêcher toute tentative de récupération ultérieure. -
Mises à jour ou plantages système inattendus – Lors d’une mise à niveau du moteur Plesk ou MariaDB, si le serveur est redémarré de manière incorrecte ou si des erreurs de compatibilité se produisent, certains fichiers de base de données peuvent être corrompus. Plesk pourrait alors se déplacer
/var/lib/mysql// conserver l'état des données avant de forcer un redémarrage du service.
Que se passe-t-il si le processus s’arrête ?
Si la tentative de réparation automatique échoue est interrompu ou échoue, la base de données n'est pas restaurée et le répertoire principal /var/lib/mysql/ reste vide, créant un problème sérieux : MariaDB ne trouve plus ses fichiers de données et ne peut pas démarrer.
À ce stade, Plesk n'affiche aucun avertissement clair à l'administrateur sur les raisons pour lesquelles la base de données ne fonctionne pas. La seule façon de le savoir est connectez-vous via SSH et inspectez manuellement les dossiers.
Si vous trouvez un dossier comme /var/lib/psa/dumps/mysql.repair-innodb.*.d, il est très probable que Plesk ait tenté une récupération automatique mais n'ait pas réussi à la terminer. Dans ces cas, il est nécessaire Déplacer manuellement les fichiers du dossier de récupération vers le répertoire d'origine (/var/lib/mysql/) et procéder à une restauration manuelle de la base de données.
Plesk essaie, ça aide, mais ce n'est pas suffisant
Bien que Plesk tente de gérer les situations d'urgence par lui-même, son mécanisme de réparation n'est pas infaillible et peut laisser votre serveur dans un état de état critique si l'opération ne se termine pas avec succès.
À moins que vous n’ayez une compréhension approfondie de la gestion de la ligne de commande MariaDB, la récupération d’une base de données qui a été automatiquement déplacée par Plesk peut être une opération complexe et risquée.
Pour cette raison, lors de la gestion d'un serveur avec Plesk, il est essentiel de :
- Surveiller l'espace disque pour éviter les saturations soudaines.
- Effectuer des sauvegardes régulières de la base de données, indépendamment des fonctionnalités automatiques de Plesk.
- Avoir un accès SSH avec des privilèges root pouvoir intervenir manuellement en cas de problèmes graves.
Pour plus de détails sur les procédures de réparation automatique de Plesk, vous pouvez consulter la documentation officielle :
La morale : Autonomie vs. Expertise système
Plesk est probablement le meilleur des panneaux Web pour la gestion de l'hébergement et des serveurs, mais s'appuyer exclusivement sur une interface graphique n'est pas toujours un choix gagnant. Le principal problème de Plesk n’est pas tant sa fonctionnalité, mais la fausse sécurité qu’il peut offrir à ceux qui l’utilisent sans compétences système avancées.
De nombreux utilisateurs font confiance à Plesk en pensant que l'interface graphique est suffisante pour assurer une gestion complète du serveur, sans jamais avoir à toucher à la ligne de commande. Cependant, lorsque des problèmes critiques tels que le crash de MariaDB surviennent, l'ensemble de l'infrastructure basée sur Plesk tombe en panne, rendant toute intervention impossible sans accès SSH et compétences Linux avancées.
Un autre aspect qui est souvent négligé est que Plesk, par défaut, n'offre pas de protection adéquate contre les scénarios catastrophiques, comme la saturation du disque ou la corruption de la base de données. Si un utilisateur ne configure pas manuellement instantanés réguliers, sauvegardes automatiques et surveillance proactive des ressources, risquent de se retrouver dans des situations d’urgence sans issue.
Et voici le nœud du problème : Ceux qui utilisent Plesk ne sont presque jamais administrateurs système. La cible typique de cet outil sont les développeurs, les agences, les responsables e-commerce ou les freelances, qui ont besoin de gérer des sites Web et des applications sans avoir à s'occuper de l'infrastructure sous-jacente. Cela conduit inévitablement à un cercle vicieux : l’utilisateur s’appuie sur Plesk en pensant qu’il n’aura jamais à faire face à des problèmes complexes, mais lorsque ceux-ci surviennent, il n’a pas les outils ni les connaissances pour les résoudre.
Lorsqu'un serveur tombe en panne, lorsqu'une base de données disparaît, lorsque Plesk lui-même devient inaccessible, Il ne s’agit plus de cliquer sur des boutons ou de suivre des guides en ligne. Il faut de réelles compétences, des outils de ligne de commande, des années d’expérience pour savoir comment résoudre le problème sans aggraver la situation.
La une solution plus prudente ? Faites confiance à des administrateurs système Linux professionnels, forts de plusieurs décennies d’expérience, capables de prévenir et de gérer les problèmes critiques avant qu’ils ne deviennent des catastrophes. Une interface graphique peut faciliter la gestion quotidienne, mais lorsque tout va mal, C'est l'expérience d'un véritable expert qui fait la différence entre la récupération de données et la perte totale de données..
