L'entreprise continue de remettre en état les différents datacenters de son site, ravagé par un incendie la semaine dernière.
Après avoir contacté ses clients, certains s'étant vu proposer une remise de plusieurs mois sur les services impactés, une page vient apporter des détails sur l'état de chacun mais aussi des sauvegardes.
En effet, certaines étaient également stockées à Strasbourg et ne seront pas exploitables. C'est par exemple le cas de certains Datastore de l'offre Hosted Private Cloud, de VPS ou de Plesk, prisé par les agences web.
Pour chaque « univers », les services sont détaillés selon leur datacenter/salle et leur zone OpenStack. On peut ainsi voir la liste de ceux récupérables et l'état de leurs sauvegardes internes à OVHcloud.
De quoi rappeler à chacun l'importance de disposer de sauvegardes tierces et de ne pas se reposer sur un seul datacenter ou prestataire pour faire face à des problèmes de cette ampleur.
Commentaires (28)
#1
Effectivement, les sauvegardes (fonctionnelles) sont importantes, et le “Cloud” n’est pas magique…
Comme indiqué dans le dernier lien, il faut à “minima” une sauvegarde disponible rapidement (ex : même hébergeur mais sur un centre de données distant) et une sauvegarde locale (au sein de la structure pas sur le serveur lui-même ;)).
Attention aux sauvegardes de base de donnée également ! Les fichiers ne sont pas suffisants !
Beaucoup de personnes ont malheureusement découvert avec cet incendie ce qu’était un PRA, et accusent OVH de tous les maux… Les assurances / avocats vont avoir du taf !
#2
Etonné devant le fait que les solutions de stockage style “backup storage” ne suivent pas la règle du 3-2-1, j’ai regardé un peu les descriptions sur le site d’OVH. Effectivement, à aucun moment, il ne parle de redondance dans la sauvegarde.
Le service ainsi intitulé “backup storage” est, à mon avis, trompeur. C’est un espace de stockage, pas un espace de stockage pour les backups.
Sa description laisse aussi perplexe :
La notion de sécurité est ici toute relative. En continuant un peu dans la page, on se rend compte que la sécurité est une sécurité de confidentialité (accès) et aucunement une sécurité d’intégrité. Comme les termes utilisés sont vagues, le nom trompeur, on fait facilement de fausse supposition.
En bref, l’histoire est loin d’être terminée car je sens qu’il va y avoir quelques batailles judiciaires derrières pour les entreprises ayant perdues leurs données.
#2.1
Les backup storage ne sont pas hébergés sur le même DC. En revanche ils sont stockés géographiquement au même endroit.
Ils n’ont jamais parlé de backup multi région, ni de backup redondé.
Bon en revanche, “backup” est commercialement inadapté, à l’origine cela s’appelait “snapshot”…
Les avocats vont tenter de s’engouffrer dans ce défaut d’appellation je pense, et tenteront de la faire passer comme “trompeuse”. Et au pire OVH se fera allumé uniquement sur l’appellation trompeuse de ce service.
Dans les CGV et CGU, vu le nombre de fois qu’il est écris clairement et même en majuscule qu’OVH n’est pas responsable de la perte de données, et qu’il appartient au client d’effectuer lui même ses sauvegardes et ses PRA, ca risque tout de même d’être ensuite difficile de les attaquer pour autre chose. D’autant qu’ils indiquent aussi clairement que dans le cas d’une activité professionnelle :
Donc en gros, ce sera surtout Assurance contre Assurance
#3
idée à la con …
ça serait peut etre le bon moment de suggérer à OVH qu’il serait peut etre temps de supporter IPv6 en failover ?
parce que le failover uniquement IPv4 signifie que cela va être un merdier pas possible pour les clients VPS qui utilisent aussi IPv6 chez eux.
#4
Pour certains services, si ! Et c’est OVH même qui le dit. Par exemple, les Datastore.
Tout à fait. Toutefois, l’usage d’expressions comme “sécurisé”, “Entièrement géré par nos équipes”, “solution fiable”, etc… tant à induire en erreur sur la portée exacte du service, sans compte l’usage du mot “backup” laissant entendre que cet espace de stockage est “conçu pour”.
Attention, backup et snapshot sont deux choses différentes !
Sauf que l’appellation désastreuse peut avoir des conséquences irréversibles. Pas certains que cela soit juste sur la nature trompeuse du service. Mais là, il faudra attendre la conclusion des éventuels procès à ce sujet.
Si je suis d’accord sur le principe du PRA. Par contre, si OVH vend un service qui est qualifié de trompeur, et que le PRA est inefficace à cause de ce service trompeur, OVH pourrait (conditionnel hein !) bien être tenu pour responsable bien qu’il y ait une clause dans les CGU et CGV.
#5
DataStore et Backup ne sont pas identique et n’ont pas même vocation
C’est bien la le soucis, lorsqu’ils ont donnés la possibilité d’automatiser les snapshots avec un rotate, ils ont appelé ca “backup”. Mais ca reste des snapshots.
C’est justement le but de la RC Pro, chacune des assurances évaluera les dommages et les devoirs de chacun, et se retournera contre ceux qui ont manqués à leur obligation.
Mais fort à parier qu’OVH va se payer une magnifique surprime sur la totalité de leurs assurances…
#6
Alors attention, dans la liste d’OVH tous les “Internal Backup” sont les backup d’OVH pour gérer l’infra et faire ses interventions.
Donc 1. c’est absolument pas contractuel c’est purement un besoin interne, 2. c’est normal que ce soit dans la même salle du même DC, c’est plus pratique et rapide de tout mettre à proximité.
Et 3. c’est pas un stockage de sécurité redondant !
Après je comprend les gens qui ragent, mais à moins d’avoir demandé l’option adéquate (et d’avoir compris entièrement en quoi consiste la dite option) c’est pas là faute d’OVH …
Mais je comprend que de nombreuses personnes soient mécontentes, après si tu pense qu’avec même pas 10 balles par mois tu as un service multi redondé avec des backups de l’espace et un taux de service de 99.9999999% c’est qu’il faut surement changer de métier ou chercher un informaticien compétent
#7
Tout à fait. C’était juste pour illustrer qu’un service et son backup pouvait être situé dans la même unité, sur le même DC ! Chose que je ne pensais pas imaginable… (en tout cas, pas de la part d’un prestataire comme OVH).
Mais on a bien les deux. Sur mes VPS, je peux faire soit un snapshot, soit des backups (voire les deux).
Ce qui est compliqué ici, c’est qu’il faut éplucher les CGU/CGV. Je n’ai pas lu tout en détail, mais je n’ai rien vu quant à l’utilisation de Backup Storage. Donc quand OVH dit pour un VPS par exemple, on ne fait pas de sauvegarde, OK, c’est à charge du client. Si le client prend l’option “backup automatisé” ? Le client a fait ce qui était demandé dans les CGU. Il a pris une solution quant à la sauvegarde. où est la responsabilité ? Cet incident malheureux va être riche en enseignement de ce point de vue là aussi ( et au niveau du RGPD ! Par exemple, à des questions comme est-ce que le client est responsable de la défaillance de son prestataire ? Jusqu’où un client doit vérifier les compétences de son prestataire ? etc…)
Oh ça oui !!!!
#8
Après il faut bien différencier Backup et Backup externalisé/délocalisé.
J’ai l’impression que pour beaucoup de gens le côté délocalisé coule de source… ben non, à la base un backup peut être fait sur un disque du même serveur, rien dans cette appellation n’implique que ce soit stocké ailleurs.
D’ailleurs quand on construit une infra il est bien d’avoir un backup “sur place” pour pouvoir restaurer très rapidement en cas de crash, en plus d’un backup externalisé sur une autre plate-forme pour le côté sécurité.
#9
Cet accident va constituer un précédent pour sûr. Les gens commencent à découvrir que le cloud n’est pas un “nuage magique”, et que stocker ses données sur internet repose sur des solutions avant tout matérielles. Si ces infrastructures partent en fumée (dans tous les sens du terme) ces données sont perdues.
Ici on parle de solutions professionnelles avec un vocabulaire technique (les “Pra”, les “snapshots”, les “back-up”…), et de la responsabilité de chefs d’entreprises ou de services informatiques, mais que dire des solutions grand public comme le Drive de Google qui ne possède sans doute pas les mêmes garanties qu’un hébergeur pro, et qui invite le monde entier à stocker ses photos et données perso “en lieu sûr”, en poussant même les gens à se débarrasser de leurs fichiers locaux du moment qu’ils ont une connexion internet ?
#10
Faut comparer aussi, Google et MS par exemple sont des monstres et ils ont déjà toutes leurs données en triple dans 3 DCs différents a des distances supérieur à 50kms.
Mais quand tu payes 0 impots, que tu as des centaines de millions de clients et des milliards pour ton infra, les coûts de redondance ne sont pas vu de la même manière.
Les DATA sont la valeur que recherche Google/MS (donc elles sont redondés par défaut, car critique), ce qui n’est pas le cas d’un hébergeur, qui fournit de l’infra et “se fou” de la DATA, qu’ils ne facturent pas (sauf en quantité de stockage).
#10.1
Pour MS et AWS, le principe est le même que chez OVH. Serveur privé = aucune résponsabilité de sauvegarde. Service mutualisé distribué = Sauvegarde à des fins technique uniquement.
Je rigole quand je vois les PME fondre sur Office365 en disant “c’est cool pas besoin de serveur au bureau, c’est Microsoft qui gère TOUT!”. Sauf que, en cas d’effacement involontaire (ou pas) du contenu d’une boite mail, Microsoft nous dis “Bah… on en as rien a faire nous
“. Il faut donc bien sauvegarder aussi les Office365/GoogleDrive/etc indépendamment de ce que fait le fournisseur du service.
#10.2
D’ou ma reflexion plus haut. C’est un discours dangereux que de vendre un service de cloud (je parle bien d’un service grand public destiné au particulier où aux petites entreprises qui n’ont pas une connaissance fine des infrastructures informatiques) en garantissant des sauvegardes “sécurisées et en lieu sûres”. Je pense que ça va créer un précédent tout ça…
Sinon petite histoire personnelle. Je gérais avec un pote une association audiovisuelle, et nos “sources” étaient originellement disponible sur des DVD-R (c’était encore le milieu des années 2000). Puis on a transmis tout ça sur des disques externes (quatre back-up dont deux chez lui et deux chez moi). Il y a quelques années j’ai eu l’idée de tout placer sur Google Drive (abo 2 to). Pour convaincre mon pote/associé, résolument “anti-cloud” et qui ne voyait pas l’intérêt de payer alors qu’on dégueulait déjà de sauvegardes, je lui ai dit “mais si un jour nos disques de back-up nous lâchent au fur et à mesure, ça sera toujours accessible sur le drive”.
Sur le fond, je pense encore avoir raison, ce qui est arrivé à OVH reste très exceptionnel, mais ça lui donne tout de même à présent de solides arguments pour tâcher de me convaincre que je me plante bien avec “mon cloud”.
#11
Un DataStore, vulgairement c’est juste une sorte de “disque dur”, qu’il soit proche du serveur est normal pour des soucis de rapidité d’accès aux données. Qu’on fasse un backup dessus pour se permettre une restauration rapide en cas de compromission, je veux bien, mais en aucun cas, c’est à la base une “solution de sauvegarde”. A la rigueur, 2 Datastores sur 2 zones géographiques, avec une copie de l’un sur l’autre, oui, c’est un début de sauvegarde, et encore, on aura du mal à remonter dans le temps…
Certes, mais ce qui se cache derrière le “backup” est un simple snap automatisé. La localisation du Snap en question est d’ailleurs bien mentionné vu qu’il y a une colonne “Localisation” aussi bien dans la liste des Snapshot, que dans la liste des backup. Donc pas de doute possible.
Dans les CGV le Backup Storage n’est pas franchement expliqué en effet. Mais quoi qu’il arrive, la règle d’un backup c’est 3-2-1, donc oui le backup storage permet d’avoir une seconde copie pour un “self service rapide” et peut participer à un protocole de sauvegarde, mais nous n’avons ni la 3ème copie, ni le 2 ème support (puisque sous la même infrastructure), ni l’emplacement géographique différent.
Donc on ne peut pas incriminer une perte total à un hébergeur surtout sur des Serveur privatisés. Ce qu’il nous doit, c’est l’infra et la disponibilité de notre infra, le reste ne le regarde pas, d’autant que les données lui sont inaccessibles. Ce n’est pas de l’infogérance.
Pour les mutualisés c’est une autre histoire (idem CloudWeb et CloudDB qui sont infogéré par OVH)
En revanche, les petites sociétés d’info qui ont promis une infra sécurisée et sauvegardées à leurs clients finaux en louant des VPS ou des PCI, sans se ficeler ne serait-ce qu’un échappatoire en cas d’indisponibilité de OVH (sans parler d’incendie), ils nous ont juste fait un loupé magistral!
Perso les instances que j’ai chez OVH sont :
Dans le pire des cas, je vais héberger un serveur autre part, et je remonte mes backups.
#12
OVH n’à jamais voulu vendre aux particuliers et TPE des serveurs dédiés hébergés, ca ce sont les petites boites d’info qui leur ont promis plein de choses en bricolant des bouts de ficelles (je dis pas, certains sont sérieux…). L’offre Perso/Pro c’est juste un hébergement mutu avec des boites mails!
Sinon pour ta petite histoire, j’avoue avoir été dans le même cas que ton pote, ne pas vouloir mettre de backup sur le cloud. Mais un incendie chez un proche, qui finalement à perdu beaucoup car justement quelques bribes seulement étaient en d’autres lieux, m’a fait prendre conscience que le “backup cloud” est une possibilité complémentaire à un backup local offrant d’autres sécurités !
#13
Je suis peut-être un peu trop bisounours sur les bords mais j’arrive pas comprendre comment une boîte qui vend du stockage et de l’hébergement peut se dédouaner de la responsabilité des données qui lui sont confiées ?
C’est son fond de commerce bordel.
Un peu comme si ta banque se fait braquer et ah ben tant pis pour ton pognon.
Fallait en garder un peu sous le matelas…
#13.1
ça semble surprenant mais si on essae de faire un parallèle:
Quand tu loues un appartement , et qu’il y a le feu, c’est à toi de t’assurer ( c’est d’ailleurs obligatoire) et c’est ton assurance qui s’occupera de toi et de ce qu’il y avait à l’intérieur
pas celle de ton proprio
Mais bon je suis pas très bisounours
#13.3
Exact, on me confie quelque chose et je prends toutes les mesures qu’il faut pour pouvoir restituer la chose dans l’état dans lequel on me l’a confiée.
Ce que ne fait pas OVH.
#13.4
oui et non
tu loue une voiture avec “garantie intégrale” histoire que quoi qu’il arrive, tu aie une voiture
si tu la repeint en rouge
et qu’elle crame
tu vas reprocher au loueur de te fournir une voiture de remplacement verte ?
idem si tu laisse ton appareil photo dedans, suivant les assurances, tu peux être remboursé de la valeur de l’appareil photo qui a cramé, mais tu peux pas exiger du loueur de la voiture de te fournir ton appareil photo avec les photo d’avant que la voiture crame
je parle de la partie “serveur” uniquement hein, ça a déjà été dit, mais y’a plusieurs choses qu’on peut prendre chez ovh, entre les mutualisés / cloud / dédiés … et certains services incluent la pérennité des données, d’autres non
#13.5
Ok maintenant j’ai compris, merci.
Désolé je connais pas trop ovh ni ses différents services.
#13.6
Y’a pas de mal, ca sert à ca les commentaires
#13.7
c’était qu’un exemple un peu extrême / fumeux hein, ça va dépendre des types de services souscrits / contrats, mais à voir les commentaires sur les différents articles / brèves y’a eu des amalgames et certains disent “c’est pas normal de tout perdre”, c’est pas faux, mais tout n’est pas la faute d’ovh à mon avis, et la transparence dont ils semblent faire preuve m’incite à penser qu’ils sont plutôt réglo.
et ceux qui se sont dit “je colle tout chez ovh, c’est indestructible” ont soit été mal informés (cf quelques formulations un peu ambiguës relevées dans les descriptions des offres ovh mentionnées dans les commentaires sur cet article ou d’autres, ou alors des choses dites par des prestataires qui utilisent les services ovh, mais là ovh n’y peut pas grand chose), soit n’ont pas voulu entendre les mises en garde
je bosse pas pour ovh, ni n’utilise leurs services, mais je suis dans le web et ma boite à quelques serveurs chez eux, et à part le stress de devoir remonter de nouveaux serveurs à partir des backups (je crois qu’on en a chez eux, mais je sais pas si c’est “coup de bol” dans un autre DC ou si c’était volontaire, et en plus on les récupère en interne dans nos locaux), j’ai pas entendu qu’on avait eu des pertes
#13.2
Pour ceux qui ont tout perdu (Hosted Private Server, VPS, Public Cloud, etc), OVH ne fournis qu’une infrastructure, c’est le l’IaaS (Infrastructure As A Service). Ils nous doivent une machine (physique ou virtuelle) en état de fonctionnement durant la durée du contrat. Si la machine claque, ils nous doivent une machine de remplacement dans un délai imposé contractuellement. C’est ce qui est fait ici. Si l’offre n’existe plus, ils peuvent la rompre unilatéralement, et nous obliger à passer sur des nouvelles offre. Concernant les sauvegardes, contractuellement voici ce qui est inscrit dans les CGV :
Pour faire une analogie, c’est comme si tu demandais à HP, Dell et consort de restaurer la sauvegarde de ton disque dur car ton Serveur as brulé. Ils te fournissent du stockage pourtant. Mais ils ne sont pas responsable de ce que tu mets dessus. Si ton Serveur vient à brûler par leur faute durant la durée du contrat (garantie) ils te le remboursent ou te l’échange, mais toujours sans récupération de données qui ne les concerne toujours pas. Tes assurances non plus ne couvrent pas les données, mais juste le matériel (sauf option spécifique et hors de prix). Ce sera ensuite la RCPro qui prendra le relais pour potentiellement “indemniser le préjudice”, et encore… ils pourront invoquer un manquement aux devoirs du client.
Sur un Mutualisé, ou une offre “infogéré” par OVH (matériel ET logiciel), il en est tout autre, puisqu’ils nous doivent la sauvegarde et la redondance de nos données. De ce fait nous sommes un peu plus protégé, mais quoi qu’il arrive, il est écrit noir sur blanc dans les CGV :
Ce qui signifie que quoi qu’il arrive, tu es propriétaire et seul responsable de tes données, et que de ce fait tu dois tout mettre en œuvre pour en éviter la destruction totale ou partielle, et ce même si tu as souscrit à une “option backup” au sein du même prestataire.
#14
Oui…et non. Car une modification volontaire (normal) des données est normalement répliqués partout (aussi sur les backup, donc !) , à moins de s’en rendre compte avant la prochaine rotation des sauvegardes.
-> On ne peut pas garder ad-vitam toutes les versions d’un dossier/document, c’est techniquement impossible, donc souvent on se contente de 5-10 version maximums (et encore, seulement sur certain type de document, typiquement les doc offices), ce que font bien MS/Google sur leur offre O365 et GoogleDoc (sur sharepoint, tu click sur version de fichier, et ils te proposent bien 5 version antérieur de ton fichier snapshoté après chaque modification)
MS et Google propose donc bien un service de restauration des données (limité, certes) mais ils en ont un, et heureusement, car un effacement par un utilisateur ou un effacement pour cause de DC qui brûle, ça revient au même au final (juste le canal d’utilisation qui change) : Tu restaure les données depuis la dernière sauvegarde, qui existe, car pour MS/Google, la donnée est ce qui porte la valeur du service, elle est donc redondées (3 fois).
La différence est bien qu’un hébergeur (OVH) propose de l’infra, MS/Google propose du service. Les enjeux de perte de données ne sont pas les mêmes.
C’est le même distinguo avec le IAAS/PAAS/SAAS, à chaque fois la responsabilité glisse de plus en plus vers le fournisseur.
#14.1
Trop de mondent confondent “Versionnage” et “Sauvegarde”
Le versionnage permet juste de revenir dans le temps.
Pour O365 et GoogleDrive la solution proposé est un “Versionnage du fichier” et non une “Sauvegarde”. Et c’est justement ce que les gens pensent à tort “C’est dans le cloud, donc c’est sauvegardé”.
Non :
La vocation d’une sauvegarde n’est pas juste le fait de dupliquer quelque chose quelque part et par quelqu’un, mais d’avoir en sa possession une copie exploitable.
Sinon les prestataires de sauvegarde tel que Oodrive ne fourniraient pas des connecteurs Office 365 pour backuper toutes les nuits l’intégralité des données en dehors de l’infra Microsoft.
#14.2
Pourquoi techniquement impossible ?
)
Tu devrais aller te ballader du côté de Salt Lake City ( sans obligation de devenir Mormon
Je connais des boites qui gardent des centaines et des milliers de versions pendant des années ( principalement pour des raisons légales) .
)
Ils font de la sauvegarde incrémentale et les versions flaguées “inactive” partent à l’archivage sur un des média de sauvegarde de type cartouche ( et 1 fichier de 20 megs qui a eu 3 lignes de modifiées n’aura besoin que de 4k de plus … pour sa sauvegarde .. du versionning comme en parle th3squal)
Ils font des runs de colocation régulièrement pour éviter de perdre du temps en cas de besoin.
On emmène le media de colocation quelque part ( regarde par exemple Granite Cloud de Perpetual Storage … rien que le nom est assez parlant
Et régulièrement après disons une dizaine d’année , ces données cartouches sont de nouveau dupliquées sur un autre média car le hardware suppportant le média , arrive en fin de vie.
ça existe depuis des années
PS: pour info la colocation c’est quand on met toutes les données de sauvegarde situées sur plein de cartouches différentes au fil d temps sur une seule et même cartouche.
de cette façon on ne fait qu’un ou deux mounts
#15
https://www.francebleu.fr/infos/economie-social/victime-de-l-incendie-du-data-center-ovh-une-manchoise-se-voit-proposer-un-geste-commercial-de-30-1615818352
“il est hors de question de leur faire à nouveau confiance. J’irai chez un autre hébergeur, et je prendrai l’option garantie de sauvegarde””
Ca c’est intéressant comme phrase. La personne ne veut plus faire confiance à OVH mais c’est elle a omis d’assurer ses sauvegardes. ;)
#16
Et le pire c’est “Le conjoint qui s’y connait en informatique”
Fort a parier que c’est lui qui as configuré le VPS avec un tuto sous le code en disant “T’inquiète, c’est dans le cloud, t’aura pas de soucis”