TESI DI LAUREA IN PROGRAMMAZIONE IN RETE Network backup nella MAN di Ateneo: il caso di Bacula

UNIVERSITÀ DEGLI STUDI DI BARI FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI CORSO DI LAUREA IN INFORMATICA A.A. 2010/11 TESI DI LAUREA IN PROGRAMMAZIONE IN RETE Network backup nella MAN di Ateneo: il caso di Bacula Relatore: Chiar.mo prof. Filippo LANUBILE Correlatori: Emanuele Magno Dario Mastropasqua Laureando: Daniele D AGNELLI ANNO ACCADEMICO 2010-2011

Sommario 1. Introduzione... 1 2. Il Backup... 2 2.1. Adempimenti di legge... 3 2.2. Qualità desiderabili... 3 2.3. Approcci al Backup... 4 2.3.1. Il backup dell intero sistema... 4 2.3.2. Il backup dei dati delle applicazioni... 6 2.3.3. I livelli di backup... 6 2.3.4. La periodicità dei backup... 7 3. Il software di Backup... 8 3.1. Software a Confronto... 8 3.1.1. Perché Bacula... 9 3.2. Bacula... 11 3.2.1. Stato dello sviluppo... 11 3.2.2. La licenza... 11 3.2.3. Le statistiche di Ohloh.net... 11 3.2.4. L architettura... 13 3.2.5. Le componenti... 13 3.2.6. L interazione... 15 3.2.7. Il protocollo... 16 3.2.8. L autenticazione... 16 3.2.9. La configurazione... 16 3.2.10. Funzioni... 16 4. Analisi dei Requisiti... 18 4.1. I servizi attivi al CSI CAMPUS... 18 4.1.1. Apache HTTP Server... 19 4.1.2. MySQL... 19 4.1.3. Dovecot... 20 4.1.4. OpenLDAP... 21 4.1.5. BIND... 21

4.1.6. Syslogd... 21 4.1.7. Bacula... 21 4.2. Linux CentOS... 22 5. L Installazione... 23 6. La configurazione... 24 6.1. Automatizzazione dei task da eseguire prima e dopo il backup... 25 6.2. web1.uniba.it... 26 6.2.1. Implementare il Mirroring Master-Slave... 26 6.2.2. Apache... 28 6.3. mail.uniba.it... 29 6.4. auth1.uniba.it... 29 6.4.1. LDAP Sync Replication... 29 6.5. gauss.uniba.it... 29 6.6. logger.csi.uniba.it... 30 6.7. bacula.uniba.it... 30 6.7.1. Il server Slave del DBMS MySQL di web1.uniba.it... 30 6.7.2. Il mirror del server OpenLDAP di auth1.uniba.it... 31 7. Estrazione dei Dati... 32 7.1. Disaster Recovery... 32 8. Il Testing... 34 8.1. L hardware del server Bacula... 34 8.2. Il repository EPEL... 34 8.3. Compatibilità tra le versioni... 34 8.4. L installazione manuale di Bacula 3 attraverso gli RPM... 35 8.5. La configurazione degli agenti bacula-fd... 35 8.6. Backup di web1.uniba.it... 37 8.6.1. TCP Wrappers... 37 8.7. Backup di gauss.uniba.it... 38 8.7.1. Il firewall iptables... 38 8.8. Backup di bacula.uniba.it... 38 8.8.1. Il directory OpenLDAP di auth1.uniba.it... 38 8.8.2. Il catalogo SQL di Bacula... 39 8.8.3. Script da eseguire prima del backup tramite il parametro ClientRunBeforeJob... 39 8.8.4. Script da eseguire dopo il backup tramite il parametro ClientRunAfterJob... 39 8.9. Performance... 40

8.9.1. Velocità del Backup sul Network: il backup delle directory /etc... 40 8.9.2. Velocità del ripristino sul Network della directory /etc... 42 8.9.3. Le velocità di trasferimento a confronto... 43 8.9.4. Velocità del Backup sul Network di notte... 44 8.9.5. Velocità del ripristino sul Network di notte... 46 8.9.6. L estrazione dei dati del DBMS di web1.uniba.it... 47 8.10. Previsioni... 48 web1.uniba.it... 48 mail.uniba.it... 48 logger.uniba.it... 49 gauss.uniba.it... 49 auth1.uniba.it... 50 bacula.uniba.it... 50 8.10.1. Confronto tra gli spazi di archiviazione richiesti per un Full Backup... 51 8.10.2. Confronto del tempo impiegato per un Full Backup... 51 9. Conclusioni... 52 10. Sviluppi Futuri... 54 Appendice: le Tape Library... 55 I Tape Drive... 55 FUJITSU ETERNUS LT40... 56 Ringraziamenti... 57 Bibliografia... 58

1. Introduzione Questa tesi è il risultato del lavoro svolto presso il Centro Servizi Informatici (CSI) dell Università degli Studi di Bari, dove si è resa necessaria una soluzione affidabile che garantisse l incolumità dei dati che vengono gestiti. Al momento non è in vigore nessuna politica per quanto riguarda le copie di sicurezza dei dati, generalmente se ne effettua una copia prima delle operazioni di aggiornamento o modifica delle configurazioni; i dati salvati sono spesso archiviati sulla stessa macchina e nessuna precauzione è adottata per tutelarsi da eventi disastrosi. La tesi analizza tutte le fasi che portano all implementazione del sistema di backup per il CED CSI CAMPUS: analisi dei requisiti, scelta del software e strategie di configurazione nonché i risultati dei test di archiviazione e ripristino effettuati. Il sistema desiderato deve centralizzare oltre all archiviazione dei dati il controllo sui client in modo che la soluzione possa facilmente essere integrata con altre periferiche in futuro. Tutte le macchine in oggetto comunicano tra loro attraverso la rete, nel nostro caso una LAN ma potrebbe essere anche Internet. Questo tipo di soluzione è generalmente chiamato Network Backup. 1

2. Il Backup Per Backup si intende una generica operazione che realizzi una copia dei dati al fine di un loro eventuale recupero in caso di perdita. I dati potrebbero andare perduti per diversi e imprevedibili motivi, per questo è importante intraprendere, al fine di tutelare i dati, azioni che limitino l'impatto di questi eventi, ovvero il lavoro e quindi il tempo di coloro che su questi dati lavorano. Una perdita dei dati può avere diverse cause: Intenzionale: un file o un programma vengono deliberatamente eliminati da un utente Non intenzionale: la cancellazione accidentale di un file o di un applicazione, lo smarrimento di un supporto di archiviazione, errori dell amministratore di sistema Guasto: o Interruzione improvvisa dell alimentazione con conseguente perdita dei dati in memoria non ancora archiviati su supporti di archiviazione permanente o L hardware sul quale i dati sono archiviati smette di funzionare o Il crash inaspettato di un software con conseguente perdita dei dati non salvati o Un bug software porta a una cancellazione inattesa Disastro: disastri naturali come terremoti, allagamenti o incendi Crimine: furto, attacco informatico o la presenza di malware sui sistemi 2

2.1. Adempimenti di legge A rafforzare l'importanza dei backup sussistono precisi obblighi imposti dalla legge riguardo la gestione dei dati personali, come email e spazi web. L'argomento è trattato dal D.lgs 192/2003 - "Codice in materia di protezione dei dati personali ( [1]) In particolare, citando l articolo 31 del D.lgs: I dati personali oggetto del trattamento sono custoditi e controllati [ ] in modo da ridurre al minimo, mediante l adozione di idonee e preventive misure di sicurezza, i rischi di distruzione o perdita, anche accidentale, L'articolo 31 specifica, con il comma 1-f, che il trattamento dei dati personali è legittimo solo se sussistono adeguati requisiti di sicurezza e disponibilità degli stessi. La legge impone inoltre, con l'articolo 18, che i salvataggi avvengano con cadenza almeno settimanale e che in caso di bisogno il ripristino debba avvenire entro sette giorni. Tutti i provvedimenti presi devono essere inoltre riportati, secondo l'articolo 19, nel documento programmatico sulla sicurezza. 2.2. Qualità desiderabili È importante identificare quali siano tutte le proprietà desiderabili per un sistema di backup, prima di analizzare i compromessi che inevitabilmente il caso particolare impone. 3

Semplicità: se la realizzazione dei backup è complessa, si corre il rischio che la soluzione non venga adottata come previsto, rendendo tutto il lavoro inutile; Affidabilità e velocità: tutti i dati devono poter essere recuperati e i sistemi che hanno subito perdite devono poter tornare operativi in breve tempo anche in caso di disastro; Discrezione: la soluzione di backup deve avere un impatto minimo sulle normali attività svolte dai sistemi che la impiegano, non deve penalizzarne le prestazioni né la disponibilità dei servizi; Archiviazione fuori sede: il recupero dei dati deve essere possibile anche in caso di evento catastrofico (furto, incendio, allagamento, etc..) e bisogna organizzarsi per mantenere una ulteriore copia aggiornata dei dati in un luogo fisicamente distante. 2.3. Approcci al Backup La scelta della modalità varia da sistema a sistema ed è la conseguenza del compromesso tra economicità, prestazioni e affidabilità richieste. 2.3.1. Il backup dell intero sistema Il Backup dell intero sistema è la soluzione che offre la massima affidabilità. Sebbene i dati che si intendono proteggere sono quelli di lavoro mentre i file di programma e sistema operativo possono essere recuperati con una nuova installazione, questo approccio permette di far fronte ai cambiamenti imprevisti del sistema in uso. Un sistema potrebbe venire aggiornato o potrebbero venire 4

aggiunti dei nuovi servizi che operano in posizioni non precedentemente indicate al servizio di Backup. Il rovescio della medaglia risiede nel fatto che un backup integrale implica il salvataggio anche di dati ai quali non si è interessati e questo si traduce in uno spazio di archiviazione richiesto maggiore, un maggior traffico sul network e ancora in un maggior tempo per terminare il task. 2.3.1.1. Salvare tutti i dati del disco Quando si è interessati a salvare tutti i dati di un sistema è sufficiente indicare al software di backup la directory radice (root) come posizione di interesse. Utilizzando questo approccio bisogna tener presente che su Linux anche i device sono considerati file e che come tali sono presenti sul filesystem. Salvare questi file non è di alcuna utilità, oltretutto spesso risultano bloccati dal sistema operativo. In tal caso si può quindi indicare al software di backup quali sono i loro percorsi, tramite un opportuna lista di esclusione che può comprendere anche i file temporanei. 2.3.1.2. Lo snapshot LVM Nei sistemi che utilizzano LVM il backup completo può essere ottenuto mediante un suo snapshot. LVM è un software per la gestione dei volumi che permette l astrazione di dischi fisici in volumi logici e il loro ridimensionamento anche durante operazioni di scrittura; tramite l opzione snapshot del comando lvcreate è possibile creare un volume logico che rappresenta il sistema nell istante in cui viene eseguito. 5

Il volume creato può essere montato e utilizzato dal sistema di backup affinché possa effettuare una copia dei dati a partire da uno stato consistente del filesystem mentre lo stesso può continuare ad essere utilizzato. La durata del processo non è tuttavia predicibile e la consistenza dei dati è minacciata, soprattutto se il volume è utilizzato da un DBMS; inoltre se un applicazione utilizza volumi diversi contemporaneamente non è garantita la consistenza tra la realizzazione di uno snapshot e l altro. Queste caratteristiche limitano la generalità dell impiego di questa soluzione che rimane però la scelta più affidabile in tutti quei contesti per i quali i requisiti sono soddisfatti. 2.3.2. Il backup dei dati delle applicazioni Al software di Backup si indicano esplicitamente i percorsi delle directory e dei file da archiviare. Di interesse sono i dati su cui operano le applicazioni, i contenuti dei database, le directory degli utenti e i file di configurazione dei servizi. 2.3.3. I livelli di backup Non è sempre necessario effettuare una copia integrale dei dati di interesse; a seconda dell affidabilità richiesta si può effettuare un backup completo o un backup incrementale. I tipi di backup, secondo una terminologia consolidata, sono classificati in: Livello 0: tutti i file di interesse; Livello 1: differenze rispetto all ultimo backup di livello 0; 6

Livelli da 2 a 9: differenze rispetto al livello precedente; Incrementale: tutto i cambiamenti rispetto all ultimo backup di qualsiasi tipo. 2.3.4. La periodicità dei backup Come linea guida il backup è un processo da eseguire quotidianamente quando l attività sui server e il traffico sul network sono minimi, ad a esempio di notte. Figura 2 Grafico prodotto da MRTG del traffico settimanale sugli Switch dei servizi fornitii da Uniba (Verde traffico in ingresso, Blu traffico in uscita) Una pratica consolidata è effettuare un backup di Livelloo 0 ogni settimana, e un backup di livello 1 ogni giorno. Ill compromesso come sempre è tra affidabilità richiesta e ottimizzazione delle risorse in quanto ogni backup completo (livello 0) impiega più spazio su disco e più traffico sul network ma è una risorsa indipendente, i backup incrementali li dipendonoo invece dall integrità dei backup di livello inferiore a cui si riferiscono. r 7

3. Il software di Backup Per il Network Backup dei servizi del CSI CAMPUS non era indispensabile un software multipiattaforma in quanto i server attivi hanno sistemi operativi omogenei. Non ci si è però voluta precludere la possibilità di future integrazioni e quindi un requisito preso in considerazione è stato che la componente client, quella da installare su ogni sistema di cui si vuole effettuare il backup, lo fosse stata. Nella scelta del software hanno influito da un lato il budget limitato che ha costituito un forte incentivo all adozione di soluzioni gratuite, dall altro la compatibilità con l hardware di cui l Università ha pensato di dotarsi, la Tape Library Fujitsu ETERNUS LT 40, discusso in Appendice. I principali sistemi che soddisfano i questi requisiti sono risultati essere Amanda, Bacula e Arkeia Network Backup. 3.1. Software a Confronto Arkeia è dei tre l'unico prodotto non Open Source, supporta i backup di molti servizi senza interromperli, ma è distribuito con una licenza commerciale a pagamento. Amanda e Bacula hanno il vantaggio di essere gratuiti, nonché OpenSource. Questo si traduce in un investimento iniziale nullo a fronte di una richiesta di maggiori competenze, di cui però l'università dispone. Tra i tre software la scelta che meglio soddisfa le esigenze del centro è risultato essere Bacula. 8

3.1.1. Perché Bacula Bacula oltre ad essere gratuito a differenza di Arkeia offre inoltre alcuni vantaggi rispetto ad Amanda. Il primo è la GUI: per Bacula ne esistono diverse tra le quali q una molto completa chiamata BAT (Bacula Administration Tool), liberamente e gratuitamente disponibile mentre. Per Amanda è invece disponibile unn tool di configurazione basato su Web solo nella sua versione commerciale a pagamento chiamata Zamanda. Figura 3 Navigazione tramite BAT attraverso le versioni dei file tra i quali scegliere per il recupero [2] 9

Figura 4 Zamanda [3]] La differenza più importante di archiviazione dei dati. Amanda rispetto a Bacula B è laa modalità di Amanda utilizza gli strumenti standard messi a disposizione dal sistema operativo (tar, gzip, dump etc.), Bacula ha un suo personale formato d'archiviazione. Il formato di archiviazione di Amanda dipende invece dallaa particolare implementazione dei tool che utilizza, implementazione che potrebbe variare tra diverse versioni del sistema operativo; tra diverse versioni potrebbero cambiare le opzioni disponibili o i limiti alla profondità dell'albero delle directoryy che possono gestire. I dati archiviati da Bacula sono in un nuovo formato, aperto, ma coerente tra i vari sistemi. 10

3.2. Bacula Bacula è un insieme di programmi per la gestione del Backup, recupero e verifica dei dati di sistemi in un network eterogeno. Il software è Open Source ed è progettato per scalare dall impiego su una singola macchina a quello distribuito in un network grazie alla sua architettura client/server. Gestisce in maniera trasparente l archiviazione su diversi tipi di supporti, anche in combinazione, come dischi rigidi, dispositivi a nastro e media ottici quali CD e DVD. 3.2.1. Stato dello sviluppo Il progetto Bacula, nato nel 2002 e giunto alla sua quinta versione, è distribuito con licenza Open Source Affero General Public License (AGPL), un estensione della licenza GNU GPL 2. 3.2.2. La licenza La GNU General Public prescrive che opere derivate da codice distribuito con licenza GPL siano a loro volte distribuite sotto tale licenza. La AGPL estende quest obbligo alle opere derivate che, anche se non materialmente distribuite, vengono rese accessibili in rete come servizi riconoscendo il diritto agli utenti di tali servizi di aver accesso al codice sorgente. 3.2.3. Le statistiche di Ohloh.net Oholoh.net è una piattaforma che monitora lo sviluppo di più di 500.000 software Open Source fondata nel 2004 da due ex-manager Microsoft. Stando alle statistiche offerte dal portale, Bacula ha goduto di un repentino sviluppo dalla sua 11

creazione nel 2002 fino a metà 2008 godendo adesso dii una codebase matura e ben consolidata. [4] Figura 5 Crescita delle righe di codice nel tempoo [5] Figura 6 Crescita degli update al codice nel tempo [5] 12

3.2.4. L architettura Bacula è strutturato in componenti cooperanti che comunicanoc o tra di loro utilizzando il protocolloo TCP/IP, il l che permette di distribuire il carico di ognuna su un hardware indipendente e specializzato. Il trasporto dei dati via TCP può essere a sua volta incapsulato in TLS (Transport Layer Security) S che ne consente la protezionee della trasmissione tramite la cifratura. 3.2.5. Le componenti Figura 7 - Schema dell interazione tra le applicazioni di Bacula [6] Ogni componente è implementataa come applicazione indipendente all interno dell ambientee Bacula. 13

3.2.5.1. Bacula Director È l applicazione centrale di tutta l architettura Bacula: accentra pressoché tutte le configurazioni e le politiche del sistema specificando la definizione dei pool dei media di archiviazione, la schedulazione dei Job, il controllo degli accessi e la reportistica. 3.2.5.2. DBMS Bacula mantiene un indice di tutti i file archiviati all interno di un database relazionale esterno. Allo stato attuale dello sviluppo sono disponibili driver che permettono l utilizzo trasparente di SQLite, MySql e PostgreSQL. 3.2.5.3. Bacula Storage E il demone che gestisce l interazione con i supporti di backup (nastri, dischi rigidi, supporti ottici) e l unico ad interagirvi direttamente, fornendo alle altre componenti un interfaccia astratta. Il demone di storage gestisce il mountunmount dei volumi, l etichettatura dei nastri e la gestione di Tape Library automatizzate. 3.2.5.4. Console di amministrazione È una console che permette all amministratore di interagire con il sistema per l esecuzione di nuovi Job, il recovery dei file, la consultazione dei log e dello schedulatore. È disponibile sia nella versione a riga di comando, che implementa tutte le funzioni disponibili in Bacula, sia tramite GUI. 14

3. 2.5.5. Bacula File È il demone che va installato sui client dei quali si vuole effettuare un backup con Bacula. Comunica con il i Director e quest ultimo determina quali dati e metadati devono essergli trasmessi. 3.2.6. L interazione Il Director comunica all File Deamon con quale Storagee Deamon interagire per effettuare i backup, escludendosi quindi dal traffico intenso del trasferimento dei dati. Il Director ha un proprio schedulatore che organizza i Job e si occupa del recapito dei log via maill agli amministratori. Figura 8 - Diagramma a blocchi che mostra l interazione tipica tra i servizi di Bacula per realizzaree un Backup. Ogni blocco b rappresenta in generale un processo, normalmente un demone. Inn generalee il Director monitora il flusso di informazione ed è anche responsabile del mantenimento del Catalogo. [7]] 15

3.2.7. Il protocollo Quello di comunicazione tra le componenti di Bacula è un protocollo a pacchetti realizzato sulla base degli stream standard TCP/IP. Al livello più basso i trasferimenti sono implementati tramite richieste di read() e write() alle socket di sistema. I trasferimenti dei file avvengono invece tramite le routine bnet_open, bnet_write, bnet_recv e bnet_close che garantiscono che tutti i byte inviati tramite la socket siano ricevuti come un singolo pacchetto, indipendentemente dal numero delle chiamate alle socket di sistema read() e write() necessari. 3.2.8. L autenticazione Ogni servizio è caratterizzato da un nome e da una password, salvata in chiaro nel suo file di configurazione e in quello del Director. Le password sono utilizzate per l autenticazione ma non vengono trasmesse direttamente in chiaro sul network ma vengono utilizzate per generare l hash dell acknowledge tra i servizi. 3.2.9. La configurazione Fatta eccezione del DBMS, che è indipendente, ogni servizio ha un suo file di configurazione che definisce gli oggetti su cui Bacula opera e come devono essere amministrati. 3.2.10. Funzioni 3.2.10.1. Catalogo SQL Memorizza la lista dei file che sono stati archiviati, gli attributi di ognuno, il checksum, il nome del client dal quale sono stati estratti e la posizione logica nella quale adesso sono archiviati. 16

3.2.10.2. Backup Multivolume Una delle caratteristiche più evolute di Bacula è il supporto ai backup multivolume. Quando configurato con una Tape Library è in grado di gestire i nastri senza l intervento umano e gestirne l etichettatura. Qualora fosse necessario l intervento umano Bacula comunica con l amministratore tramite messaggi via console o email. 3.2.10.3. Livelli di Backup in Bacula Bacula permette diversi livelli di backup: Completo: tutti i file Differenziale: backup di tutti i file cambiati rispetto all ultimo backup completo Incrementale: backup di tutti i dati modificati rispetto all ultimo backup di qualsiasi tipo 3.2.10.4. Formato di archiviazione I dati salvati vengono conservati nei volumi. Un volume è un semplice un archivio per i dati di backup. Bacula implementa questo unico formato anziché ricorrere a strumenti standard come tar o dump per garantire la consistenza tra diversi sistemi operativi e le implementazioni degli stessi tool, che possono variare da un sistema all altro. Il recupero dei dati dai volumi deve quindi avvenire tramite la console di Bacula o una delle tante interfacce grafiche liberamente disponibili o ancora utilizzando due applicazioni stand-alone che vengono messe a disposizione: bls e bextract. 17

4. Analisi dei Requisiti Il Centro Servizi Informatici dell Ateneo si occupa dello sviluppo, acquisizione e gestione di servizi telematici e di supporto al sistema informativo dell Università di Bari. Al Centro sono affidati: i servizi informatici, telematici e di comunicazione di utilità generale per l'università; il servizio di archivazione ed elaborazione dati dell'università; l'organizzazione di corsi d'addestramento sull'uso dei servizi di rete e di software applicativi; il coordinamento dell'accesso alle banche dati esterne; la gestione dei protocolli e livelli di sicurezza del sistema informativo. [9] Il Centro è organizzato in due sedi: CSI ATENEO e CSI CAMPUS, il primo ubicato presso Palazzo Ateneo e CSI CAMPUS presso il Dipartimento di Fisica. 4.1. I servizi attivi al CSI CAMPUS Web Hosting: Apache HTTP Server DBMS: MySQL Posta elettronica: Dovecot Autenticazione utenti: OpenLDAP DNS: BIND Log di sistema: Syslogd 18

Backup: Bacula Tutti i servizi al momento operativi di cui eseguire i backup, tra i quali lo stesso server di backup, sono in esecuzione su macchine con sistema operativo GNU/Linux, quasi tutte con distribuzione CentOS. Tutti i server comunicano tra loro tramite interfacce Gigabit Ethernet, in rete locale. L ampiezza di banda di 1000Mbit/s e il non dover concorrere per questa con gli utenti permette di trascurare, in questa sede, l impatto del traffico di rete generato dal backup sulla disponibilità al pubblico dei servizi. 4.1.1. Apache HTTP Server I dati su cui opera il server web sono un insieme relativamente statico di file. I file di configurazione di Apache indicano quali sono le directory servite e il backup si esaurisce specificando nel file di configurazione di Bacula Director quali siano queste directory. 4.1.2. MySQL MySQL non si appoggia direttamente al filesystem per l archiviazione permanente dei suoi dati ma implementa un ulteriore astrazione, invisibile all utente. Per archiviare su file il contenuto del database si utilizza il tool mysqldump. L output è un un file con estensione.sql che contiene tutte le istruzioni per creare lo schema dei database, delle tabelle e dei dati che lo popolano. Effettuare il backup di un database MySQL equivale quindi ad esportare una copia del dump. 19

Al fine di garantire la consistenza dei dati durante l esportazione delle tabelle mysqldump sospende le operazioni di scrittura sul database, e tale interruzione è direttamente proporzionale alla quantità di dati gestita dal DBMS. Dovendo garantire la continuità del servizio si utilizza quindi una tecnica chiamata Mirroring Slave-Master. 4.1.2.1. Il Mirroring Slave-Master Consiste nell avere un altro server MySQL (Slave), che non si interfaccia con l esterno, contenente una copia esatta del server operativo (Master). Lo Slave viene caricato con una copia iniziale dei dati del Master (un esecuzione di mysqldump e conseguente sospensione del servizio è comunque necessaria) e ne segue ogni aggiornamento mantenendosi sincronizzato. Il backup avviene quindi tramite il dump delle tabelle dello Slave la cui sincronizzazione riprende dopo il temporaneo lock della scrittura. 4.1.3. Dovecot La posta elettronica è affidata al servizio Dovecot che utilizza lo standard Maildir per l archiviazione. Lo standard prevede che ogni messaggio di posta sia mantenuto in un file separato dotato di un nome univoco e che ogni casella di posta sia una directory. La gestione del lock dei file, la scrittura lo spostamento e la cancellazione sono a carico del filesystem; non ponendosi problemi di consistenza dei dati il backup è molto semplice e consiste nell indicare al software la directory radice per tutte le caselle di posta. 20

4.1.4. OpenLDAP È un protocollo standard per l interrogazione e la modifica dei servizi di directory che utilizza la struttura ad per codificare i dati. Per esportare una copia dei dati si utilizza il comando slapcat; questo genera un file nel formato standard LDIF. Per garantire la consistenza dei dati questa è un operazione che va eseguita a servizio sospeso. Per il backup bisogna indicare al software la posizione del file LDIF così generato. Per garantire la continuità del servizio agli utenti e la consistenza dei dati di backup, come specificato nel caso del DBMS MySQL, è implementabile un servizio parallelo funzionale all estrazione di dati e metadati, dopo un breve stop di quest ultimo. 4.1.5. BIND Il server DNS utilizza file di configurazione, tutti statici, che è sufficiente indicare al software di Backup. 4.1.6. Syslogd Syslogd è un servizio che gestisce in maniera centralizzate i log di sistema di diverse macchine. Non sussistendo problematiche legate alla consistenza dei dati è sufficiente indicare al software di Backup la directory a partire dalla quale vengono salvati tali file. 4.1.7. Bacula Bacula è il servizio che si occupa del backup e come tale necessita anch esso di una copia di sicurezza dei dati sui quali opera, quindi del catalogo e dei file di configurazione. 21

I file di configurazione sono statici e basta indicarne la posizione in cui si trovano nel sistema all interno degli stessi. Il catalogo è gestito da un DBMS, nel nostro caso MySQL e va quindi effettuato un dump su file dei dati in esso contenuti e poi creare di questi ultimi una copia di sicurezza da esportare tramite Bacula. 4.2. Linux CentOS Il sistema operativo di riferimento utilizzato al CSI CAMPUS e sul quale sarà in esecuzione il software di backup è la distribuzione GNU/Linux CentOS. CentOS è una distribuzione GNU/Linux derivata dalla più nota distribuzione commerciale Red Hat Enterprise Linux (RHEL). RHEL è utilizzata in ambiti altamente professionali ed è caratterizzata da grande affidabilità e rapidità nel rilascio degli aggiornamenti. Red Hat vanta importanti clienti proprio per la sua affidabilità, uno dei più prestigiosi dei quali è il New York Stock Exchange che si affida a sistemi dotati di RHEL per gestire le sue transazioni finanziarie. [10] Sebbene commerciale RHEL fa uso di software Open Source ed è quindi tenuta a distribuire, secondo la licenza GPL del codice che implementa, il codice sorgente degli aggiornamenti che rilascia sotto la stessa licenza. La community che rilascia CentOS ricompila e ridistribuisce gli aggiornamenti di Red Hat, con l'unico accorgimento di eliminarne i marchi - quelli sì - protetti dal diritto d'autore, fornendo gratuitamente una versione compatibile al 100% con RHEL, dalla quale si differenzia solamente per l'assenza di un supporto tecnico. 22

5. L Installazione L installazione dei software avviene tramite il gestore dei pacchetti disponibile in CentOS, chiamato yum, che ne gestisce dipendenze e aggiornamenti. Bacula non è presente nei repository di default di e vanno per questo integrati con quelli di EPEL (Extra Packages for Enterprise Linux), gestiti dalla community di Fedora, il progetto Open Source di Red Hat. Sulla macchina che ospiterà il server bacula sono installati anche i server MySQL, OpenLDAP dedicati alle operazioni di Mirroring dei rispettivi servizi al pubblico, ed il primo anche alla gestione del catalogo di Bacula. 23

6. La configurazione Su ogni macchina del CSI CAMPUS girano servizi dedicati e collaudati tramite l uso nel tempo. L approccio scelto è quello di stabilire a priori quali saranno i dati di cui effettuare il backup in modo da economizzare l impiego di tutte le risorse. Tutti i servizi forniti dal centro devono garantire continuità, sono di pubblico accesso e vengono offerti globalmente. Ciò significa che non esiste un momento di completa inattività e vanno quindi esclusi tutti gli approcci che prevedono una interruzione dei demoni. Le operazioni di backup vengono comunque eseguite quando è notte in Italia e quindi il carico sui i server e sul network è al minimo. Nelle notti tra sabato e domenica si effettua un backup di Livello 0, punto di riferimento per i backup di Livello 1 dei giorni a seguire. Nel file di configurazione di bacula-director si indicano i percorsi dei dati di lavoro dei diversi servizi. Per ogni sistema si salva inoltre il contenuto della directory /etc all interno della quale, nei sistemi GNU/Linux CentOS di cui ci occupiamo, sono presenti tutti i file di configurazione del sistema. 24

Figura 10 Server operativi nel CSI CAMPUS 6.1. Automatizzazione dei task da eseguire prima e dopo il backup Alcuni servizi operanoo su file statici e non è necessaria alcuna operazione preliminare affinché Bacula possa effettuare il backup. In altri casi invece i dati su cui operano le applicazioni sono archiviati in formati proprietari o non si trovano in uno stato consistente se s il servizio non viene preventivamente arrestato; questo accade ad esempio con i DBMS. 25