Developpez.com

Plus de 14 000 cours et tutoriels en informatique professionnelle à consulter, à télécharger ou à visionner en vidéo.

GitLab parvient à restaurer certaines données supprimées accidentellement et se remet en ligne
Mais 6 heures de données n'ont pas pu être récupérées

Le , par Olivier Famien, Chroniqueur Actualités
Le 31 janvier dernier aux environs de 18 h GMT, un administrateur chez GitLab a accidentellement supprimé plus de 300 Go de données de production. À la suite de cette erreur humaine, le site fut indisponible depuis cet incident jusqu’au lendemain aux environs de 18 h GMT.

Généralement, les entreprises qui stockent des données sensibles assurent leur résilience en faisant des sauvegardes régulières de leurs données et cela dans différents endroits. Par ailleurs, elles s’efforcent de suivre des codes de bonnes pratiques en testant de manière régulière l’intégrité de leurs sauvegardes afin de ne pas avoir de mauvaises surprises en cas de soucis. Toutefois, l’incident qui a frappé la plateforme GitLab a démontré que l’entreprise ne s’était pas préparée à tout cela. Toutes les tentatives de restauration de la base de données supprimée à partir des sauvegardes ont échoué.

Fort heureusement, les données supprimées ne concernaient que celles des utilisateurs, des commentaires, des snippets, des bogues, des demandes d’intégration de changements, etc. Les dépôts Git et Wiki des développeurs ainsi que les installations hébergées par l’entreprise n’ont pas été affectés par cet accident. Par ailleurs, GitLab souligne que seul 1 % des utilisateurs (707 en tout) sont concernés par ces données supprimées.

En fin de compte, GitLab a pu récupérer un instantané des données disponibles sur un serveur de tests afin de restaurer les données supprimées et est de retour sur la toile. Toutefois, GitLab explique que ces données restaurées proviennent d’une sauvegarde vieille de 6 heures. Ce qui signifie que toutes les données de projets, de problèmes, de demandes de fusion d’utilisateurs, de commentaires, de snippets comprises entre 17 h 20 et 23 h 25 GMT du 31 janvier sont perdues.

Consciente que la perte de données de production sans possibilité de les restaurer en totalité est inacceptable, GitLab entend publier dans les jours à venir les causes de l’occurrence d’un tel accident et la liste des mesures qu’elle a implémentées pour éviter que pareilles erreurs ne surviennent à nouveau.

Source : GitLab

Et vous ?

Quelles leçons tirez-vous de l’accident qui a frappé GitLab ?

Quels conseils pouvez-vous donner afin de permettre aux autres entreprises de mieux gérer de tels incidents ?

Voir aussi

Un administrateur système de GitLab supprime accidentellement 310 Go de données de production et rend le site indisponible depuis plusieurs heures
GitHub : des utilisateurs de la plateforme se disent « frustrés » et « complètement ignorés » sur une pétition signée par des centaines d'entre eux

Forum Actualités, Wiki Developpez.com, Débats Best of, FAQ Developpez.com


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de kedare kedare - Membre expérimenté https://www.developpez.com
le 03/02/2017 à 9:54
Citation Envoyé par ddoumeche Voir le message
Il faut espérer au contraire qu'il soit mis à la porte ou lourdement sanctionné, la sauvegarde doit rester l'alpha et l'oméga du travail de tout administrateurs système ou DBA.

Il n'y a pas de journaux de transaction dans Postgresql, qui puisse être rejoués depuis la dernière sauvegarde ?
Si, mais le soucis c'est qu'il faut faire un full restore avant, et ils ont payés des virtual disks cheap donc super lent pour copier et restaurer le full backup (5MBps je crois..), du coup ca a mis super longtemps.
Aussi ils ont commencé en voulant faire une réparation sur le serveur secondaire (Qui aurait pu failover), donc le secondaire était H.S et il a voulu tout effacer pour le refaire clean sauf qu'il était connecté sur le primaire a ce moment la, du coup... secondaire H.S et primaire H.A aussi... Pas de chance la dessus.
Avatar de MikeRowSoft MikeRowSoft - Provisoirement toléré https://www.developpez.com
le 03/02/2017 à 10:07
Comment ça ?

Selon les cours d'administrateur de bases de données il restait encore des traces dans les logs et sur le disque dur (fichier de bases de données). Bien plus que se qu'il peut y avoir sur les partitions après suppression normalement (table d'allocation) dans quelques cas.

Tout aurait dû être récupéré. A moins que se soit du spécifique Oracle chose très probable... (le seul que je connais autant )
Avatar de xarkam xarkam - Membre averti https://www.developpez.com
le 03/02/2017 à 12:36
Citation Envoyé par grunk Voir le message
Ce moment de solitude quand tu te rend compte que la commande de suppression est lancée l'environnement de prod
Oui, enfin, le minimum requis c'est d'avoir un prompt bien distinct avec coloration différente selon que tu es sur prod ou réplication, voir même carrément le background xterm en rouge sur la/les machine(s) de prod.
Avatar de MikeRowSoft MikeRowSoft - Provisoirement toléré https://www.developpez.com
le 03/02/2017 à 13:00
Citation Envoyé par xarkam Voir le message
Oui, enfin, le minimum requis c'est d'avoir un prompt bien distinct avec coloration différente selon que tu es sur prod ou réplication, voir même carrément le background xterm en rouge sur la/les machine(s) de prod.
j'adore, il en faut au moins deux pour faire l'erreur.
Avatar de TiranusKBX TiranusKBX - Expert confirmé https://www.developpez.com
le 04/02/2017 à 23:19
Avant de faire mes commandes sur SSH je verifie toujour le nom de la machine affiché en haut à gauche de la fenêtre putty, ça évite ce genre de problème
Avatar de tchize_ tchize_ - Expert éminent sénior https://www.developpez.com
le 05/02/2017 à 10:26
Citation Envoyé par xarkam Voir le message
Oui, enfin, le minimum requis c'est d'avoir un prompt bien distinct avec coloration différente selon que tu es sur prod ou réplication, voir même carrément le background xterm en rouge sur la/les machine(s) de prod.
Je vois pas en quoi ça changerais grand chose. Sauf si t'es du genre à ne jamais faire la moindre opération sur tes serveur de production. Ca n'évitera jamais l'espace coincé dans une commande, le script qui perd les pédales, le mauvais dossier courant, les mauvais caractères de substitution. Les erreur ça arrive. Et sur la production, ça peux faire du dégât. On peux mitiger au maximum (ne jamais être root, avertissements dans le terminal) mais on n'évitera jamais l'erreur humaine ou la distraction.

Je ne considère personnellement pas le prompt coloré comme un minimum requis. D'abord parce que toutes les consoles ne supportent pas nécessairement la coloration, que ton opérateur peut être daltonien ou simplement que ça peut être incompatibles avec certains outils ou certains modes de connexion. De plus rien ne nous dit que ce n'était pas le cas ici. Ce n'est pas une solution magique
Avatar de Jitou Jitou - Membre averti https://www.developpez.com
le 06/02/2017 à 13:30
Dans certaines boites il n'y a pas de garde fou pour parer aux loupés des admins et l'usage de sudo devient alors la règle et il est devenu quoi cet admin téméraire ?
Avatar de Stéphane le calme Stéphane le calme - Chroniqueur Actualités https://www.developpez.com
le 13/02/2017 à 12:08
GitLab revient sur la panne qui l'a frappé le 31 janvier dernier
et indique les mesures prises pour garantir que cela ne se reproduise plus

Le 31 janvier dernier, la plateforme de gestion des développements collaboratifs GitLab a été indisponible pendant plusieurs heures. Sur son portail, les utilisateurs pouvaient lire « GitLab.com est actuellement hors ligne en raison de problèmes avec notre base de données de production. Nous travaillons dur pour résoudre le problème rapidement. Suivez GitLabStatus pour les dernières mises à jour ».

Un problème qui est survenu alors qu’un administrateur système de GitLab a entamé une procédure de réplication des données de production pour les utiliser à d'autres fins. Un incident qui a conduit à la suppression de plus de 300 Go de données en production. GitLab a indiqué avoir perdu plus de 6 heures de données qui ont atterri sur sa plateforme, ce qui signifie qu’environ 4613 projets réguliers, 74 forks, et 350 importations ont été effacés. Elle s’est attelée à restaurer le maximum de données possible.

Dans un billet de blog, GitLab a reconnu que « perdre des données de production est inacceptable. Pour garantir que cela ne se reproduise plus, nous travaillons à de multiples améliorations à nos opérations et procédures de récupération pour GitLab.com ». Aussi, avant de présenter son analyse (notamment ce qui s’est mal passé, ce qui a été fait pour restaurer les données et les décisions prises pour éviter ce genre d’incident à l’avenir), le PDG de GitLab a tenu à présenter ses excuses à tous les utilisateurs personnellement et également au nom de toute l’équipe.

Pour analyser la cause première de ces problèmes, GitLab a utilisé la règle des « 5 why ». L’incident a été divisé en deux problèmes principaux : GitLab.com en panne et la grosse quantité de temps que cela a coûté pour restaurer GitLab.com.

Problème 1: GitLab.com était en panne pendant 18 heures environ.

  1. Pourquoi GitLab.com était-il en panne ? Le répertoire de la base de données primaire a été supprimé par accident, au lieu de supprimer le répertoire de base de données secondaire.
  2. Pourquoi le répertoire de base de données a-t-il été supprimé? La réplication de base de données s'est arrêtée, nécessitant la réinitialisation / reconstitution du secondaire. Ceci nécessite à son tour que le répertoire de données PostgreSQL soit vide. Sa restauration doit être faite en manuel, car le processus n’est pas automatisé. De plus ce processus n’a pas été convenablement documenté.
  3. Pourquoi la réplication a-t-elle cessé ? Un pic de chargement de la base de données a provoqué l'arrêt du processus de réplication de la base de données. Cela était dû au retrait primaire des segments WAL avant que le secondaire ne puisse les reproduire.
  4. Pourquoi la charge de la base de données a-t-elle augmenté ? Cela a été causé par deux événements se produisant en même temps : une augmentation du spam, et un processus visant à supprimer un employé GitLab et les données associées.
  5. Pourquoi un employé de GitLab devait-il être retiré ? L'employé a été signalé par un troll pour abus. Le système actuel utilisé pour répondre aux rapports d'abus facilite la négligence des détails concernant ceux qui ont été signalés. Par conséquent, l'employé a été accidentellement programmé pour un retrait.

Problème 2 : la restauration de GitLab.com a pris plus de 18 heures.

  1. Pourquoi la restauration de GitLab.com a-t-elle duré si longtemps? GitLab.com a dû être restauré en utilisant une copie de la base de données intermédiaire. Cette dernière était hébergée sur des machines virtuelles plus lentes d'Azure dans une région différente.
  2. Pourquoi la base de données intermédiaire était nécessaire pour restaurer GitLab.com? Les snapshots de disque Azure n'étaient pas activés pour les serveurs de base de données et les sauvegardes de bases de données périodiques à l'aide de pg_dump ne fonctionnaient pas.
  3. Pourquoi ne pas se tourner vers l'hôte de base de données secondaire ? Les données de la base de données secondaire ont été effacées dans le cadre de la restauration de la réplication de la base de données. En tant que telle, elle ne pouvait donc plus être utilisée pour la restauration.
  4. Pourquoi ne pas utiliser une procédure standard de sauvegarde ? La procédure de sauvegarde standard utilise pg_dump pour effectuer une sauvegarde logique de la base de données. Cette procédure a silencieusement échoué, car elle utilisait PostgreSQL 9.2, tandis que GitLab.com s'exécute sur PostgreSQL 9.6.
  5. Pourquoi la procédure de sauvegarde a-t-elle silencieusement échoué ? Des notifications ont été envoyées après l’échec. Cependant, à cause du rejet des courriels, il n'y avait aucune indication d'échec. L'envoi était un processus automatisé sans autre moyen de signaler des erreurs.
  6. Pourquoi les courriels ont-ils été rejetés ? Les courriels ont été rejetés par le serveur mail à cause des courriels qui n’étaient pas signés en utilisant DMARC.
  7. Pourquoi les snapshots de disque Azure n'ont-ils pas été activés ? Nous avons supposé que nos autres procédures de sauvegarde étaient suffisantes. En outre, la restauration de ces snapshots peut prendre des jours.
  8. Pourquoi la procédure de sauvegarde n'a-t-elle pas été testée régulièrement ? Parce qu'il n'y avait pas de propriétaire assigné, par conséquent personne n'était responsable pour les tests de cette procédure.

L’entreprise a décidé de travailler à corriger et améliorer ses diverses procédures de restauration. Voici comment elle a réparti ses tâches :
  • mettre à jour PS1 sur tous les hôtes pour différencier plus clairement les hôtes et les environnements (# 1094) ;
  • surveiller les sauvegardes Prometheus (# 1095) ;
  • Définir max_connections de PostgreSQL sur une valeur rationnelle (# 1096) ;
  • étudier la restauration ponctuelle et l'archivage continu de PostgreSQL (# 1097) ;
  • effectuer des snapshots LVM horaires des bases de données de production (# 1098) ;
  • effectuer des snapshots de disque Azure des bases de données de production (# 1099) ;
  • restauration des répliques de production (# 1101) ;
  • tests automatisés de récupération des sauvegardes de bases de données PostgreSQL (# 1102) ;
  • améliorer la documentation de réplication PostgreSQL (# 1103) ;
  • recherchez pgbarman pour créer des sauvegardes PostgreSQL (# 1105) ;
  • étudier l'utilisation de WAL-E comme moyen de sauvegarde de base de données et de réplication en temps réel (# 494) ;
  • création de la restauration en continu de la base de données ;
  • affecter un propriétaire pour la durabilité des données.

Source : GitLab

Et vous ?

Que pensez-vous de ces mesures ? Sont-elles suffisantes pour endiguer ce type de problème à l'avenir ?
Avatar de abriotde abriotde - Membre éclairé https://www.developpez.com
le 13/02/2017 à 14:13
Merci GitLab : C'est la première fois que je vois une entreprise être aussi transparente et c'est une chose extraordinairement bien. Je pense que les erreurs sont courantes en entreprise mais en général les entreprises se contentent de dire "Cela ne se reproduira pas. Nous avons fais ce qu'il faut". Sous entendu, "nous avons mis la pression et virer 2-3 personnes responsables.".

J'apprécie les détails techniques que nous avons là et même si tous le monde ne les comprendra pas, ils apportent un sérieux et une véritable transparence.
Avatar de hotcryx hotcryx - Membre chevronné https://www.developpez.com
le 13/02/2017 à 14:33
"L'employé a été signalé par un troll pour abus.
... par conséquent, l'employé a été accidentellement programmé pour un retrait."

hein! Des robots?
Avatar de Mingolito Mingolito - Membre chevronné https://www.developpez.com
le 13/02/2017 à 15:31
Enfin du coup tout ça c'est une belle pub pour Github, parce que au moins Github ça marche.
D'ailleurs peu être qu'on découvrira que l'informaticien responsable de ce désastre à été payé par Github ?
A moins que ça soit un coup des russes ?

Avatar de Traroth2 Traroth2 - Membre chevronné https://www.developpez.com
le 13/02/2017 à 16:35
Rien ne permet d'être sûr qu'un truc pareil n'arrivera pas chez GitHub.

Un cas typique de clusterfuck. Généralement, quand un problème se produit, ça peut se régler assez facilement. C'est quand il y a plusieurs problèmes qui se produisent en même qu'on peut assez rapidement se retrouver coincé...
Avatar de Aurelien.Regat-Barrel Aurelien.Regat-Barrel - Expert éminent https://www.developpez.com
le 13/02/2017 à 18:18
Citation Envoyé par Traroth2 Voir le message
Rien ne permet d'être sûr qu'un truc pareil n'arrivera pas chez GitHub.

Un cas typique de clusterfuck. Généralement, quand un problème se produit, ça peut se régler assez facilement. C'est quand il y a plusieurs problèmes qui se produisent en même qu'on peut assez rapidement se retrouver coincé...
Certes, mais quand on gratte un peu, on se rend souvent compte que c'est pas un hasard que ça arrive sur certains projets et pas d'autres. Perso, je pense que ce genre de problèmes en chaîne ne relève pas du hasard mais est symptomatique d'une accumulation de négligences. Ce qui est résumé - selon moi - par cette phrase :

Parce qu'il n'y avait pas de propriétaire assigné, par conséquent personne n'était responsable pour les tests de cette procédure.
c'est exactement l'impression que m'a donné Gitlab quant à la façon de gérer les issues : au petit bonheur la chance ! Pour avoir aussi déjà reporté (une fois) un problème à Github, j'ai pu voir la différence ! Hyper réactivité d'un côté pour un sujet mineur, pas de nouvelles de l'autre pour un vrai problème de config (LDAP).

Ca m'a donné l'impression qu'ils se sont égarés dans une course aux fonctionnalités au détriment de la rigueur et de la qualité. Et je suis bien content que cet événement se soit passé ainsi, car au final ils s'en tirent bien et ça fait office d'électro-choc sur leur façon de gérer les issues. Enfin, c'est ce que j'espère, car c'est un outil que j'apprécie beaucoup !
Avatar de Lyons Lyons - Membre confirmé https://www.developpez.com
le 13/02/2017 à 18:39
Citation Envoyé par abriotde Voir le message
Merci GitLab : C'est la première fois que je vois une entreprise être aussi transparente et c'est une chose extraordinairement bien. Je pense que les erreurs sont courantes en entreprise mais en général les entreprises se contentent de dire "Cela ne se reproduira pas. Nous avons fais ce qu'il faut". Sous entendu, "nous avons mis la pression et virer 2-3 personnes responsables.".

J'apprécie les détails techniques que nous avons là et même si tous le monde ne les comprendra pas, ils apportent un sérieux et une véritable transparence.
Contrairement aux autres entreprise dont on nous relate souvent les exploits en matière d'incompétence informatique, GitLab est une entreprise dont les services sont destinés à des informaticiens. La clientèle étant tout aussi compétente qu'eux dans le domaine en question, ils se doivent d'être un minimum transparent s'ils veulent pas avoir l'air de gros charlots.
Avatar de Traroth2 Traroth2 - Membre chevronné https://www.developpez.com
le 14/02/2017 à 15:47
@Aurelien.Regat-Barrel : Ça se défend, ce que tu dis.
Avatar de admadama admadama - Futur Membre du Club https://www.developpez.com
le 15/02/2017 à 10:04
Pourquoi la réplication a-t-elle cessé ? Un pic de chargement de la base de données a provoqué l'arrêt du processus de réplication de la base de données. Cela était dû au retrait primaire des segments WAL avant que le secondaire ne puisse les reproduire.
Un contributeur au système de réplication de PG explique en réponse dans un post qu'il est fort probable que si le mec n'avait pas touché à la réplication, le problème aurait fini par se résoudre une fois l'attaque passée.

I’m not sure there was any action needed at all. The replication delay was caused by the huge write spike on the database that came about because of the denial of service attempts from hackers. It would likely have reduced back to lower levels quite quickly.
source : https://blog.2ndquadrant.com/dataloss-at-gitlab/
Avatar de Sve@r Sve@r - Expert éminent sénior https://www.developpez.com
le 27/02/2017 à 20:55
Bonjour

Moi quand je bossais sour Sun j'avais l'habitude de purger /tmp. Je tapais donc la commande cd /tmp; rm -fr * .* et ça fonctionnait super.

Un jour j'ai voulu aller plus vite et j'ai tapé rm -fr /tmp/* /tmp/.*. Et là, la commande ne m'a pas rendu la main. Je fronce les sourcils et je commence à me demander ce qui se passe. Et d'un coup j'ai compris que dans "/tmp/.*" il y avait "/tmp/.." (*) !!!
Bon plutôt que d'investiguer sur les dégats j'ai préféré réinstaller ma machine. Alors certes ce n'était pas une machine de prod mais une machine de dev donc les dommages étaient locaux mais c'est pour dire que parfois, même quand on maitrise, ben des conneries on en fait quand-même. D'ailleurs bien plus récemment (en 2012) avec des copains on j'avait créé une maquette de démo avec bdd Postgres (c'est moi qui m'était occupé de la bdd). Et le jour de la démo devant des clients acheteurs, 2h avant la démo ; une mauvaise redirection et j'écrase le dump de la bdd. Bon là j'ai immédiatement prévenu mes potes pour limiter les dégats. Je leur ai proposé de rentrer chez-moi récupérer un dump que j'avais conservé (1h30 aller/retour mais c'était faisable) mais mon pote (qui était l'analyste du groupe) a préféré recréer le contenu de la bdd avec les infos qu'il avait en tête et dans ses fichiers (10mn).
Donc voilà, tout le monde fait des conneries (mais c'est dommage que les backup aient foirés).

(*) Aujourd'hui sous Linux la commande est protégée et rm .* bloque la remontée sur ".." mais à l'époque...
Offres d'emploi IT
Responsable de projet logiciel H/F
Safran - Ile de France - Éragny (95610)
Ingénieur statisticien H/F
Safran - Ile de France - Moissy-Cramayel (77550)
Ingénieur produit (FADEC militaire) H/F
Safran - Ile de France - 100 rue de Paris 91300 MASSY

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil