Bonjour à tous.
Depuis 48h, OVH a bloqué mon hébergement performance (cluster 107). En général quand cela se produit, c'est en raison d'un hack du site web, mais on peut toujours accéder au FTP pour récupérer les fichiers, trouver la faille, corriger, et réactiver le site avec un chmod 755 depuis Filezilla. Dans mon cas c'est différent :
Je n'ai plus accès au FTP : l'authentification fonctionne, mais les droits sur le répartoire / sont à 000 : je ne peux donc pas accéder à mes fichiers.
Je ne peux plus non plus accéder en FTP aux archives de fichiers snap-1, snap-2... : les droits sont là aussi interdits sur le dossier /
Je n'ai pas reçu d'emails d'OVH m'informant du blocage du site, ce qui est fait généralement quand un hack est arrivé : on reçoit ce fameux emails indiquant "votre site a été piraté, etc... puis bloqué...". Mais donc mon cas, pas d'email. Et le support ne m'a pas dit non plus que mon site avait été hacké.
Le support ne me donne aucune information : ils m'ont annoncé avoir lancé un scan de hack sur mes fichiers le premier jour, mais depuis, pas d'info, ils n'ont donc rien trouvé. Je ne sais pas quel est le problème, ils ne me redonnent pas accès à mes archives snap-X, ils ne me disent pas si elles sont toujours présentes, je ne sais donc pas si j'ai tout perdu.
Quand je regarde les activités de maintenance d'OVH, je constate qu'ils ont lancé des tâches de maintenance il y a 3 jours sur plusieurs clusters, dont le 107 (le mien) : https://web-cloud.status-ovhcloud.com/incidents/ywctn0lhyrjj
Je ne sais pas si c'est une coïncidence, mais 24h plus tard mon site est bloqué, mon répertoire / est en accès interdit, et je n'ai plus d'archives.
Nous faisons suite à votre signalement d’indisponibilité de votre hébergement.
Je vous assure qu'il n'y a pas eu de suppression de fichiers sur votre hébergement.
En effet l’interruption que vous rencontrez est directement liée à cette maintenance (https://web‑cloud.status‑ovhcloud.com/incidents/ywctn0lhyrjj).
Cette opération de maintenance impacte chaque UID de fichiers de votre hébergement. En raison du nombre très important de fichiers présent sur votre hébergement (plus de 170 millions de fichiers), le traitement nécessite davantage de temps que prévu et reste donc en cours.
Nous sommes conscients des désagréments que cela engendre et vous présentons nos excuses les plus sincères.
Ils ont supprimé les 170M de fichiers qui étaient des fichiers de session dans un dossier, mais ils n'ont toujours pas réactivé mon hébergement qui est marqué bloqué. Je n'ai reçu aucun mail suite au blocage, ils ne m'ont donné aucune explication sur ce qui avait été fait par la tâche de maintenance, ni aucune date de remise en ligne, c'est juste lamentable.
Donc en gros ils ont planté mon hébergement depuis maintenant 6 jours, et n'ont toujours rien fait pour le remettre en ligne. Je suis surpris d'être le seul dans ce cas, et si je suis réellement le seul, pourquoi ne se focalisent ils pas sur mon hébergement pour le réactiver ?
Je suis preneur de votre avis, ou de témoignages de personnes se trouvant dans le même cas que moi.
En raison du nombre très important de fichiers présent sur votre hébergement (plus de 170 millions de fichiers), le traitement nécessite davantage de temps que prévu et reste donc en cours.
Vous avez 170 millions de fichiers.
Quel abonnement avez vous exactement chez OVH ?
Plus de 170 millions de fichiers sur votre hébergement, ce n’est pas un nombre que le système puisse traiter dans les délais habituels
Le fait que vous ne receviez aucune nouvelle information ne signifie pas que vous ne pouvez pas la demander. Répondez à votre ticket de support et mentionnez le numéro d’incident ywctn0lhyrjj ainsi que le cluster 107. Expliquez que votre hébergement est bloqué depuis 6 jours, que vous avez vu que la maintenance s’est officiellement terminée le 7 août et que vous avez besoin de savoir :
Si la maintenance est terminée et quel est l’état actuel de votre hébergement.
Quel est le plan d’action pour réactiver votre service et restaurer l’accès à vos fichiers.
Une estimation du délai de résolution.
J’espère que ces informations vous aideront à mieux comprendre la situation et à savoir où insister pour obtenir une réponse.
J’espère que vous obtiendrez une solution au plus vite.
Je n'ai pas 170M de fichiers, je n'ai que 135 Go de stockage utilisé donc c'est impossible, c'est ce que me dit le support. Ils indiquent que ce sont des fichiers de session, ça me semble impossible. Je leur ai dit de supprimer ces fichiers.
La tâche de maintenance n'est pas terminée. J'ai déjà posé toutes ces questions, et je n'ai aucune réponse du support, ils ne répondent pas. Ils ont reconnu que la faute était chez eux mais ne font rien pour rétablir le service.
J'ai un hébergement performance. J'ai déjà appelé au 1007, on ne peut plus les joindre pour les incidents techniques, ils ont coupé la ligne cette semaine (je suppose qu'ils avaient trop d'appels). J'ai essayé par le chat, sans succès. J'essayerai sur Twitter demain, merci pour l'info.
Votre service est-il toujours bloqué ?
La maintenance que vous signalez a effectivement eu comme effet une suspension des quelques clients concernés le temps de procéder et nous avons eu quelques cas avec des nombres de fichiers présents dépassant les usages raisonnables.
Je suis personnellement intervenu sur certains cas remontés par le support dont un sur le même cluster que vous avec un profil similaire a ce que vous décrivez, il y avait bien 170 millions de fichiers de session.
Ce qui dans un usage standard n'est pas normal, les fichiers de session étant des fichiers éphémères. Cela indique un défaut dans un plugin de votre CMS ou le CMS lui même qui ne réalise les nettoyages réguliers des dis fichiers.
Si votre problème est toujours en cours, donnez moi votre numéro de ticket support que je check.
--
Bruno B.
Team Lead Infrastructures Hébergements Mutualisés
Merci pour votre réponse Bruno. L'hébergement est revenu en ligne hier, mais je n'ai toujours pas accès aux sauvegardes FTP.
Même s'il y a un défaut du CMS qui ne supprime pas les fichiers de session, il n'est pas normal de lancer un changement de cluster (puisque c'est ce qui se cache derrière l'opération de maintenance sans jamais être expliqué) sans avoir vérifié combien de fichiers il y avait à transférer du nouveau vers l'ancien, et sans prévenir non plus les clients. Un simple comptage des fichiers aurait pu lever le problème en avance de phase : j'aurais alors pu réaliser la suppression des fichiers de session. Et s'il y avait réellement 170 M de fichiers, je suis surpris que leur suppression ait pris 5 jours comme le support le dit, ça reste relativement lent...
Il n'est pas non plus normal que le support ne donne aucune information sur les raisons du blocage de l'hébergement quand on lui pose la question et qu'il faille se battre pour obtenir en semblant de réponsE;
La maintenance a été annoncée en avance de phase via la page status comme nous le faisons systématiquement pour les maintenances à impact connu comme celle-ci.
Et je tiens à préciser, il n'a nullement été lancé un changement de cluster, nous avons comme le support vous l'a précisé dû procéder à changement d'uid de certains hébergements, rien de plus.
Ce qui nous a surpris ce sont les quelques cas comme le votre, nous connaissons quelques usages intensifs, mais ces extrêmes sont rares et peu imaginables pour ce type de produit.
Quand nous avons eu le feu vert dans le ticket pour nettoyer les fichiers, nous l'avons fait, mais une manipulation de fichiers lance de multiples appels aux serveurs de fichiers pour être prise en compte, multiplié par 170M, cela prend énormément de temps qu'il nous est impossible de compresser.
Pour les accès aux sauvegardes, vous pouvez lancer la restauration depuis le manager sans souci. Mais dans des cas comme le votre, recopier les 170M de fichiers a de fortes chance de dépasser les délais prévus et d'échouer.
En FTP, vous aurez accès aux sauvegardes réalisées à postériori de l'intervention, pour celles avant, elles sont sur l'ancien l'uid et un snapshot de backup est immuable, nous ne pouvons donc pas changer les uid pour rendre l'accès à avant l'intervention. Seul la restauration via le manager gère l'adaptation des uid lors de la restauration (attention la restauration via le manager restaure 100% des fichiers avec écrasement de l'existant)
--
Bruno B.
Team Lead Infrastructures Hébergements Mutualisés
En effet, le CMS n'a pas supprimé ces fichiers, je n'en avais pas connaissance, mais ça n'a aucun impact sur mes clients et cela ne regarde QUE MOI.
Ce n'est pas le cas de l'opération de maintenance qui a coupé le site de mes clients pendant 7 jours parce que personne chez OVH n'a eu l'idée de vérifier le nombre de fichiers avant de la lancer : c'est n'est pas moi qui suit à l'origine de cette opération de maintenance et donc à la coupure de mon hébergement.
Si le site avait été bien surveillé et géré et donc tous les fichiers temporaires effacés vous n'auriez pas eu de coupure ni d'indisponibilité de site.
Bonjour, il y a une information que je n'ai pas vu passer.
Ces 170 M fichiers, étaient-ils tous logés dans un unique répertoire ? Ou bien dans une arborescence ?
exemple 1: /sessions/session000000001 jusque /sessions/session170012345
exemple 2: /sessions/000/000/session000000001 jusque /sessions/170/012/session170012345
Si vous voyez dans l'exemple 2, chaque dossier contient au maximum 1000 sous-dossiers ou 1000 fichiers de session.
Par contre dans l'exemple 1, un unique dossier qui contient un nombre incroyablement élevé de fichiers, va engendrer une charge exponentielle sur le serveur. La conception des filesystems ne va jamais favoriser cette mauvaise utilisation.
