[Insolite] Soucis chez Storify : un membre de l’équipe a effacé la BDD

Ah tiens, une autre idée de T@LC

Le 21 septembre 2012 à 14h50

2 min

Internet

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)

FileNotFound Abonné

Le 21/09/2012 à 15h24

tchize a écrit :

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.

Visiblement ici ce serait plus un DROP (DATABASE) qu’un DELETE.

un delete * from tu peut l’annuler par rollback (si tu t’en rends compte bien sur) " />

FelX Abonné

Le 21/09/2012 à 15h24

jonathanpatate a écrit :

+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).

vive les alias qui te demande confirmation :p

yvan Abonné

Le 21/09/2012 à 15h25

Aznox a écrit :

Pour celui qui posait la question de la base de donnée, on général on a ça :

Sauvegarde (par exemple incrémentielle en semaine, complète le WE, avec plus ou moins de rétention, et si possible externalisée)

Repose sur du hardware redondé (raid 10 / double alim ..)

Répliquée en temps réel sur un autre serveur (si possible avec bascule automatique en cas de panne du premier).

Donc dans leur cas il devait manquer la réplication.

Edit: grilled

A cette échelle de données je ne pense pas que ce soit le genre de politique de sauvegarde possible

Si quelqu’un bosse en datacenter sur le sujet il/elle pourra en dire plus " /> mais copier des données de cette taille sur une sauvegarde me semble impossible même hebdomadairement.

Quant à la réplication si tu fais un drop ben le drop est répliqué ça ne permet pas de retrouver les données.

Snark

Le 21/09/2012 à 15h25

Yutani a écrit :

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)

Dans ma boite, ça fonctionne comme ça:

Base de donnée de production

> Log binaire des requêtes SQL

> Réplication temps réel sur un second serveur

> Dump journalier sur un 3ème serveur en fichier texte (avec archivage sur 1 an)

Et on pense actuellement ajouter un second réplicat avec 10mn de décalage, qui permet de réagir en cas de “DROP TABLE” accidentel :).

La perte d’un base de donnée peu couler une société, donc on y met les moyens !

gaten

Le 21/09/2012 à 15h25

Yutani a écrit :

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)

Le RAID n’est pas une sauvegarde.

klemix

Le 21/09/2012 à 15h26

jonathanpatate a écrit :

Visiblement ici ce serait plus un DROP (DATABASE) qu’un DELETE.

un delete * from tu peut l’annuler par rollback (si tu t’en rends compte bien sur) " />

As tu deja essayer un drop database ?? tu le fais pas comme cela

Un truncate plutot

tifounon

Le 21/09/2012 à 15h28

autre possibilité, déjà utilisée : snapshot de la VM

Erisis

Le 21/09/2012 à 15h30

carbier a écrit :

Je te rassure il n’y pas que chez toi, chez moi c’est arrivé il y a 2 jours " />

Bon en même temps ce n’était pas la racine mais juste le répertoire de prod

C’est arrivé à mon collègue lorsqu’il a commencé à faire du bash…

Il m’a demandé avant d’exécuter si c’était bon et moi naïvement je lui avais répondu: un rm . c’est très méchant, ne te plante pas…. le chemin n’était pas bon, il a dû réinstaller son poste " />

Yutani

Le 21/09/2012 à 15h31

merci pour toutes vos réponses " />

tarti Abonné

Le 21/09/2012 à 15h32

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é :

tu as la sauvegarde hebo ou journalière (dump de la base a un moment donnée

copie en synchro sur de multiple disque dur (l’intérêt est que si un disque crache les autres prennent le relais)

copie en temps réel sur un ou plusieurs serveur(s) pour bascule automatique

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.

Nicolas Vidia

Le 21/09/2012 à 15h33

Indus a écrit :

Il n’existe que deux sorte d’administrateurs ; Ceux qui ont déjà fait une grosse connerie et ceux qui vont en faire une jvachez " />

" /> " />

zefling a écrit :

" /> Depuis le passage dans certaines boîtes plus rien ne peu m’étonner. J’ai vu des exploits bien pire.

De la jvachezerie ?! " />

Wawet76

Le 21/09/2012 à 15h39

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

alzorglub

Le 21/09/2012 à 15h43

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 !

zefling Abonné

Le 21/09/2012 à 15h44

Nicolas Vidia a écrit :

De la jvachezerie ?! " />

Heu, ça c’est un peu d’un autre registre.

FelX Abonné

Le 21/09/2012 à 15h49

hehe ca devient vicieux la :p

alzorglub a écrit :

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 !

Ca arrive souvent les fenêtres identiques ou tu te trompe…

tAran

Le 21/09/2012 à 15h55

Ils auraient pu demander le dernier dump aux anonymous " />

Believe In Nothing

Le 21/09/2012 à 15h55

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.

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 " /> mais il n’a pas perdu son poste.

TaigaIV

Le 21/09/2012 à 15h59

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.

FelX Abonné

Le 21/09/2012 à 16h01

ç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…

taralafifi

Le 21/09/2012 à 16h03

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.

maxxyme

Le 21/09/2012 à 16h04

Il pensait alors supprimer uniquement une copie qui était située sur son portable

Non mais c’est pas sérieux… " /> " /> " />

ionutioio Abonné

Le 21/09/2012 à 16h10

Hmmm j’ai une erreur zarbi quand j’essaye de publier l’article sur Facebook… je pense pas que cela vienne de chez moi

Ricard

Le 21/09/2012 à 16h16

jethro a écrit :

Dans ma boite, après un exploit pareil t’es promu n+2 minimum

Ils embauchent chez toi ?" />

FileNotFound Abonné

Le 21/09/2012 à 16h26

Rappel : Free

zefling Abonné

Le 21/09/2012 à 17h09

jonathanpatate a écrit :

Rappel : Free" /> Dans les fais c’est bien plus compliqué. Il manque des « peut-être », des « mais », des « si », etc.

Ricard

Le 21/09/2012 à 17h12

zefling a écrit :

" /> Dans les fais c’est bien plus compliqué. Il manque des « peut-être », des « mais », des « si », etc.

Et des Yakafokon aussi." />

Fantassin

Le 21/09/2012 à 17h18

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.

elezoic

Le 21/09/2012 à 17h30

Wawet76 a écrit :

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

Personnellement, je fais au minimum “rm ../nomdurepertoirecourant/*”. Et je les précède d’un espace pour éviter d’historiser la commande.

kochka22

Le 21/09/2012 à 17h30

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 " />

Jarodd Abonné

Le 21/09/2012 à 18h04

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 " />

Lumina

Le 21/09/2012 à 19h48

Ca me donne envie de trouver un poste de secrétaire à l’ICANN pour voir si on peut effacer l’Internet.

" />

BreizFenrir

Le 21/09/2012 à 19h49

FelX a écrit :

ça existe pas un système genre sudo pour ce genre d’opérations vraiment risquées?

Comme indiqué par kochka22 plus tôt, l’idéal c’est de ne pas avoir les droits permettant la destruction de données sauf sur un compte qui sert donc très rarement. Sinon la remarque de taralafifi juste après la tienne est aussi excellente.

Ah, si seulement ça avait été le cas quand j’ai accidentellement supprimé les droits d’accès SSH sur le compte utilisé sur la machine de prod distante pendant que je configurais une autre machine disposant de la même base logicielle, mais située elle dans mon bureau. Quand je m’en suis rendu compte, j’ai un peu fait la gueule. On n’a pu retrouver les accès que le lendemain, après intervention d’un technicien sur place. " />

illogict

Le 21/09/2012 à 15h14

Ça me rappelle la suppression d’un projet sans sauvegarde aucune à quelques heures de le rendre à l’école " />

Aznox

Le 21/09/2012 à 15h15

Indus a écrit :

Il n’existe que deux sorte d’administrateurs ; Ceux qui ont déjà fait une grosse connerie et ceux qui vont en faire une " />

+1

jiph

Le 21/09/2012 à 15h15

jethro a écrit :

Dans ma boite, après un exploit pareil t’es promu n+2 minimum

Pas que dans ta boite ^^ malheuresement.

zefling Abonné

Le 21/09/2012 à 15h16

Indus a écrit :

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 " />)

À bon laquelle ?

Ça me rappelle une connerie que j’ai fais avec ftp perso. Je voulais le copier vers un nouveau serveur. Comme un con, j’ai utilisé une comparaison pour faire la copie que j’ai écris à l’envers… Bref : copie d’une référence vide vers un disque plein… Il a écrasé 80% des données du disque plein quand je m’en suis rendu compte. Heureusement j’avais une copie sur mon PC, sauf qu’il m’a fallu 1 semaine pour tout reuploader. " /> C’est dans ce genre de situation que t’as les boules (encore plus dans le cadre pro).

wanou2

Le 21/09/2012 à 15h17

Il a testé le code 1 2 3 4 5 6 " />

SebGF Abonné

Le 21/09/2012 à 15h17

Indus a écrit :

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 " />)

Et moi de la deuxième. " />

tchize

Le 21/09/2012 à 15h18

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 ^^

yvan Abonné

Le 21/09/2012 à 15h18

Yutani a écrit :

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)

Ca dépend de la BDD (et de s’il y en a une tout court) et de l’échelle des données à sauvegarder et de l’objectif de restauration/reprise sur incident visé derrière… c’est une réponse de merde mais on peut aborder de tellement de manières différentes le sujet que je vais pas écrire 60 lignes d’approximations un vendredi " />

Leezi

Le 21/09/2012 à 15h18

Faut le prendre dans l’équipe d’hadopi lui !! " />

tofu

Le 21/09/2012 à 15h18

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 ?”

" />

jethro

Le 21/09/2012 à 15h20

PC INpact pourrait lui envoyer un T-shirt.

C’est un des notres, obligé" />

zglurb

Le 21/09/2012 à 15h21

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.

carbier Abonné

Le 21/09/2012 à 15h21

klemix a écrit :

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

" />

Je te rassure il n’y pas que chez toi, chez moi c’est arrivé il y a 2 jours " />

Bon en même temps ce n’était pas la racine mais juste le répertoire de prod

Aznox

Le 21/09/2012 à 15h21

Pour celui qui posait la question de la base de donnée, on général on a ça :

Sauvegarde (par exemple incrémentielle en semaine, complète le WE, avec plus ou moins de rétention, et si possible externalisée)

Repose sur du hardware redondé (raid 10 / double alim ..)

Répliquée en temps réel sur un autre serveur (si possible avec bascule automatique en cas de panne du premier).

Donc dans leur cas il devait manquer la réplication.

Edit: grilled

yvan Abonné

Le 21/09/2012 à 15h22

tchize a écrit :

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 ^^

Tu peux revenir sur un commit si ta BDD est paramétrée pour ça. Le truc là c’est que je pense qu’un site pareil fonctionne en nosql pour le temps de réponse et que les images n’étant probablement pas dans les BDD voire stockées sur des serveurs à part des données “interractives” remonter dans le temps n’est pas forcément possible.

Diwann

Le 21/09/2012 à 15h22

Indus a écrit :

Il n’existe que deux sortes d’administrateurs ; Ceux qui ont déjà fait une grosse connerie et ceux qui vont en faire une " />

Est-ce que ca veut dire que si on fait partie de la prmière catégorie, on est immunisé à vie ?

sinon, moi je connaissais le proverbe :

L’erreur est humaine mais une vraie catastrophe nécessite le mot de passe root.

" />

DarKCallistO

Le 21/09/2012 à 15h00

Ça c’est du trolledi de compét’ effacer une base de données pour faire chier,il y a pas mieux. " />

Maicka

Le 21/09/2012 à 15h00

Haha !

Un blâme ?

John Shaft

Le 21/09/2012 à 15h00

Yutani a écrit :

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)

Au pif je dirais un dump journalier de la base " />

Lochnar

Le 21/09/2012 à 15h02

" />

Yutani

Le 21/09/2012 à 15h03

John Shaft a écrit :

Au pif je dirais un dump journalier de la base " />

et je n’y avais même pas pensé " />

Lafisk

Le 21/09/2012 à 15h03

Yutani a écrit :

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)

John Shaft a écrit :

Au pif je dirais un dump journalier de la base " />

ça dépend de la configuration en fait et de ton besoin, mais en général je vois plus une sauvegarde hebdomadaire, avec une save incrémentielle journalière

après le raid en soit n’a rien à voir avec cela, tu peux très bien faire ta sauvegarde sur un pauvre disque dur externe …

Nicolas Vidia

Le 21/09/2012 à 15h07

Ah tiens, une autre idée de T@LC

…comme éffacer la salle B4 ? " />" />

zefling Abonné

Le 21/09/2012 à 15h07

" /> Depuis le passage dans certaines boîtes plus rien ne peu m’étonner. J’ai vu des exploits bien pire.

Indus

Le 21/09/2012 à 15h07

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 " />)

al_bebert

Le 21/09/2012 à 15h11

Lafisk a écrit :

ça dépend de la configuration en fait et de ton besoin, mais en général je vois plus une sauvegarde hebdomadaire, avec une save incrémentielle journalière

après le raid en soit n’a rien à voir avec cela, tu peux très bien faire ta sauvegarde sur un pauvre disque dur externe …

sur de l’oracle 2 options : export complet ou export complet + archivelog

permet de remonter une base à la minute prêt en permanance

(en fait oracle conserve toutes les transaction effectuées)

FelX Abonné

Le 21/09/2012 à 15h11

En effet il pourrait servir d’entrainement au gardien de la B4 avant le rush qui s’annonce prochainement :)

FileNotFound Abonné

Le 21/09/2012 à 15h13

+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).

Snark

Le 21/09/2012 à 15h13

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.

klemix

Le 21/09/2012 à 15h13

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

" />

Orphis

Le 21/09/2012 à 15h14

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.

David_L Abonné

Le 21/09/2012 à 15h14

klemix a écrit :

Un mec chez nous avez un script du style

cp \chemin

rm .

Sauf que son chemin n’hesitez plus, il a donc fait son rm sur le dossier racine

" />

" />

zglurb

Le 21/09/2012 à 20h18

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.

Virtual_Spirit

Le 21/09/2012 à 21h13

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 :)

divinechild

Le 22/09/2012 à 03h01

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

gummy35

Le 22/09/2012 à 06h30

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)

deepinpact

Le 22/09/2012 à 08h09

Indus a écrit :

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 " />)

C’est tellement vrai… " />

Khinto

Le 22/09/2012 à 19h05

jonathanpatate a écrit :

+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).

ah, le coup de la crontab, ça m’est déjà arrivé aussi " />

Depuis, moi aussi je fais bien gaffe avant d’appuyer sur entrée !!

hellmut Abonné

Le 21/09/2012 à 14h53

delete

from dual

" />

Ricard

Le 21/09/2012 à 14h53

J’en connais un qui va commencer de très longues vacances." />

jethro

Le 21/09/2012 à 14h58

Dans ma boite, après un exploit pareil t’es promu n+2 minimum

Rastaman971

Le 21/09/2012 à 14h58

" />

On tient un champion du monde en puissance là.

Yutani

Le 21/09/2012 à 14h59

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)

ksnap

Le 21/09/2012 à 14h59

il aurais mieux fais de ctrl + Z cette journée

John Shaft

Le 21/09/2012 à 15h00

" />

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 ? " />

Catégories

Nous Suivre

À propos

[Insolite] Soucis chez Storify : un membre de l’équipe a effacé la BDD

Ah tiens, une autre idée de T@LC

Commentaires (77)