Questa è una di quelle storie che fa ridere solo il sottoscritto ma mi pareva ugualmente carino condividere.
Da qualche giorno l’installazione del TSM di un cliente mi da parecchi pensieri, Tivoli è Il sistema di backup di classe enterprise e tendenzialmente vive di vita propria, basta dargli in pasto qualche cassetta ogni tanto, un po’ come fosse una pianta grassa.
Capita però che, un po’ per noia, un po’ per stanchezza, a TSM passi la voglia di lavorare per bene e cominci a mancare un backup qui e uno la. Fortunatamente parliamo comunque di un Signor prodotto che produce quintalate di log compresivi di codici errori univoci e descrizioni altisonanti.
Attraverso l’interpretazione dei codici errori, l’aruspice di turno e cioè me, deriva il passato e il futuro dello sfortunato backup. L’interpretazione dei suddetti errori passa attraverso la “Client Message List“, la porta verso un più consapevole troubleshooting.
Ad essere fortunati, in pochi minuti si torna operativi più gagliardi che mai! Ad essere sfortunati si infilano 3 codici tipo:
ANS1316E: The server does not have enough recovery log space to continue the current operation: IBM dice che è una cosa temporanea e di non dargli peso ma se, come in questo caso son 3 giorni, di chiamare l’amministratore di sistema che per un caso barbino del destino, sono io.
ANR2579E: Schedule schedule name in domain domain name for node node name failed (return code return code): in questo caso si consiglia di visualizzare il log degli errori presente sul client che ha fallito il backup. Va da sé che nel log, non c’è scritto nulla di utile, al più un altro codice di errore che rimanda fatalmente a questo creando una spirale di violenza che genera altra violenza, sul povero amministratore (sempre io).
ANR4532W: The total DB used in DB space is log space used megabytes, and the total space available in the DB space is log space available megabytes. The ratio is log file system used ratio: questo secondo me è il migliore del terzetto! La spiegazione dell’errore ripete sostanzialmente il messaggio di errore, non si sa qual è il comportamento del server in questo caso e non è presente nessuna azione possibile.
Andando a cercare un senso a tutto ciò vien fuori che forse c’è tra le altre cose un errore nella versione in uso di TSM per cui, stanco com’è, non rilegge certi parametri e il “workaround” proposto è quello di fare una proporzione, una di quelle che si imparava a fare alle elementari e, con il valore ottenuto ingannare il povero TSM.
Mi ricorda tanto quella volta che un collega ha messo l’ora sbagliata su un domain controller e 24 suoi fratellini, han smesso di replicarsi per 3 giorni.