IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

66PARTAGES

10  0 
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de xarkam
Membre éprouvé 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.
4  0 
Avatar de Traroth2
Membre émérite 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é...
3  0 
Avatar de abriotde
Membre chevronné 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.
2  0 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior 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 !
2  0 
Avatar de Lyons
Membre éclairé 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.
2  0 
Avatar de 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...
2  0 
Avatar de kedare
Membre chevronné 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.
1  0 
Avatar de 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
0  0 
Avatar de 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
0  0 
Avatar de Jitou
Membre confirmé 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 ?
0  0