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)
#1
#2
Supprimer des fichiers comme ça à la main sans vérifier les sauvegardes … 
" />
" />
#3
Ça fait amateur non ? par contre communiquer correctement, ça nous change.
#4
en me^me temps il on assurés
#5
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.”
#6
En même temps, c’est rare qu’une erreur soit qualifiée de professionnelle.
#7
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
" /> .
#8
#9
Ç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.
#10
#11
#12
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 ?
#13
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…
" />
#14
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.
#15
#16
Et pour les comptes floués, ils ont surement les data en local non?
#17
C’est vrai que ça fait amateur comme erreur, mais franchement ils ont quand même vraiment pas eu de chance.
" />
" />
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.
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é).
#18
Ils étaient sous prozac pour gérer le stress…
#19
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…
" />
[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]
#20
#21
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 thinks that perhaps pg_basebackup 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 db1.cluster.gitlab.com, instead of db2.cluster.gitlab.com.
At 2017/01/31 11:27pm UTC,
team-member-1 - terminates the removal, but it’s too late. Of around 300 GB only about 4.5 GB is left.
#22
-Erreur-
#23
Les sauvegardes étaient trop libres
" />
#24
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?
#25
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é.
#26
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.
#27
C’est moche :/
#28
Stopper la réplication et révoquer l’accès à celui les utilisants comme CDN n’aurait pas été mieux ?
#29
#30
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…
#31
#32
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 ? .
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?
#33
gem install wayback_machine_downloader
wayback_machine_downloader https://gitlab.com
#34
“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
#35
#36
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).
#37
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é
#38
La magie du cloud
#39
#40
En général chaque dev possède la copie complète en local donc ça paraît compliqué de tout perdrz
#41
#42
Merci à toi et Qmarlats
" />
#43
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.
#44
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.
#45
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
" />
" />
#46
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.
#47
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…
" /> En plus s’ils passaient chez AWS par exemple ils pourraient utiliser RDS (un équivalent doit sûrement exister chez GCE aussi).
#48
il semble qu’ils aient les deux, en redondance.
#49
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…
" /> (Plus sérieusement merci de l’info je savais pas)
#50
#51
#52
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..).
#53
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.
#54
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…
#55
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 ?
#56
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).
#57
#58
Bizarre les chiffres, ils parlaient d’une perte de 6h de data…
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.
#59
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… 
" />
#60
#61
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.
#62
#63
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.
#64
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 ! 
" />
#65
#66
#67
#68
#69
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.
#70
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 ?
#71
C’est un repo git, tu perds pas tes données (avec gitlab, github, bitbucket…).
#72
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..;-)
#73
5000€ le petit NAS? 
" />
#74
le mot important, c’est “petit”
" />
#75
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.
#76
#77
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
" />
Après ça dépend des disques…
#78
RS3614xs+ avec 12 HDD 2 To SATA
#79
#80
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..
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.
#81
#82
#83
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.
#84
Bof, pour les commits c’est pas dramatiques dans le mesure ou on commit d’abord en local avant d’uploader.
#85
Mais gitlab c’est git. Tous les comptes impactés devaient avoir leur travail en local non?
#86
#87
La news a été modifiée depuis, donc je peux comprendre que mon commentaire semble bizarre maintenant, mais il y avait des incohérences ;)
#88
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é.
#89
Oui et non.
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.