Meilleur accident d'administrateur système [fermé]

Je cherche des histoires amusantes d'accidents d'administrateur système que vous avez eu. Supprimer le courrier électronique du PDG, formater le mauvais disque dur, etc.

Je vais ajouter ma propre histoire comme réponse.

Je me suis amusé à découvrir la différence entre la commande linux "killall" (élimine tous les processus correspondant au nom spécifié, utile pour arrêter les zombies) et la commande solaris "killall" (élimine tous les processus et arrête le système, ce qui est utile pour arrêter le serveur de production heures de pointe et obliger tous vos collègues à rire de vous pendant une semaine).

J'étais responsable de notre proxy Web d'entreprise qui, à l'époque, était le produit de Netscape. En jouant dans les formulaires d’administrateur (c’était une interface Web), il y avait un gros bouton (et je jure qu’il était rouge) qui disait Supprimer la base de données d’utilisateurs . Pas de problème, j'ai pensé. Voyons quelles sont les options que cela me donne quand je frappe cela. Il y aura sûrement une invite de confirmation s'il n'y a pas d'options.

Oui, pas de confirmation. Aucune option. Pas plus d'utilisateurs.

Alors, je suis allé voir M. Solaris Sysadmin et j'ai dit que j'avais désespérément besoin d'une restauration à partir d'une bande à laquelle il a répondu: "Je ne sauvegarde pas cette boîte."

"Euh, viens encore" rétorquai-je.

"Je ne sauvegarde pas cette boîte. C'est sur ma liste d'éléments à ajouter à la rotation de sauvegarde, mais je n'y suis pas encore parvenue."

"Ce serveur est en production depuis près de 8 mois!" J'ai crié.

haussa les épaules , répondit-il. "Pardon."

Il y a de nombreuses années, l'entreprise pour laquelle je travaillais avait un client qui effectuait une sauvegarde nocturne de son serveur NT 4.0 sur un lecteur Jaz (comme un disque zip de grande capacité).

Nous avons créé un fichier de commandes qui s’est exécuté comme un travail planifié pendant la nuit. Chaque matin, ils récupéraient le disque de la dernière nuit sur le lecteur et, avant de partir le soir, inséraient le disque suivant dans la séquence.

Quoi qu'il en soit, le fichier de commandes ressemblait à quelque chose comme ça (le lecteur Jaz était le lecteur F:) ...

@echo off
F:
deltree /y *.*
xcopy <important files> F:

Quoi qu'il en soit, une nuit, ils ont oublié de mettre le disque. La modification du lecteur F: a échoué (aucun disque dans le lecteur) et le fichier de commandes a continué de s'exécuter. Le répertoire de travail par défaut pour le fichier de commandes? C :. Pour la première fois, une routine de sauvegarde détruit le serveur en cours de sauvegarde.

J'ai appris un peu quelque chose à propos de sysadminning (et de la gestion des exceptions) ce jour-là.

Jim.

PS: Le correctif? "deltree / y F: \ *. *".

root @ dbhost # find / -name core -exec rm -f {} \;

Moi: "Vous ne pouvez pas entrer? OK. Comment s'appelle le DB?"

Cu: "Core."

Moi: "Oh."

J'aime la façon dont tout le monde qualifie leur histoire de "quand j'étais jeune / vert" comme s'ils ne le feraient plus jamais. Les accidents peuvent arriver même aux pros les plus aguerris.

Mon pire moment est si grave que des palpitations s’y attendent encore…

Nous avions un réseau SAN avec des données de production. Critique à l'entreprise. Mon "mentor" a décidé d'étendre une partition pour libérer de l'espace disque. Pouvez-vous voir où cela se dirige? Il a dit que le logiciel SAN pouvait faire cela en direct, pendant les heures de production et que personne ne le remarquerait. Les sonneries d’alarme auraient dû commencer à sonner, mais elles étaient particulièrement silencieuses. Il a dit qu'il l'avait fait "des tas de fois auparavant" sans aucun problème. Mais voici la chose - il m'a obligé à cliquer sur le bouton qui dit "êtes-vous sûr?"! Comme j'étais nouveau dans l'entreprise, je pensais que ce gars savait de quoi il parlait. Grosse erreur. La bonne nouvelle est que le LUN a été étendu. La mauvaise nouvelle était ... eh bien, je savais qu'il y en avait une mauvaise quand j'ai commencé à constater des erreurs d'écriture sur le disque sous Windows.

Je suis content de porter un pantalon marron.

Nous devions expliquer pourquoi 1 To de données avait disparu à l'heure du déjeuner. C'était vraiment une très mauvaise journée.

En fait, c'est un bon principe - avant de faire quelque chose qui vous fait douter, imaginez devoir expliquer à la direction si quelque chose ne va pas. Si vous ne trouvez pas de bonne réponse pour expliquer vos actions, ne le faites pas.

Nagios nous a envoyé un ping un matin lorsque les heures de bureau ont commencé à indiquer qu’il ne pouvait pas se connecter à un serveur non critique. Ok, randonnée à la salle des serveurs. C'est un vieux serveur, un Dell 1650 acheté en 2002, et nous savions que les 1650 avaient des problèmes matériels. Le PFY poignarde le bouton d'alimentation. Rien. Appuyez à nouveau dessus et maintenez-le enfoncé pendant cinq secondes pour «forcer le démarrage» ... qui annule la protection contre les erreurs du contrôleur BMC, car sans DRAC, il est impossible d'examiner les journaux du contrôleur BMC sans avoir à mettre le châssis sous tension.

La machine démarre le POST, puis meurt à nouveau. Je me tiens au-dessus de ça et je dis: "Je sens la fumée." Nous tirons le serveur sur ses rails et l'un des blocs d'alimentation a l'air chaud, alors le PFY le tire et est sur le point de refermer la boîte. Je dis: "Non, ce n'est pas de la fumée d'alimentation, c'est de la fumée de carte mère."

Nous rouvrons le boîtier et cherchons la source de l'odeur de brûlé. Une bobine d'induction et un condensateur ont fait sauter le régulateur de tension de la carte mère, et ont pulvérisé du cuivre en fusion et un condensateur de condensateur à travers tout, raccourcissant un tas de choses et provoquant de gros dégâts.

Le pire pour moi a été de reconnaître que j'avais fumé assez de matériel pour reconnaître la différence entre l'odeur d'une carte mère brûlée et celle d'une alimentation brûlée.

Il y a trois jours (sérieusement), je me suis connecté à distance à un serveur scolaire en installant le Service Pack 2 sur un serveur de fichiers Windows Server 2008.

J'ai décidé de planifier le redémarrage nécessaire tard dans la nuit, lorsque les enseignants ne seraient pas connectés à la fin de leurs bulletins de fin d'année. J'ai tapé quelque chose comme:

 à 23h59 "arrêt -r -t 0" 

... qui aurait bien fonctionné.

Mais ensuite je me suis deviné. Est-ce que ma syntaxe 'shutdown' était correcte? J'ai essayé d'afficher l'aide à l'utilisation en tapant

 arrêt / h 

... et instantanément perdu ma connexion RDP. Paniquant, j'ai consulté Google pour la syntaxe. Une recherche rapide a révélé que la version d'arrêt de Server 2008 comprenait un commutateur a / h, qui (comme vous l'avez peut-être deviné) met la machine en veille prolongée.

Les enseignants ont commencé à m'appeler en quelques minutes pour signaler qu'ils ne pouvaient plus ouvrir ou enregistrer les fiches de rapport sur lesquelles ils travaillaient. Étant donné que j'étais hors site et que la salle des serveurs était verrouillée, je devais appeler directement la directrice de l'école et la guider dans le processus de remise sous tension de la machine.

Aujourd'hui, j'ai apporté des biscuits maison à tout le monde en guise d'excuse.

Dans un emploi précédent, nous avions un excellent système local qui enregistrait et archivait chaque courrier envoyé, laissé ou resté au sein de l'entreprise.

Vous avez vidé toute votre boîte aux lettres? Aucun problème! Vous recherchez un courrier que quelqu'un vous a envoyé il y a une semaine, un mois ou une année, mais vous ne vous rappelez pas qui l'a envoyé ou quel était son sujet? Aucun problème! Nous allons simplement renvoyer tout ce qui va du mois de février à un dossier spécial.

À un moment donné, le PDG de la société a eu besoin de surveiller les messages échangés entre un concurrent et un vendeur interne soupçonné. Nous avons donc mis en place un script qui a été lancé chaque nuit et avons envoyé au PDG les messages pertinents de la veille. Aucun problème!

Environ un mois plus tard, la nouvelle d’un problème urgent et plus grave est venue d’en haut. Il semble que, alors qu'il lisait la liste des courriers envoyés à $ OTHERCOMPANY, il est tombé sur celle-ci:

To: somebody@$OTHERCOMPANY
From: CEO
Subject: CEO has read your message (subject line here)

Naturellement, le PDG étant une personne importante et importante, il était trop occupé pour cliquer sur toutes ces boîtes de dialogue "Envoyer un accusé de réception" dans Outlook et avait configuré son client pour qu'il les envoie toutes. L'un des messages capturés par le filtre de surveillance comportait un ensemble de demandes de confirmation de lecture. Devinez ce que Outlook a fait? Certainement embrouillé la surveillance «clandestine».

Notre tâche suivante: ajouter des règles au filtre de messagerie pour bloquer les accusés de lecture sortants adressés par le PDG à cette entreprise. Oui, c'était le moyen le plus simple. :)

Ahhh, le mien l'était il y a environ 10 ans, quand je mouillais encore. J'ai eu la joie d'installer des sauvegardes de batterie sur tous les ordinateurs des programmeurs. Ils souhaitaient également que le logiciel chargé charge de prévenir les pannes de courant et de s'arrêter correctement.

Alors, je l’ai configuré sur mon ordinateur pour tout tester en premier et pour s’assurer que tout fonctionnait bien. Alors, je débranche le cordon d’alimentation et le message s’affiche à l’écran. msgstr "alimentation externe perdue, début de l 'arrêt du système".

Alors j'ai pensé, Hé cool, ça a fonctionné. Mais pour une raison étrange, je ne me souviens même pas, il a envoyé ce message sous forme de message réseau, de sorte que les 200 ordinateurs de la société ou plus ont reçu ce message, où plus de 100 utilisateurs étaient des programmeurs.

Ouais, parle de masse freak out !!

J'ai gardé la tête basse à cet endroit pendant un moment!

J'utilisais souvent la commande "sys-unconfig" sur les machines Solaris pour réinitialiser le service de nom de machine, l'adresse IP et le mot de passe root. J'étais sur un système d'utilisateurs et je me suis connecté au serveur d'installation du bâtiment et j'ai cherché quelque chose (en tant que root), puis j'ai oublié la connexion à une autre machine (invite "#" non descriptive) et j'ai exécuté la commande "sys-unconfig".

# sys-unconfig     
        WARNING

This program will unconfigure your system.  It will cause it
to revert to a "blank" system - it will not have a name or know
about other systems or networks.

This program will also halt the system.

Do you want to continue (y/n) ? y

Connection closed

#

Ce message "connexion fermée" s'est lentement transformé en panique ... sur quelle machine étais-je connecté lorsque j'ai exécuté cette commande.

Le pire dans tout cela n'était pas la période difficile que mes collègues m'ont donnée, c'est que j'ai fait la même chose un mois plus tard.

J'ai un très bon. Certes, c'était avant mon poste d'administrateur système, mais toujours lié à la technologie, j'ai donc décidé de l'ajouter.

À l'époque, je travaillais comme technicien satcom / large bande pour l'US Air Force. Ayant récemment terminé mes études techniques, je me suis retrouvé en Corée du Sud. Peu de temps après leur arrivée à la station, une opportunité s'est présentée de se rendre dans le sud avec les "grands gars" qui étaient là depuis un certain temps et qui travaillaient réellement sur du matériel réel (c'est-à-dire "de production").

Je suis descendu avec l'équipe et en tant que jeune technicien enthousiaste, j'étais impatient de pouvoir mettre la main sur un équipement qui transmettait un trafic voix et données militaire en temps réel.

Pour commencer, ils me tendirent un manuel, se tournèrent vers la section de maintenance préventive et me dirigèrent vers quatre racks remplis de plusieurs grands multiplexeurs numériques. L'équipement était assez facile, nous avions couvert le même équipement à l'école technique.

Première page du manuel lu; "Mettez le multiplexeur ditigal sous tension. Mettez les deux commutateurs arrière en position ON et attendez la mise sous tension de l'équipement, puis commencez les tests." J'ai levé les yeux, et il y avait déjà le pouvoir appliqué!

J'étais dans un dilemme à coup sûr. Ne sachant pas comment procéder, j'ai tiré de mon mieux, "Ummmm .. Un peu perdu ici", regardez l'aîné.

Il m'a regardé et a rigolé: «Non, non, c'est bon. Vous pouvez ignorer cette partie de la liste de contrôle." Puis, alors qu'il remarquait l'expression sur mon visage (depuis qu'on nous avait appris à l'école de NE JAMAIS, JAMAIS ignorer une partie de la liste de contrôle, et qu'il était certain que la mort et la destruction si on devait le faire), il jeta un regard sérieux à sa face et dit: "Ignorez UNIQUEMENT cette partie! Suivez le reste, à la lettre!"

Il est vrai que j’ai parcouru les instructions du PM en plusieurs étapes, heureux comme une palourde et fier d’avoir laissé une technologie aussi basse, bien que intelligente, faire ce travail important.

Quelque part entre les cinquième et sixième listes de contrôle de maintenance préventive de ces énormes multiplexeurs, j'ai commencé à remarquer une activité accrue autour de moi. Les téléphones sonnaient, les gens se déplaçaient rapidement. Des regards interrogatifs étaient échangés.

Finalement, un groupe de personnes a couru vers moi, dirigé par l'un des techniciens chevronnés qui m'avait abattu.

"Hé! Nous voyons d'énormes pannes dans le trafic de données, et nous avons isolé / tracé le chemin qui mène aux racks sur lesquels vous travaillez! Voyez-vous des choses étranges ..."

(À ce moment-là, il a été coupé par un autre des dépanneurs qui s’était approché du premier groupe de multiplexeurs sur lequel je jouais les premiers ministres.)

"LES SAINTS NOIX! ILS ONT ÉTÉ ÉTEINTS! IL ÉTAIT LES ÉTEINDRE !!!!"

En un rien de temps, je les ai regardés parcourir à la hâte la première étape du manuel: "Tournez les deux commutateurs arrière sur la position ON ...". Lorsque le technicien supérieur a terminé, il est venu vers moi et m'a demandé, incrédule, ce que je pensais. de, en éteignant les pièces critiques de l'équipement.

Effrayé, je lui tendis la liste de contrôle que je suivais, jurant que je n'avais pas dévié du tout. Que je l'avais suivi, "à la lettre" comme il l'avait indiqué.

Après un moment, il se mit à rire et signala le problème.

Dans le manuel, la dernière étape de la liste de contrôle de la maintenance préventive était la suivante:

"Enregistrez la lecture finale de la sonde, essuyez le panneau avant, enlevez la poussière et les particules, puis tournez les deux interrupteurs d'alimentation arrière en position OFF".

:)

C'est une sorte d'accident système ... dans la mesure où les administrateurs système doivent parfois transporter physiquement un grand nombre de machines d'un point A à un point B (où A et B sont apparemment toujours séparés par plusieurs escaliers dans un bâtiment sans ascenseur). Lors du neuvième voyage de la journée, je me suis arrêté trois jours après pour prendre une pause, pour discuter avec quelqu'un qui descendait, calé dans la tour de taille normale avec la station que je trépignais sur la rampe intérieure de la cage d'escalier ouverte. et ... eh bien, vous avez deviné ... légèrement perdu mon emprise sur elle. Il a sans aucun doute plongé droit dans le puits et quand il a atteint le fond, euh ... pas tellement avec la fonctionnalité pour celui-là! Total des pièces récupérables: deux bâtons de RAM, un lecteur de disquette et une carte RNIS (Dieu bénisse les ingénieurs de Hermstedt!). Tout le reste est fissuré,

Par la grâce de Dieu, personne ne marchait en dessous, ce qui, heureusement pour moi, était le premier de mon patron, alors je devais garder mon travail. Je me suis senti très malade pendant une heure environ.

Morale: la gravité gagne toujours!

Je rechargeais un système pour quelqu'un et, pendant le processus de sauvegarde manuelle, je lui ai posé la question "Avez-vous d'autres programmes que vous utilisez?" et "Y a-t-il autre chose d'important que vous fassiez sur l'ordinateur?"

Il a dit "non" plusieurs fois.

J'étais convaincu et formaté le lecteur.

Environ 30 minutes plus tard, il a dit "oh mon dieu" et a mis ses deux mains sur sa tête.

Il s'avère qu'il travaillait sur un scénario de livre depuis plus de 10 ans dans un programme spécialisé. C'était à l'époque où les programmes utilisaient pour enregistrer les données utilisateur dans son répertoire de fichiers programme et je l'avais manqué.

Whhhhooooops.

Il n'était pas en colère contre moi, mais c'était un sentiment qui faisait réfléchir.

Mon préféré n'est pas vraiment le mien et j'en suis TRÈS content. Jetez un coup d'oeil ici.

Cela ne m'est pas arrivé, mais…

Je travaillais dans une entreprise qui fabriquait des logiciels fonctionnant sur des machines Linux fournies par le client. Nous voudrions essentiellement «prendre en charge» les machines, les configurer complètement selon nos spécifications et effectuer toute la gestion et la surveillance. Nous formions essentiellement une équipe de 10 à 15 administrateurs système, gérant des milliers de serveurs pour des centaines de clients. Les erreurs devaient arriver.

Un des membres de notre équipe a découvert des problèmes sur un serveur (une sauvegarde, je crois) et a décidé d’exécuter fsck sur celui-ci. Il a arrêté tous les services pertinents, s'est assuré que le système avait fait faire des sauvegardes récemment, puis a exécuté fsck, mais s'est plaint du fait que le système de fichiers avait été monté. Comme nous étions à distance et que nous n'avions aucun accès à distance (DRAC, OIT, etc.), il ne pouvait pas utiliser fsck, mais il était à peu près sûr qu'il était prudent de le faire avec le système de fichiers monté, si vous faisiez attention.

Il a décidé d'essayer lui-même en exécutant fsck sur sa partition racine, avec des résultats prévisibles: il a corrompu sa partition racine et ne pouvait plus démarrer.

Confus, il s'est approché et a parlé à notre chef d'équipe. Le responsable a déclaré qu'il était à peu près sûr que vous ne pouviez pas faire cela, et le membre de l'équipe a déclaré: "Vous pouvez le faire!", A pris son clavier et l'a montré, en exécutant fsck sur la partition racine de ce dernier. Ce qui a complètement corrompu la partition racine HIS.

Résultat final? Aucune donnée client perdue, grâce aux tests du membre de l'équipe. Deux jours de productivité des employés ont été perdus, mais cela valait beaucoup, beaucoup moins que les données sur la machine du client. Et pour mémoire? Vous pouvez exécuter fsck sur un lecteur monté, mais uniquement pour vérifier des données. Ne pas le réparer. C'était l'erreur du membre de l'équipe.

-

Pour ajouter ma propre histoire, je travaillais dans la même entreprise et j'essayais de réinitialiser un mot de passe d'utilisateur. Notre système a refusé de me laisser définir le mot de passe dont il avait besoin, car il surveillait les anciens mots de passe et ne vous permettait pas de le dupliquer. Le mécanisme était simple: il a validé votre mot de passe par rapport au hachage le plus récent de la base de données.

(Et pour mémoire, il devait s'agir de l'ancien mot de passe car il s'agissait d'un compte partagé et s'assurer que tout le monde savait que le nouveau mot de passe était irréalisable)

J'ai décidé d'aller simplement dans la base de données des utilisateurs et de supprimer les nouveaux enregistrements afin que celui-ci utilise l'ancien. Il ne s'agit que de SQL (exécutant une version ancienne de Sybase), donc c'est simple. Tout d'abord, je devais trouver les enregistrements:

SELECT * FROM users_passwords WHERE username='someuser';

J'ai trouvé le vieux disque qu'il voulait garder; il y en avait deux autres devant. J'ai décidé d'être intelligent et de simplement supprimer quelque chose de plus récent que l'ancien enregistrement. En regardant l'ensemble de résultats, j'ai vu que l'ancien mot de passe était l'ID 28 dans la base de données et que les nouveaux étaient l'ID plusieurs milliers (système très occupé). C'est simple, toutes les anciennes lignes étaient> 28, donc:

DELETE FROM users_passwords WHERE id > 28;

Il n'y a rien de pire que de faire de simples élagages de rangs et de voir «212 500 rangs affectés». Heureusement, nous avions deux serveurs de base de données maîtres (avec l'ID utilisateur), mais Sybase (au moins, notre version) ne prenait pas en charge la réplication automatique et ne supprimait donc pas automatiquement les anciens enregistrements. Il était trivial d’obtenir une sauvegarde de la table users_passwords et de la réimporter. Pourtant, un assez gros 'oh f ** k!' moment.

Un autre de mes favoris:

Lors de la configuration d’un ordinateur et d’une imprimante laser locale sur un système, j’ai eu l’idée brillante de les brancher sur l’onduleur de l’ordinateur. Avez-vous déjà essayé d'imprimer sur une imprimante laser locale lorsqu'elle est branchée sur un onduleur de bureau? Eh bien, si vous ne le savez pas, cela tend à tirer tous les amplis ... Ce qui redémarre l'ordinateur ... Et le travail d'impression ne se termine jamais ...!

Je reçois toujours l'appel: ' Chaque fois que j'imprime, l'ordinateur redémarre et n'imprime pas !!! '?

Ooops!

JFV

DELETE sans clause WHERE, dans la base de données de clients en direct des clients.

Tapé en kill 1tant que root. initet tous ses enfants sont morts. Et tous leurs enfants. etc, etc. Oops.

Ce que je voulais taper était kill %1

Après avoir réalisé ce que je faisais, je me suis précipité vers le panneau de commande d'une grosse machine de tri de balles de laine et j'ai appuyé sur le bouton d'arrêt d'urgence. Cela a empêché la machine de se déchirer en morceaux, car je venais de tuer le logiciel qui la contrôlait.

Nous étions en pleine panne de courant et avons constaté que l'onduleur fonctionnait à 112% de sa charge configurée. Ce n'était pas vraiment un problème car nous utilisions le générateur à l'époque.

Nous avons donc utilisé des câbles d’alimentation de secours pour réduire la consommation d’énergie de cet onduleur (nous en avions deux, l’un bien plus gros que l’autre). Nous sommes arrivés au commutateur de réseau qui gérait la salle des serveurs (c’était la salle des serveurs avec tous les serveurs internes de la société, les serveurs faisant face au client se trouvant dans une autre salle des serveurs). Le commutateur était un grand commutateur de classe entreprise doté de trois blocs d'alimentation. Les fournitures étaient N + 1, il ne nous en fallait donc que deux pour pouvoir utiliser le commutateur.

Nous avons choisi un câble et l'avons sorti. Malheureusement pour nous, les deux autres ont été branchés sur une seule bande d’alimentation, qui a rapidement explosé au fur et à mesure que la charge montait sur les deux blocs d’alimentation qui y étaient branchés. L’administrateur système a ensuite paniqué et a branché le troisième câble. Le commutateur a essayé de s’allumer, plaçant toute la charge du commutateur sur une seule source d’alimentation. Au lieu de couper l'alimentation électrique, il a explosé sous une pluie d'étincelles à moins de 12 pouces de mon visage, me renvoyant dans le panier de serveurs.

Par instinct, j’ai essayé de sauter sur le côté, mais malheureusement à ma gauche, il y avait un mur et deux à ma droite, il y avait un très grand gars de 6'4 ". Je suis parvenu à lui sauter dessus, ou peut-être à travers lui en rebondissant des racks Compaq (ceux avec les fronts en mailles fines) sans mettre un tout dans le rack, et sans toucher aux installations.

À un moment de ma carrière, une enquête judiciaire au sein de la société pour laquelle je travaillais nous a obligés à conserver tous les courriels à partir de "aujourd'hui", sauf indication contraire. Après environ un an de stockage quotidien de sauvegardes complètes de notre environnement d’échange (1 To par nuit), nous avons commencé à manquer d’espace.

Les administrateurs d'échange nous ont suggéré de ne conserver que la huitième copie du courrier électronique. Pour ce faire, nous leur avons demandé de restaurer quelques jours de bases de données, d'extraire le courrier électronique dont ils avaient besoin (des personnes spécifiques identifiées pour enquête) et de le ré-archiver. Ils l'ont fait tous les huit jours de courrier électronique pour toutes nos sauvegardes. Le 8ème jour a été choisi car Exchange avait un jeu de paramètres dans lequel les "éléments supprimés" sont conservés dans la base de données pendant 8 jours.

Après avoir terminé chaque archive, je relisais et supprimais toutes les sauvegardes plus anciennes que celles archivées.

TSM ne dispose pas d'un moyen simple d'effectuer cette opération. Vous devez donc supprimer manuellement les objets de la base de données de sauvegarde.

J'ai écrit un script qui supprime toutes les sauvegardes antérieures à une date, en calculant la date en utilisant la différence entre aujourd'hui et la date en question. Un jour, j'ai dû supprimer environ un mois de sauvegardes, sauf lorsque j'ai fait le calcul de la date, j'ai fait une faute de frappe et entré la date le 7/10/2007 au lieu du 6/10/2007 et j'ai exécuté le script. J'ai supprimé un mois supplémentaire de données, ce qui faisait accidentellement partie d'un procès très important.

Après cela, j'ai ajouté quelques étapes au script pour confirmer que vous vouliez supprimer les données et vous indiquer ce qu'il allait supprimer.

Heureusement, ils n'ont même jamais utilisé les données que nous avons travaillé si dur pour les conserver, et j'ai toujours mon travail.

Après une longue journée ou une performance recherchée et le réglage d'un gros ordinateur central (vous connaissez les bêtes qui prennent quelques heures avant que tous les sites de sauvegarde en attente aient convenu qu'il est en effet redémarré et entièrement synchronisé), j'ai étiré mes doigts, dactylographié satisfait satisfait -p maintenant dans l'invite de mon ordinateur portable, a fermé le couvercle, a tiré le câble série hors de l'ordinateur central, avec l'anticipation d'un bon verre de bière froide.

Soudain, j'entends le bruit assourdissant de l'ordinateur central alors que mon ordinateur portable affichait toujours X avec joie.

En attendant que la machine soit à nouveau entièrement en ligne, j'ai décidé de disposer du temps nécessaire pour que mon ACPI fonctionne sur mon ordinateur portable. Je ne suis donc jamais tenté de fermer mon ordinateur portable.

Cet accident n'a pas eu lieu ... mais il convient de mentionner:

J'ai été envoyé dans un centre de données très utilisé pour effectuer des tests de bande passante sur un nouveau circuit. Je suis arrivé dans la salle de démonstration / IDF, j'ai trouvé un emplacement sur l'un des racks de mon routeur de test, j'ai établi mes connexions et commencé les tests. Malheureusement, j'ai complètement omis de remarquer que le routeur frontière en production était non seulement placé exactement sur le prochain rack (presque au même niveau), mais qu'il était également identique à la marque et au modèle de mon routeur de test.

Une fois le test terminé, j’ai commencé à appuyer sur le bouton de mise en marche en position éteinte (... imaginez-le au ralenti ...) et, je jure, juste au moment où j’appliquais une pression, je me suis rendu compte que le routeur sur lequel j’étais sur le point éteindre était celui en production. Mon cœur s'est arrêté et j'ai presque ... eh bien, utilisez votre imagination.

J'ai quitté le MDF du centre de données avec un air effaré et pâle, mais en même temps je suis heureux d'avoir encore un travail!

J'ai supprimé le compte de quelqu'un par erreur, j'ai mélangé les noms avec celui que je devais effacer. Opps

La partie cool est qu'ils n'ont jamais su ce qui s'est passé. Vous avez l'appel qu'ils ne pouvaient pas se connecter, le sou a été supprimé du compte que j'ai supprimé.

Alors que j'étais au téléphone avec eux, j'ai rapidement recréé leur compte, y ai attaché leur ancienne boîte aux lettres (heureusement, Exchange ne supprime pas les boîtes aux lettres immédiatement) et l'ai redirigé vers leurs anciens fichiers d'utilisateurs.

Ensuite, je leur ai reproché d'avoir oublié leur mot de passe que je venais de réinitialiser pour eux :)

J'ai accidentellement installé un fichier tar.gz sur ma machine Gentoo Linux au mauvais endroit et laissé des fichiers partout. Cela devait être autour de 1999, 19 à l'époque (merci pour les commentaires ci-dessous)

Étant le geek que je suis, j'ai décidé d'essayer de me sortir du travail consistant à parcourir manuellement chaque fichier.

Alors j'ai essayé:

tar --list evilevilpackage.tar.gz | xargs rm -rf

Cela ne m'a pas pris longtemps pour constater que tar répertoriait également tous les répertoires utilisés par le programme, notamment "/ usr, / var, / etc" et quelques autres que je ne souhaitais pas vraiment voir disparus.

CTRL-C! CTRL-C! CTRL-C! Trop tard! Tout est parti, réinstallez le temps. Heureusement, la boîte ne contenait rien d'important.

Dans le cadre d'une petite partie de mon ancienne vie, j'ai administré le serveur de fichiers de la société, une boîte NetWare 4:11. Il n’a à peine eu besoin d’aucune entrée, mais si c’était le cas, vous avez ouvert une fenêtre de console distante.

Habitué à utiliser DOS tout le temps, quand j’avais fini, j’allais naturellement taper "Exit". Pour Netware, "exit" est la commande permettant d'arrêter le système d'exploitation. Heureusement, il ne vous laissera pas arrêter à moins que vous ne mettiez d'abord le serveur hors tension (rendez-le indisponible pour le réseau / les clients). Ainsi, lorsque vous tapez "Exit" dans la console, il dit utilement: "Vous devez d'abord taper" Down "avant de pouvoir sortir"

Demandez-moi combien de fois j'ai 1: tapé "exit" dans la session de console et 2: tapé docilement "Down" puis "Exit" afin que je puisse "finir ce que j'essayais de faire"

Et puis le téléphone commence à sonner .....

LOL

Une autre histoire qui ne s'est pas produite (ouf):

Nous faisions religieusement des sauvegardes incrémentielles tous les jours sur un lecteur de bande.

Il nous est arrivé d'écrire une cassette contenant des données à expédier à quelqu'un d'autre. Ils ont dit "nous ne pouvons pas lire votre bande". En fait, nous ne pourrions pas non plus. Ou n'importe quelle bande en fait.

Nous avons acheté un autre lecteur de bande et avons retenu notre souffle jusqu'à ce que nous l'installions.

Morale de l'histoire. Assurez-vous toujours de tester vos sauvegardes.

Le dernier endroit où j'ai travaillé, mon collègue avait ses enfants avec lui dans la salle des serveurs (pourquoi? Je n'ai aucune idée!).

Il s'assura qu'ils étaient loin des serveurs et expliqua à son fils de 5 ans qu'il ne devait toucher à AUCUN des serveurs et en particulier à aucun des interrupteurs d'alimentation.

En fait, il les avait tout près de la porte ... (pouvez-vous voir où cela va ...?)

Le garçon ne toucha aucun des boutons d'alimentation du serveur ... Non, ce serait trop facile à expliquer. Au lieu de cela, il appuya sur le gros bouton rouge qui se trouvait près de la porte ... Le bouton qui éteint toute la salle du serveur !!!

Les lignes téléphoniques se sont immédiatement éclairées et se demandaient pourquoi Exchange, les serveurs de fichiers, etc. n'étaient pas disponibles ... Imaginez-vous en train d'expliquer CELA au PDG!

-JFV

Une fois, je me suis battu avec le logiciel de surveillance APC UPS. En tant que petite entreprise, nous avions deux petits onduleurs et divers serveurs avaient été configurés pour les surveiller. La plupart des serveurs étaient Linux, mais quelques-uns fonctionnaient sous Windows et étaient donc ceux utilisés, car le logiciel APC est uniquement Windows.

Cependant, le logiciel APC de l'époque était codé en dur pour supposer que l'onduleur avec lequel il parle parle alimente également le PC! Ce n'était pas le cas pour ce serveur, mais je l'ai découvert trop tard pour lui dire de s'arrêter. De plus, malheureusement, le programmeur principal a présenté le produit de la société à un partenaire - il s’agissait d’une application Web fonctionnant sur le même serveur. Je ne voulais pas que le logiciel APC soit arrêté ...

Je donnais à un nouveau administrateur système une visite d'une application de Service Manager. J'ai dit "si jamais vous deviez arrêter ce service, vous cliquez sur ce bouton, mais vous ne devriez jamais le faire pendant la journée." Vous ne croiriez jamais à quel point son bouton de souris était sensible!

Deux minutes plus tard, le service avait repris et personne ne semblait le remarquer.

Trébucher sur un serveur tour coincé derrière un rack et me frapper la tête à l'arrière du routeur principal de Cisco alors que je descendais. Cela révèle à quel point les cordons d’alimentation étaient insérés dans les blocs d’alimentation situés à l’avant du Catalyst 6500 .

Ouais. Nous avons un casque sur un crochet dans la salle des serveurs maintenant. Avec mon nom dessus