📑 Sommaire

    La suppression ou la corruption d’une base de données est la perte de données la plus brutale que puisse connaître un propriétaire de site : vos fichiers sont toujours là, le site semble presque se charger, mais il n’y a plus de contenu. Commandes, membres, articles — tout était dans la base. Cet article détaille, dans l’ordre, ce qu’il faut faire.

    1. Arrêtez immédiatement les écritures

    C’est l’étape la plus critique de tout le processus, et la plus souvent négligée. Si la base a été supprimée ou corrompue, tant que le système continue de tourner, de nouvelles données s’écrivent par-dessus et vos chances de récupération diminuent de minute en minute.

    • Passez le site en mode maintenance ; empêchez l’enregistrement de nouvelles commandes, inscriptions et commentaires.
    • Arrêtez les tâches d’import ou de synchronisation automatiques.
    • Avant d’essayer de « réparer » quoi que ce soit dans la panique, faites une copie de l’état actuel.

    ⏱ Vous courez contre la montre

    Des données supprimées restent techniquement récupérables tant que rien ne s’est écrit par-dessus. Plus le site tourne, plus cette chance s’évapore vite. La première chose à faire n’est ni de nettoyer ni de réparer, mais d’ arrêter.

    2. Diagnostiquez correctement ce qui s’est passé

    Ce qu’il faut faire dépend entièrement du type de problème. Il existe trois situations distinctes à ne pas confondre :

    • La base ou la table a été supprimée : les données ont réellement disparu. La seule solution est la restauration depuis une sauvegarde.
    • La table est corrompue : les données sont là mais illisibles. Des outils de réparation peuvent les récupérer.
    • La connexion est rompue : données et tables sont intactes ; le problème vient du nom d’utilisateur, du mot de passe ou de l’adresse du serveur dans le fichier de configuration. C’est le meilleur cas, sans aucune perte.

    Si le site affiche « erreur de connexion à la base de données », écartez toujours d’abord la troisième hypothèse — c’est fréquent après un déménagement de serveur ou un changement de mot de passe, et aucune donnée n’est perdue.

    3. En cas de corruption, tentez d’abord la réparation

    La corruption de table vient généralement d’un arrêt brutal du serveur, d’un disque plein ou d’une panne matérielle. La plupart des outils d’administration de bases proposent une fonction de vérification et de réparation, accessible depuis le gestionnaire de bases de votre panneau d’hébergement. Avant de réparer, n’oubliez pas de copier les fichiers existants — le processus peut corrompre davantage les données.

    4. Restaurez depuis une sauvegarde

    Si les données ont réellement été supprimées, c’est la seule vraie solution. Points de vigilance lors de la restauration :

    • Choisissez la bonne date. La sauvegarde la plus récente n’est pas toujours la meilleure ; si le problème dure depuis un moment, il vous faudra une copie plus ancienne.
    • Testez d’abord. Si possible, chargez la sauvegarde dans une base séparée, vérifiez son contenu, puis passez en production.
    • Mettez à jour les informations de connexion. Si vous restaurez sur un autre serveur ou sous un autre nom de base, le fichier de configuration de votre site doit aussi être mis à jour.
    • Essayez de récupérer les données intermédiaires. Vous pouvez reconstituer partiellement les commandes postérieures à la sauvegarde à partir des relevés de votre prestataire de paiement, et les inscriptions depuis les notifications e-mail.

    5. Trouvez la cause

    Une base ne se supprime pas toute seule. Causes fréquentes : une commande exécutée sur la mauvaise base, la suppression du mauvais compte depuis le panneau d’hébergement, un site compromis, une extension défaillante ou un quota disque saturé. Sans identifier la cause, le risque de récidive est élevé.

    Limiter la perte : la fréquence de sauvegarde

    La vraie question à se poser après une récupération est celle-ci : « Quelle quantité de données puis-je au maximum me permettre de perdre ? » La réponse détermine directement votre fréquence de sauvegarde.

    • Site vitrine : le contenu change rarement ; hebdomadaire ou quotidien suffit.
    • Blog ou site d’actualité : quotidien est raisonnable ; vous perdez au pire une journée de contenu.
    • E-commerce : le quotidien coûte cher. L’horaire réduit la fenêtre de perte à une heure.
    • Boutique à fort trafic : peut nécessiter mieux que l’horaire.

    Les fichiers changent rarement, la base change en permanence. Pouvoir leur attribuer des fréquences distinctes améliore donc la protection tout en réduisant le coût : fichiers quotidiens, base horaire, par exemple.

    🗄 Donnez à la base sa propre fréquence

    Chez Yedekalma, fichiers, base de données et e-mail sont des composants séparés, chacun avec sa propre fréquence. De plus, la base est sauvegardée de façon incrémentale au niveau des tables : seules les tables modifiées sont exportées, si bien que des sauvegardes fréquentes n’épuisent pas votre serveur. Découvrir la sauvegarde de base de données.

    En résumé

    En cas de perte de base, l’ordre est clair : arrêter → diagnostiquer → réparer (si corrompue) → restaurer depuis la sauvegarde → trouver la cause. Le quatrième maillon de cette chaîne casse si vous n’avez pas de sauvegarde. Le vrai travail consiste donc à mettre en place le dispositif avant la perte.

    Questions fréquentes

    Une base MySQL supprimée peut-elle être récupérée ?

    Si la base a réellement été supprimée, la restauration depuis une sauvegarde est le seul moyen fiable. Si le système a continué de tourner après la suppression, de nouvelles données ont pu s’écrire par-dessus et les chances de récupération bas niveau chutent rapidement. D’où l’importance de passer le site en maintenance et d’arrêter les écritures dès que vous vous en apercevez.

    Une « erreur de connexion à la base » signifie-t-elle une perte de données ?

    Le plus souvent non. Cette erreur vient généralement d’un nom d’utilisateur, d’un mot de passe ou d’une adresse de serveur erronés dans le fichier de configuration ; les données sont intactes. C’est fréquent après un déménagement de serveur ou un changement de mot de passe. Vérifiez les informations de connexion avant de paniquer.

    Une table de base corrompue peut-elle être réparée ?

    Généralement oui. La corruption vient d’un arrêt brutal, d’un disque plein ou d’une panne matérielle, et se corrige avec la fonction de vérification/réparation des outils d’administration. Copier les fichiers existants avant la réparation est indispensable ; le processus peut corrompre davantage les données.

    À quelle fréquence sauvegarder ma base de données ?

    Cela se détermine par la perte maximale acceptable. Hebdomadaire ou quotidienne pour les sites vitrines, quotidienne pour les blogs et sites d’actualité, horaire pour l’e-commerce, plus fréquente encore pour les boutiques très actives. Les fichiers changeant rarement, donner à la base un rythme plus soutenu qu’aux fichiers améliore la protection et réduit le coût.

    Vais-je perdre les commandes intermédiaires en restaurant ?

    Oui, les enregistrements créés après la date de la sauvegarde disparaissent avec la restauration. Pour limiter cette perte, essayez d’exporter les enregistrements critiques de la base actuelle avant de restaurer ; les relevés de votre prestataire de paiement et vos e-mails de notification de commande permettent aussi de reconstituer une partie des données manquantes.