Spesso si sente ripetere in modo un po’ banale che la condizione necessaria per un backup consistente è il test di restore, io di solito considero necessarie queste condizioni:

• il backup deve essere fatto (…)
• va effettuato un test di restore periodico
• il backup deve essere schdulato e automatico (non deve dipendere da azioni manuali)
• il backup deve inviare notifiche su eventuali anomalie occorse durante la schedulazione

Quest’ultimo aspetto ahimè è spesso ignorato, oppure ci si affida a notifiche inviate a prescindere senza distinguere l’effettivo esito del processo (troppe informazioni che inevitabilmente comportano la mancata rilevazione di un problema).

Questa la premessa, come ho già avuto modo di dire mi capita spesso di sguazzare tra vecchi ruderi informatici sparsi per i datacenter più insospettabili, di recente mi è capitato di mettere le mani su un server MS SQL (brrr…) 2000 (brrr²….) con piani di manutenzione disastrati e backup in uno stato di completo abbandono.
Come solo i vecchi sistemisti ricorderanno MS SQL 2000 richiede ufficialmente l’utilizzo di Exchange (brrrr³…) per inviare notifiche email sull’esito dei maintenance plan, un autentico furto a mano armata…

Come alternativa propongo questa semplice soluzione che non comporta alcuno stravolgimento architetturale ed è applicabile anche a versioni più recenti del database MS (che per fortuna hanno colmato questa lacuna con apposite procedure).

Prosegui con la lettura »

Durante qualche scorribanda sistemistica potrebbe capitare anche voi di trovarvi nella spiacevole condizione di non riuscire a installare un semplice package rpm su una delle distribuzioni GNU/Linux derivate da RedHat.

A me è capitato di recente mentre mi accingevo ad installare l’agente EMC² Networker su un server presso un cliente, il triste errore è il seguente:

Controllando meglio il server (fresco fresco di installazione e quindi non ancora sotto monitoraggio) mi sono accorto che il volume montato in /var risultava completamente saturo, motivo per cui il package manager non è riuscito ad aggiornare il database locale.

Anche dopo aver esteso il volume però il risultato non ha accennato a migliorare, sintomo che doveva essere successo qualcosa di spiacevole al suddetto database rpm. Vista la situazione non è rimasto altro da fare che cancellarlo…

…e ricostruirlo mediante il comando “rpm –rebuilddb”, al termine del quale l’installazione del package si concluso con esito splendido splendente.