10 mois de notes du blog ont pour l’heure disparu – en raison d’une mauvaise assistance par l’hébergeur OVH

Comme vous le constatez, la note la plus récente antérieure à celle-ci date d’août 2020. Pourquoi ? Ce site/blog wordpress est hébergé par OVH. Fin mai, l’accès à l’interface de gestion est devenu impossible. Ce problème, rencontré antérieurement à plusieurs reprises, était provoqué par une base de données parvenue à saturation (son maximum autorisé atteint). Mais, antérieurement, ce problème était anticipé et fut rarement atteint, parce qu’une alerte était envoyée dans les jours qui précédaient la possible saturation de la base de données. Dans ce cas, il n’en fut rien – il n’y eut aucune alerte. Et, brusquement, l’interface était inaccessible. Le service d’assistance d’OVH a été contacté. La personne qui a pris en charge ce qui s’appelle un “ticket” a répondu, en prenant acte de cette saturation, qu’il fallait sauvegarder et restaurer la base de données, en l’implantant sur une autre base de données disponible. L’action de sauvegarde est une opération “simple”, puisque c’est le système informatique qui l’opère. Mais ce que le gestionnaire de cette assistance ne précisait pas, c’est que la base de données n’avait pas à être supprimée. Il aurait fallu ou accéder à l’interface dite “ftp” de gestion du site pour modifier la base de données utilisée par le site pour les publications, ou, plus simplement encore, procéder à une purge de la base de données saturée, afin d’en éliminer des éléments sans intérêt, ce qui aurait permis de se servir de la base de données qui était menacée de saturation pendant plusieurs semaines ou plusieurs mois encore. Des sites spécialisés en sites wordpress le disent : attention à la base de données ! C’est là que se trouve les informations essentielles (notes, images, …). Or, à l’erreur qui a consisté à supprimer la base de données saturée, s’est ajoutée que la sauvegarde de la base de données a généré une “base de données corrompue” (format rar). Du coup, sa restauration sur la nouvelle base de données est devenue impossible. Et aucune sauvegarde récente du site/blog n’avait été opérée par l’intermédiaire de ce que l’on appelle un plug-in, dans l’interface de gestion du blog (plusieurs outils permettent de réaliser de telles sauvegardes, régulièrement). Bref, pendant quelques jours, le site/blog est resté indisponible, puisqu’il n’y avait plus rien dans sa mémoire. En outre, OVH a fait évoluer son assistance : antérieurement, il était facile de “créer un ticket” pour bénéficier d’un conseil, mais actuellement, sauf si vous avez souscrit à une assistance d’au moins 50 euros par mois, cela n’est plus le cas, et il a été mis en place un système qui restreint les possibilités de créer un tel ticket. En outre, si vous y parvenez, et que vous recevez une réponse, l’auteur de la réponse se permet de clore la demande, même si de votre côté, sa réponse n’est pas suffisante pour traiter le problème. Heureusement, après reconstruction d’un compte wordpress pour le blog, une sauvegarde effectuée à l’été 2020 a été retrouvée et a permis de publier ce que vous trouvez actuellement. Reste que la base de données sauvegardée initialement et qui est informatiquement considérée comme corrompue, alors qu’elle contient l’ensemble des publications effectuées depuis la création du site/blog jusqu’à fin mai 2021, est encore disponible, et, quand elle sera réparée, si elle peut l’être, l’ensemble de ces parutions redeviendront alors accessibles. Si vous avez un site/blog wordpress, soyez prudents, et usez d’un outil de sauvegarde – la plupart sont payants. Pour être complet sur ce sujet, si l’assistance initiale d’OVH a été mauvaise, l’assistance d’OVH via Twitter a pris le relais pour un soutien réel, sérieux – mais là encore insuffisant, puisque la perte complète, et désormais heureusement partielle, du site/blog n’est pas imputable à l’usager mais à cette assistance technique initiale qui s’est contentée de répondre en quelques petits mots, quand il fallait prendre le temps de quelques phrases précises, notamment en expliquant qu’il ne fallait tout de même pas toucher à la base de données saturée.