Discussion :

[Killing Joke]

Je ne comprends même pas comment certains peuvent s'imaginer qu'une offre "cloud" puisse tout sauvegarder en automatique en tâche de fond sans avoir rien à faire.

Ca peut être techniquement possible dans certains cas, mais c'est bien évidemment plus compliqué que celà dans l'immense majorité des situations réelles, par ex. si vous avez un serveur dédié avec une base de données (non managée = que vous gérez vous mêmes), vous voulez bien sûr que la sauvegarde permette de retrouver des données cohérentes en base après restauration. Pour çà, il n'y a pas 36 solutions : il faut soir avoir une base répartie sur plusieurs instances (fut-ce du NoSQL), soit au moins faire des exports consistents (pour que la première table exportée soit en ligne avec la dernière). Et çà, c'est tellement dépendant de l'architecture interne de ce qui est hébergé qu'il est douteux que celà puisse être automatisé en hébergement sur dédié par l'hébergeur - ou alors il faut être chez AWS avec une offre "database as a service" (ce qui à ma connaissance n'est pas proposé par OVH ici).

Et une offre "cloud", c'est juste une offre commerciale, il peut y avoir toute une gamme de services plus ou moins évolués, plus ou moins chers, plus ou moins automatisés, mais çà reste des services au sein d'une offre commerciale - il faut bien sûr faire le mapping entre ses besoins (quelqu'un qui saura facilement redéployer un site statique en intégration continue peut même ne pas avoir besoin de sauvegardes, car il a les fichiers sources ailleurs et les outils pour tout forker ailleurs très rapidement) et les propositions commerciales, avec toute la gamme de questions classiques allant de "comment déployer", "comment administrer au jour le jour", etc. à "comment remonter le service en cas de crash".

[pebaroiller]

Moi ce qui me fait halluciner , c'est tous ces "soi-disant" professionnels qui depuis 1 semaine sont là à pleurer parce que leur serveur est mort !
pas de sauvegarde ... pas de plan de secours ... pourtant c'est un minimum !!!

[Invité]

Moi ce qui me fait halluciner , c'est tous ces "soi-disant" professionnels qui depuis 1 semaine sont là à pleurer parce que leur serveur est mort !
pas de sauvegarde ... pas de plan de secours ... pourtant c'est un minimum !!!

Attention. Il n'y a pas que des professionnels pseudos ou non. Il y a plein de petites associations de bénévoles, qui n'ont pas de connaissance particulière en informatique et dont les moyens souvent très limités ne permettent pas d'avoir des solutions plus pérennes.... C'est le système D et la formation sur le tas qui prévalent ... et parfois le tas est semé d'embuches.

[Patrice Henrio]

Utiliser un hébergeur de sites sans faire soi-même de sauvegarde c'est prendre la mer sans s'assurer qu'on a un gilet de sauvetage. OVH héberge plusieurs de mes sites (simples) mais tout est sauvegardé chez moi en cas de pépin. Parce qu'après tout même la sauvegarde de chez OVH peut merder à un moment.
Il n'est pas difficile de programmer soi-même une sauvegarde régulière de ses données ... surtout si on a un copain qui s'y connait.

[Invité]

Bonjour,

Parce qu'après tout même la sauvegarde de chez OVH peut merder à un moment.

Je confirme , j'ai fréquenté un forum il y a quelques année. Suite à une erreur d'encodage dans un message lors de l'écriture en BDD > crash du site + wiki . Résultat 5000 messages et 2 mois d'archives volatilisées. Le plus risible > pas de fichier de sauvegarde, alors que le gestionnaire du site est un graphiste informatique !

Pas très serieux tout cela

[Christophe]

Hébergez-vous des données ou sites sur OVHcloud ? Avez-vous été impactés par cet incendie ?

Peu, surtout les boites mails inaccessibles pendant une journée pour beaucoup de client ou un retard d'acheminement. Les offres grand-publics avec petits sites simples (en mutualisé) ont été peu impactés, du moins de ce que j'en ai vu. Quelques site peu importants tombés non gérés par moi, car hébergés par de petites agences qui louent un serveur pour héberger les sites de plusieurs clients.

Je ne connais pas OVH mais est-ce que leur communication (et celle des revendeur) est clair sur la nécessité de faire des sauvegardes et la possibilité réel de perdre des données et ce que ces options sont mises en avant comme sur Azure par exemple ?

Tu as 2 parties chez OVH, les offres grand-public et les offres professionnelles. Sur les offres grand-publics type mutualisés, tu peux restaurer facilement la base jusque J-30 et le contenu FTP à J-2,J-2, J-3,1 semaine, 2 semaines, mais c'est non contractuel, précisé dans les CGV, cela sur une offre qui coute par exemple 45 € par an soit moins de 4€ par mois, avec 100 go d'espace disque, 4 sites web possible, 1 base de données de 200 Mo. Très bien pour une petite asso, certainement pas suffisant pour un site marchand Pour la partie offres VPS, serveurs dédiés, etc. tu as des offres de backup, tu peux redonder sur d'autres datacenters, mais là t'es plus dans la même cour : pour le private cloud c'est du VMWare avec des offres de par exemple 2 hôtes avec 48 Go de RAM et 12 coeurs pour 1200 € par mois voire 1500 € pour du certifié HDS. Et à ce prix là tu peux à mon avis choisir ton datacenter et donc stocker 2 hôtes dans 2 datacenters différents.

Le problème est qu'aussi beaucoup de gens ici qui bavent sur OVH n'ont jamais mis un pieds dans un de leurs DATACENTER, et ne connaissent absolument pas les mesures anti-incendie qui étaient en place (ou pas)

Ce qui leur serait reprochable, si c'est avéré, c'est la présence d'une salle de backup contigüe à une salle de serveurs pour les mêmes données, de ce que j'ai cru comprendre. Mais sur le type d'offre concerné, on est censé avoir suffisamment d'autonomie pour comprendre et être capable d'avoir une sauvegarde fiable ailleurs (on peut envisager une sauvegarde au même endroit sous réserve qu'il y en ai au moins une autre ailleurs), voire une redondance automatique pour une totale résilience sans interruption, mais effectivement ça commence à couter. Et là je ne sais pas si on parle de backup contractuel ou non.

Incendie d’OVHcloud : une Normande perd son site Internet et se voit proposer 30 euros de dédommagement, après avoir subi un préjudice estimé à 2000 euros

Il ne lui a pas été proposé 30 euros de dédommagement mais 6 mois gratuit, c'est pas la même chose. Ca veut dire qu'elle paye normalement 5 euros par mois. Elle estime subir un préjudice de 2000 euros si le site repart en une semaine. Ca fait donc un chiffre d'affaires de 8000 € par mois, et elle ne met que 5€ par mois dans le site ? Un petit peu plus de dépenses pour au moins un backup pour quelques euros de plus... mais elle a peut-être mal été conseillée. Elle peut heureusement compter sur son conjoint qui s'y connait en développement, mais qui n'a semble t'il pas choisi la formule adequat avec sauvegarde pour l'hebergement.

[Thomas404]

PS : je ne suis pas chez OVH et j'ai des sauvegardes multiples sur plusieurs sites, inutile de me prendre pour un con en criant une fois de plus "fallait sauvegarder espèce de buse", merci

Non mais bon, visiblement ici on préfère s'en prendre au client qui paie un service plutôt qu'à l'entreprise qui a des installations qui prennent feu.

La logique est absente de ce topic .

[Christophe]

Visiblement ici on préfère s'en prendre au client qui paie un service plutôt qu'à l'entreprise qui a des installations qui prennent feu.

Ben non justement, ceux qui ont eux les problèmes sont sont qui ont pris des VPS, des VM mais n'ont pas pris les services de sauvegarde et/ou redondance entre DC.

Ceux qui étaient en mutualisé ont eu peu de probs, mise à part un retard dans l'acheminement des mails et un ralentissement des autres services suite à la charge accrue sur les autres DC.

Cela n’empêche pas OVH d'avoir des tords si ils n'ont pas servis à leurs clients la qualité et disponibilité de service défini dans leur contrat. Par exemple dans le cas des sites Web mutualisés et des services mails, il y a des sauvegardes automatiques mais non contractuelles. Et je ne pense pas qu'il y ai de GTR sur ce type de service. Pour les pros, pour av

Et leur image de marque en a pris un coup de toute façon.

Les services impactés sont des services dédiés aux professionnels. Si un professionnel n'est pas capable de préparer un PRA, ou éventuellement déléguer, il a au moins une co-responsabilié.

[xavier.valentin]

Ben non justement, ceux qui ont eux les problèmes sont sont qui ont pris des VPS, des VM mais n'ont pas pris les services de sauvegarde et/ou redondance entre DC.

Ceux qui étaient en mutualisé ont eu peu de probs, mise à part un retard dans l'acheminement des mails et un ralentissement des autres services suite à la charge accrue sur les autres DC.

Cela n’empêche pas OVH d'avoir des tords si ils n'ont pas servis à leurs clients la qualité et disponibilité de service défini dans leur contrat. Par exemple dans le cas des sites Web mutualisés et des services mails, il y a des sauvegardes automatiques mais non contractuelles. Et je ne pense pas qu'il y ai de GTR sur ce type de service. Pour les pros, pour av

Et leur image de marque en a pris un coup de toute façon.

Les services impactés sont des services dédiés aux professionnels. Si un professionnel n'est pas capable de préparer un PRA, ou éventuellement déléguer, il a au moins une co-responsabilié.

Le problème est que les 2 datacenters concernés n'avaient pas que des VM et des VPS. (ou autres offres low cost)

Mais également des Hosted Private Cloud : https://www.ovhcloud.com/fr/enterpri...-cloud/prices/
(l'offre commence à plus de 1000 € HT/ mois et après c'est no limit)
Qui sont des offres avec de nombreux services inclus (dont les sauvegardes - comme tu peux le voir dans l'image ci dessous)

Le problème est qu'OVH est certifié ISO 27001&HDS, certifié SOC et j'en passe... (https://www.ovhcloud.com/fr/enterpri...ty-compliance/) Ce qui oblige d'avoir des sauvegardes, comme tout hébergeur sérieux, sur des sites séparé de 45km



Hors OVH a bien fait des sauvegardes, y compris pour les Private Cloud
Le problème c'est qu'elles ont été faites dans le même datacenter et sans respecter les règles les plus élémentaires d'éloignement des sauvegardes... ce qui a rendu ces sauvegardes totalement inutiles. (car entièrement détruites)

Ce qui me gène c'est que le professionnel qui a souscrit chez OVH un private Cloud à 3000 €HT/mois et avec des sauvegardes, pour avoir un PRA, est comme un con. Et qu'OVH au lieu de dire que son propre PRA est un lamentable échec, renvoie la faute sur ce même professionnel qui lui faisait confiance.

Mais il faut être honnête également, c'est une catastrophe pour OVH, mais également pour les professionnels impactés. Mais le fautif, et Octave l'a bien dit dans son interview, est la conception d'ancienne génération de ces datacenters et le système de sauvegarde dans le même DC.

PS : je ne suis pas chez OVH, et je ne suis pas impacté par ce problème.

[Christophe]

Le problème c'est qu'elles ont été faites dans le même datacenter et sans respecter les règles les plus élémentaires d'éloignement des sauvegardes

Ce qui n'est pas clair dans le doc c'est si les services et les sauvegardes concernent les mêmes clients. Si c’est le cas, les clients auront perdus les deux, si ce n'est pas le cas certains auront perdus leur services et devront restaurer les sauvegardes, d'autres devront refaire leurs sauvegardes.

Le problème est qu'OVH est certifié ISO 27001

Je ne connais pas exactement la norme, mais si ils l'ont obtenu, je suppose qu'ils répondent aux critères de celle-ci.
Je suppose aussi que sur les offres private cloud, tu peux choisir ton datacenter, et celui ou tu stockes tes sauvegardes.

46% des entreprises n'ont pas de PRA. Je parlais de co-responsabilité car ceux qui ont tout perdu n'ont probablement pas de PRA.
Et sur ce type d'offre (private cloud cher), il est recommandé de redonder sur un autre cloud. Mais ça c'est pour les très gros.

[Escapetiger]

Cela n’empêche pas OVH d'avoir des tords si ils n'ont pas servis à leurs clients la qualité et disponibilité de service défini dans leur contrat. Par exemple dans le cas des sites Web mutualisés et des services mails, il y a des sauvegardes automatiques mais non contractuelles. Et je ne pense pas qu'il y ai de GTR sur ce type de service. Pour les pros, pour av

Et leur image de marque en a pris un coup de toute façon.

Les services impactés sont des services dédiés aux professionnels. Si un professionnel n'est pas capable de préparer un PRA, ou éventuellement déléguer, il a au moins une co-responsabilié.

J'en profite pour nos chères lectrices et lecteurs (et moi-même) avec tous ces acronymes sigles :

GTR Garantie de Temps de Rétablissement qui fait partie d'un PRA Plan de Reprise d' Activité (également appelé PRI Plan de Reprise Informatique et plus connu en anglais en tant que DRP Disaster Recovery Plan)

Il est important de connaître les différents concepts et niveaux, voir ci-après par exemple :

Préface de Bruno BROCHETON - Vice-Président du CIGREF (Réseau de Grandes Entreprises) et Chief Information Officer d'Euro Disney.
Ce livre s'adresse principalement aux Responsables des risques et de la continuité (RPCA, Risks Managers, RSSI), aux Di...

Plan de Continuité d'Activité Concepts et démarche - Correspondance français-anglais - Open mediabook - Editions ENI

[Patrick Ruiz]

OVH abandonne le datacenter SBG1 envahi par de la fumée provenant de batteries lors du nouvel incendie maîtrisé :
le résultat d’erreurs de conception de l’alimentation électrique révélées en 2017 ?

Dizaine difficile pour OVH lancé dans la gestion d’un incendie qui lui a valu la perte du datacenter dénommé SBG2 sur son site de Strasbourg. En effet, l’addition est désormais plus salée pour le leader français et espoir européen de l’hébergement web. L’entreprise a frôlé un nouvel incendie et décide y faisant suite de l’abandon du datacenter SBG1. Qu’est-ce qui explique cette série de départs en fumée ? La piste de l’erreur de conception de l’alimentation électrique n’est-elle pas à explorer ?

La fumée dans le datacenter SBG1 provenait d’un lot de 300 batteries stockées en son sein dans un local non utilisé. Dans la foulée, OVHCloud a annoncé que tous les serveurs SBG1 seraient finalement déplacés sur d'autres centres de données situés sur le site de Strasbourg ou sur ses campus de Gravelines et Roubaix. L’entreprise avait pointé du doigt un dysfonctionnement d’un onduleur comme cause de l’incendie qui a détruit le datacenter SBG2. À date, 60 % des VPS de SBG3 sont en principe fonctionnels, contre 25 % pour l'offre bare metal. On reste dans l’attente de 40 % de Private Cloud (pCC). Le travail se poursuit. Il en va de même pour SBG4, avec le redémarrage attendu pour ce mercredi 24 mars.

La piste de l’erreur de conception de l’alimentation électrique du site est-elle à exclure ?

Dans une mise à jour de gestion d’incident survenu en 2017 Octave Klaba explique que :

« Ce matin à 7 h 23, nous avons eu une panne majeure sur notre site de Strasbourg (SBG) : une coupure électrique qui a mis dans le noir nos trois datacentres SBG1, SBG2 et SBG4 durant 3h30. Le pire scénario qui puisse nous arriver.

« Le site de SBG est alimenté par une ligne électrique de 20 kV composée de deux câbles qui délivrent chacun 10 MVA. Les deux câbles fonctionnent ensemble, et sont connectés à la même source et sur le même disjoncteur chez ELD (Strasbourg Électricité Réseaux). Ce matin, l’un des deux câbles a été endommagé et le disjoncteur a coupé l’alimentation des datacentres.

« Le site SBG est prévu pour fonctionner, sans limite de temps, sur les groupes électrogènes. Pour SBG1 et SBG4, nous avons mis en place, un premier système de deux groupes électrogènes de 2 MVA chacun, configurés en N+1 et en 20 kV. Pour SBG2, nous avons mis en place trois groupes en N+1 de 1.4MVA chacun. En cas de coupure de la source externe, les cellules haute tension sont reconfigurées automatiquement par un système de bascule motorisé. En moins de 30 secondes, les datacentres SBG1, SBG2 et SBG4 sont réalimentés en 20 KV. Pour permettre toutes ces bascules sans couper l’alimentation électrique des serveurs, nous disposons d’onduleurs (UPS) sachant fonctionner sans aucune alimentation durant huit minutes.

« Ce matin, le système de basculement motorisé n’a pas fonctionné. L’ordre de démarrage des groupes n’a pas été donné par l’automate. Il s’agit d’un automate NSM (Normal Secours Motorisé), fournit par l’équipementier des cellules haute-tension 20 kV. Nous sommes en contact avec lui, afin de comprendre l’origine de ce dysfonctionnement. C’est toutefois un défaut qui aurait dû être détecté lors des tests périodiques de simulation de défaut sur la source externe. Le dernier test de reprise de SBG sur les groupes date de la fin du mois mai 2017. Durant ce dernier test, nous avons alimenté SBG uniquement à partir des groupes électrogènes durant 8H sans aucun souci et chaque mois nous testons les groupes à vide. Et malgré tout, l’ensemble de ce dispositif n’a pas suffi aujourd’hui pour éviter cette panne.

« Vers 10h, nous avons réussi à basculer les cellules manuellement et nous avons recommencé à alimenter le datacentre à partir des groupes électrogènes. Nous avons demandé à ELD de bien vouloir déconnecter le câble défectueux des cellules haute tension et remettre le disjoncteur en marche avec un seul des deux câbles, et donc limité à 10 MVA. La manipulation a été effectuée par ELD et le site a été réalimenté vers 10 h 30. Les routeurs de SBG ont été joignables à partir de 10 h 58.

« Depuis, nous travaillons, sur la remise en route des services. Alimenter le site en énergie permet de faire redémarrer les serveurs, mais il reste à remettre en marche les services qui tournent sur les serveurs. C’est pourquoi chaque service revient progressivement depuis 10 h 58. Notre système de monitoring nous permet de connaitre la liste de serveurs qui ont démarré avec succès et ceux qui ont encore un problème. Nous intervenons sur chacun de ces serveurs pour identifier et résoudre le problème qui l’empêche de redémarrer.

« À 7 h 50, nous avons mis en place une cellule de crise à RBX, où nous avons centralisé les informations et les actions de l’ensemble des équipes. Un camion en partance de RBX a été chargé de pièces de rechange pour SBG. Il est arrivé à destination vers 17 h 30. Nos équipes locales ont été renforcées par des équipes du datacentre de LIM en Allemagne et de RBX, ils sont tous mobilisés sur place depuis 16H00. Actuellement, plus de 50 techniciens travaillent à SBG pour remettre tous les services en route. Nous préparons les travaux de cette nuit et, si cela était nécessaire, de demain matin.

« Prenons du recul. Pour éviter un scénario catastrophe de ce type, durant ces 18 dernières années, OVH a développé des architectures électriques capables de résister à toutes sortes d’incidents électriques. Chaque test, chaque petit défaut, chaque nouvelle idée a enrichi notre expérience, ce qui nous permet de bâtir aujourd’hui des datacentres fiables.

« Alors pourquoi cette panne ? Pourquoi SBG n’a pas résisté à une simple coupure électrique d’ELD ? Pourquoi toute l’intelligence que nous avons développée chez OVH, n’a pas permis d’éviter cette panne ?

« La réponse rapide : le réseau électrique de SBG a hérité des imperfections de design liées à la faible ambition initialement prévue pour le site.

« La réponse longue :

En 2011, nous avons planifié le déploiement de nouveaux datacentres en Europe. Pour tester l’appétence de chaque marché, avec de nouvelles villes et de nouveaux pays, nous avons imaginé une nouvelle technologie de déploiement de datacentres, basée sur les containers maritimes. Grâce à cette technologie, développée en interne, nous avons voulu avoir la souplesse de déployer un datacentre sans les contraintes de temps liées aux permis de construire. À l’origine, nous voulions avoir la possibilité de valider nos hypothèses avant d’investir durablement dans un site.

« C’est comme ça que début 2012, nous avons lancé SBG avec un datacentre en containers maritimes : SBG1. Nous avons déployé huit containers maritimes et SBG1 a été opérationnel en seulement deux mois. Grâce à ce déploiement ultra rapide, en moins de 6 mois nous avons pu valider que SBG est effectivement un site stratégique pour OVH. Fin 2012, nous avons décidé de construire SBG2 et en 2016, nous avons lancé la construction de SBG3. Ces deux constructions n’ont pas été faites en containers, mais ont été basées sur notre technologie de « Tour » : la construction de SBG2 a pris neuf mois et SBG3 sera mis en production dans un mois. Pour pallier les problèmes de place début 2013, nous avons construit très rapidement SBG4, l’extension basée encore sur les fameux containers maritimes.

« Le problème est qu’en déployant SBG1 avec la technologie basée sur les containers maritimes, nous n’avons pas préparé le site au large scale. Nous avons fait deux erreurs : primo, nous n’avons pas remis le site SBG aux normes internes qui prévoient deux arrivées électriques indépendantes de 20*KV, comme tous nos sites de DC qui possèdent plusieurs doubles arrivées électriques. Il s’agit d’un investissement important d’environ 2 à 3 millions d’euros par arrivée électrique, mais nous estimons que cela fait partie de notre norme interne. Deuxio, nous avons construit le réseau électrique de SBG2 en le posant sur le réseau électrique de SBG1, au lieu de les rendre indépendants l’un de l’autre, comme dans tous nos datacentres. Chez OVH, chaque numéro de datacentre veut dire que le réseau électrique est indépendant d’un autre datacentre. Partout sauf sur le site de SBG.

« La technologie basée sur les containers maritimes n’a été utilisée que pour construire SBG1 et SBG4. En effet, nous avons réalisé que le datacentre en containers n’est pas adapté aux exigences de notre métier. Avec la vitesse de croissance de SBG, la taille minimale d’un site est forcément de plusieurs datacentres, et donc d’une capacité totale de 200*000 serveurs. C’est pourquoi, aujourd’hui, pour déployer un nouveau datacenter, nous n’utilisons plus que deux types de conceptions largement éprouvées et prévues pour le large scale avec de la fiabilité : la construction de tours de cinq ou six étages (RBX4, SBG2-3, BHS1-2), pour 40*000 serveurs ; l’achat des bâtiments (RBX1-3,5-7, P19, GRA1-2, LIM1, ERI1, WAW1, BHS3-7, VIH1, HIL1) pour 40 000 ou 80 000 serveurs.

« Même si l’incident de ce matin a été causé par un automate tiers, nous ne pouvons nous dédouaner de la responsabilité de la panne. À cause du déploiement initial basé sur les containers maritimes, nous avons un historique à rattraper sur SBG pour atteindre le même niveau de normes que sur les autres sites d’OVH.

« Cet après-midi, nous avons décidé du plan d’action suivant : la mise en place de la 2e arrivée électrique, totalement séparée, de 20 MVA ; la séparation du réseau électrique de SBG2 vis-à-vis de SBG1/SBG4, ainsi que la séparation du futur SBG3 vis-à-vis de SBG2 et SBG1/SBG4 ; la migration des clients de SBG1/SBG4 vers SBG3 ; la fermeture de SBG1/SBG4 et la désinstallation des containers maritimes.

« Il s’agit d’un plan d’investissement de 4-5 millions d’euros, que nous mettons en route dès demain, et qui, nous l’espérons, nous permettra de restaurer la confiance de nos clients envers SBG et plus largement OVH.

« Les équipes sont toujours en train de travailler sur la remise en route des derniers clients impactés. Une fois l’incident clos, nous appliquerons les SLA prévus dans nos contrats.

« Nous sommes profondément désolés pour la panne générée et nous vous remercions des encouragements que vous nous témoignez durant cet incident. »

La Cnil monte au créneau

La CNIL a pour sa part procédé à la publication d’ une note sur son site qui rappelle les règles du RGPD aux propriétaires des sites web affectés par les incidents OVH. S'ils ont perdu des données personnelles, il faut le signaler à l'autorité :

« Suite à l’incendie du 10 mars 2021 ayant eu lieu dans un centre de données d’OVH à Strasbourg, la CNIL rappelle les obligations en matière de notification de violation en cas d’indisponibilité ou de destruction de données personnelles. La destruction de données personnelles (temporaire ou définitive), y compris accidentelle, constitue une violation de données au sens du RGPD. À ce titre, les responsables de traitement qui hébergeaient des données personnelles au sein des infrastructures touchées doivent documenter la violation (les faits, ses effets et les mesures prises pour y remédier) dans un registre tenu en interne. Les sous-traitants doivent informer leurs clients de l'incident afin que ces derniers puissent remplir leurs propres obligations, dont celle de documentation dans le registre des violations tenu en interne par chacun d’entre eux. »

Sources : Twitter, Cnil

Et vous ?

Qu’en pensez-vous ?

Voir aussi :

OVHcloud lance le processus d'une éventuelle introduction en bourse selon un porte-parole de l'entreprise
Capgemini et OVHcloud signent un partenariat mondial pour permettre aux organisations de mener leur transformation dans le cloud de manière sécurisée et apporter des solutions cloud robustes
OVHcloud s'associe à Orange Business Services afin d'accompagner les projets de migration et de transformation vers le cloud OVHcloud dans «*une approche multifournisseur »
OVHcloud s'associe à IBM et Atempo pour offrir aux organisations européennes une solution de stockage dans le cloud souveraine et compétitive, partenariat basé sur les solutions de stockage sur bande

[user056478426]

Que dire ?

[toutwd]

Je ne comprends pas bien l’intérêt.
Au final, cet incendie a t'il plus impacté le patrimoine d'OVH ou ses clients ?
Si créer un laboratoire est bon pour l'image de l'entreprise du futur, je ne pense pas que cela permettra pas de rétablir la confiance du présent.
Ce qui a brûlé, c'est du hard, c'est du soft mais c'est surtout une partie du crédit de la société.
Je crois que les sociétés, les professionnels qui ont "tout perdu" vont allez voir d'autres hébergeurs et leur première question sera: "hormis les back-up payant, disposez-vous de sauvegardes générales redondantes digne de ce nom" ?
Des laboratoires d'expertises et des centres de recherches performants et professionnels contre l'incendie existent déjà, il suffit d'en mandater un, à chacun son métier non ?

[Fleur en plastique]

Je suis tout feu tout flamme !

C'est vraiment des bandes de branquignoles, là on peut dire que leur réputation a cramé, que la confiance est partie en fumée, mais le feu de la catastrophe à venir devait couver depuis longtemps. Il a fallu que les flammes du destin viennent consumer le clair manque de sécurité de leurs datacentres. OVH sur le coup, a fait long feu, et leur aura de premier hébergeur de France est en cendres. Il est certain qu'il leur faudra des années à OVH pour faire des étincelles à nouveau.

Pour mon expérience personnelle : j'exploite un serveur situé sur le datacentre SBG1, dans l'une des salles qui a échappée au premier feu. Le serveur a été rallumé 7 jours après l'incident, mais mis en mode rescue, obligeant du coup à une opération manuelle pour le mettre en mode normal. Mais le robot de reboot était HS, il a donc fallu attendre qu'ils soit réparé pour que je puisse le relancer en mode normal. OVH a envoyé deux mails de condoléances dans les jours qui suivaient l'incident, a prévenu du démarrage du serveur en mode secours. Mais depuis, plus rien. D'ailleurs, le serveur est à nouveau HS, probablement suite au déménagement prochain vers un datacentre non maudit ? En tant que cliente, je n'en ai pas la moindre idée.

Je pensais les incendier au téléphone. J'ai été mise en attente pendant très exactement 59 minutes, m'assurant qu'un opérateur allait prendre mon appel. Mais au final, on m'a juste raccroché au nez. J'étais verte.

[Anselme45]

Ce ne serait pas plus "productif" de simplement ajouter à leurs datacenters un système anti-incendie efficace comme c'est le cas dans tous les datacenters sérieux?

Ou pourquoi pas, soyons fou, de ne pas mettre les serveurs et leur backup dans le même local?

[Sylvain_LD]

Ce ne serait pas plus "productif" de simplement ajouter à leurs datacenters un système anti-incendie efficace comme c'est le cas dans tous les datacenters sérieux?

Ou pourquoi pas, soyons fou, de ne pas mettre les serveurs et leur backup dans le même local?

Je ne pesais vraiment pas qu'OVH était amateur à ce point! Se vanter d'âtre le N°1 et avoir des systèmes concentrés au même endroit sans redondance miroir ça fait vraiment guignol!
Le B A BA de la sécutité des systèmes informatiques bafoué!

[Mingolito]

Et voila comment on gagne des centaines de millions : faire croire aux gogos qu'on leur vends un cloud haut de gamme, en réalité en ne faisant qu'entasser n'importe comment des serveurs pas cher dans un container maritime avec une infrastructure électrique en toc, aucune sécurité incendie, et pire encore en mettant les sauvegardes sur le même site ce qui est profondément idiot.

Vu que sa réputation est grillée, Octave n'a plus qu'à fuir la France et partir du Costa Rica avec le mago

[frfancha]

... quand tu loues une voiture savoir que les freins sont "en cours d'installation" n'est peut être pas exactement suffisant...

[Levure]

Donc en 2017, OVH annonce ceci :

« Cet après-midi, nous avons décidé du plan d’action suivant : la mise en place de la 2e arrivée électrique, totalement séparée, de 20 MVA ; la séparation du réseau électrique de SBG2 vis-à-vis de SBG1/SBG4, ainsi que la séparation du futur SBG3 vis-à-vis de SBG2 et SBG1/SBG4 ; la migration des clients de SBG1/SBG4 vers SBG3 ; la fermeture de SBG1/SBG4 et la désinstallation des containers maritimes.

« Il s’agit d’un plan d’investissement de 4-5 millions d’euros, que nous mettons en route dès demain, et qui, nous l’espérons, nous permettra de restaurer la confiance de nos clients envers SBG et plus largement OVH.

Et en 2021, rien n'a été apparemment fait :

• Il n'y a toujours qu'une seule alimentation électrique pour l'ensemble du site de Strasbourg.
• SBG1 et SBG4 sont toujours là. (Ce n'est que maintenant qu'ils vont fermer SBG1 et déplacer une partie des serveurs de SBG1 vers SBG4)

Pire, OVHCloud a annoncé qu'ils allaient alimenter SBG4 (électricité et réseau) à partir de SBG3.
Il n'y a aucune redondance sur le datacenter de Strasbourg, c'est effrayant. Le site de Strasbourg est clairement un site à éviter en l'état.

Et quand à la climatisation des salles via un refroidissement à eau, OVH n'a rien inventé : ça existe déjà chez Scaleway (DC5) : https://lafibre.info/scaleway/dc5/

Enfin, la dernière annonce d'OVHCloud de vouloir "faire évoluer les standards de protection" fait rire (jaune)...
Qu'ils implémentent déjà les principes de base existants de l'agencement et la gestion d'un datacenter et qu'ils soient plus transparents sur l'éventuel backup de leurs hébergements ainsi que leurs offres payantes de backup (réplications éventuelles et lieux de stockages des backups), ce sera déjà un énorme pas en avant...
..
OVHCloud c'est du low-cost, et le low-cost - il n'y a pas de magie - ca se fait toujours au détriment de l'un ou l'autre élément.
Je ne comprends pas comment on a pu reconnaître OVHcloud comme fournisseur de cloud souverain.