Il faut des sauvegardes quotidiennes sur au moins 2 supports complètement distincts en plus du cloud (le "cloud" peut aussi partir en fumée).Envoyé par tanaka59
Et un plan de reprise d'activité testé.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Il faut des sauvegardes quotidiennes sur au moins 2 supports complètement distincts en plus du cloud (le "cloud" peut aussi partir en fumée).
Et un plan de reprise d'activité testé.
Bonjour,
La je parle d'un contexte perso
Quotidien : pc + cloud / distanciel (donc a 2 endroits)
Mensuelle : sur dde (chaque mois j'ai quoi 5 documents de plus importants ?)
En contexte pro j'ai une "quadri" / "penta" réplications ... PC + sur serveur + distanciel (cloud) . A chaque fois des serveurs qui sauvegardes en doubles dans des lieux bien distinct sur des circuits bien distinct. Faut vraiment avoir le cas improbable ou tout lâche en même temps au même moment.
Comme toujours le probleme des sauvegardes qu'on neglige, il suffit de se faire avoir une fois pour prendre le sujet au sérieux.
Apres je trouve que ces hebergeurs en vendant du cloud a tout va donnent l'impression que tout est facile dans le nuage, dupliqué on ne sait ou, ainsi securisé donc donnent le sentiment que les sauvegardes ne sont pas vraiment utiles.
Seulement derriere le cloud ca n'est que de l'hebergement classique de données sur des serveurs materiels. Je plains vraiment les utilisateurs pour lesquels leur activité professionnelle est impactée.
Surtout n'oubliez pas de sauvegarder vos photos et autre elements precieux dans le cloud, c'est la panacée.
Finalement c'est peut etre un mal pour un bien car ca remet un peu en tete aux gens ce qu'il y a derriere tous ces concepts qu'on nous vend et qui donnent l'impression que c'est magique. Dur retour a la realité.
Un raid5 inter site OVH rappelant le NFS d'antan
Pour pallier à ce genre de perte de données OVH pourrait prévoir un raid5 non pas sur un serveur mais plutôt inter-site de façon transparente à l'utilisateur.
Il n'ont qu'a s'inspirer de ElasticSearch et autres techno le faisant en mémoire ils n'ont qu'a le transposer sur disque.
Je sens l'erreur humaine mais bon laissons l'enquête prendre son chemin.
Qu'est-ce que le cloud computing ? la réponse de microsoft Azure https://azure.microsoft.com/fr-fr/ov...ting/#benefits
le "Il rend ces activités moins coûteuses", indique clairement que ça n'est pas d'origine dans les prestations.Le cloud computing simplifie la sauvegarde des données, la récupération d’urgence et la continuité des activités. Il rend ces activités moins coûteuses, car les données peuvent être mises en miroir sur plusieurs sites redondants au sein du réseau du fournisseur.
heu, avec 50 K€ de CA/jour, ils n'ont pas défini de plan de reprise d'activité ?
Et les backups?
Sinon les backups dans des clouds externes comme Dropbox, Amazon S3 , onedrive et j'en passe et des meilleurs pour sauvegarder ces sites ça existent aujourd'hui,,😁
Il y a un vieux proverbe qui dit "ne jamais mettre tous ces oeufs dans le même panier" .
A méditer
Je trouve bizarre que sur un forum plutôt orienté pro, on discute de chose aussi évidente que la sauvegarde des données.
Je ne suis pas impacté par cet incendie, j'aurai été sans doute furax et pesté comme certains intervenants. Toutefois, je connais le niveau de risque encouru de faire du prix planchers.
Cloud, pas cloud : ce n'est que du commercial. On est en environnement B2B, ce genre de vocabulaire commercial ne devrait même pas tromper. Si les clients n'ont pas compris, c'est qu'il n'avait pas assez étudier la technique et se sont fait manger par les commerciaux.
Pour faire un parallèle simple, ce n'est pas parce que j'ai souscrit un contrat d'assurance tous risque que je suis assurer sur tous les évènements. Il y a bien marquer assurance tous risque en gros partout, mais on sait tous que ça ne veut rien dire : ça n'assure pas de tous les risques.
Il est évident qu'un contrat à 3 euros par mois n'a pas le même niveau de couverture qu'un contrat d'assurance à 100€ par mois.
Je ne comprends pas que ça soit une évidence dans un contrat d'assurance, mais que ça ne le serait pas chez un autre prestataire. Comme le souligne plusieurs intervenants, le contrat fait toujours foi.
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".
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.
Utiliser un hébergeursans faire de sauvegarde !
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.
Bonjour,
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
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.Hébergez-vous des données ou sites sur OVHcloud ? Avez-vous été impactés par cet incendie ?
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.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 ?
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.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)
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.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
OVHcloud frôle un nouvel incendie sur son site de Strasbourg
OVHcloud frôle un nouvel incendie sur son site de Strasbourg
l'entreprise suspend le plan de redémarrage de ses datacenters
Dix jours après le feu qui a détruit un des quatre datacenters d'OVHcloud, certains médias ont annoncé un nouvel incendie sur le site de Strasbourg du leader français et espoir européen de l'hébergement Web. Ledit incendie aurait éclaté ce vendredi à 19h. Fort heureusement, le pire a été évité. Il s'agirait selon Octave Klaba d'une épaisse nuée de fumée qui a rapidement été maitrisée, grâce à l'intervention rapide des sapeurs-pompiers.
Un important incendie s'est déclaré dans la nuit du mardi 9 au mercredi 10 mars sur les installations d'OVHCloud à Strasbourg. Un incident déplorable qui a mis hors ligne environ 3,6 millions de sites Web répartis sur 464 000 domaines distincts. Octave Klaba n'a pas tardé à faire une sortie vidéo pour présenter ses excuses et expliquer à ses clients ce qui aurait déclenché le feu. On retient surtout que le patron d'OVHCloud a promis tirer des enseignements de ce sinistre et tout faire désormais pour qu'une telle situation « n'arrive plus jamais ».
Incendie du 9 au 10 mars sur le site d'OVHcloud à Strasbourg
Tout juste après la promesse d'Octave Klaba, un nouvel incendie aurait été une situation vraiment embarrassante, surtout que le plan de redémarrage des datacenters de Strasbourg n'était pas encore terminé. Heureusement, la situation a rapidement été maitrisée. Il n'y a pas de fumée sans feu, dit-on. Mais OVHcloud rassure que le feu n'a pas eu le temps d'éclater, il y a eu juste beaucoup de fumée. Vu le nouvel incident, le plan de reprise annoncé après l'incendie du 9 au 10 mars a été suspendu, le temps de voir plus clair dans cette affaire.
« Dès que les fumées ont été détectées, nos équipes ont été alertées et nous avons immédiatement coupé l'alimentation des datacenters SBG 1 et SBG 4 », explique une responsable de l'entreprise. Et d'ajouter : « Nous avons pris la décision d'évacuer SBG 1 et d'interrompre les opérations de la nuit. Toutes les équipes mobilisées sur SBG 3 et SBG 4 sont rentrées chez elles. »
Comme l'explique Octave Klaba dans une série de tweets, la fumée a envahi une salle dans le datacenter SBG 1. Elle venait de batteries stockées dans un local non utilisé. Les batteries elles-mêmes n'étaient ni utilisées ni alimentées.
Les causes de ce nouvel incident sur ces batteries non utilisées restent encore inconnues.
Voir aussi :
OVHcloud lance le processus d'une éventuelle introduction en bourse selon un porte-parole de l'entreprise
Un dernier hommage à "feu" le cloud souverain français
Oui c'est bien possible de prendre en option une sauvegarde chez ovh, mais d'après certains clients la salle de sauvegarde qui était positionnée avec une grande intelligence juste à coté à cramé aussi, donc.... des millions de sites toujours en panne à ce jour.
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
Oh, qui oserait dire cela?...
Bonjour,
Récemment on entendait des problèmes de livraisons ou de qualité de matériel sur les chaines de productions en Asie. OVH aurait acheté de la camelote ?
Franchement pas très sérieux ...
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 .
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.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.
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é.
Eduquer.. les clients!
J'ai monté un petit service commercial sur un serveur dédié. Chiffre d'affaires se comptant en centaines d'euros, donc pas question de louer un serveur à 30 ou 40 € par mois, ce ne serait pas rentable. Clairement là pour tester le concept plutôt que pour devenir ma source de revenus.
Hébergé sur un serveur dédié dès les premières phases de conception. J'aurais très bien pu commencer localement, sauf que je voulais pouvoir y accéder depuis mes différents lieux de travail (sachant que je ne peux pas prendre un portable). Clairement, choix du cloud pour la mobilité, pas pour une question de sauvegarde.
Hébergement Kimsufi, donc OVH. Je n'ai jamais cherché à savoir s'ils faisaient des sauvegardes. Au lieu de ça, j'ai un script sur mon PC à la maison qui vient récupérer les données importantes de temps en temps. Pour moi, une sauvegarde ne se justifie que si elle est physiquement distante du site sauvegardé, et d'une manière générale je ne mets pas tous mes œufs dans le même panier.
Un jour, alors que j'étais encore en phase de test, plus d'accès au site. J'arrive encore à faire un ssh vers le serveur, les fichiers restent visibles mais la plupart semblent contenir des signes cabalistiques. Une heure après, un mail d'OVH: ils ont constaté que le serveur ne répondait plus, ils ont tenté plusieurs fois de le relancer et ont fini par conclure à une défaillance du disque principal. Ils me demandent s'ils doivent le remplacer tout de suite ou si je veux prendre le temps de sauvegarder.
Je tente bien de sauvegarder mais rapidement il faut se rendre à l'évidence: la majorité des fichiers est corrompue. Donc je donne le feu vert pour le remplacement, en me disant qu'après tout j'ai mes sauvegardes.
Le seul hic au final c'est justement qu'on était en phase de tests: les testeurs voulaient voir les corrections rapidement et donc j'avais pris la mauvaise habitude de les faire directement sur site sans augmenter la fréquence de mes sauvegardes.
Du coup j'ai dû refaire toutes les corrections de bug, mais rien d'autre. Heureusement que les bug trackers envoient systématiquement des mails à chaque événement: au moins les descriptions de tickets étaient intactes. Encore une fois, pas tous les œufs dans le même panier.
Je n'ai pas blâmé OVH pour l'incident: j'avais pris la précaution de faire des sauvegardes mais seulement sous-estimé le volume de travail et donc la fréquence nécessaire. J'étais entièrement responsable.
Aujourd'hui le service est opérationnel. Sans rentrer dans les détails, c'est un service de synchronisation en temps réel, les utilisateurs travaillent avec un client lourd sur PC qui envoie ses données sur le site via une interface REST. Donc, les données d'un utilisateur A vont aller sur le site, quand l'utilisateur B arrive il reçoit celles du collègue, et réciproquement. Comme c'est du temps réel et qu'il est rare qu'un utilisateur C arrive longtemps après le début du projet, aucune raison de conserver les données dans la durée (puisque de toute façon le client lourd sauvegarde tout sur le PC, que les données soient celle de l'utilisateur ou récupérées de ses collègues). Du moins, c'est ce qu'un informaticien comprendrait à priori en lisant la description du service. Les clients, qui ne sont pas informaticiens, c'est une autre histoire, surtout quand on leur répète partout que le cloud c'est la mode et que c'est génial pour les sauvegardes.
J'ai donc eu beaucoup de mal à leur faire comprendre que mon service était optimisé pour synchroniser très rapidement de très petites quantités de données, alors que la plupart des propositions concurrentes sont optimisées pour le gros volume, mais rarement en temps réel. On ne peut pas tout avoir en même temps, faut avoir des priorités, et j'avais fait le choix d'avoir un service complémentaire plutôt que concurrent des autres (le mien pour le temps réel et les autres pour le long terme). Mais quand est seul sur un marché, ce n'est pas toujours un avantage parce qu'il faut expliquer deux fois plus.
Je n'ai pas été impacté par l'incident de Strasbourg, mais suite à l'événement relaté plus haut, je n'ai pu m'empêcher de m'interroger sur ce qui se serait passé si tel avait été le cas.
En ce qui concerne mes données de développeur, je sauvegarde bien plus maintenant, donc je n'aurais pas eu le moindre souci.
Pour les données concernant les clients, j'aurais peut-être perdu les dernières factures, tout au plus.
Pour les données des clients, c'est une autre histoire; techniquement je n'aurais rien perdu parce que les données n'étaient pas sauvegardées de toute façon. La vraie question est plutôt de savoir si les clients l'auraient compris. Alors je vais de ce pas vérifier le contrat pour voir si je ne devrais pas profiter de cet incident pour être un peu plus explicite sur ce point. A priori, il est déjà indiqué que les données sont détruites après un temps donné (dépendant de l'offre choisie) mais je ne voudrais pas qu'un client considère que tant que la limite n'est pas atteinte ses données disposent d'un niveau de garantie que je n'ai jamais affirmé proposer. Normalement, si le site était indisponible quelques jours, ça voudrait seulement dire que les utilisateurs ne peuvent plus compter dessus pour se synchroniser: ça ne veut pas dire que les données sont perdues, mais vue l'image que véhicule le cloud, ça risque d'être dur de le leur faire comprendre.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager