Discussion :

[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]

Il est toujours possible d'avoir un spare master avec une réplication décalée pour ce genre de cas. Ça se fait partout depuis un moment :
https://dev.mysql.com/doc/refman/5.6...n-delayed.html
https://docs.mongodb.com/manual/tuto...ca-set-member/
https://www.postgresql.org/docs/curr...plication.html
https://docs.oracle.com/database/121...ter.htm#i46930

Ça fait une perte de données moindre et on peut plus rapidement basculer sur le spare que lorsqu'on doit réimporter toute la DB, recalculer les indexs, etc.

Tu peut rajouter SQL Server avec AlwaysOn qui permet jusqu'à 8 répliques de la base dont 2 synchrone et 6 asynchrones.
En sus et dans ce cas, le DROP DATABASE, n'est jamais propagé aux répliques et provoque une erreur sur la base source... Pour supprimer une base enrôlée dans un groupe de disponibilité AlwaysOn, il faut commencer par supprimer le groupe de disponibilité, c'est à dire l'ensemble des répliques.... Ceci pour des raions évidentes de sécurité !

Donc une telle erreur est impossible dans l'environnement SQL Server si la haute disponibilité est mise en œuvre ! Et cela date de 2005... donc 12 ans déjà !

A +

[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.