Rapport d'intervention du 14 août 2025 : Les travaux de maintenance annoncés ont pris fin vers 5h45 aujourd'hui.
La maintenance a pris plus de temps que prévu à cause d'un problème de démarrage serveur lié à d'énormes données de cache « Redis » que le serveur tentait de charger d'un coup dans la RAM au démarrage.
Veuillez nous excuser pour cet inconvénient 🙏
Nous avons eu besoin d'un peu de temps pour trouver la cause de ce problème au démarrage et supprimer ces données de cache Redis chargées inutilement.
Des mesures vont être mises en place pour à l'avenir demander à Redis de partir sur des données fraîches aux reboot, afin d'éviter que ce problème n'apparaisse lors de prochaines mises à jour de kernel + reboots.
Nos utilisateurs profitent maintenant de MariaDB 11.4.7, ainsi que d'un kernel Linux parfaitement à jour dans sa version 5.14.0-570.32.1.el9_6.
Les prochaines 48 heures nous permettront de voir l'effet de ces améliorations sur nos outils de monitoring pour envisager la suite.
Merci pour votre confiance !
____________________
Annonce initiale :
Malgré nos efforts pour éviter ce type de problème, nous avons expérimenté, en pleine nuit, de légères perturbations pour la 2e fois en moins d'une semaine.
Perturbations liées à des travaux de maintenance et des tâches réalisées de nuit...
(https://massivehoster.com/wp-content/uploads/2025/08/incident-backups-mh.png)
En effet, nous avons eu cette nuit un souci relatif à nos routines de backups nocturnes.
Pour rappel, nous avons chez MassiveHoster plusieurs dispositifs de sauvegarde, car par mesure de sécurité, nous décentralisons les données vers 2 emplacements distants (alors qu'à notre connaissance, les concurrents sur notre gamme de prix le font généralement à un seul emplacement, dans la room d'à côté du même datacenter 👀).
Même si notre choix d'architecture est plus long et coûteux (réduisant notre "marge"), ce type de sécurité pour lequel nous avons opté nous tient à coeur, car c'est (bien plus sûr) indispensable en cas d'incident majeur.
Concrètement,
- Nous effectuons un backup hebdomadaire de secours du serveur au complet / non incrémental, qui démarre dans la nuit de dimanche à lundi et prend environ 24h à être complété, car la tâche est mise en priorité basse pour éviter la charge
- En parallèle, nous effectuons du mardi au dimanche, tôt dans la nuit, des backups incrémentaux vers le cloud. Il s'agissait d'une tâche généralement très rapide, entre 90 et 180 minutes par jour. Mais vu la croissance très rapide de MassiveHoster, les choses évoluent rapidement.
- Enfin, le mercredi seulement (donc aujourd'hui), tard dans la nuit, nous lançons un backup système destiné à notre DRP (son but est de nous permettre de rétablir aussi rapidement que possible un serveur qui se verrait détruit physiquement, comme par un incendie ou une autre catastrophe naturelle).
Le souci qui s'est produit cette nuit est que ce Backup DRP du mercredi (tard dans la nuit) s'est lancé alors que notre Backup quotidien (tôt dans la nuit) n'avait pas eu le temps de se compléter à 100% 😮
...ce qui a créé une superposition et une réaction en chaîne : ralentissement du backup quotidien en cours ; charge trop importante sur le serveur d'hébergement..., donc perturbations momentanées ayant pu se ressentir sur les comptes utilisateurs.
Le fait est que nous avons de plus en plus de données à sauvegarder et à décentraliser ! 🔥
Donc, les backups qui mettaient toujours uniquement quelques heures à être complétés pendant la nuit, peuvent maintenant durer toute la nuit et commencer à déborder sur la matinée, lorsque le trafic en Europe arrive sur vos sites, créant ainsi une consommation cumulée qui peut perturber nos services 😵💫
En complément, nous savons que notre clientèle de #SEO est fermement attachée à son taux de disponibilité (uptime), même nocturne, et monitor judicieusement la disponibilité de ses sites, à tel point qu'à chaque tâche de maintenance planifiée réalisée en plein milieu de la nuit (et nous en réalisons beaucoup ces dernières semaines), pour une indisponibilité approximative de 5 minutes, nous recevons déjà plusieurs DM et Tickets pour nous en informer 😅
Nous sommes toujours heureux de communiquer de manière proactive et de répondre à chaque question, en fournissant toujours les détails des raisons identifiées qui ont engendré telle ou telle perturbation... il suffit de demander 😉
Néanmoins, même si nous fournissons des services premium de hosting aux PME depuis 2009 déjà, nous savons aussi qu'en tant que jeune acteur du secteur avec « MassiveHoster » (un service ouvert en bêta depuis seulement 1 an), notre clientèle nous observe et attend de se faire un avis à long terme sur notre offre 👀
Et notre clientèle ne nous pardonnera pas de lui infliger les mêmes désagréments que ce que l'ancien fournisseur a fait subir.
Pour ces raisons,
Nous savons que le taux de disponibilité (uptime) est tellement important pour nos utilisateurs, qu'il nous arrive même de retarder certains travaux de maintenance utiles qui devraient être réalisés de nuit.
Retardés, car ils génèrent inévitablement une certaine période de downtime...
Nous pensons à des travaux tels que la mise à jour critique de MariaDB ou encore la mise à jour de Kernel (noyaux Linux) qui offrent souvent des correctifs améliorant les performances et la stabilité d'une infrastructure.
Si vous êtes arrivé jusqu'ici, vous devez certainement penser comme nous qu'il n'est pas raisonnable de retarder des mises à jour softwares utiles, uniquement pour éviter les plaintes de quelques utilisateurs... 🤔
Pourtant, lorsqu'on est une jeune offre, avec une architecture technique qui est toujours en cours d'apprentissage, chaque plainte ou avis négatif compte et peut impacter négativement la réputation, et donc, la croissance du projet ♾
C'est pourquoi nous marchons sur des oeufs.
Néanmoins, avant d'être « Entrepreneurs », nous sommes « Hébergeurs », et nous devons veiller à la stabilité de nos services et avancer...
Même si cela implique des tâches de maintenance qui peuvent frustrer certains utilisateurs qui ne connaissent pas l'envers (technique) du décor.
De toute façon, certaines interruptions arrivent toujours tôt ou tard, car une infrastructure, par définition, doit toujours réaliser des maintenances et est toujours victime d'incidents un jour ou l'autre, même si le but du jeu est que cela soit le moins fréquent possible et d'agir sans délai lorsque cela arrive.
C'est pourquoi demain, jeudi, de nuit, nous mettrons à jour l'ensemble des composants qui avaient été post-posés, avec interruption temporaire de MySQL et redémarrage physique complet.
****
Vous devrez donc vous attendre à un certain délai d'interruption pendant ces tâches, de nuit, désolé 😬
****
Nous allons également entreprendre ensuite de nouveaux travaux, comme nous le faisons depuis plusieurs mois, pour continuer d'optimiser tout ce qui peut l'être sur notre jeune infrastructure en apprentissage...
Spontanément, nous pensons à la marge de progression que nous avons pour continuer si possible de faire évoluer nos technologies "web server", ainsi qu'à revoir la manière dont sont exécutés nos routines de sauvegardes pour faire face à la quantité massive et grandissante de données dynamiques que nous sauvegardons pour vous quotidiennement.
Bien sûr, il s'agit de travaux que nous devons réaliser conformément à la structure unique de notre offre aux tarifs défiant toute concurrence.
En effet, le projet a été initié avec plusieurs priorités, dont celle de vous offrir le meilleur Rapport Qualité-Prix... et dans « Rapport Qualité-Prix », il y a aussi « PRIX ».
La même équipe mène d'autres projets « hosting » depuis plusieurs années, notamment via EasyHoster (https://www.easyhoster.com/), avec des stats d'Uptime défiant toute concurrence et croyez-le, moins de défis techniques... car menés sur d'autres technologies :
Serveurs cPanel, Serveurs moins "partagés", etc.
Les défis auxquels nous faisons face progressivement sont directement liés aux tarifs concurrentiels que nous désirons maintenir afin de permettre à nos clients de réaliser des économies sur leur hébergement web.
Encore une fois, nous admettons volontiers être toujours en apprentissage sur le terrain du « low cost », avec des tarifs et un service qui se sont finalement avérés intenables par d'énormes concurrents directs, qui ont augmenté leur tarif et revu leur SAV à la baisse 👀
Nous invitons donc comme toujours, notre communauté de gentils clients, s'ils le souhaitent, à soutenir ce projet naissant et en cours d'évolution, en s'armant de patience concernant les imperfections en cours de résolution et les quelques minutes d'instabilités par ci par là, de nuit.
Nous ne pouvons pas tout faire en un jour 😅
Et pour toute demande plus spécifique, nous restons avec plaisir ouverts aux échanges en privé, par DM et via les Tickets sur notre site.
Merci pour votre intérêt et à bientôt pour la suite 😉