Sull’importanza di monitorare i backup

Di norma chi si occupa dell’IT di un’azienda si preoccupa anche di avere un backup funzionante. A volte si tratta di semplici copie su nastro, altre di varie copie in parallelo su vari sistemi. Altre ancora di macchine intere che vengono replicate tramite snapshot del sistema di virtualizzazione.

In ogni caso, una volta che il tutto viene configurato e controllato per qualche giorno, la cosa passa per funzionante e nessuno la guarda più. Finché ovviamente non capita il disastro.

Questa volta, dopo che sono stato chiamato proprio a causa di un disastro, e dopo aver ripristinato il sistema (Solaris 10 su SunFire 880 con BaanIV e Oracle 10), mi è stato chiesto di controllare la procedura di backup.

Tra le varie operazioni svolte, c’è quella di copiare interamente le directory con i datafile di oracle tramite il comando tar. Il tutto avveniva tramite un job lanciato di notte dal cron di sistema, che mandava poi l’esito all’utente root del quale ovviamente nessuno controllava la casella di posta sul server.

Orbene, il comando tar copiava tutti i file eccetto uno (fortunatamente contenente solo indici), e dava questo messaggio d’errore

tar: /disc2/oradata/BAAN/indx700.dbf too large to archive. Use E function modifier.

che è un messaggio del tar di Solaris dovuto al file indx700.dbf che supera gli 8Gb e non è quindi archiviabile. Il tar di Solaris ha una opzione apposita per cambiare formato e gestire file molto grossi, oppure si può utilizzare gtar (GNU tar) che è già presente in Solaris 10.

Ma la cosa più importante è che le operazioni vanno sempre monitorate costantemente. Quindi la casella email di root va letta tutti i giorni, oppure si può inviare l’output del job ad un altro indirizzo email, magari apposito. Ed è molto importante che questi messaggi siano inviati ogni giorno, e non solo in caso di problemi. Perché il fatto che ogni giorno arrivi l’email vuol dire che la procedura di backup è stata eseguita. Se invece l’email non venisse inviata non si avrebbe la certezza dell’avvenuta esecuzione (con successo o meno) del backup.