+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 2 12 DernièreDernière
  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Webmaster
    Inscrit en
    janvier 2014
    Messages
    616
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Webmaster
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2014
    Messages : 616
    Points : 12 922
    Points
    12 922

    Par défaut Panne GitLab : la société indique les mesures prises pour éviter que ce type de scénario se reproduise

    Un administrateur système de GitLab supprime accidentellement 310 Go de données de production
    et rend le site indisponible depuis plusieurs heures

    La plateforme de gestion des développements collaboratifs GitLab est indisponible depuis hier 31 janvier. Sur son portail, on peut lire ouvertement que « GitLab.com est actuellement hors ligne en raison de problèmes avec notre base de données de production. Nous travaillons dur pour résoudre le problème rapidement. Suivez GitLabStatus pour les dernières mises à jour ».

    Ce problème est survenu alors qu’un administrateur système de GitLab a entamé une procédure de réplication des données de production pour les utiliser à d'autres fins. Après avoir entamé la procédure de réplication, l’administrateur a dû l’interrompre pour régler un problème de spam et de surcharge de la base de données. Lorsque ce dernier a pu rétablir à la normale le chargement de la base de données PostgreSQL et est revenu sur la réplication de sa base de données, il a reçu une alerte du système qui refusait de répliquer la base de données. Après avoir essayé plusieurs solutions sans succès, l’administrateur s’est dit que le système doit certainement détecter un répertoire vide et décide de supprimer ce répertoire. Malheureusement pour ce dernier, après une ou deux secondes, il remarque qu’il a exécuté la requête sur la base de données de production. Il tente désespérément d’annuler la requête, mais sur les 310 Go de données contenues dans le répertoire, il ne reste plus que 4,5 Go de données.

    Comme conséquences de ce fâcheux accident, l’entreprise indique qu’elle a perdu plus de 06 heures de données qui ont atterri sur sa plateforme, ce qui signifie qu’environ 4613 projets réguliers, 74 forks, et 350 importations sont effacés. L’entreprise ajoute que 707 utilisateurs sont affectés par cette perte et l’on peut également envisager une perte de tous les webhooks (fonctionnalités d’une application permettant de fournir des données en temps à une autre application), même si l’information reste encore non confirmée.

    Depuis cet accident, l’entreprise se bat avec ses équipements pour récupérer les données perdues. La grosse difficulté pour GitLab est que les instantanés du gestionnaire des volumes logiques sont effectués par défaut une fois toutes les 24 heures. De même, les sauvegardes régulières sont également faites une fois toutes les 24 heures. Du côté d’Azure, ce sont les mêmes difficultés. Les instantanés de disque dans Azure sont activés pour le serveur NFS, mais pas pour les serveurs de base de données. En plus de ces problèmes répertoriés, GitLab souligne que « le processus de synchronisation supprime les webhooks une fois qu’il a synchronisé les données à la simulation. À moins que nous puissions les retirer d’une sauvegarde régulière des dernières 24 heures, elles seront perdues ». En envisageant de passer par la réplication, l’équipe de GitLab estime que « la procédure de réplication est super fragile, encline à l’erreur, repose sur une poignée de scripts de shell aléatoires et est mal documentée ». À ces maux, il faut adjoindre le fait que les sauvegardes sur le cloud Amazon S3 ne fonctionnent pas du tout, bucket, l’unité de logique de stockage sur Amazon Web Services (AWS) est vide. Les ingénieurs de GitLab expliquent qu’ils n’ont pas un système solide d’alerte et de pagination lorsque les sauvegardes échouent.

    En fin de compte « sur les cinq techniques de sauvegarde/réplication déployées, aucune ne fonctionne correctement ni n’est configurée en premier lieu ». Le pire dans cette histoire est que l’entreprise a annoncé vers la fin de l’année dernière qu’elle abandonnait le cloud pour migrer vers Ceph FS, le nouveau système de fichiers utilisant des groupes de serveurs pour stocker ses données sur la plateforme Ceph afin d’améliorer les performances de l’accès aux données. Malheureusement, en privilégiant cette plateforme pour ses performances et la haute disponibilité des données, GitLab a négligé d’autres aspects ce qui lui coûte cher aujourd’hui.

    Actuellement, l’entreprise essaye de restaurer la sauvegarde qui a été faite six heures avant la perte de données. Sur Tweeter, GitLab affirme qu’elle a pu restaurer ces données. Cela signifie donc que si les données sont restaurées avec cette sauvegarde, il y aura certainement des pertes de données qui se feront ressentir. Pour l’administrateur qui a occasionné cette perte, il retient « qu’il est préférable pour lui de ne plus rien exécuter aujourd’hui avec sudo ». Mais au-delà de cet incident, l’on peut également noter que GitLab a été véritablement transparent dans cet incident en communiquant énormément sur les différentes étapes des actions entreprises.

    Gitlab Live Stream: working on restoring gitlab.com


    Source : GitLab, GitLab Google docs détails sur l’incident, Tweeter

    Et vous ?

    Que pensez-vous de cet incident ?

    Erreur, négligence ou incident inévitable ?

    Voir aussi

    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

  2. #2
    Membre habitué Avatar de Narann
    Inscrit en
    juin 2007
    Messages
    120
    Détails du profil
    Informations forums :
    Inscription : juin 2007
    Messages : 120
    Points : 176
    Points
    176

    Par défaut

    Plus que transparent. C’était un live en continue dans les locaux de GitLab ou les différentes personnes intervenaient et expliquaient en détails les problèmes et solutions.

  3. #3
    Membre habitué

    Profil pro
    Inscrit en
    mars 2003
    Messages
    51
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France

    Informations forums :
    Inscription : mars 2003
    Messages : 51
    Points : 145
    Points
    145

    Par défaut

    Jolie communication, effectivement !
    Au dela du fait que sur les cinq procédés de sauvegardes, aucune ne fonctionnait réellement (les bras m'en tombent ceci dit), je ne comprends pas trop la problématique de sauvegarde de base sur Azure. Je pensais, pour l'avoir vu, que les bases de données étaient sauvegardés en automatiques quasiment toutes les 15 minutes ? A moins que ce ne soit que pour certains types de base ?

  4. #4
    Membre à l'essai
    Profil pro
    Inscrit en
    janvier 2008
    Messages
    14
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : janvier 2008
    Messages : 14
    Points : 19
    Points
    19

    Par défaut

    Y'a pas un mec qui a vu que les backup fonctionnait pas ou mal ? Hallucinant.
    Au moins vérifier une fois par mois que les backup fonctionnent bien, qu'on peut les restaurer, etc. Mais là sur 5 plateformes à la fois LOL
    Le pauvre administrateur, j'espère qu'il sera pas mis à la porte pour autant.
    ça m'est déjà arrivé sur une grosse base de production client, heureusement que les backup m'ont sauvé la vie, je crois que j'aurais dûe revendre ma maison si j'avais pas eu ça

  5. #5
    Expert éminent

    Homme Profil pro
    Directeur des systèmes d'information
    Inscrit en
    avril 2002
    Messages
    1 141
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : Luxembourg

    Informations professionnelles :
    Activité : Directeur des systèmes d'information
    Secteur : Finance

    Informations forums :
    Inscription : avril 2002
    Messages : 1 141
    Points : 7 661
    Points
    7 661

    Par défaut

    Le coup des backups qui sont faits sans que personne n'ai jamais essayé de faire un recovery pour vérifier que tout est ok jusqu'au jour ou... c'est un grand classique, c'est très courant mais les gens évitent de crier ça sur les toits

    Ceci combiné à la croissance des ransomwares ou autres catastrophes sécuritaires ca promets qu'on continue à avoir régulièrement des millions d'euros de dommages partis en fumée et des dépôts de bilans...
    Ne prenez pas la vie au sérieux, vous n'en sortirez pas vivant ...

  6. #6
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2007
    Messages
    24 992
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2007
    Messages : 24 992
    Points : 47 781
    Points
    47 781

    Par défaut

    Bah c'est du Git, les devs des projet au pire peuvent repousser tout ce qu'ils ont en local, c'est bien comme ça qu'on vends toujours git? Tout est local

    Pour le reste, sans blamer qui que ce soit, les bourdes ça arrive. C'est bien facile de dire qu'il faut tester ses backup, mais c'est toujours face au désastre qu'on se rend compte qu'il y a un petit détails qui avait été oublié dans les scénarios testé, et qui fait qu'il faut tout improviser.

    Genre le serveur LDAP mort et les backups inaccessible car impossible de s'authentifier sur le serveur distant qui a cloné le ldap foireux et qui s'en sert pour l'authentification
    Les bandes hors site qu'on rapatrie en urgence et qui finissent dans un crash auto
    Le backup accessible, testé régulièrement par sondage et qui, une fois lancé pour un full restore t'annonce joyeusement "do not stop process, restoring, estimated time: 120h"
    David Delbecq Java Software engineer chez Trimble. TRANSPORT & LOGISTICS.     LinkedIn | Google+

  7. #7
    Expert éminent

    Profil pro
    Inscrit en
    juin 2003
    Messages
    5 580
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France

    Informations forums :
    Inscription : juin 2003
    Messages : 5 580
    Points : 8 442
    Points
    8 442
    Billets dans le blog
    3

    Par défaut

    Gitlab est un bon produit (pour lequel je fais pas mal de promo) mais malheureusement cette histoire me surprend moyennement. Je ne pense pas que ce soit un simple accident mais symptomatique d'une rigueur / qualité perfectible. Entre autre, ils ont près de 6000 tickets ouverts sur leur produit...

    Pour moi cette histoire est plutôt une bonne chose (pas de dégât vraiment sérieux) car c'est l'opportunité d'envoyer un signal aux responsables pour revoir leurs priorités et se focaliser un peu plus sur la finalisation de l'existant plutôt que la course à l’échalote en terme de nouvelles fonctionnalités. En tous cas c'est comme ça que je perçois l'ambiance vu de l'extérieur.

  8. #8
    Provisoirement toléré Avatar de MikeRowSoft
    Homme Profil pro
    sans profession
    Inscrit en
    avril 2013
    Messages
    1 070
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : sans profession

    Informations forums :
    Inscription : avril 2013
    Messages : 1 070
    Points : 0
    Points
    0

    Par défaut

    Normalement, c'est des copies. BitTorrent a la rescousse ? Encore faut-il que l' "E.D.I." soit du "Git I.D.E."...

    Oui, sa se ressemble non ? "On regarde bien developpez.com a cette instant". Pourtant Labview et les autres, donc les outils d'émulation et simulation de circuits, y sont aussi parfois cité...

    Bon courage à l'administrateur fautif, tous n'est pas perdu comme pour les "astronautes" en difficultés dans le film Gravity, il y aura peut-être des pertes (en avion, c'est pas pareil)...

  9. #9
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Architecte Web / Android
    Inscrit en
    août 2003
    Messages
    4 315
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Architecte Web / Android
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 4 315
    Points : 11 032
    Points
    11 032

    Par défaut

    Ce moment de solitude quand tu te rend compte que la commande de suppression est lancée l'environnement de prod
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  10. #10
    Membre habitué Avatar de Narann
    Inscrit en
    juin 2007
    Messages
    120
    Détails du profil
    Informations forums :
    Inscription : juin 2007
    Messages : 120
    Points : 176
    Points
    176

    Par défaut

    Les backups c'est quantique, ça existe jusqu’à ce que tu regarde ce qu'il y a dedans.

  11. #11
    Membre éprouvé Avatar de ddoumeche
    Homme Profil pro
    Développeur J2EE
    Inscrit en
    octobre 2007
    Messages
    445
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Eure (Haute Normandie)

    Informations professionnelles :
    Activité : Développeur J2EE

    Informations forums :
    Inscription : octobre 2007
    Messages : 445
    Points : 987
    Points
    987

    Par défaut

    Citation Envoyé par tmcuh Voir le message
    Y'a pas un mec qui a vu que les backup fonctionnait pas ou mal ? Hallucinant.
    Au moins vérifier une fois par mois que les backup fonctionnent bien, qu'on peut les restaurer, etc. Mais là sur 5 plateformes à la fois LOL
    Le pauvre administrateur, j'espère qu'il sera pas mis à la porte pour autant.
    ça m'est déjà arrivé sur une grosse base de production client, heureusement que les backup m'ont sauvé la vie, je crois que j'aurais dûe revendre ma maison si j'avais pas eu ça
    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 ?

  12. #12
    Membre confirmé
    Profil pro
    Developpeur
    Inscrit en
    septembre 2013
    Messages
    207
    Détails du profil
    Informations personnelles :
    Localisation : France, Seine Maritime (Haute Normandie)

    Informations professionnelles :
    Activité : Developpeur

    Informations forums :
    Inscription : septembre 2013
    Messages : 207
    Points : 461
    Points
    461

    Par défaut

    Les ingénieurs de GitLab expliquent qu’ils n’ont pas un système solide d’alerte et de pagination lorsque les sauvegardes échouent
    Petit rire car je connais ça. Et d'un point de vue extérieur je trouve que ça pue, surtout quand on a des données client.

    Mais même si la faute n'est pas négligeable je ne suis pas pour qu'on vire l'admin. Pour m'être déjà fait quelques petites frayeurs sur ce sujet j'imagine à quel point le type doit se sentir mal.

  13. #13
    Expert éminent sénior
    Avatar de Paul TOTH
    Homme Profil pro
    Freelance
    Inscrit en
    novembre 2002
    Messages
    6 702
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Freelance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2002
    Messages : 6 702
    Points : 21 326
    Points
    21 326

    Par défaut

    ça me rappelle un de mes premiers programme GAP sur AS/400 j'ai fait une boucle sans condition de sortie, la CPU est partie en vrille et le système a rebooté

    comme je débutais sur ce système j'étais bien incapable de faire un "appel système 2" pour tuer mon process .. ou même de me rendre compte que ma bourde pouvais pénaliser tout le monde
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Produits : UPnP, RemoteOffice, FlashPascal

  14. #14
    Membre émérite
    Avatar de RyzenOC
    Homme Profil pro
    NR
    Inscrit en
    juin 2013
    Messages
    2 982
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2013
    Messages : 2 982
    Points : 2 658
    Points
    2 658
    Billets dans le blog
    8

    Par défaut

    Moi j'utilise le sgbd Cassandra, si un serveur lâche ou si on supprime toutes les datas sont répliqués au minium sur 2 autres cluster (qui ne sont pas au même endroit).
    Il faut attendre 1 semaine pour tous perdre définitivement.

    Je trouve étrange de postgres n'est un mécanisme de réplication des datas ?
    =>Comment jouer sur xbox one à moindre coût ?
    Achetez un notebook de 2010 à 50€ sur leboncoin, installez steam, connectez le pc à un écran, branchez une manette xbox au pc
    Enjoy

  15. #15
    Membre éprouvé Avatar de ddoumeche
    Homme Profil pro
    Développeur J2EE
    Inscrit en
    octobre 2007
    Messages
    445
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Eure (Haute Normandie)

    Informations professionnelles :
    Activité : Développeur J2EE

    Informations forums :
    Inscription : octobre 2007
    Messages : 445
    Points : 987
    Points
    987

    Par défaut

    C'est récent, cela n'existe que depuis la version 9.0 (donc 2010).

    A mon avis, c'est surtout que les administrateurs systèmes sont incompétents où qu'on lance des startups en amateur de nos jours.

  16. #16
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    4 527
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 527
    Points : 18 458
    Points
    18 458

    Par défaut

    Citation Envoyé par ddoumeche Voir le message
    C'est récent, cela n'existe que depuis la version 9.0 (donc 2010).

    A mon avis, c'est surtout que les administrateurs systèmes sont incompétents où qu'on lance des startups en amateur de nos jours.
    Ben oui, personne ne veut faire le boulot, vu que c'est payé au lance-pierres. Et au final, ça coute bien plus cher. Comme d'habitude.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  17. #17
    Chroniqueur Actualités

    Homme Profil pro
    Webmaster
    Inscrit en
    janvier 2014
    Messages
    616
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Webmaster
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2014
    Messages : 616
    Points : 12 922
    Points
    12 922

    Par défaut GitLab parvient à restaurer certaines données supprimées accidentellement et se remet en ligne

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

  18. #18
    Membre expérimenté
    Avatar de kedare
    Homme Profil pro
    System Reliability Engineer
    Inscrit en
    juillet 2005
    Messages
    1 495
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Espagne

    Informations professionnelles :
    Activité : System Reliability Engineer

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 495
    Points : 1 591
    Points
    1 591

    Par défaut

    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.

  19. #19
    Provisoirement toléré Avatar de MikeRowSoft
    Homme Profil pro
    sans profession
    Inscrit en
    avril 2013
    Messages
    1 070
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : sans profession

    Informations forums :
    Inscription : avril 2013
    Messages : 1 070
    Points : 0
    Points
    0

    Par défaut

    Comment ça ?

    Selon les cours d'administrateur de bases de données il restait encore des traces dans les logs et sur le disque dur (fichier de bases de données). Bien plus que se qu'il peut y avoir sur les partitions après suppression normalement (table d'allocation) dans quelques cas.

    Tout aurait dû être récupéré. A moins que se soit du spécifique Oracle chose très probable... (le seul que je connais autant )

  20. #20
    Membre averti
    Profil pro
    Développeur .NET
    Inscrit en
    février 2005
    Messages
    198
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2005
    Messages : 198
    Points : 418
    Points
    418

    Par défaut

    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.

Discussions similaires

  1. [Lyon] Administrateur Systèmes/Développeur web
    Par akurosa dans le forum Demandes
    Réponses: 0
    Dernier message: 26/07/2007, 11h00
  2. Réponses: 9
    Dernier message: 22/10/2006, 21h03
  3. Administrateur système-réseau : on y fait quoi?
    Par Nasky dans le forum Emploi
    Réponses: 12
    Dernier message: 19/04/2006, 08h59
  4. Réponses: 5
    Dernier message: 05/07/2005, 19h05

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo