Discussion :

[pascal-od]

Ça me rappelle des souvenirs Il y a environ 10-12 ans j'ai écrasé la BDD de prod par une ancienne sauvegarde (je voulais mettre à jour ma base en local).
Ce qui m'a sauvé la mise c'est les logs binaires de mysql, j'ai donc pu reproduire toutes les requêtes qui avaient été faites depuis la dernière sauvegarde et restaurer la BDD sans perte.
Depuis ce jour je vérifie toujours plusieurs fois chaque opération critique que je fais avec des BDD

[Hikima]

C'est bien la sauvegarde, mais comme on peut le constater cela demande du temps pour la restauration des données.
Pour ma part je pense que le développeur doit se doter d'un moyen pour distinguer intuitivement les environnements de prod et de test.
Les entreprises doivent penser à mettre en place un Plan de Reprise d'Activité (PRA) pour les parties sensibles de leur système d'information,
ce qui réduira de façons significative l'impact de ce type d'erreur sur la continuité et la disponibilité des services de l'entreprise.

[damthemad]

ça m'est arrivé. En charge d'une application centralisée qui sert plusieurs centaines d'agence en France et qui est indispensable au business (réseau d'agences d'interim, application minitel pour contrôle par la direction du crédit avant tout signature de contrat de mission)

Un fs était plein, je devais faire du ménage.
Le système était monté de telle façon que je devais travailler en root
je fais une série de ls récursif puis je vois ce que je peux supprimer et je passe à la suppression
je me rappelle plus exactement mais j'avais tapé le rm et le téléphone a sonné
j'ai répondu
une fois la conversation terminée, je reviens sur mon terminal et comme je savais plus où j'en étais je tape un ls -R * ou un truc du genre sans voir que la commande rm était déjà là.... je valide.
du coup j'ai fait une suppression de fichier récursive sans le vouloir et supprimé une partie de la base de données (des extends de la base se baladaient sur un peu tous les fs).
j'ai failli ne pas le voir en plus. le message d'errreur de suppression de la commande rm ls m'a alerté et j'ai lu mon écran avec attention et vu qu'un rm -r était passé (un truc du genre, c'était il y a un moment sur un unix 386).
bon ceci dis, le téléphone a commencé à sonner dans les minutes qui ont suivies.... heureusement, on était à 15 minutes de la fermeture des agences.

j'ai eu de la chance, les procédures d'exploitation étaient très bien faites avec une sauvegarde chaque nuit et un log activé à neuf chaque matin qui enregistrait toutes les opérations de la journée. J'ai alerté l'exploitation (hé oui, j'étais aux études et obligé de travailler en root et de faire un certain nombre de travaux courants, pas ITIL tout ça), les accès réseau ont été coupés, la sauvegarde remontée et le redo log passé ce qui a permis de retrouver la base au complet sans aucune perte de données.

Mais, ça a duré des heures, deux personnes ont passé la nuit sur place (ils m'ont béni), et coup de chance le problème est survenu en fin de journée. Quant à moi j'ai transpiré ;-)

[SQLpro]

ça m'est arrivé. ... je tape un ls -R * ou un truc du genre sans voir que la commande rm était déjà là.... je valide.
du coup j'ai fait une suppression de fichier récursive sans le vouloir et supprimé une partie de la base de données (des extends de la base se baladaient sur un peu tous les fs).

Là encore, impossible de supprimer une base de données Microsoft SQL Server dans ce cas. En effet, les fichiers des bases en production sont "hookés" par le serveur afin d'en protéger les accès indésirables comme les suppressions intempestives.

Encore faut-il utiliser les bons outils et pas n'importe quoi sans sécurité du genre MySQ...

A +

[iberserk]

Cloisonnement des environnement, comment la production peut-elle etre accessible à des poste de DEV?

Comment les serveur de recettes peuvent ne serait-ce que pinger la prod?

[Grogro]

Cloisonnement des environnement, comment la production peut-elle etre accessible à des poste de DEV?

Comment les serveur de recettes peuvent ne serait-ce que pinger la prod?

Parce que tout le monde n'a pas les moyens ni les compétences pour mettre en place 3 ou 4 environnements de travail cloisonnés.