(Avvertenza: se non sei un sysadmin, lascia perdere…)
Server DC e Exchange, RAID 5. Un disco RAID rotto dopo la mia ultima visita, nessuno se ne è accorto. Temporale scorsa settimana. Errori vari su eventlog, server funzionante ma partizione invisibile da gestione disco (????). Exchange (16 giga di posta) fermo. Mentre succede io sono a Milano, il server è a Genova e deve intervenire una persona reperibile. Errori sullo store, non recuperabili. Ripristino backup (cassetta Mercoledì, tenetelo a mente) non funziona: dati salvati buoni ma che non vengono ripristinati correttamente causa errori di disco suddetti (e sono 16 giga, 2 ore solo per tentare). Passano due giorni (posta ferma) in attesa che IBM sostituisca il disco rotto. Arrivo quindi dal cliente. Provo a ripristinare il backup (sempre nastro Mercoledì, che funziona), continua a non scrivere su disco correttamente. Perdo ore a tentare di riparare i db. Nulla da fare, un database da 16 giga non montato perché, oltre agli errori sulla partizione, manca un file log da 5 mega (sigh). Passo la notte insonne a googolare possibili soluzioni. Si decide di tentare un disaster recovery, ma non esiste full backup, va fatto adesso, prima di formattare il server. E’ l’unico DC, quindi decido di affiancarne un’altro, almeno per mettere al sicuro AD. Riesumo un vecchio Dell Poweredge, ci metto un HD nuovo e installo 2000 server. Dcpromo, repliche, ecc ecc ecc. Torno al server in panne, compro un disco esterno da 160 e faccio il full backup, compreso il system state. Non backuppo il db di posta perché tanto ho i nastri (ah ah ah ah!!!). Il backup a 4 giga si ferma. Mi sono dimenticato di convertire la partizione del disco USB a NTFS (su FAT32 no file > 4 giga). Converto e ricomincio da capo. Al termine devo rifare il backup di alcuni files saltati perché bloccati dall’SMTP ancora funzionante.
Mi basta un’installazione minimale di 2000 server, è sufficiente che giri ntbackup. Purtroppo i drivers del controller RAID richiedono che il s.o. sia installato tramite la IBM ServerGuide, processo lento anche se rigoroso. Al momento di creare la partizione, mi sembra che qualcosa non quadri, ma ho fretta, sono “cotto”, e il cliente preme, quindi procedo. Errore di creazione della partizione.
Mi accorgo che un deficiente (io, certo) ha lasciato collegato il disco esterno alla porta USB. Il ServerGuide ha cancellato dal disco la partizione con il full backup.
Cancellata.
Vuota.
Naturalmente il ServerGuide ha voluto per forza aggiornare il firmware del controller RAID, e mi ha costretto a ricreare il volume, cancellando tutto ciò che c’era, quindi non posso ritornare indietro e rifare il backup. Semplicemente i dati, tutti, non esistono più. Naturalmente l’interfaccia non ti avverte di quale disco sta cancellando la partizione.
Vorrei morire.
Dopo una serie di peripezie (FTP non funzionanti, firewall bloccati, ecc ecc), recupero da un collega(*) “Easy Recovery Professional” che mi fa recuperare i 7 giga del full backup, per fortuna (????). Il file finisce sul mio portatile (mezz’ora), da cui lo trasferisco via rete al server (mezz’ora). Ripristino il sistema (mezz’ora), e mi stupisco moltissimo che la cosa funzioni. Il server è andato su bene, AD funziona e replica. Manca solo l’ultimo passo, recuperare il db da nastro. Inserisco il nastro Mercoledì (quello che ha sempre funzionato), il catalogo deve essere ricostruito. Ntbackup si legge tutto il nastro (40 minuti) e poi se ne esce con: “Errore di periferica di backup”. Aggiorno il driver del DAT, riavvio e riprovo (altri 40 minuti). “Errore di periferica di backup”. Provo (40 minuti) con il nastro Martedì, che invece funziona. Solo che l’ultimo Martedì è ferragosto, il 14 e il 15 nessuno ha cambiato il nastro. Morale: db dell’8 Agosto. Finalmente monto gli store, che vanno su senza problemi. Non funziona il servizio di trasferimento messaggi, devo recuperare il secondo backup che avevo fatto per i file bloccati. Così finalmente riparte tutto. Aggiorno i drivers del modem e riparte anche il fax server ed il suo connettore Exchange. Ora funziona tutto solo c’è un buco dal 9 al 19 agosto. Una delle peggiori esperienze mai avute sul lavoro. Murphy non ha tutte le responsabilità: oltre alla sfiga c’è un mix di colpe mie e incuria del cliente.
Nota: (*) Il mio collega è un santo, oltre ad essere un sistemista formidabile. E’ grazie a lui che ne sono uscito.
Nota: Il full backup non c’era per motivi lunghi a spiegarsi, in ogni caso siete autorizzati a sputarmi in un occhio. Ora comunque c’è. Tutte le settimane. Oltre a un doppio backup quotidiano su disco e nastro.
Commenti
22 risposte a “Murphy è vivo e lotta con noi”
Errare è umano, certo è che quando quella sostanza ti passa sopra il naso, riemergere è difficile, duro e snervante, poi una volta fuori … l’odore ch eresta permeato nelle narici fa si che l’attenzione e la sensibilità su certe attività sia decuplicata all’ennesima potenza.
Capisco benissimo cos’hai vissuto!
Resident Devile Addicted!
Complimentissimi…
Cavolo che nottate che ti sei passato!
Ti capisco benissimo. Io ho avuto un cliente che ha beccato un virus che gli ha portato via mezzo HD, bene, mi ha dato il backup che il server ha fatto il giorno stesso, si era dimenticato di cambiare l’HD e quello prima era della settimana precedente!
Da allora gli ho impostato un backup su 2 cartelle differenti, un giorno una cartella un giorno un’altra su di un server messo si apposta, almeno non si dimentica di cambiare HD!
Cmq è proprio vero, murphi ci vede troppo bene a volte!
non sono un sysadmin, ne ho abbastanze delle battaglie post-formattazione di questa settimana…ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
Non si è macchine, una situazione del genere è snervante, soprattutto se il cliente è rognoso e pretende di ripartire in mezz’ora… e vai a pensare che la SG ripartizioni anche periferiche esterne…beh dai.
Per fortuna erp ha tirato su tutto. Anche su ultimate boot cd ci sono dei tool per il ripristino delle partizioni non male e averne sempre una copia dietro è una delle cose che mi hai insegnato te 😉
eh beh, ma una volta girava la massima “il mondo dell’informatica si divide in due categorie: chi ha perso dati e chi li perderá” 🙂
son stato male solo a leggerlo: per fortuna in ufficio tutti i server girano su linux obsoleti ma stabili. quando si è rotto il raid5 son riuscito a risolvere in 10 minuti di comandi. il server di posta in compenso è l’orrido ibm domino
Paolo, in condizioni normali, un server con un controller RAID ricostruisce il disco senza battere ciglio. E’ il blackout su un array già compromesso che ha creato il casino.
Roby: pensa che lo avevo UBCD, ma mica ci ho pensato. Funge anche su periferiche USB?
…dura la vita in qst occasioni.
Capita soprattutto quando hai un Raid5 e nessun disco in attesa di sostituire il disco rotto… Cioè, ai miei clienti PRETENDO che acquistino, ad esempio, server con 4 dischi; 3 per il Raid5 ed uno inserito ma in attesa.
E i Log del DAT me li faccio spedire in automatico sulla mia casella di posta…(servizio a pagamento ;P )
Visto che ci siamo; una volta che hai configurato un server, ad esempio con W2003, Exchange, SQL 2005 e AD ovviamente (DNS e DHCP con reservation)… Di cosa ti fai SUBITO un backup? Per le configurazioni intendo, nel caso di un ripristino o di una compromissione totale del server?
Troppo forte questa storia…
ma ne capitano di tutti i colori tra noi SYS-ADMIN…
Io a tal proposito ho un adesivo che ho attaccato sul mio monitor:
“GOD SAVES, BUT BUDDHA MAKES INCREMENTAL BACKUPS”
SALUTI da Roma
@paolo: se Andrea invece di Exchange avesse trovato un server Domino, magari su linux, magari in cluster, non avrebbe perso nemmeno una mail ed avrebbe potuto ripristinare il server con calma, senza nemmeno 1 minuto di downtime sul cliente.
Mamma mia che situazione… hai tutta la mia solidarietà. Mi fa venire in mente quella volta che su un server è saltato TUTTO l’array RAID5, l’unità di backup era in riparazione, l’unità sostitutiva non era abbastanza capiente, fortuna che col mio collega avevamo messo su un serverino Linux con Samba, e la notte prima aveva fatto il backup via rete, per cui si è persa solo una giornata di lavoro (il server è schioppato intorno alle 18:00 quando non c’era nessuno, ovviamente).
A me è andata bene, ma era un attimo perdere 10 giorni di lavoro di una P.A., credo che sarei morto di un colpo apoplettico io prima che potessero uccidermi loro… 🙂
Io lo dico così tanto per dire qualcosa ma in tasca tengo sempre la RIP, da riga di comando è un filino ostica ma recupera TUTTO, raid, non raid, NTFS, partizioni cancellate… Forse non i nnastri danneggiati ma non si sa mai 🙂
non ti invidio proprio…
mi hai fatto venire una fifa vado a controllare il srv
Giuseppe, se avessi avuto un cluster non avrei avuto problemi neppure con Exchange, e comunque anche Domino non è esente da casini, BTW.
Murphy è passato anche da me poco tempo fa. 23 giugno, TRASLOCO TOTALE dell’azienda. Il vecchio server Exchange deve essere spento e riacceso nella nuova sede per migrazione a nuovo Exchange su VMware. Il vecchio server è un Compaq ML che non aveva MAI dato mezzo problema. Indovinate quando il controller RAID ha deciso di piantarsi? Il 23 stesso, circa 5 MINUTI PRIMA CHE DA TABELLA DI MARCIA DOVESSIMO SPEGNERLO. Imprecazioni varie, smontiamo, puliamo, cambiamo slot: NIENTE, NON PARTE. Morale della favola: abbiamo fatto il trasporto dei dati tramite backup (che per fortuna c’erano, aggiornati, abbondanti e su circa 3/4 media diversi). E non è finita: nei giorni successivi al trasloco ho tentato di farlo ripartire ma niente, morto. Proprio l’altro ieri, al rientro dalla ferie, mi son detto: “Cià che proviamo a vedere se parte”. Si è acceso, è bootato ed ora son 2 giorni che va che è una scheggia…
Storia simile: un venerdi pomeriggio, prima di uscire dall’ufficio, controllo il server con le home degli utenti: un disco del RAID 5 è partito. “Hmm… lunedi devo ordinare un nuovo disco” penso. Temporalone finesettimanale (la città si riempi di voragini) e lunedi trovo il server bloccato perchè un secondo disco ha dato errore.
Mano ai backup: nastri illeggibili. Panic! Visto che il server si incaglia solo nel momento in cui va a leggere una traccia difettosa, passo i successivi due giorni a fare il reboot, montare il filesystem in read only e copiare un po’ di directory, fino al prossimo errore. Reboot, readonly, salva una altro pezzettino… etc. Per fortuna riesco a salvare abbastanza dati da non attapirare troppi utenti.
Da allora “God saves, and Buddha makes incremental backups, but Confucius wisely tests his backups” 🙂
@Andrea: Vero, anche Domino non è esente da casini, ma “orrido” non si può dire: oltre a fare molte più cose di exchange è senz’altro un prodotto più maturo e robusto, per molti versi più lineare e “manutenibile”… ad esempio, per dirlo con parole tue: http://www.andreabeggi.net/2005/09/13/spostare-uninstallazione-di-lotus-domino/
Putroppo è uno sporco lavoro, quanto più penso di essere sicuro del mio lavoro quanto scopro più eventi che potrebbero bloccarlo….. .
Esempio? dischi in raid su di un server…. tutto funzionava bene, ho fatto un scandisk per provare se tutto
andava bene, il controller ha iniziato ha fare un beep continuo… spengo riaccendo… no system disk…. .
sostituisco il disco, rimonto il mirror… . Tutto bene.
Un client si blocca ( ovviamente ci sono stati temporali in quei giorni ) disco andato.
In quel disco c’era un file che era “vitale” per il mio cliente. Ho fatto un ghost del disco con salto degli errori.
Dopo 12 ore di clack clack è arrivato a copiare il 20 % del disco.
ho messo il disco su un pc, easy recovery professional mi ha ritrovato il file che mi serviva.
Fortuna ma anche sfiga…. .
ciao
a me s’è cancellata una compact flash da 64 mega.
no vabeh, siccome qua tutti ne hanno da raccontare e raccomandare, non volevo essere da meno 😛 😛
ciao andrea,questa storia non è da poco!davvero!!
ti posso però capire,almeno per quello che ho passato io..
la bellezza di 3 mesi e mezzo di lavoro quotidiano senza sabati e domeniche….
brevemente (e ti faccio fare na bella risata)
trovo un lavoro,un’azienda molto bella anche proprio da lavorarci in provincia di salerno,un bel server fujitsu-siemens sai di quelli normali per una media-grande azienda niente di eccezzionale,tutta in voip su centralino alcatel…insomma na cosa carina……
ALL’APPERENZA!!!!!!!!!!
tutta la rete pronta
policy,ad,condivisioni,stampanti e tutto il resto era apposto……poi magicamente mentre sto lavorando ad un ripristino di un client ……BOOOOOM !!!
nessuno riesce a stampare,odbc che non vanno,carichi di rete mai visti,e l’unica cosa normale :l’idle del server al 99%….
comunque…sta tarantella avanti per mesi e io dietro a perdere tempo e “denari” (ogni giorno di tasca mia muoviti perchè poi è uscito fuori che ero stato io a sp****re tutto)…e lo sapete alla fine cos’era?????
quel pirla dell’admin che aveva inserito le impostazioni di alimentazione “MANUALI” alla scheda di rete….e la scheda di rete si è non spu******ta,anzi
s’è bruciata direttamenteeee!!! e quand’è che si è bruciata: il giorno che sono arrivato io
spero non accada nulla di simile a nessuno di voi
ciao
Ciao a tutti,io uso acronis true image faccio l’immagine del server ed il backup giornaliero dei dati.
In caso di guasto ho l’immagine da parte,ripristino tutto (s.o.,exchange,AD,applicativi) e ripristino i dati da DAT.
Secondo voi è una soluzione valida?
Ti capisco xchè mi è successa su x giù la stessa cosa. Mal comune mezzo gaudio?