![[Insolite] Soucis chez Storify : un membre de l'équipe a effacé la BDD](https://cdn.next.ink/inpactv7/data-next/images/bd/wide-linked-media/0.jpg "[Insolite] Soucis chez Storify : un membre de l'équipe a effacé la BDD")
Les clients de Storify ont rencontré quelques soucis ces dernières heures, certains ayant remarqué la perte de données sur leurs comptes. La société vient d'indiquer qu'elle confirmait un souci de son côté : un membre de son équipe a tout simplement effacé la base de données.
Storify est au départ un service qui vous permet d'agréger des contenus issus de différentes sources afin de les partager simplement sous la forme d'une « Story » via un lien ou un code intégrable. Mais dans la nuit, certains utilisateurs ont constaté que dans leur compte, plusieurs éléments récents avaient disparu.
Ainsi, des erreurs 404 apparaissaient en lieu et place, causant la grogne de plusieurs personnes qui utilisent activement l'outil. Ce matin, avec la plus grande honnêteté, Storify a annoncé la cause de ces soucis qui est plutôt insolite : un membre de l'équipe a supprimé toute la base de données par erreur.
"Use Storify" they said! "It's the cool new thing" they said! twitter.com/tracegilton/st…
— Trace Gilton (@tracegilton) Septembre 21, 2012
Il pensait alors supprimer uniquement une copie qui était située sur son portable, alors que ce n'était pas vraiment le cas. On pourra tout de même s'interroger sur les procédures de fonctionnement interne de la société, pour qu'une telle manipulation soit possible sans lever le moindre bouclier. La base a bien entendu été restaurée, mais depuis une sauvegarde précédente. Des données ont donc été perdues au passage et la création de nouvelles « Story » a été suspendue durant la procédure.
La société s'excuse bien entendu du désagrément, et devrait au moins servir de cas d'école pour la transparence dont elle fait preuve, bien que le châtiment prévu (goudron et plumes, huile bouillante...) pour l'employé en question n'ait pas été précisé. On espère néanmoins que les procédures de travail de l'équipe vont se durcir un minimum pour éviter que cela ne se répète.
We finally recovered all published stories. If it was published today after 3pm PST, you will need to republish it. #storifypocalipse
— Xavier Damman (@xdamman) Septembre 21, 2012
Commentaires (77)
#1
delete
" />
from dual
#2
J’en connais un qui va commencer de très longues vacances.
" />
#3
Dans ma boite, après un exploit pareil t’es promu n+2 minimum
#4
On tient un champion du monde en puissance là.
#5
je vais poser une question qui va vous paraitre conne mais comment fonctionnent les sauvegardes sur les BDD ? serveur en Raid ou autre ? sauvegarde logicielle ?
(je suis novice en BDD je précise)
#6
il aurais mieux fais de ctrl + Z cette journée
#7
le châtiment prévu (goudron et plumes, huile bouillante…) pour l’employé en question n’a pas été précisé
Y a bien une p’tite place pour lui en B4 ?
#8
Ça c’est du trolledi de compét’ effacer une base de données pour faire chier,il y a pas mieux.
" />
#9
Haha !
Un blâme ?
#10
#11
#12
#13
#14
Ah tiens, une autre idée de T@LC
…comme éffacer la salle B4 ?
#15
#16
Il n’existe que deux sorte d’administrateurs ; Ceux qui ont déjà fait une grosse connerie et ceux qui vont en faire une
" />
" />)
(Je fais parti de la première catégorie
#17
#18
En effet il pourrait servir d’entrainement au gardien de la B4 avant le rush qui s’annonce prochainement :)
#19
+1 Indus. Seuls ceux qui ne touchent à rien ne font pas de conneries.
" />
" />
" />
L’autre fois au boulot, mon doigt a ripé : crontab -r au lieu de crontab -e. 1 lettre d’écart sur le clavier.
Trop tard ! La prochaine fois relire avant de faire Entrée !
Une incrémentale journalière peut ne pas suffire, n’oubliez pas les archives logs !!!
Penser à sauvegarder RMAN aussi, sinon çà ne sert à rien.
Vous n’êtes pas sous ORACLE ? Oh les noobs !!! (Humour, je rigole).
#20
Hééé, on se moque pas, ça peut arriver a tout le monde !!!
….
……..
…………..
Oui, bon, ça m’es arrivé il y a deux semaines dans ma boite. Mais je suis le mainteneur principale de bases de données, et suite à une migration de serveur j’ai effacé la base de production, et pas celle de test…
Résultat: 20mn d’interruption de site. Merci le réplicat + les logs binaires ! Zero pertes de données.
#21
Un mec chez nous avez un script du style
" />
cp \chemin
rm .
Sauf que son chemin n’exister plus, il a donc fait son rm sur le dossier racine
#22
Le raid ne servirait à rien car il sert soit à accélérer les chargements (RAID0) ou à vérifier l’intégrité des données. Ici les données étaient bonnes et le support de stockage a fait ce qu’on lui demandait: effacer les données.
Donc oui, c’est plutôt un dump régulier de la base de donnée + log.
#23
#24
Ça me rappelle la suppression d’un projet sans sauvegarde aucune à quelques heures de le rendre à l’école
" />
#25
#26
#27
#28
Il a testé le code 1 2 3 4 5 6
" />
#29
#30
On pourra tout de même s’interroger sur les procédures de fonctionnement interne de la société, pour qu’une telle manipulation soit possible sans lever le moindre bouclier.
Je ne connais pas beaucoup de base de données, même à haute disponibilité, qui te demande deux fois ton avis avant de faire un delete.
T’as beau mettre plein de sécurité, quand tes bonhommes doivent faire 50 trucs par jour sur la prob, si il y a une chance sur 10.000 de se planter, ça te fais une moyenne d’une fois par an ^^ . Y a que les gens qui ne font rien qui ne strompent jamais ^^
#31
#32
Faut le prendre dans l’équipe d’hadopi lui !!
" />
#33
Je pense qu’avec un truc comme ça, les jours qui suivent tu fais profile bas…
" />
“Heu patron, au fait pour mon augmentation dont on parlait la semaine dernière ?”
#34
PC INpact pourrait lui envoyer un T-shirt.
" />
C’est un des notres, obligé
#35
M’est arrivé une fois de faire ça (
" /> ). Bon c’était une appli intranet utilisée par 3 pèlerins pas un site web public. Et j’avais un dump de moins de 2 minutes réimporté aussi sec après un gros coup de chaleur.
A la base je voulais faire un dump de prod pour l’importer sur mon poste en local. Sauf que j’ai fait le DROP DATABASE avant l’import sur la prod et pas sur mon poste.
#36
#37
Pour celui qui posait la question de la base de donnée, on général on a ça :
Donc dans leur cas il devait manquer la réplication.
Edit: grilled
#38
#39
#40
#41
#42
#43
#44
#45
#46
autre possibilité, déjà utilisée : snapshot de la VM
#47
#48
merci pour toutes vos réponses
" />
#49
Pour celui qui demande pour la sauvegarde des bases, j’explique de façon simple les différentes technique qui sont souvent coexistante dans une société :
et enfin mon préféré copie sur bande pour des données a conserver plusieurs année ( beaucoup moins utilisé).
Dans ma boite (une très grande institution française) on cumule l’ensemble des solutions : les multi disque pour le crache d’un disque, les multiserveurs dans plusieurs bâtiment éloigné de centaines de km en cas de problème important sur un bâtiment. Et sauvegarde sur bande pour les données anciennes de 3 à 10 ans pour des questions administrative et juridique.
#50
#51
Vous faites souvent “rm .” en bash ?
Parce que “rm *” ça suffit. Et pour que les erreurs fassent vraiment mal prenez l’habitude de toujours mettre -rf
#52
lol..j’ai fait la même: j’avais 2 fenêtres ouvertes, la base de test et la base de prod, de même aspect..fatigue..stress.. trompage de fenêtre avec un truncate.. heureusement y’a les sauvegardes !
#53
#54
hehe ca devient vicieux la :p
#55
Ils auraient pu demander le dernier dump aux anonymous
" />
#56
J’ai déjà vu un : delete from nom_table dans l’environnement de production, la table contenait entre 4 et 5 millions de lignes.
" /> mais il n’a pas perdu son poste.
On était obligé de restaurer la sauvegarde de la veille, le résultat n’était pas sans perte de données.
La personne qui a fait ça n’a pas dormis 3 jours
#57
Vécu :
-Tu as un backup de la base ?
-Tu parles de la base de prod sur laquelle je ne voulais pas te donner les droits d’admin ?
-Oui, c’est celle la.
-Bon ben va on remettre le backup de la veille et faire mumuse avec les logs binaires.
#58
ça existe pas un système genre sudo pour ce genre d’opérations vraiment risquées?
Ca serait plus contraignant, mais bon la au moins si le gars voit une demande de pass, il serait amener a vérifier.
Sinon toutes les opérations “dangereuses” sur une base répliquée, et ça n’est répercuté sur la base principale que s’il n’y a aucun soucis…
#59
Voilà pourquoi il ne faut jamais utiliser la même machine pour bosser en qual ou en prod.
Chez nous, on a toujours 2 serveurs : Un de qualification et un autre de production.
Et on prend la main sur ces serveurs à partir de clients différent. Une machine où on n’attaque que le serveur de qual, et une autre où on n’attaque que le serveur de prod.
Comme ça pas de risque de se tromper.
#60
Il pensait alors supprimer uniquement une copie qui était située sur son portable
Non mais c’est pas sérieux…
#61
Hmmm j’ai une erreur zarbi quand j’essaye de publier l’article sur Facebook… je pense pas que cela vienne de chez moi
#62
#63
Rappel :http://boddingtons.free.fr/incidents.html
#64
#65
#66
Maintenant le patron de la boite va mettre du scotch sur les touches Del, D, E et L de tous les claviers.
" />
Bon sinon c’est quelques milliers d’euros et de clients de perdus, c’est pas la mort.
#67
#68
Ahahaha
" />
" />
" />
J’ai fais ça sur un très gros site il y a 2 mois
En voulant lancer un script, j’ai fais un
rake -t ou lieu de rake -T et bizarrement ça a eu pour effet de déclencher tous les scripts de maintenance dont db:drop…. quand le truc est parti je m’en suis rendu compte en tapant ctrl-c comme un malade mais rien à faire :)
j’ai effacé tous les serveurs d’un coup => replication
Bon on a rien perdu grâce a la backup de la nuit + binlogs de replication mais grosse soirée de merde et downtime de 5 heures….
Depuis j’ai enlevé le droit de DROP de la plupart de mes users
#69
Je ne vais pas me moquer, un jour j’ai fait pareil avec une préprod
" /> Avec un backup vieux de plus de 6 mois 
" />
" />
En fait c’est rapidement arrivé : tu fais un export avec un client, tu veux passer la requête de création sur ta base, mais tu ne vois pas que l’export commence par un “DROP DATABASE”, et du coup paf la base
#70
Ca me donne envie de trouver un poste de secrétaire à l’ICANN pour voir si on peut effacer l’Internet.
" />
#71
#72
En l’occurrence, l’employé de Storify il s’est trompé d’environnement. Le mieux pour prévenir ce genre d’erreur c’est de bien mettre en avant que t’es en prod. Genre un prompt avec écrit “PROD $” en rouge.
#73
En faite je me dis que ça pourrait très facilement m’arriver ça.
J’utilise un logiciel qui s’apelle Navicat et j’ai l’arboressence de mes serveurs / BDD / Tables sur la gauche.
Dans la liste des serveurs j’ai :
Local
Tests
Production
Mais au final une petite erreur d’inattention et je sélectionne le serveur de Prod à la place de celui de test.
Et là du coup je me dis, comment faire pour éviter un DELETE un DROP ou une connerie du genre ?
L’idée de donnée des droits restreint aux utilisateurs (et se créer un compte exprès pour les opérations délicates) me semble intéressant pour les DROP et compagnies qu’on utilise logiquement assez peu souvent en production.
Mais si d’autre personnes ont d’autres idées je suis preneur :)
#74
Et péter le lien principal + son backup entre 2 back bones de 2 data center d une banque, qui l a fait ?
" />
p.s: pas moi heureusement, juste mon boss xD
#75
en ssh, après une commande bien chiante, quelques completions de directory, et donc un affichage foireux (et ouais, ca arrive):
sudo rm -rf / home/gummy/testalakon (notez l’espace entre le / et le home)
cd
bash: cd: Aucun fichier ou dossier de ce type
ls
ls : commande introuvable (testicules qui remontent dans l’abdomen)
#76
#77