GitLab : erreur humaine et sauvegardes défaillantes entrainent la perte de 6h de données

GitLab : erreur humaine et sauvegardes défaillantes entrainent la perte de 6 h de données

Oups ?

89

GitLab : erreur humaine et sauvegardes défaillantes entrainent la perte de 6h de données

GitLab se remet péniblement d’un accident qui a vu la disparition de nombreuses informations. Pendant six heures, des problèmes se sont succédé, suite à une mauvaise manipulation d'un administrateur. 

GitLab, une alternative open source à GitHub, se remet péniblement d’un incident majeur dans ses bases de données. Un administrateur système a supprimé par erreur un dossier contenant 300 Go de données diverses : bugs, merge requests, métadonnées utilisateurs, commentaires, snippets et autres. Une action qui a pris place dans le cadre d'une lutte contre un phénomène détecté de spam.

Environ 5 000 projets ont été touchés

Si l’on connait en détails les raisons de cet accident, c’est que GitLab a choisi de jouer la carte de la transparence complète. Et si ce point est particulièrement appréciable, c’est que l’éditeur assume pleinement sa faute dans le déroulement de l’incident. Et pour cause : sur les cinq mécanismes mis en place pour gérer et restaurer les sauvegardes, aucun n’a fonctionné pleinement.

Les erreurs constatées par les administrateurs sont à la fois surprenantes et assez « amusantes ». On trouve pêle-mêle des sauvegardes qui ne se faisaient que toutes les 24 heures, des données sauvegardées à des emplacements inconnus, des informations parfois irrécupérables à cause d’erreurs dans la configuration, des snapshots Azure qui n’étaient activés que pour le serveur NFS, des sauvegardes qui n’ont pas du tout fonctionné avec les serveurs S3 (Amazon), une réplication des données générant des incohérences, des fichiers de quelques octets à peine...

Les problèmes ont commencé mardi soir. Ils se sont enchainés pendant environ six heures, GitLabs constatant au fur et à mesure que ses techniques de sauvegarde et de duplication ne fonctionnaient pas, ou alors très mal. Un véritable feuilleton puisque l'éditeur a ouvert pour l'occasion un flux vidéo en direct sur YouTube, suivi par des milliers de personnes.

GitLab indique que seuls 1 % des utilisateurs ont été touchés par le problème, ce qui représente précisément 707 comptes. En tout, 5 037 projets, 74 forks et 350 importations environ ont été supprimés. Environ 5 000 commentaires sont également perdus. Ces informations correspondent en fait aux données non prises en charge par la dernière sauvegarde, qui dataient de six heures auparavant.

La transparence d'un côté, l'étonnement de l'autre

Si la suppression malencontreuse n'avait laissé que 4,5 Go de données sur les 300 Go initiaux, presque tous ont pu finalement être restaurés hier soir après une longue lutte. Signalons par ailleurs que les données centrales des dépôts Git n’ont pas été touchées. GitLab indique en effet que seules des « métadonnées périphériques » ont été perdues « pendant une fenêtre de six heures ». Cependant, même si GitLab a montré une transparence exemplaire en ne cachant rien de ses problèmes et de sa propre responsabilité, les développeurs concernés pourraient ne pas être d’accord avec cette notion de « périphériques ».

Le fait qu’aucun des cinq mécanismes de sauvegarde et de réplication n’ait correctement fonctionné représente évidemment un sérieux problème. De fait, GitLab est à la fois félicité pour ses informations précises données aux utilisateurs et condamné pour ne pas avoir suffisamment testé ses propres outils. GitLab servant de carrefour pour la gestion de projets, la fiabilité et la confiance sont en effet primordiaux.

Actuellement, tous les services fonctionnent normalement, après une interruption d'environ 24 heures. GitLab assure que des mesures ont été prises et continueront de l’être pour que ce type d’incident ne se reproduise plus, y compris sur les mécanismes fautifs de sauvegarde.

Commentaires (89)








Kernelcoffee a écrit :



Les systèmes moderne sont stable (j’ai pas reinstall un windows parce qu’il était mort depuis win 7)

Pour peu qu’on ai plusieurs ordi on peut sauvegarder les documents important

avec Dropbox ou BittorrentSync en plus du backup sur disque externe

+90% des jeux sont acheté/install via une plateforme du type steam qui syncro les sauvegardes

(+ tout mon taff est sur github/gitlab)





Alors tu sauvegarde tes projets sur gitlab ?



Supprimer des fichiers comme ça à la main sans vérifier les sauvegardes …&nbsp;<img data-src=" /><img data-src=" />


Ça fait amateur non ? par contre communiquer correctement, ça nous change.


en me^me temps il on assurés


Petite pensée au 707 comptes dont certains ont perdu certainement beaucoup. GitLab s’en lave les mains: “Excusez-nous mais on ne peut rien pour vous.”


En même temps, c’est rare qu’une erreur soit qualifiée de professionnelle.


Sur une rediffusion partielle de leur live, on pouvait voir les mecs sourire et rigoler en même temps qu’ils essayaient de réparer tout le merdier, même pas peur l’équipe <img data-src=" /> .








Cacahuete586 a écrit :



Petite pensée au 707 comptes dont certains ont perdu certainement beaucoup. GitLab s’en lave les mains: “Excusez-nous mais on ne peut rien pour vous.”





En meme temps que peuvent-ils faire ?



Ça m’a bien niqué ma journée hier, j’étais sur le cul qu’un tel truc se produise. Mais chapeau pour la transparence, la communication en continu et la restauration en live sur youtube! J’avais jamais vu ça.



Bref ces mecs font un taf super pour proposer une vraie alternative à github ou bitbucket donc je leur laisse une chance parce que j’ai envie de croire qu’ils amélioreront leur système.








Zekka a écrit :



Sur une rediffusion partielle de leur live, on pouvait voir les mecs sourire et rigoler en même temps qu’ils essayaient de réparer tout le merdier, même pas peur l’équipe <img data-src=" /> .



En même temps ils vont pas se mettre à pleurer, ca ne changera rien…









Cacahuete586 a écrit :



Petite pensée au 707 comptes dont certains ont perdu certainement beaucoup. GitLab s’en lave les mains: “Excusez-nous mais on ne peut rien pour vous.”





Il faut lire les conditions d’utilisation : https://about.gitlab.com/terms/ §16

Au mieux, ils remboursent les 12 derniers mois … ce qui va pas faire lourd pour des comptes gratuits.



Après j’ai quand même envie de dire que l’utilisateur est responsable de ses données.



Est-ce que Gitlab prend contractuellement à sa charge la responsabilité des sauvegardes ?


En attendant, j’ai peur qu’il y ait de légers problèmes qui restent, je ne peux pas commenter sur une issue dont le sujet est que l’auteur n’arrive plus à commenter une issue… <img data-src=" />


Je n’ai pas dis le contraire, c’est juste qu’on voyait peu le stress de la situation sur leur visage “yololo tout va bien”, ça prêtait seulement à sourire.








Zekka a écrit :



Je n’ai pas dis le contraire, c’est juste qu’on voyait peu le stress de la situation sur leur visage “yololo tout va bien”, ça prêtait seulement à sourire.





Ils ne vont pas se fouetter ni se mettre des oignons sous les yeux pour paraitre tristes, non plus.

Sourire, attitude positive, toussa…



Et pour les comptes floués, ils ont surement les data en local non?


C’est vrai que ça fait amateur comme erreur, mais franchement ils ont quand même vraiment pas eu de chance. <img data-src=" />

Si j’ai bien compris, les problèmes ont commencés à cause de quelqu’un qui se servait de Gitlab comme un CDN. Ça a surchargé leur base de données primaire, puis bloqué la réplication dans la base secondaire. Le gars de GitLab voulait effacer la base secondaire pour reprendre la réplication à zéro mais il s’est trompé et a effacé la primaire. Pas de chance, aucune de leurs sauvegardes ne fonctionnaient. Et comme si ça suffisait pas, dès qu’ils trouvent (un peu par chance) une sauvegarde fonctionnelle, ils doivent la copier et la copie est limitée à 5-6 Mo/s. Ils ont eu un enchaînement de malchance juste hallucinant. <img data-src=" />

Mais ils ont été exemplaires sur la transparence (non seulement ils communiquaient, mais en plus ils répondaient aux questions des gens). Et ils ont publié sur leur issues tracker ce qu’ils comptent faire pour que ça n’arrive plus et forcément vu l’ampleur de l’incident qu’ils ont eu, ils vont se mettre en mode parano. Donc perso ils sont pardonnés, ce genre de chose peut arriver (et c’est déjà arrivé à Github dans le passé).


Ils étaient sous prozac pour gérer le stress…


J’ai eu la même attitude lorsque j’ai bousillé 150 Go de données de projets divers (dont des contrats, sources, etc.) pour m’apercevoir aussi que les sauvegardes étaient mortes depuis 15 jours, et comme nous n’avons que 7 jours de rétention… <img data-src=" />



[MyLife]

Après avoir pris une soufflante en règle par mes chefs parceque c’était inadmissible de n’avoir que 7 jours de rétention, je leur ai rappelé que c’était aussi leur faute car ils n’avaient pas voulu investir dans un petit NAS à 5000 € (preuve par email).

Bizarrement, ce fut le silence radio après

[/MyLife]








Zekka a écrit :



Je n’ai pas dis le contraire, c’est juste qu’on voyait peu le stress de la situation sur leur visage “yololo tout va bien”, ça prêtait seulement à sourire.



Je ne vois toujours pas ce que ca change…



Je pense qu’il faudrait préciser (titre + article) que le problème a touché Gitlab.com et non le projet Gitlab



Sinon, ouais, incroyable…



At 2017/01/31 11pm-ish UTC,

team-member-1&nbsp;thinks that perhaps&nbsp;pg_basebackup&nbsp;is refusing to work due to the PostgreSQL data directory being present (despite being empty), decides to remove the directory.

After a second or two he notices he ran it on&nbsp;db1.cluster.gitlab.com, instead of&nbsp;db2.cluster.gitlab.com.



At 2017/01/31 11:27pm UTC,

team-member-1&nbsp;- terminates the removal, but it’s too late. Of around 300 GB only about 4.5 GB is left.


-Erreur-


Les sauvegardes étaient trop libres <img data-src=" />


Mais que ça change quoi? J’ai pas parlé de changer quelque chose.

Rire un peu de la situation ça va c’est possible encore ou non?


Quand le stream a été mis en place, ils y avait déjà passé plusieurs heures, et c’était la fin de journée pour l’équipe (la suppression accidentelle de la base primaire a été faite à 23h chez eux). Je sais pas toi, mais perso, quand je suis sur un problème depuis 6 ou 7h après ma journée de travail, j’ai du mal à rester stressé. Et puis bon, le plus gros était déjà passé.


Ha ! les sauvegardes, ça marche jusqu’au jour où on en a besoin. J’ai l’impression que les mecs, là, ils ont aligné toutes la panoplie de la sauvegarde raté, quoique, il manque je trouve le coup de la défaillance matérielle, que l’on se rend compte que notre disque de sauvegarde était déjà mort.









Zekka a écrit :



Sur une rediffusion partielle de leur live, on pouvait voir les mecs sourire et rigoler en même temps qu’ils essayaient de réparer tout le merdier, même pas peur l’équipe <img data-src=" /> .





Tu sais, lorsque tu as perdu tout espoir, ils ne te restes plus qu’à rire de ton malheur. Je suis le premier à être plié de rire quand les merdes s’accumulent.



C’est moche :/


Stopper la réplication et révoquer l’accès à celui les utilisants comme CDN n’aurait pas été mieux ?








tazvld a écrit :



Tu sais, lorsque tu as perdu tout espoir, ils ne te restes plus qu’à rire de ton malheur. Je suis le premier à être plié de rire quand les merdes s’accumulent.





D’après mon expérience de visionnage “D’unité spéciale pour les victime”, il ne faut surtout pas faire ça!

L’avocat de la défense dira que tu est consentant. :reflechie:



C’est sans doute nerveux.

Ca m’est arrivé quand dans la même journée :

on a cartonné 2 fois ma voiture,

crash disque de mon poste,

multiplication des incidents avant mise en prod d’un projet important…

&nbsp; &nbsp;

&nbsp;








Zekka a écrit :



Je n’ai pas dis le contraire, c’est juste qu’on voyait peu le stress de la situation sur leur visage “yololo tout va bien”, ça prêtait seulement à sourire.





Personnellement, lorsque je suis dans cette état, un peu “yolo”, c’est justement là que j’arrive a mieux géré pour sauver les meubles que juste avant lorsque j’étais roulé en boule dans un coins bloqué sur un détail inutil et de toute façon sans espoir. Il y a un moment où on accepte que de toute façon, on ne va pas pouvoir tout sauver, c’est à ce moment où on arrive à se libèrer des détails pour s’intéresser finalement à ce qui est le plus important.



J’ai un peut de mal a comprendre. Sous Win/Lin y’a des programmes de récupérations de données.

Pourquoi n’utilisent il pas ce genre de soft ? .

&nbsp;

Est ce a cause des sauvegardes réseaux ? . Parce que j’imagine que si j’ai un serveur sur 1on1 / page perso chez Free / ou autres, doit yavoir moyen de lancer une recupe des données?

&nbsp;


gem install wayback_machine_downloader

wayback_machine_downloader&nbsp;https://gitlab.com


“out of five backup/replication techniques deployed none are working reliably or set up in the first place.”

Ils ont vraiment pas eu de chance <img data-src=" />








Drepanocytose a écrit :



Ils ne vont pas se fouetter ni se mettre des oignons sous les yeux pour paraitre tristes, non plus.

Sourire, attitude positive, toussa…









Patch a écrit :



Je ne vois toujours pas ce que ca change…





En effet, mais là on parle de communication de crise. Il ne faudrait pas que les clients, surtout ceux concernés par la perte de données, aient l’impression que les équipes prennent ça à la légère.

Je suis d’accord qu’il est important pour les équipes qu’elles arrivent à garder le moral dans une telle situation, et que faire la gueule/être stressé ne fera pas revenir les données, mais c’est une attitude valable en “back office”. L’idée du stream est bonne pour la transparence, mais il ne faudrait pas que ça nuise à leur image.&nbsp;



Je suis pas sûr d’avoir tout bien compris de ce qu’il s’est passé, mais il me semble que au moment de la surcharge dû à cet utilisateur (qu’ils ont supprimé rapidement, mais le mal était déjà fait) et au spam, la réplication a pris du retard puis s’est bloqué, et ils n’ont pas réussi à la redémarrer. Et c’est à ce moment là que le gars de GitLab, en voulant supprimer la base de données secondaire, s’est trompé et a supprimé la primaire. Maintenant j’ai peut-être mal compris, tu peux vérifier par toi-même, tout est très détaillé sur leur blog (lien dans l’article).


C’est après avoir ban qui de droit, et en essayant de remettre en place la réplication qu’ils ont supprimé le mauvais dossier. (en fait le bon dossier, mais sur la mauvaise machine)

Edit: Grillé


La magie du cloud








Tarvos a écrit :



J’ai un peut de mal a comprendre. Sous Win/Lin y’a des programmes de récupérations de données.

Pourquoi n’utilisent il pas ce genre de soft ? .

&nbsp;

Est ce a cause des sauvegardes réseaux ? . Parce que j’imagine que si j’ai un serveur sur 1on1 / page perso chez Free / ou autres, doit yavoir moyen de lancer une recupe des données?

&nbsp;





Parce que le stockage en bases de données / en réseau quand tu as du stockage éclaté sur plusieurs prestataires / infras, c’est juste “un peu” plus compliqué que le stockage sur un disque dur sur un poste isolé.



En général chaque dev possède la copie complète en local donc ça paraît compliqué de tout perdrz








Juju251 a écrit :



Parce que le stockage en bases de données / en réseau quand tu as du stockage éclaté sur plusieurs prestataires / infras, c’est juste “un peu” plus compliqué que le stockage sur un disque dur sur un poste isolé.





Ah la la, ils auraient du prendre une time machine sur l’apple cloud… Les noobs.



Merci à toi et Qmarlats <img data-src=" />


A priori ce ne sont “que” les données sur une fenêtre de 6h qui sont perdues.

Les données de projet git (code, wiki) n’ont pas été impactées par cet incident.


Ils sont open jusqu’au bout, chapeau. Y’a pas mal de structures que leur exemple va motiver à vérifier leurs propres systèmes de sauvegardes.


C’est clairement le genre de probleme qui ne pourrait jamais arriver dans le monde Open Source, parcequ’on sait qu’il y a des centaines de gens qui auditent attentivement le code et les process <img data-src=" />



<img data-src=" />


Bof tu t’adresse à des devs qui si c’est leur métier savent comment ça se passe. Quand c’est pété c’est pété, tu fais de ton mieux et puis c’est tout. Pleurer n’arrangera rien et les devs le savent.



Si tu montres ça à des managers peut être qu’ils ne comprendraient pas, mais le live ne leur était pas vraiment destiné. Il ne faut pas oublier aussi qu’on parle de comptes gratuits sur gitlab.com, les clients payants payent soit pour une licence pour héberger eux même une version entreprise, soit payent pour que gitlab les hébergent sur un serveur séparé (donc j’imagine qu’ils n’ont pas été touchés par cet incident). Tu peux te permettre de revoir tes exigences à la baisse quand tu ne lâche pas un rond alors que ces mecs travaillent comme des dingues sur leur produit. Gitlab.com est une sorte de vitrine et bien que les utilisateurs ne payent pas ils ont déjà une sacré qualité de service. J’y suis depuis un moment pour mes projets perso et au départ c’était très loin de ce qu’il y a maintenant. Ils avaient un pauvre serveur dédié qui peinait à fournir le service à tout le monde et ils essaient constamment d’améliorer.


Par contre j’imagine que si la copie de la sauvegarde était limitée à 5-6 Mo/s c’était de la faute à Azure, du coup je me demande pourquoi ils restent chez eux… <img data-src=" /> En plus s’ils passaient chez AWS par exemple ils pourraient utiliser RDS (un équivalent doit sûrement exister chez GCE aussi).


il semble qu’ils aient les deux, en redondance.


Le principe de la redondance normalement c’est que si une base de données tombe une autre prend le relais, pas que si une base de données tombe elle entraîne l’autre (indirectement) dans sa chute… <img data-src=" /> (Plus sérieusement merci de l’info je savais pas)








tazvld a écrit :



c’est à ce moment où on arrive à se libèrer des détails pour s’intéresser finalement à ce qui est le plus important.





“où diable ai-je laissé ce petit sac de cocaïne ?” ?









qmarlats a écrit :



Par contre j’imagine que si la copie de la sauvegarde était limitée à 5-6 Mo/s c’était de la faute à Azure, du coup je me demande pourquoi ils restent chez eux… <img data-src=" /> En plus s’ils passaient chez AWS par exemple ils pourraient utiliser RDS (un équivalent doit sûrement exister chez GCE aussi).



Visiblement ils ont aussi eu des soucis avec leur infra AWS …



GitLab pour héberger sur son propre serveur c’est très bien mais je vois pas trop l’intérêt de l’utiliser comme alternative à Github pour les dépôts publics open source, ce dernier étant bien plus complet (et fiable visiblement..).


Erreur humaine, communication au top. On peut regretter s’il y a eu des dégâts chez les clients, mais Gitlab a fait ce qu’il pouvait, dans une situation pas facile. Et ça va les inciter à s’améliorer, et corriger ces erreurs.


Les dépôts Git ne sont dans tous les cas pas touchés, c’est “juste” les données qui gravitent autour : tickets, merge requests…


Euh… ils n’ont pas perdu 300Go de données vu qu’il y avait un backup manuel qui a été fait 6h avant et qu’ils ont pu restaurer la base.



Effectivement ils ont perdu des commentaires / issues / etc (mais aucun code versionné) mais seulement sur cette fameuse fenêtre de 6h.



L’article sous entend qu’ils ont perdu presque la totalité des 300Go définitivement et qu’il ne reste que 4,7Go soit 99% des donnés mais que seulement 1% des utilisateurs sont touchés oO Incohérent non ?


Tu n’as pas du trop connaître les DDOS/downtime de GitHub en 2015-2016. C’était une horreur qui durait plusieurs heures et qui revenait régulièrement. Bon on perdait pas de données, juste des journées de boulots :(



Concernant les fonctionnalités de GitLab.com pour les projets open-sources, on a quasiment voir toutes les fonctionnalités de GitHub avec en plus une plateforme de CI directement intégrée là où pour GitHub, il est nécessaire d’utiliser un service externe pour l’utiliser. C’est fluide, aussi simple que GitHub, et bien meilleure que d’autres solutions commerciales (Bitbucket, je pense à toi).&nbsp;








StackHeap a écrit :



GitLab pour héberger sur son propre serveur c’est très bien mais je vois pas trop l’intérêt de l’utiliser comme alternative à Github pour les dépôts publics open source, ce dernier étant bien plus complet (et fiable visiblement..).





C’est marrant je trouve Gitlab bien plus complet

Et je l’utilise sur Framagit



Bizarre les chiffres, ils parlaient d’une perte de 6h de data…&nbsp;



As of time of writing, we’re restoring data from a six-hour-old backup of our database. This means that any data between 5:20pm UTC and 11:25pm UTC from the database (projects, issues, merge requests, users, comments, snippets, etc.) is lost by the time GitLab.com is live again.


Perso j’utilise Gogs depuis plusieurs mois, c’est le seul que mon raspberry était capable d’encaisser car gitlab était trop lourd pour lui. Et bien pour l’instant rien à redire c’est une tuerie, de plus je suis le maître de mon serveur ce qui est un plus pour les backups…&nbsp;<img data-src=" />








Trollalalala a écrit :



Perso j’utilise Gogs depuis plusieurs mois, c’est le seul que mon raspberry était capable d’encaisser car gitlab était trop lourd pour lui. Et bien pour l’instant rien à redire c’est une tuerie, de plus je suis le maître de mon serveur ce qui est un plus pour les backups…&nbsp;<img data-src=" />





<img data-src=" />



Installation prévue à court terme!

&nbsp;



Au final, sur les 300 Go concernés par la commande de suppression, il ne restait plus que 4,5 Go. GitLab indique que seuls 1 % des utilisateurs ont été touchés par le problème, ce qui représente précisément 707 comptes. En tout, 5 037 projets, 74 forks et 350 importations environ ont été supprimés. Environ 5 000 commentaires sont également perdus.

Ils ont supprimé la base de donnée et restoré une sauvegarde qui avait était faite 6h avant. Ils n’ont pas perdu 300Go (qui est la taille totale des données) mais simplement les donnée crée durant ces 6 heures.








Chiendelune a écrit :



Tu n’as pas du trop connaître les DDOS/downtime de GitHub en 2015-2016. C’était une horreur qui durait plusieurs heures et qui revenait régulièrement. Bon on perdait pas de données, juste des journées de boulots :(





C’est toujours le cas en 2017 au passage. On a eu une coupure de 8H en debut d’année.



On se retrouve quand même face au B.A.-BA du métier : s’assurer que les mécanismes de récupération de données fonctionnent bien comme attendu.


Tu ne devrais pas être déçu !La compilation par les sources est un peu délicate pour un non-initié sur un pi mais ils fournissent des binaires pour les systèmes debian et la doc du site est vraiment complète, la config se fait avec la doc également, franchement rien à redire !&nbsp;<img data-src=" />








ITWT a écrit :



On se retrouve quand même face au B.A.-BA du métier : s’assurer que les mécanismes de récupération de données fonctionnent bien comme attendu.





Et normalement on a des plans de test pour ce genre de chose, qui sont exécutés régulièrement :p









LostSoul a écrit :



Et normalement on a des plans de test pour ce genre de chose, qui sont exécutés régulièrement :p





Ca c’est la théorie, quand tu vends au client&nbsp;<img data-src=" />









StackHeap a écrit :



GitLab pour héberger sur son propre serveur c’est très bien mais je vois pas trop l’intérêt de l’utiliser comme alternative à Github pour les dépôts publics open source, ce dernier étant bien plus complet (et fiable visiblement..).





Et les repo privés? On a le droit de vouloir faire des projets pour soi sans souhaiter les exposer à la face du monde (ou alors pour une boîte qui ne souhaite pas forcément exposer tout son code)



Sinon je ne vois pas vraiment où Github est plus complet en plus les mecs de chez Gitlab sont assez proactifs sur l’évolution de leur produit alors que Github ça bouge pas vraiment.



Le gros plus de Gitlab pour moi c’est l’outil d’intégration continu intégré qui marche très bien. J’aime pas avoir 50 outils surtout sur des choses comme ça où ça a du sens de les regrouper.









Alexyu a écrit :



Ca c’est la théorie, quand tu vends au client&nbsp;<img data-src=" />





De fait, la preuve <img data-src=" />



Ca va me faire “plaisir” quand cela va arriver sur un iCloud ou un truc de style et que des personnes vont perdre beaucoup. Les gens réaliseront peut-être enfin que c’est totalement dingue de laisser toutes ces données dans le Cloud à la merci d’un seul prestataire et que cela ne remplace pas une sauvegarde faite soit même en parallèle.


Des plans de test toutes les 6 heures ?

Si j’ai bien tout compris, ils n’ont finalement perdu que 6h de données, donc c’est que la dernière bonne sauvegarde datait de 6h non ?


C’est un repo git, tu perds pas tes données (avec gitlab, github, bitbucket…).


Heureusement que ce sont des petits jeunes car les vieux trouvent que ce n’est pas si grave. Si cela avait été des petits vieux, on imagine les sauts de vomi de la part des petits jeunes sur ces vieux c.. qui n’y connaissent rien., Je me demande comment ils vont vieillir ces petits jeunes irréprochables..;-)


5000€ le petit NAS?&nbsp;<img data-src=" />


le mot important, c’est “petit” <img data-src=" />


A se demander quand meme si les gens suppriment leur projet une fois poussé …



Je pense que le pire ce sont ceux qui poussé leurs trucs en vue d’un formatage PC. Peux être des mois de code qui sont partie en fumée. Mais bon faut être fou d’accorder 100% de confiance a ces services en ligne. Moi je m’en tiens a 98%, les 2% c’est le zip en plus que je copie sur un autre disque dur, clé usb.








Leixia a écrit :



5000€ le petit NAS? <img data-src=" />







Oui, un ptit Syno 10 To <img data-src=" />



On a un un 2416RP+ au boulot et perso j’ai un DS1815+ chez moi, j’en ai pas eu pour 5000€ que ce soit au boulot ou chez moi <img data-src=" />

Après ça dépend des disques…


RS3614xs+ avec 12 HDD 2 To SATA








Folgore a écrit :



A se demander quand meme si les gens suppriment leur projet une fois poussé …



Je pense que le pire ce sont ceux qui poussé leurs trucs en vue d’un formatage PC. Peux être des mois de code qui sont partie en fumée. Mais bon faut être fou d’accorder 100% de confiance a ces services en ligne. Moi je m’en tiens a 98%, les 2% c’est le zip en plus que je copie sur un autre disque dur, clé usb.





Pourtant il suffit de lire la news pour se rendre compte qu’aucune ligne de code n’a été perdue. “Seulement” la base de données (donc tout ce qui n’est pas du code : users, pull requests, paramétrages, commentaires …)



Rien d’incohérent.. Encore une fois la DB touchée est celle qui s’occupe des commentaires, merges etc.. En gros, sur les 6h perdues, t’as 1% des utilisateurs qui ont dû être actifs et qui ont perdus les comments, merges, etc..&nbsp;

Perso je vois rien de déconnant là-dedans.



Quant à l’attitude “yolo” décriée par certains.. Retrouvez-vous dans une situation de crise semblable, et vous comprendrez tout à fait que se rouler en position foetale sous le bureau n’arrangera rien, le mal est fait, autant y aller coolos et tenter de trouver des solutions en étant positif.&nbsp;








ITWT a écrit :



On se retrouve quand même face au B.A.-BA du métier : s’assurer que les mécanismes de récupération de données fonctionnent bien comme attendu.









LostSoul a écrit :



Et normalement on a des plans de test pour ce genre de chose, qui sont exécutés régulièrement :p





ça m’a juste fait penser à ceci :&nbsphttp://www.commitstrip.com/fr/2016/09/05/do-we-have-a-back-up-in-the-audience <img data-src=" />&nbsp;









YamaLandia a écrit :



ça m’a juste fait penser à ceci :&#160http://www.commitstrip.com/fr/2016/09/05/do-we-have-a-back-up-in-the-audience <img data-src=" />







M’en rappelle de celui là !



Je suppose que les équipes qui ont perdu des données sur le serveur distant, les ont encore en locale. C’est un gros coup à l’image de l’entreprise, ceux qui s’en frottent les mains doivent être GitHub.


Bof, pour les commits c’est pas dramatiques dans le mesure ou on commit d’abord en local avant d’uploader.


Mais gitlab c’est git. Tous les comptes impactés devaient avoir leur travail en local non?








jpaul a écrit :



Pourtant il suffit de lire la news pour se rendre compte qu’aucune ligne de code n’a été perdue. “Seulement” la base de données (donc tout ce qui n’est pas du code : users, pull requests, paramétrages, commentaires …)




La news a été modifiée depuis, donc je peux comprendre que mon commentaire semble bizarre maintenant, mais il y avait des incohérences ;)


Ouai mais mon point majeur c’est: donc en fait on s’en bat un peu les steaks?



L’incident a certes de l’importance. Mais l’impact reste extrêmement limité.


Oui et non.



&nbsp;S’ils ont perdu les issues, ce sont plusieurs jours de planification/documetnation de sprint qui ont pu être perdu.



Dans l’absolu, ce n’est pas grave, ça dépend surtout de l’état d’esprit des chefs de projets et/ou dsi.


Fermer