BACULA GPL Storage Management System

Transcript

1 BACULA GPL Storage Management System INSTALLAZIONE E CONFIGURAZIONE Introduzione Bacula è un potente sistema di Network Backup che permette di centralizzare i backup verso un vero e proprio backup server, in genere una macchina dedicata, dotata di dischi veloci e unità destinate all archiviazione, come ad esempio i DAT. Il sito ufficiale è : Possiede i client per sistemi diversi e funziona egregiamente con gli Unix/Linux e con i sistemi Win32 (WinXP/2000/2003). Passare per la documentazione ufficiale è un obbligo. vista l incredibile quantità di opzioni e di possibilità di configurazione che il programma offre. Questo documento non è che un breve sunto delle possibilità di questo sistema di backup, per cui se aveste dei dubbi o cercaste un approfondimento potete andare qui: Il funzionamento di base Il programma ad un primo impatto può sembrare complesso, in effetti lo è. Ma una volta capita la sua logica se ne può apprezzare la potenza e la versatilità. La strutturazione è completamente gerarchica, occorre predisporre una struttura ad albero contenente oggetti diversi che portano alla realizzazione del backup finale. Prima di iniziare è bene predisporre almeno un client remoto, con GNU/Linux o Win32, in modo da poter controllare remotamente il bacula server. Le connessioni in rete sono gestite con una password standard molto complessa che va inserita sia nei file del server che del client. Può essere ovviamente modificata e magari semplificata. Le impostazioni delle password per consentire l accesso remoto vanno fatte nel file bacula-fd.conf. Vediamo ora il funzionamento di bacula usando lo schema del manuale originale: In sostanza, questo software si divide in 3 blocchi più importanti che corrispondono ai demoni (o servizi). Il primo e più importante si fa carico di gestire tutti i job, le schedulazioni e la comunicazione per gli altri 2 demoni. Lo possiamo identificare nell'immagine come Backup Server oppure Bacula director daemon. Se notiamo le frecce possiamo meglio comprendere quali sono le sue funzioni. Una è diretta al database server (MySQL, PostgreSQL, SQLLite) per ottenere le informazioni dal catalogo. Una seconda è diretta al File Server ossia Bacula file daemon. In questo modo il director indica al file daemon che un backup è iniziato e quindi dovrà iniziare ad inviare i dati al demone di storage, il quale si preoccuperà di immagazzinare i dati che il director ha precedentemente segnalato al file daemon sul supporto specificato. La freccia rimanente è collegata allo storage daemon affinchè venga avvisato a sua volta dell'inizio di un job. Ciò avviene anche per motivi di sicurezza. Un file daemon non è autorizzato a contattare 1

2 lo storage daemon a meno che questo non sia stato prima informato dal demone director (specificato nel suo file di configurazione). In questo modo eviteremo che un eventuale attacco possa sfruttare una qualsiasi falla del demone file per corrompere eventuali volumi collegati al demone di storage. Rimangono ora le frecce più marginali che sono quelle stanno ad indicare le eventuali tray monitor oppure le console remote che permettono di monitorare da eventuali client remoti lo stato dei servizi nonché gestire il director da remoto. N.B. Un grazie ad Aristedes Maniatis per lo schema Vediamo ora il processo interazione tra i servizi di Bacula: 2

3 N.B. Come si può notare da questi schemi, il sistema di demoni di bacula è completamente modularizzato, questo permette di separare lo Storage (porta 9103), il FileDaemon (porta 9102) ed il Director Server (porta 9101) su sistemi diversi. Il tutto viene comunque poi centralizzato dal director che controlla tutto il sistema. Anche lo schema di interazione tra i servizi mostra come sia flessibile e completo il meccanismo di funzionamento, tra il comando impartito, la gestione delle credenziali e l accesso al Catalogo dei dati. Metodologie di Backup Visto che se ne parlerà ampiamente all interno del documento è bene prima di iniziare, chiarire alcuni concetti sui tipi di backup. Quanti tipi di backup esistono? Personalmente sono a conoscenza di tre tipi di backup: Completo Incrementale Differenziale Vediamo ora la differenza fra questi: Completo: Sicuramente il più semplice da capire o intuire. Si tratta di un backup di tutti i dati che abbiamo specificato in fase di backup. Nel caso in bacula dovessimo definire un backup solamente incrementale oppure differenziale il primo job sarà sempre di tipo completo (oppure da definizione nei file di configurazione: full). Incrementale:Il backup incrementale copia solamente i files che hanno subito una modifica rispetto all ultimo backup completo oppure incrementale. Certi programmi (vedi rsync) riescono a determinare quale parte di un file è stata modificata riuscendo così ad ottimizzare l'operazione di backup. Differenziale: Il backup differenziale copia tutti i files che sono stati modificati rispetto all ultimo backup completo, senza tenere conto dei salvataggi intermedi avvenuti con la metodologia incrementale. Requisiti 3

4 Basta un sistema con GNU/Linux, noi lo abbiamo provato su Slackware 10.1 e Debian Sarge, con MySQL server per la gestione del catalogo. Avere spazio disco e risorse di sistema a sufficienza è importante, poiché come noto le procedure di backup che accedono e scrivono sui dischi in modo pesante, richiedono risorse hardware, cpu, RAM e dischi veloci. Installazione di Bacula Su Slackware 10.1 Costruire uno script per il configure #!/bin/bash YOUR_ _ADDRESS=paolo@netlink.it YOUR_SMTP_SERVER_ADDRESS=localhost./configure \ --with-mysql=/usr \ --enable-gnome \ --enable-wx-console \ --enable-tray-monitor \ --with-dump- =$your_ _address \ --with-job- =$your_ _address \ --with-smtp-host=$your_smtp_server_address Configuration on Wed May 18 16:14:54 CEST 2005: Host: i686-pc-linux-gnu -- slackware Slackware Bacula version: (22 April 2005) Source code location:. Install binaries: /sbin Install config files: /etc/bacula Scripts directory: /etc/bacula Working directory: /var/bacula/working PID directory: /var/run Subsys directory: /var/run/subsys C Compiler: gcc C++ Compiler: g Compiler flags: -g -O2 -Wall Linker flags: Libraries: -lpthread Statically Linked Tools: no Statically Linked FD: no Statically Linked SD: no Statically Linked DIR: no Statically Linked CONS: no Database type: MySQL Database lib: -L/usr/lib/mysql -lmysqlclient_r -lz Job Output Traceback SMTP Host Address: paolo@netlink.it paolo@netlink.it localhost Director Port: 9101 File daemon Port: 9102 Storage daemon Port: 9103 Director User: Director Group: Storage Daemon User: Storage DaemonGroup: File Daemon User: 4

5 File Daemon Group: SQL binaries Directory /usr/bin SQL binaries Directory /usr/bin Large file support: yes Bacula conio support: yes -ltermcap readline support: no TCP Wrappers support: no ZLIB support: yes enable-smartalloc: yes enable-gnome: yes Version 2.x enable-wx-console: no enable-tray-monitor: yes client-only: no ACL support: no # make;make install Nel caso i vostri host siano firewallati le porte su girano i servizi di bacula sono: bacula-dir 9101/tcp bacula-fd 9102/tcp bacula-sd 9103/tcp Possono essere aggiunti al file /etc/services: bacula-dir bacula-fd bacula-sd 9101/tcp # Bacula Director 9102/tcp # Bacula Client 9103/tcp # Bacula Storage Su Debian Sarge Installare il pacchetto bacula # apt-get install bacula bacula-director-common bacula-director-mysql Nel caso in cui serva solo il client ed il sistema non funga da Director allora si può insellare solo il client # apt-get install bacula-client In questo caso il demone utilizzato è solo bacula-fd. L installazione crea una directory /var/bacula/working, in cui verranno salvati log e file relativi al funzionamento del programma. Sarebbe opportuno prevedere anche un backup di questa directory. Post Installazione Occorre effettuare alcune operazioni necessarie al funzionamento del sistema come la crezione del Catalogo per Bacula, indispensabile per tracciare tutto le operazioni effettuare. 5

6 Attenzione queste procedure di configurazione e gestione si riferiscono all installazione effettuata su Slackware Per altre distribuzioni si possono verificare delle lievi differenze specie nel metodo di avvio dei diversi programmi. Creazione DB SQL e assegnazione dei permessi Creazione del Catalog per Bacula # mysqladmin create bacula # sh make_bacula_tables -p Making MySQL tables Creation of Bacula MySQL tables succeeded. # cd /etc/bacula # sh grant_mysql_privileges -p Privileges for bacula granted. Avvio di Bacula #./bacula start Starting the Bacula Storage daemon Starting the Bacula File daemon Starting the Bacula Director daemon Arresto di Bacula # /etc/bacula/bacula stop Stopping the Bacula File daemon Stopping the Bacula Storage daemon Stopping the Bacula Director daemon Verifica dello status # /etc/bacula/bacula status bacula-sd (pid ) is running... bacula-fd (pid ) is running... bacula-dir (pid ) is running... Analisi delle direttive di configurazione Illustriamo utilizzando lo schema ufficiale le varie direttive dei file di configurazione: Bacula per funzionare ha bisogno di 4 file di configurazione essenziali: bacula-dir.conf file di configurazione principale per il Director bacula-fd.conf file di configurazione principale per il Client bacula-sd.conf file di configurazione per i dispositivi di storage (File e/o DAT) bconsole.conf file di configurazione per la console di comando di bacula. 6

7 Director Config Director: Definizione di sé stesso 1. Job: Definizione di un job di backup ove vengono specificate diverse opzioni 2. Client: Nome del client da backuppare 3. Storage: Puntatore al dispositivo di backup 7

8 4. Schedule: Sta ad indicare quando il job dovrà essere eseguito e che tipo di job sarà (Completo, incrementale, differenziale) 5. FileSet: Definizione dei file da includere all'interno del backup 6. Pool: Contenitore dentro il quale si trovano i vari volumi che corrispondono ad un job precedente Catalog: Dettaglio che specifica il tipo di catalogo da usare. Ossia i dati contenuti nel database server Messages: Setup per la notifica dei job File Daemon Config Client: Definisce il nome del client e la porta dove resta in ascolto Director: Specifica il director abilitato a contattarlo Messages: Setup per la notifica del job Storage Daemon Config Storage: Definisce il nome del demone e la porta dove resta in ascolto Director: Specifica il director abilitato a contattarlo Device: Dettagli dello storage. Una direttiva per ogni dispositivo di backup Messages: Setup per la notifica del job Ecco un disegno invece che può chiarire le idee riguardo ai riferimenti di certe etichette nei file di configurazione come possono essere quelle che stanno ad indicare il director: Configurazione generale di Bacula La configurazione di Bacula per il director server prevede di manipolare tre file principali: bacula-dir.conf file di configurazione principale per il Director bacula-fd.conf file di configurazione principale per il Client 8

9 bacula-sd.conf file di configurazione per i dispositivi di Storage (File e/o DAT) Per semplicità impostare tutti i campi password con una password uguale (anche i client), per poi sostituirla con una criptata. In pratica il sistema prevede l utilizzo tre password che possono ovviamente essere diverse, ma che all inizio possono essere unificate per semplicità: Monitor { Password = "bacula" Client { Password = "bacula" Storage { Password = "bacula" password per il Director password per il FileDaemon password per lo StorageDaemon Altri file di configurazione: gnome-console.conf configurazione gnome console per accesso bconsole.conf configurazione console per accesso tray-monitor.conf configurazione monitor per accesso Per semplicità impostare tutti i campi password con una password uguale (anche i client), per poi sostituirla con una criptata. Le password di Bacula Volendo le password possono anche essere modificate secondo lo schema illustrato. Bacula-fd.conf (File Daemon) # Password per accesso al director (client) Director { Name = debian-dir Password = "bacula_dir" #password per Restricted Director usata dal tray monitor per ottenere lo stato del file daemon Director { Name = debian-mon Password = "bacula_mon" Monitor = yes Bacula-sd.conf (Storage Daemon) # password per Directors a cui è permesso di contattare lo Storage daemon # Director { Name = debian-dir Password = "bacula_dir" 9

10 #password per Restricted Director usata dal tray monitor per ottenere lo stato del file daemon Director { Name = debian-mon Password = "bacula_mon" Monitor = yes Bacula-dir.conf (Director Daemon) # password per accesso al Directory dalla console (bconsole o wxconsole) Director { # define myself Name = debian-dir Password = "bacula_mon" # Console password Messages = Daemon # password per l accesso ad ogni client Client { Name = server2 Address = FDPort = 9102 Password = "bacula_client" # password for FileDaemon In questo caso nel file bacula-fd.conf del client la password per il directory dovrà essere bacula_client. Bconsole.conf # Password per accedere al Director Director { Name = server2-dir DIRport = 9101 address = server2 Password = "bacula_mon" Ricordo che queste password sono in chiaro nei file e devono essere, per evidenti motivi di sicurezza, sostituite con password criptate, Gestione di Bacula Il controllo di bacula lo si ha utilizzando la console di bacula (bconsole), operazione che può essere fatta in diversi modi: dal sistema stesso attraverso la riga di comando bconsole in grafica sul sistema gnome console da remoto via rete usando la bconsole (*NIX) o la WX-Console (Win32) Vediamo un primo elenco dei comandi a disposizione, che permettono un controlla totale del sistema di Backup. Ogni informazione ed operazione viene archiviata e può essere visualizzata per comprendere come si sono svolte le operazioni di backup e restore. Gestione da console 10

11 #./bconsole Connecting to Director server2: OK: server2-dir Version: (22 April 2005) Enter a period to cancel a command. *help Command Description ======= =========== add add media to a pool autodisplay autodisplay [on off] -- console messages automount automount [on off] -- after label cancel cancel <job=nnn> -- cancel a job create create DB Pool from resource delete delete [pool=<pool-name> media volume=<volume-name>] estimate performs FileSet estimate, listing gives full listing exit exit = quit gui gui [on off] -- non-interactive gui mode help print this command list list [pools jobs jobtotals media <pool=pool-name> files <jobid=nn>]; from catalog label label a tape llist full or long list like list command messages messages mount mount <storage-name> prune prune expired records from catalog purge purge records from catalog quit quit query query catalog restore restore files relabel relabel a tape release release <storage-name> reload reload conf file run run <job-name> status status [storage client]=<name> setdebug sets debug level setip sets new client address -- if authorized show show (resource records) [jobs pools... all] sqlquery use SQL to query catalog time print current time trace turn on/off trace to file unmount unmount <storage-name> umount umount <storage-name> for old-time Unix guys update update Volume or Pool use use catalog xxx var does variable expansion version print Director version wait wait until no jobs are running When at a prompt, entering a period cancels the command. Attraverso i diversi comandi è possibile pilotare il nostro bacula server in tutte le se funzioni. I vari comandi sono abbastanza intuibili e semplici da utilizzare. Ma vediamone alcuni brevemente commentati: add permette di aggiungere Volumi ai Pool di backup cancel permette di cancellare uno o più job in esecuzione delete permette di eliminare un pool creato estimate permette di calcolare lo spazio occupato dai Fileset dei diversi client list permette di listare e visualizzare il contenuto di job, pools e media label permette di etichettare una cassetta prima di utilizzarla messages visualizza i messaggi sulla console mount permette di montare il dispositivo di storage prune effettua il pruning dei record dal catalog purge effettua il purge dei record dal catalog 11

12 query permette di interrogare il catalog restore permette di effettuare il restore dei nostri dati reload ricarica i file di configurazione, se modificati run permette di eseguire un job e Quindi di avviare un operazione di backup status permette di visualizzare lo status dello storage o di client show mostra la struttura del job update aggiorna lo stato dei Volumi o dei Pool Esistono una serie di comandi speciali utili nell utilizzo della bconsole:.die genera per Director to segment fault (for debugging).jobs lista tutti i job names.filesets lista tutti i fileset names.clients lista tutti i client names.msgs restituisce ogni queued messages.quit quit.exit quit Ognuno di questi comandi può avere a sua volta dei sotto comandi, con menu che si aprono in sequenza a seconda della selezione effettuata. Il loro utilizzo è abbastanza semplice ma richiede comunque un po di pratica. In particolar modo sono importanti i comandi di label e add i comandi di run e restore per l esecuzione di job di backup/restore e i comandi di list e status per visualizzare lo stato del director e dei client. Particolare attenzione e pratica va fatta con la console per il restore dei job, che va comunque provato e maneggiato con una certa sicurezza prima di mettere in produzione un bacula server. Per questo motivo vi rimando alla man page ufficiale della Bacula Console Restore Command: La bconsole viene utilizzata sulla normale console, mentre in grafica sotto Linux è disponibile la Gnome-console. Il suo utilizzo è del tutto identico alla bconsole. Per win32 esiste un client nativo che può essere scaricato a questo indirizzo: 12

13 Per la sua configurazione basta modificare durante l installazione i 3 file.conf: bacula-fd.conf dati e password per la connessione al server bacula bconsole.conf dati e password per il win client bacula (user agent) wx-console.conf dati e password per connettersi con la console e amministrare il server da remoto. Attenzione il campo password deve avere lo stesso valore di quello indicato in /etc/bacula/bacula-dir.conf: Password = "bacula" # Console password Questo programma consta di due parti: la prima è relativa all agent che permette al bacula server di effettuare il backup del client win32. In effetti Ogni sistema con Win32 (XP/2000) possiede un agent che permette di verificare lo status del backup/restore verso il suo sistema. In modo particolare è facilmente rilevabile lo status dell operazione che ci dice se il backup è andato a buon fine oppure no. la seconda è la wxconsole che è l esatto porting della bconsole per i sistemi GNU/Linux, il suo funzionamento è esattamente lo stesso, solo che se opportunamente configurata permette il controllo remoto del director, cosa che in genere si fa dallo stesso sistema localmente. In più come si può approfondire nella sezione dedicata al restore, esistono delle facilitazioni per le selezioni di menu o opzioni multiple, che semplificano le operazioni più complesse. 13

14 BACKUP Predisposizione dei file di configurazione per il BACKUP Passiamo alla configurazione del nostro director server per poi poter iniziare a effettuare i backup. In bacula-fd.conf (File Daemon Configuration file) definiscono i dati relativi al director # List Directors who are permitted to contact this File daemon # Director { Name = server2-dir Password = "bacula" # # Restricted Director, used by tray-monitor to get the # status of the file daemon # Director { Name = server2-mon Password = "bacula" Monitor = yes # # "Global" File daemon configuration specifications # FileDaemon { # this is me Name = server2-fd FDport = 9102 # where we listen for the director WorkingDirectory = /var/bacula/working Pid Directory = /var/run Maximum Concurrent Jobs = 20 # Send all messages except skipped files back to Director Messages { Name = Standard director = server2-dir = all,!skipped In bacula-sd.conf (Storage Daemon Configuration file) definiscono i device Storage { # definition of myself Name = server2-sd SDPort = 9103 # Director's port WorkingDirectory = "/var/bacula/working" Pid Directory = "/var/run" Maximum Concurrent Jobs = 20 Director { Name = server2-dir Password = "bacula" Director { Name = server2-mon Password = "bacula" Monitor = yes # Devices supported by this Storage daemon 14

15 # To connect, the Director's bacula-dir.conf must have the # same Name and MediaType. # su DISCO Device { Name = FileStorage Media Type = File Archive Device = /tmp/bacula LabelMedia = yes; # lets Bacula label unlabeled media Random Access = Yes; AutomaticMount = yes; # when device opened, read it RemovableMedia = no; AlwaysOpen = no; # A Linux or Solaris tape drive # su CASSETTA Device { Name = DDS-4 # Media Type = DDS-4 Archive Device = /dev/nst0 AutomaticMount = yes; # when device opened, read it AlwaysOpen = yes; RemovableMedia = yes; RandomAccess = no; ## Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d" ## Changer Device = /dev/sg0 ## AutoChanger = yes Alert Command = "sh -c 'tapeinfo -f %c grep TapeAlert cat'" Attenzione bacula deve avere la possibilità di scrivere sul device. In genere sulla directory /tmp non ci sono problemi in caso contrario è bene predisporre una directory scrivibile dallo user con cui viene eseguito bacula. In genere lo user è bacula, in caso contrario si possono avere dei problemi nelle operazioni di labelling dello storage su file. In bacula-dir.conf si definiscono: 1. JobDefs 2. Job 3. FileSet 4. Client 5. Storage Vediamo come effettuare le configurazioni per poter eseguire alcune procedure di backup: Backup del server Definiamo una procedura di backup per una porzione di filesystem del sistema su cui è in esecuzione il bacula server. La configurazione viene fatta in bacula-dir.conf e ad ogni modifica occorre fare un reboot del programma. Director { # define myself Name = server2-dir DIRport = 9101 # where we listen for UA connections QueryFile = "/etc/bacula/query.sql" WorkingDirectory = "/var/bacula/working" PidDirectory = "/var/run" Maximum Concurrent Jobs = 1 Password = "bacula" # Console password Messages = Daemon 15

16 JobDefs { Name = "DefaultJob" Type = Backup Level = Full Client = server2-fd FileSet = "Full Set" # quello standard Schedule = "WeeklyCycle" Storage = File Messages = Standard Pool = Default Priority = 10 Job { Name = "TEST Backup" JobDefs = "DefaultJob" Level = Full Storage = File FileSet="Full Set" Schedule = "WeeklyCycleAfterBackup" FileSet { Name = "Full Set" Include { Options { signature = MD5 File = /usr/src/arc Client { Name = server2-fd Address = server2 FDPort = 9102 Catalog = MyCatalog Password = "bacula" File Retention = 30 days Job Retention = 6 months AutoPrune = yes Storage { Name = File Address = server2 SDPort = 9103 Password = "bacula" Device = FileStorage Media Type = File # password for FileDaemon # 30 days # six months # Prune expired Jobs/Files # N.B. Use a fully qualified name here Vediamo nel dettaglio le direttive dei Job: Name = "DefaultJob" Nome del Job Type = Backup Azione Backup/Restore Level = Full Livello (Tipo) di Backup (Full, Differential e Incremental) Client = server2-fd Client per ill Job FileSet = "Full Set" nome del File Set che definisce quail data backuppare Schedule = "WeeklyCycle" nome dell intervallo di schedulazione da definire nello stesso file Storage = File tipo di storage File, se su filesystem o DDS se su DAT (ad esempio) 16

17 Messages = Standard tipologia di messaggistica, definita nello stesso file Pool = Default il pool a cui appartiene il backup Priority = 10 specifica l ordine in cui partono i backup, la loro priorità Nel caso in cui se si volesse abilitare la compressione occorre inserire nella sezione Include { del FileSet la direttiva compression=gzip: FileSet { Name = "Full Set" Include { Options { signature = MD5 compression=gzip File = /usr/src/arc Normalmente bacula non imposta Job concorrenti ma se si volesse far partire più Job insieme si può specificare il parametro in questo modo: Director { # define myself Name = server2-dir DIRport = 9101 # where we listen for UA connections QueryFile = "/etc/bacula/query.sql" WorkingDirectory = "/var/bacula/working" PidDirectory = "/var/run" Maximum Concurrent Jobs = 2 Password = "bacula" # Console password Messages = Daemon Job { Name = "TEST Backup 1" JobDefs = "DefaultJob" Maximum Concurrent Jobs = 2 Level = Full Storage = File FileSet="Full Set" Schedule = "WeeklyCycleAfterBackup" Job { Name = "TEST Backup 2" JobDefs = "DefaultJob" Maximum Concurrent Jobs = 2 Level = Full Storage = File FileSet="Full Set" Schedule = "WeeklyCycleAfterBackup".. Lo stesso tipo di rotazione si può ottenere usando la direttiva Maximum Volume Bytes, in questo caso i volumi vengono riciclati una volta raggiunta la dimensione indicata. Pool { Name = DAT Pool Type = Backup Recycle = yes AutoPrune = no # Bacula can automatically recycle Volumes # Prune expired volumes 17

18 Volume Retention = 12 h # 12 ore Accept Any Volume = yes # write on any volume in the pool RecycleOldestVolume=yes Maximum Volume Bytes= # 40GB Backup di client remoto GNU/Linux JobDefs { Name = "Debian" Type = Backup Level = Full Client = sarge01 FileSet = "Debian Set" Schedule = "WeeklyCycle" Storage = File Messages = Standard Pool = Default Priority = 10 Job { Name = "DebianJob" JobDefs = "Debian" Level = Full Storage = File FileSet="Debian Set" Schedule = "WeeklyCycleAfterBackup" FileSet { Name = "Debian Set" Include { Options { signature = MD5 File = /etc Client { Name = sarge01 Address = FDPort = 9102 Catalog = MyCatalog Password = "bacula" File Retention = 30 days Job Retention = 6 months AutoPrune = yes # password for FileDaemon # 30 days # six months # Prune expired Jobs/Files In questo caso sul client basta avviare il demone bacula-fd, dopo avere specificato i dati relativi al director della nostra rete: # vi /etc/bacula/bacula-fd.conf # List Directors who are permitted to contact this File daemon # Director { Name = server2-dir Password = "bacula" # 18

19 # Restricted Director, used by tray-monitor to get the # status of the file daemon # Director { Name = server2-mon Password = "bacula" Monitor = yes # # "Global" File daemon configuration specifications # FileDaemon { # this is me Name = server2-fd FDport = 9102 # where we listen for the director WorkingDirectory = /var/lib/bacula Pid Directory = /var/run/bacula Maximum Concurrent Jobs = 20 # Send all messages except skipped files back to Director Messages { Name = Standard director = server2-dir = all,!skipped Adesso che abbiamo specificato il nome del director (il nostro backup server), il cui nome deve essere risolto dal sistema possiamo avviare il client bacula, che ci permetterà do fare il backup del sistema Debian remoto. # /etc/indit.d/bacula-fd start Backup di client remoto Win32 Implementiamo un JobDefs apposito JobDefs { Name = "ClientJob" Type = Backup Level = Full Client = client10 FileSet = "Win Set" Schedule = "WeeklyCycle" Storage = File Messages = Standard Pool = Default Priority = 10 Job { Name = "Win" JobDefs = "ClientJob" Level = Full Storage = File FileSet="Win Set" Schedule = "WeeklyCycleAfterBackup" FileSet { Name = "Win Set" Include { Options { signature = MD5 19

20 File = C:/dispense Attenzione allo slash invece del classico back slash DOS, è necessario per poi poter sfogliare le directory Windows ed effettuare restore selettivi. Nel caso in cui ci fossero dei file o delle directory contenenti spazi nei nomi e bene racchiuderli tra virgolette. Come esempio vediamo come effettuare un classico backup della directory Documents and Settings di un client con Win2000: FileSet { Name = "Documents Set" Include { Options { signature = MD5 File = "C:/Documents and Settings/paolo" Exclude { File = "C:/Documents and Settings/paolo/Application Data" File = "C:/Documents and Settings/paolo/Cookies" File = "C:/Documents and Settings/paolo/Impostazioni locali" Anche nell effettuare il restore selettivo nel caso in cui non si riescano a sfogliare le risorse ricordiamo che si può risolvere il problema usando le virgolette nei path: $ cd "C:/Documents and Settings/" cwd is: C:/Documents and Settings/ $ dir drwxrwxrwx 1 root root :21:00 C:/Documents and Settings/paolo/ $ cd "C:/Documents and Settings/paolo/" cwd is: C:/Documents and Settings/paolo/ $ dir -rwxrwxrwx 1 root root :57:17 C:/Documents and Settings/paolo /.bash_history drwxrwxrwx 1 root root :21:02 C:/Documents and Settings/paolo/Desktop/ d-wx-wx-wx 1 root root :21:02 C:/Documents and Settings/paolo/Documenti/ -rwxrwxrwx 1 root root :57:17 C:/Documents and In alcuni casi, specie per configurazioni molto complesse può esser particolarmente utile usare gli include nei file di configurazione. E proprio in ambienti di lavoro molto grandi e con parecchi job di backup è molto probabile se non sicuro che i file di configurazione, specialmente per il director diventino molto grandi. Esiste la possibilità di spezzare quindi i file di configurazione specificandone preferibilmente uno per ogni client. Ciò è possibile utilizzando la seguente sintassi nel file di configurazione principale: ###DA METTERE IN SEZIONE COME NEI PRECENDENTI FILE Avvio dei Backup (Labelling) Prima di iniziare con i backup occorre assegnare una label al nostro Volume Storage # bconsole *label 20

21 The defined Storage resources are: 1: File 2: DDS-4 Select Storage resource (1-2): 1 Enter new Volume name: Backup_Netlink Connecting to Storage daemon File at server2:9103 Sending label command for Volume "Backup_Netlink" Slot OK label. Volume=Backup_Netlink Device=/tmp/bacula Adesso il sistema è in grado di effettuare backup a seconda dei job impostati. Dalla console locale o remota (WX-Console): 1. run 2. scegliere il job desiderato, che si ricava con il comando status 3. verificare con le mail l esito del backup Inoltre si può utilizzare il comando estimate per valutare (stimare) le dimensioni del backup da effettuare. Questo vale anche per i client remoti. Questo comando si può rivelare molto utile in fase di pianificazione del backup per comprendere i volumi impegnati. # bconsole *estimate The defined Job resources are: 1: Client1 2: BackupCatalog 3: Etc Job 4: Homepaolo Job 5: Mysql Job 6: Colt Job 7: Netlink Job 8: Labtel Job 9: Client10 Job 10: RestoreFiles Select Job resource (1-10): 9 Connecting to Client client10 at : OK estimate files=2647 bytes=705,746,623 *estimate Select Job resource (1-10): 5 Connecting to Client server2-fd at server2: OK estimate files=5519 bytes=607,164,731 Nel caso in cui si vogliano invece eliminare dei Volumi creati si può usare il comando delete, avendo molta cura nel farlo: *delete In general it is not a good idea to delete either a Pool or a Volume since they may contain data. You have the following choices: 1: volume 2: pool 3: job 4: jobid Choose catalog item to delete (1-4): 1 Defined Pools: 1: Default 2: DDS-4 Select the Pool (1-2):

22 MediaId VolumeName VolStatus VolBytes VolFiles VolRetention Recycle Slot InChanger MediaType LastWritten Netlink_DAT Append 17,727,176, ,536, DDS :13:42 4 File_BACKUP Append ,536, File :00: Enter MediaId or Volume name: File_BACKUP This command will delete volume File_BACKUP and all Jobs saved on that volume from the Catalog Are you sure you want to delete this Volume? (yes/no): yes Backup del Catalog Come si può notare facilmente bacula presenta un Job schedulato di default assolutamente fondamentale. E il Job che permette il backup del suo Catalogo, in cui sono contenute tutte le informazioni necessarie alla gestione ed al recupero dei dati contenuti negli archivi, siano essi File o Cassette. # Backup the catalog database (after the nightly save) Job { Name = "BackupCatalog" JobDefs = "DefaultJob" Level = Full FileSet="Catalog" Schedule = "WeeklyCycleAfterBackup" # This creates an ASCII copy of the catalog RunBeforeJob = "/etc/bacula/make_catalog_backup bacula bacula" # This deletes the copy of the catalog RunAfterJob = "/etc/bacula/delete_catalog_backup" Write Bootstrap = "/var/bacula/working/backupcatalog.bsr" Priority = 11 # run after main backup In questo Job si nota come sia possibile eseguire automaticamente dei comandi attraverso i file di configurazione di Bacula (RunBeforeJob), prima che venga effettuato il backup. In questo caso avviene l export del catalogo (make_catalog_backup), il suo backup secondo le politiche scelte e poi la sua rimozione dal filesystem (RunAfterJob - delete_catalog_backup). Backup su DAT Il backup su DAT prevede alcune operazioni specifiche per il tipo di supporto, diverso rispetto al classico metodo che prevede di utilizzare il filesystem. Per prima cosa è bene verificare che il DAT sia supportato e funzioni correttamente. Ovviamente bacula permette di effettuare un test di simulazione di accesso e scrittura sul supporto in modo da verificare la piena e corretta funzionalità del dispositivo. Test del DAT (supporto di backup) Aggiungere in bacula-sd.conf: 22

23 # A Linux or Solaris tape drive # Device { Name = DDS-4 Media Type = DDS-4 Archive Device = /dev/nst0 AutomaticMount = yes; AlwaysOpen = yes; RemovableMedia = yes; RandomAccess = no; # when device opened, read it Anche in bacula-dir.conf occorre specificare il volume DAT per lo Storage # Definition of DDS tape storage device Storage { Name = DDS-4 Do not use "localhost" here Address = server2 # N.B. Use a fully qualified name here SDPort = 9103 Password = "bacula" # password for Storage daemon Device = DDS-4 # must be same as Device in Storage daemon Media Type = DDS-4 # must be same as MediaType in Storage daemon # btape -c bacula-sd.conf /dev/nst0 Tape block granularity is 1024 bytes. btape: butil.c:258 Using device: "/dev/nst0" for writing. btape: btape.c:335 open_dev /dev/nst0 OK *test === Write, rewind, and re-read test === I'm going to write 1000 records and an EOF then write 1000 records and an EOF, then rewind, and re-read the data to verify that it is correct. This is an *essential* feature... btape: btape.c:786 Wrote 1000 blocks of bytes. btape: btape.c:465 Wrote 1 EOF to /dev/nst0 btape: btape.c:802 Wrote 1000 blocks of bytes. btape: btape.c:465 Wrote 1 EOF to /dev/nst0 btape: btape.c:811 Rewind OK. === Forward space files test === This test is essential to Bacula. I'm going to write five files then test forward spacing Il comando di verifica funziona solo se il device è smontato, una volta utilizzato ed etichettato (label) il dispositivo viene automaticamente montato ed utilizzato per i backup. Può essere comunque montato e smontato utilizzando i comandi mount ed umount nella bconsole. *mount 23

24 The defined Storage resources are: 1: File 2: DDS-4 Select Storage resource (1-2): Device /dev/nst0 is mounted with Volume "DAT_Backup" *umount The defined Storage resources are: 1: File 2: DDS-4 Select Storage resource (1-2): Device /dev/nst0 unmounted. Nel caso in cui il dispositivo fosse smotato il sistema ne richiede il mount per poter effettuare un backup o un restore. Nella configurazione del device DAT viene richiesto un programma (opzionale) che è bene installare, tapeinfo. Infatti nel file bacula-sd.conf si trova la direttiva Alert Command riferita proprio ad tapeinfo. Questo programma serve per la gestione degli alert nell utilizzo del DAT; Device { Name = DDS-4 Alert Command = "sh -c 'tapeinfo -f %c grep TapeAlert cat'" # wget Questo programma potrebbe non funzionare con tutti I DAT, per cui è bene disabilitare Alert Command in bacula-sd.conf. Maggiori informazioni: Configurazione per il Backup su DAT Se si cambia il supporto di Storage da file a DAT occorre impostare una label anche per il DAT: # bconsole *label The defined Storage resources are: 1: File 2: DDS-4 Select Storage resource (1-2): 2 Enter new Volume name: DAT_Backup Automatically selected Pool: Default Connecting to Storage daemon DDS-4 at server2: Sending label command for Volume "DAT_Backup" Slot 0... block.c:782 Read error at file:blk 0:0 on device /dev/nst0. ERR=Input/output error OK label. Volume=DAT_Backup Device=/dev/nst0 Catalog record for Volume "DAT_Backup", Slot 0 successfully created. Requesting to mount DDS

25 3001 OK mount. Device=/dev/nst0 Si può verificare lo stato di mount del DAT e la sua disponibilità come supporto di backup utilizzando la console per visualizzare lo status del dispositivo DAT: # bconolse *status Using default Catalog name=mycatalog DB=bacula Status available for: 1: Director 2: Storage 3: Client 4: All Select daemon type for status (1-4): 2 The defined Storage resources are: 1: File 2: DDS-4 Select Storage resource (1-2): 2 Connecting to Storage daemon DDS-4 at server2:9103 server2-sd Version: (22 April 2005) i686-pc-linux-gnu slackware Slackware Daemon started 25-Jun-05 13:06, 3 Jobs run since started. Running Jobs: No Jobs running. ==== Device status: Archive "FileStorage" is not open or does not exist. Device "/dev/nst0" is mounted with Volume "DAT_Backup" Total Bytes Read=7,354,368 Blocks Read=114 Bytes/block=64,512 Positioned at File=1 Block=114 A questo punto si possono schedulare i backup su support DAT esattamente come gli altri. JobDefs { Name = "etc" Type = Backup Level = Full Client = server2-fd FileSet = "etc Set" Storage = DDS-4 Messages = Standard Pool = Default Priority = 10 Job { Name = "etc" JobDefs = "etc" Level = Full Storage = DDS-4 FileSet="etc Set" L operazione di labelling di una cassetta può non funzionare per una serie di motivi che è bene conoscere, per evitare tentativi inutili: 25

26 il nome del Volume scelto specificate è già esistente nel nostro database la cassetta non è stata smontata la cassetta è già stata etichetta da Bacula. Bacula infatti impedisce il riutilizzo di cassetta già impiegate senza che queste siano state riciclate e rietichettate con il comando relabel. la cassetta non è caricata nel nostro dispositivo DAT Nel caso in cui si volesse riutilizzare una cassetta precedentemente utilizzata si può effettuare il relabel. Questa operazione richiede l uso del comando mt. Attraverso questo comando si può effettuare il rewind e poi marcare con un EOF la cassetta # mt -f /dev/st0 rewind # mt -f /dev/st0 weof A questo punto la si può riutilizzare associando una nuova etichetta con il comando label. In realtà questo metodo, sicuramente efficace, ma considerato un po troppo diretto, può essere sostituito con quello previsto effettivamente dal programma che comporta due successive operazioni, ovvero la prima che è quella di effettuare il purge del Volume e la seconda che vede utilizzare l apposito comando di relabel. Questo è un esempio di quello che può succedere se si cerca di effettuare il relabel di un Volum in stato di Append. *relabel The defined Storage resources are: 1: File 2: DDS-4 Select Storage resource (1-2): 2 Defined Pools: 1: Default 2: DDS-4 Select the Pool (1-2): MediaId VolumeName VolStatus VolBytes VolFiles VolRetention Recycle Slot InChanger MediaType LastWritten Netlink_DATNEW Append , DDS :00: Enter MediaId or Volume name: 8 Volume "Netlink_DATNEW" has VolStatus Append. It must be Purged or Recycled before relabeling. Enter MediaId or Volume name: 8 Configurazione per il Restore da DAT Job { Name = "Restoreetc" Type = Restore Client = server2-fd FileSet="etc Set" Storage = DDS-4 Pool = Default Messages = Standard 26

27 Where = /disco3/bacula-restores Recycling dei Volumi DAT Normalmente Bacula effettua l append dei dati sulla cassetta, senza sovrascrivere nulla. E comunque in grado di effettuare il recycling automatico dei dati contenuti sui supporti, quando questi non sono più sufficienti a contenere i dati in essi copiati. Si può anche scegliere di non farlo e di gestire un grosso numero di cassette nel nostro pool, in realtà bacula è molto efficiente nel rimuovere i dati più vecchi per mantenere quelli più recenti, sempre nella logica coerenza del processo di backup. Ci sono 3 opzioni che vanno settate nel pool per poter effettuare il recycling automatico: AutoPrune = yes permette il pruning dei volume vecchi VolumeRetention = <time> è il tempo di retention Recycle = yes bacula può effettuare il recycling automatico Ad esempio: # Default pool definition Pool { Name = Default Pool Type = Backup Recycle = yes # Bacula can automatically recycle Volumes AutoPrune = yes # Prune expired volumes Volume Retention = 365 days # one year Accept Any Volume = yes # write on any volume in the pool In questa configurazione il Volume Retention è molto alto quindi i dati salvati non verranno riciclati e nel caso di supporti esterni verranno richieste cassette aggiuntive per gestire l inevitabile incremento dei dati. Al contrario una configurazione tipica che prevede l uso di una sola cassetta e che ad ogni backup viene riscritta, ha valore di Volume Retention molto basso: Pool { Name = DDS-4 Use Volume Once = yes # questa direttive permette di riutilizzare la singola cassetta Pool Type = Backup AutoPrune = yes VolumeRetention = 12h # expire after 12 hours Recycle = yes In questo i caso ogni 12 ore i dati possono venire riciclati e sostituiti con quelli sempre più attuali. Si può comunque scegliere di usare pool con un alto numero di cassette in cui conservare i dati copiati. La sicurezza in questo caso cresce ma la gestione del backup diventa decisamente più complessa. Maggiori informazioni:

28 Gestione del Volume Status Il problema che spesso si pone è quello del riempimento del device DAT o Filesystem. Per questo occorre imparare a gestire i volumi. Ad esempio alcune opzioni permettono di dividere i volumi in base alla dimensione o al numero di file. Nella direttiva Pool: Pool { Name = Default Pool Type = Backup Recycle = yes AutoPrune = yes Volume Retention = 12h Accept Any Volume = yes Maximum Volume Bytes= Maximum Volume Files= # Bacula can automatically recycle Volumes # Prune expired volumes # write on any volume in the pool In questo caso bacula crea un nuovo volume ogni 100MB oppure ogni files, marcando il volume come Full. Lo stato di questi volumi passa da Append a Full, richiedendo una nuova operazione di label per poi continuare automaticamente i processi di backup fermi in coda. Lo stato dei volumi che in questo caso vengono gestiti e che sono già utilizzati, può essere modificato con il comando update: Parameters to modify: 1: Volume Status 2: Volume Retention Period 3: Volume Use Duration 4: Maximum Volume Jobs 5: Maximum Volume Files 6: Maximum Volume Bytes 7: Recycle Flag 8: Slot 9: InChanger Flag 10: Volume Files 11: Pool 12: Volume from Pool 13: All Volumes from Pool 14: Done La situazione dei volumi può essere vista con il comando *list media Pool: Default MediaId VolumeName VolStatus VolBytes VolFiles VolRetention Recycle Slot InChanger MediaType LastWritten FILE01 Cleaning 699,978, , File :12:43 4 FILE02 Full 699,942, , File :20:11 5 FILE03 Full 699,994, , File :32:36 28

29 6 FILE04 Append 64,788, , File :34: * Per gestire nel modo corretto il recycling dei volumi si può configurare il director in questo modo, specificando che per ogni volume si può avere solo un certo numero di job. Dopo di che in base al periodo di retention i precedenti volumi vengono riutilizzati con conseguente perdita dei dati contenuti. Configurando in bacula-dir.conf il pool in questo modo: Pool { Name = File Locale Pool Type = Backup Recycle = yes AutoPrune = no Volume Retention = 1 h Accept Any Volume = yes RecycleOldestVolume=yes Maximum Volume Jobs= 1 # Bacula can automatically recycle Volumes # Prune expired volumes # one year # write on any volume in the pool Un volume può contenere al massimo 1 job e quelli successivi vanno su altri volumi. A questo punto basta creare n volumi con il comando label e distribuire il backup sui diversi volumi. Una volta scaduto il periodo di retention viene utilizzato il successivo e finiti i volumi viene usato quello precedente come specificato dai log di bacula: 25-Aug 13:58 cittaroute-dir: Start Backup JobId 44, Job=BackupCatalog _ Aug 13:59 cittaroute-dir: Pruning oldest volume "due_vol" 25-Aug 13:59 cittaroute-dir: Pruned 1 Job on Volume "due_vol" from catalog. 25-Aug 13:59 cittaroute-sd: Recycled volume "due_vol" on device "/tmp", all previous data lost. 25-Aug 13:59 cittaroute-dir: Max Volume jobs exceeded. Marking Volume "due_vol" as Used. Per provare il funzionamento della rotazione dei volumi è sufficiente usare il comando update nella console e dare un valore di retention basso, tipo i secondo, in modo da provare con job successivi il funzionamento del sistema. Parameters to modify: 1: Volume Status 2: Volume Retention Period per modificare la retention 3: Volume Use Duration 4: Maximum Volume Jobs per modificare il numero dei job oltre i quali avviene la rotazione 5: Maximum Volume Files 6: Maximum Volume Bytes 7: Recycle Flag 8: Slot 9: InChanger Flag 10: Volume Files 11: Pool 12: Volume from Pool 13: All Volumes from Pool 14: Done Per essere certi che i volumi possano essere riciclati occorre verificare che abbiano attivo il recycle flag (valore uguale a 1): 29

30 Defined Pools: 1: Default 2: FileLocale Select the Pool (1-2): MediaId VolumeName VolStatus VolBytes VolFiles VolRetention Recycle Slot InChanger MediaType LastWritten due_vol Used 15,532, File :59:03 13 tre_vol Used 529,596, File :56: Per visualizzare i parametri di un singolo volume si può usare il comando llist in questo modo: *llist Volume=CLIENT MediaId: 108 VolumeName: CLIENT Slot: 0 PoolId: 26 MediaType: File FirstWritten: :05:52 LastWritten: :06:01 LabelDate: :00:00 VolJobs: 1 VolFiles: 0 VolBlocks: 2 VolMounts: 1 VolBytes: 69,819 VolErrors: 0 VolWrites: 2 VolCapacityBytes: 0 VolStatus: Used Recycle: 1 VolRetention: 604,800 VolUseDuration: 0 MaxVolJobs: 1 MaxVolFiles: 0 MaxVolBytes: 0 InChanger: 0 EndFile: 0 EndBlock: 83,357 Come si può notare vengono visualizzati i dati essenziali del Volume tra cui il periodo in cui è stato scritto e la sua Volume Retention. Politica avanzata per la gestione del Backup Un buon sistema per tenere sotto controllo i backup e suddividere i job in pool per i relativi sistemi della rete da backuppare, consiste appunto nel suddividere i job di backup di ogni sistema su pool diversi (specifici). In questo modo è possibile ruotare con sicurezza i volumi ed effettuare il recycling dei vecchi backup. Io consiglio una configurazione di questo tipo: Per ogni sistema definire un POOL nel file di configurazione di bacula (bacula-dir.conf) Pool { Name = SERVER2 30

31 Pool Type = Backup Recycle = yes AutoPrune = no Volume Retention = 1 week Accept Any Volume = yes Recycle Current Volume = yes Recycle Oldest Volume = yes Maximum Volume Jobs= 7 # 1 totale + 6 incrementali per volume (2 Volumi per POOL) il Volume Retention deve comunque essere inferiore ai 7 giorni. Per ogni sistema, come nel caso di Server2 si definiscono 7 Job così suddivisi su ogni singolo Volume: Lun backup totale Mar Incrementale Mer Incrementale Gio Incrementale Ven Incrementale Sab Incrementale Dom Differenziale Quindi occorre specificare che il volume al massimo può contenere 7 Jobs: Maximum Volume Jobs= 7 # 1 totale + 5 incrementali + 1 diif per volume (2 Volumi per POOL) A questo punto si può riavviare bacula-dir e procedere alle operazioni di labelling che richiedono la creazione di 2 Volumi per POOL. *label Automatically selected Storage: File Enter new Volume name: CLIENT10_02 Defined Pools: 1: Default 2: FILE 3: TEST 4: SERVER2 5: CLIENT10 6: DEBIAN-FD 7: CATALOG Select the Pool (1-7): 5 Connecting to Storage daemon File at : Sending label command for Volume "CLIENT10_02" Slot OK label. Volume=CLIENT10_02 Device=/BACULA Catalog record for Volume "CLIENT10_02", Slot 0 successfully created. Requesting to mount FileStorage cannot mount non-tape. In questo modo ogni 7 Jobs (in pratica i 7 giorni della settimana) bacula ruota sul nuovo volume, lasciando sempre ed in ogni caso integro quello della settimana precedente. In questo caso avremo due Volumi nel Pool SERVER2 chiamati FILE_01 e FILE_02. A questo punto non resta che schedulare la procedura di backup che per lo specifico JobDefs definisce come bacula opera in automatico di backup. La direttiva definita è: JobDefs { Name = "Server2 JobDefs" 31

32 Type = Backup Level =Full Client = server2 FileSet = "Server2 Set" Schedule = "Settimanale" Storage = File Messages = Standard Pool = SERVER2 Priority = 3 Così definita: Schedule { Name = "Settimanale" Run = Full mon at 1:05 # Lunedì il totale Run = Incremental tue-sun at 1:05 # mar-sab l'incrementale Run = Differential sun at 1:05 # dom il differenziale (rispetto al totale) Questa configurazione ci dà comunque sempre la garanzia di avere un backup completo a disposizione (full+incrementale+differenziale) da cui attingere per il restore. La stessa configurazione può essere resa ancora più flessibile creando nel singolo pool un Volume per ogni Job, per un totale di sette volumi più uno. In questo caso avremo: Lun backup totale (VOL 1) Mar Incrementale (VOL 2) Mer Incrementale (VOL 3) Gio Incrementale (VOL 4) Ven Incrementale (VOL 5) Sab Incrementale (VOL 6) Dom Differenziale (VOL 7) Il nuovo ciclo ricomincerebbe sull ottavo volume (su cui andrebbe comunque sempre il backup totale) per poi riciclare gli altri volumi. In questo caso il valore Maximum Volume Jobs= 1 deve essere rigorosamente impostato ad 1 solo Job per volume. Il Volume retention deve comunque essere inferiore ad un giorno. Ovviamente questa seconda scelta rende la configurazione di Bacula piuttosto complessa per reti grandi con molti sistemi per cui si verrebbero a creare molteplici POOL ognuno contenente otto volumi. Per creare rapidamente un grosso numero di Volumi si può usare il comando add: *add You probably don't want to be using this command since it creates database records without labeling the Volumes. You probably want to use the "label" command. Defined Pools: 1: SERVER2 2: CLIENT10 32

33 3: DEBIAN-FD 4: CATALOG 5: TEST 6: BACKUP-CLIENT10 7: BACKUP-DEBIAN-FD 8: BACKUP-CATALOG Select the Pool (1-8): 6 Automatically selected Storage: File Enter number of Volumes to create. 0=>fixed name. Max=1000: 8 Enter base volume name: SERVER2 Enter the starting number: 1 8 Volumes created in pool BACKUP-CLIENT10 I pool creati in questi modo possono essere analizzati *show pool Pool: name=backup-server2 PoolType=Backup use_cat=1 use_once=0 acpt_any=1 cat_files=1 max_vols=0 auto_prune=0 VolRetention=1 sec VolUse=0 secs recycle=1 LabelFormat=*None* CleaningPrefix=*None* recyleoldest=0 MaxVolJobs=1 MaxVolFiles=0 Pool: name=backup-client10 PoolType=Backup use_cat=1 use_once=0 acpt_any=1 cat_files=1 max_vols=0 auto_prune=0 VolRetention=1 sec VolUse=0 secs recycle=1 LabelFormat=*None* CleaningPrefix=*None* recyleoldest=0 MaxVolJobs=1 MaxVolFiles=0 Pool: name=backup-debian-fd PoolType=Backup use_cat=1 use_once=0 acpt_any=1 cat_files=1 max_vols=0 auto_prune=0 VolRetention=1 sec VolUse=0 secs recycle=1 LabelFormat=*None* CleaningPrefix=*None* recyleoldest=0 MaxVolJobs=1 MaxVolFiles=0 Pool: name=backup-catalog PoolType=Backup use_cat=1 use_once=0 acpt_any=1 cat_files=1 max_vols=0 auto_prune=0 VolRetention=1 sec VolUse=0 secs recycle=1 LabelFormat=*None* CleaningPrefix=*None* recyleoldest=0 MaxVolJobs=1 MaxVolFiles=0 Analisi dell andamento del Backup Si può avere un idea sui tempi dell andamento del backup usando il comando estimate che da un idea della dimensione dei volumi che si vogliono backuppare o restorare. *estimate The defined Job resources are: 1: Client1 2: RestoreFiles 3: BackupCatalog 4: Server2 Job 5: Debian Job 6: Client10 Job Select Job resource (1-6): 4 Connecting to Client server2 at : OK estimate files=74844 bytes=10,710,432,546 Durante il processo di backup si può invece usare il comando status storage *status storage Automatically selected Storage: File 33

34 Connecting to Storage daemon File at :9103 debian-sd Version: (28 February 2005) i386-pc-linux-gnu debian 3.1 Daemon started 15-Oct-05 12:06, 6 Jobs run since started. Running Jobs: Full Backup job Client10_Job JobId=73 Volume="CLIENT100001" device="/bacula" Files=1,317 Bytes=1,782,506,831 Bytes/sec=6,803,461 FDReadSeqNo=65,820 in_msg=61882 out_msg=5 fd=7 ==== Terminated Jobs: JobId Level Files Bytes Status Finished Name ====================================================================== 63 Incr 18 27,640,165 OK 15-Oct-05 01:08 Server2_Job 64 Incr 0 0 OK 15-Oct-05 01:08 Debian_Job 65 Incr 0 0 Other 15-Oct-05 01:38 Client10_Job 66 Full 1 25,813,745 OK 15-Oct-05 01:47 BackupCatalog 67 Incr 1 11,278 OK 15-Oct-05 12:07 Debian_Job 68 Full 2,247 64,098,776 OK 15-Oct-05 12:08 Debian_Job 69 Full 1 26,046,927 OK 15-Oct-05 12:08 BackupCatalog 70 Full 11, ,355,837 Error 15-Oct-05 12:11 Client1 71 Full 2,247 64,097,617 OK 15-Oct-05 12:11 Debian_Job 72 Full 2,247 64,097,644 OK 15-Oct-05 12:12 Debian_Job ==== Device status: Device "/BACULA" is mounted with Volume "CLIENT100001" Total Bytes=1,784,143,772 Blocks=27,656 Bytes/block=64,511 Positioned at File=0 Block=27,657 Masterizzazione automatica dei backup su CD bimagemgr Questa utility permette di utilizzare dei CD come supporto per i nostri backup. La sua interfaccia è stata realizzata in perl e permette di masterizzare i nostri Volume files direttamente su CD: Richiede: Un web server in Esecuzione sul nostro bacula server Un masterizzattore CD installato sul bacula server Il pacchetto cdrtools installato sul bacula server. Il perl, perl-dbi module, oltre ai moduli DBD-MySQL o alternativamente DBD- PostgreSQL In futuro si pensa di poter supportare anche la masterizzazione direttamente su DVD. Maggiori informazioni si possono reperire: Controllo dell integrità del Database Esiste un programma che permette di controllare l integrità del database di Bacula, si chiama dbcheck. # dbcheck dbcheck: invalid option -- p Usage: dbcheck [-c config] [-C catalog name] [-d debug_level] <working-directory> <baculadatabase> <user> <password> [<dbhost>] -b batch mode 34

35 -C catalog name in the director conf file -c director conf filename -dnn set debug level to nn -f fix inconsistencies -v verbose -? print this message Esempio di utilizzo in modalità batch: # dbcheck -C MyCatalog -c /etc/bacula/bacula-dir.conf bacula bacula dbcheck: dbcheck.c:155 Warning skipping the additional parameters for working directory/dbname/user/password/host. Hello, this is the database check/correct program. Modify database is Off. Verbose is Off. Please select the fuction you want to perform. 1) Toggle modify database flag 2) Toggle verbose flag 3) Check for bad Filename records 4) Check for bad Path records 5) Check for duplicate Filename records 6) Check for duplicate Path records 7) Check for orphaned Jobmedia records 8) Check for orphaned File records 9) Check for orphaned Path records 10) Check for orphaned Filename records 11) Check for orphaned FileSet records 12) Check for orphaned Client records 13) Check for orphaned Job records 14) Check for all Admin records 15) Check for all Restore records 16) All (3-15) 17) Quit Select function number: 16 Checking for Filenames with a trailing slash Found 0 bad Filename records. Checking for Paths without a trailing slash Found 0 bad Path records. Checking for duplicate Filename entries. Found 0 duplicate Filename records. Checking for duplicate Path entries. Found 0 duplicate Path records. Checking for orphaned JobMedia entries. Found 0 orphaned JobMedia records. Checking for orphaned File entries. This may take some time! Found 0 orphaned File records. Checking for orphaned Path entries. This may take some time! Aggiungendo il f viene effettuata il fix automatico delle incongruenze riscontarte: # dbcheck -f -C MyCatalog -c /etc/bacula/bacula-dir.conf bacula bacula 1) Toggle modify database flag 2) Toggle verbose flag 3) Repair bad Filename records 4) Repair bad Path records 5) Eliminate duplicate Filename records 6) Eliminate duplicate Path records 7) Eliminate orphaned Jobmedia records 8) Eliminate orphaned File records 9) Eliminate orphaned Path records 10) Eliminate orphaned Filename records 11) Eliminate orphaned FileSet records 35

36 12) Eliminate orphaned Client records 13) Eliminate orphaned Job records 14) Eliminate all Admin records 15) Eliminate all Restore records 16) All (3-15) 17) Quit Select function number: 16 Checking for orphaned File entries. This may take some time! Found 0 orphaned File records. Checking for orphaned Path entries. This may take some time! Found 349 orphaned Path records. Deleting 349 orphaned Path records. Checking for orphaned Filename entries. This may take some time! Found 2068 orphaned Filename records. Deleting 2068 orphaned Filename records. Maggiori informazioni: Interrogazione del database di Bacula La bconsole è dotata di un potente comando, il comando query che permette di interrogare il database alla ricerca di tutte le informazioni desiderate, su Volumi, Job e Backup effettuati: *query Available queries: 1: List Job totals: 2: List up to 20 places where a File is saved regardless of the directory: 3: List where the most recent copies of a file are saved: 4: List last 20 Full Backups for a Client: 5: List all backups for a Client after a specified time 6: List all backups for a Client 7: List Volume Attributes for a selected Volume: 8: List Volumes used by selected JobId: 9: List Volumes to Restore All Files: 10: List Pool Attributes for a selected Pool: 11: List total files/bytes by Job: 12: List total files/bytes by Volume: 13: List Files for a selected JobId: 14: List Jobs stored in a selected MediaId: 15: List Jobs stored for a given Volume name: Esempio di ricerca: Choose a query (1-15): 6 Enter Client Name: server JobId Client Level StartTime JobFiles JobBytes VolumeName server2 F :23:37 74,844 10,710,454,230 SERVER server2 D :05: ,109,284 SERVER server2 F :05:11 74,844 10,716,617,005 SERVER RESTORE Procedure per la definizione dei RESTORE 36

37 Per effettuare procedure di restore completo si può usare il comando run e poi specificare il JobId voluto. Ovviamente bisogna configurare i Job per il restore selettivo dei dati se questo è, come spesso capita necessario. Restore Locale Per effettuare un restore occorre definire un apposito job sempre nel file bacula-dir.conf. Job { Name = "RestoreFiles" Type = Restore Client = server2-fd FileSet="Backup Arc" Storage = File Pool = Default Messages = Standard Where = /tmp/bacula-restores Quando si effettua il restore in questo caso avviene in una subdirectory appositamente creata. Se si volesse ripristinare nella posizione originale, invece: Job { Name = "RestoreFiles" Type = Restore Client = server2-fd FileSet="Backup Arc" Storage = File Pool = Default Messages = Standard Where = / In questo caso i file vengono riposizionati a partire dalla radice. Ne caso in cui si voglia effettuare il restore di risorse windows (winxp/2000/2003) si può specificare un path locale in questo modo: Job { Name = "RestoreFiles" Type = Restore Client = client10 FileSet= Client10 Set" Storage = File Pool = Default Messages = Standard Where = /tmp/bacula-restores/c/ In questo caso l unità che viene recuperata è l unita C:. 37

38 Se si volesse restorare sul Client, ma in un'altra directory e non in quella originale come spesso capita, basta specificare un path diverso. Job { Where = /tmp/bacula-restores/c/recupero I file con il path originale verranno restorati in quella posizione. Restore remoto su un sistema Linux Volendo effettuare il restore sul client di provenienza dei dati è sufficiente specificare la direttiva client e l eventuale directory remota in cui dirottare i dati. Job { Name = "RestoreDebian" Type = Restore Client = sarge01 # è il client remoto su cui effettuare il restore FileSet="Debian Set" Storage = File Pool = Default Messages = Standard Where = /tmp/bacula-restores/debian Restore remoto su Win32 In questo caso occorre specificare il client di destinazione è la direttiva Where che va impostata a / Job { Name = "RestoreClient" Type = Restore Client = client10 FileSet="Win Set" Storage = File Pool = Default Messages = Standard Where = / Attenzione alla direttiva Where che deve essere impostata in quel modo se si vuole ottenere il completo restore a partire dal disco C del client. Se si volesse invece effettuare il restore in una directory diversa da quella originale ma sempre sul sistema remoto, si può specificare il path in questo modo: Job { Name = "RestoreClient" Type = Restore Client = client10 FileSet="Win Set" 38

39 Storage = File Pool = Default Messages = Standard Where = C:/TEMP In questo caso il percorso dei file completo verrà ricostruito sotto la directory C:/TEMP. Occorre fare attenzione che quando si effettua il mark per recuperare i file questi vengono sempre e comunque recuperati con tutta la struttura di directory con cui sono stati backuppati. In questo caso la directory backuppata D//CORSI/nrpe viene recuperata sul client Win32 remoto, in C:/TEMP/D//CORSI/nrpe, come dalla configurazione sopra impostata: server2-fd: -rwxrwxrwx :56:22 C:/TEMP/D//CORSI/nrpe/bin/NRPE_NT.exe server2-fd: -rwxrwxrwx :56:22 C:/TEMP/D//CORSI/nrpe/bin/ssleay32.dll 03-Jul 17:51 server2-sd: End of Volume at file 15 on device /dev/nst0, Volume "Netlink_DAT" Restore selettivo In realtà il modo corretto di effettuare un restore prevede l uso della bconsole e del comando restore che permettono di agire selettivamente sull archivio dei dati presenti nel volume di backup, e di selezionare solo quelli desiderati per il restore. La procedura può essere effettuata in modi differenti, ma grosso modo questa è la procedura migliore: # bconsole restore select the JobIds: 5 (Select the most recent backup for a client) Select the Client (1-3): 1 Select FileSet resource (1-3): 1 mark * exit Select Restore Job (1-4): 2 *restore First you select one or more JobIds that contain files to be restored. You will be presented several methods of specifying the JobIds. Then you will be allowed to select which files from those JobIds are to be restored. To select the JobIds, you have the following choices: 1: List last 20 Jobs run 2: List Jobs where a given File is saved 3: Enter list of comma separated JobIds to select 4: Enter SQL list command 5: Select the most recent backup for a client 6: Select backup for a client before a specified time 7: Enter a list of files to restore 8: Enter a list of files to restore before a specified time 9: Cancel Select item: (1-9): 5 Defined Clients: 1: server2-fd 2: client10 3: sarge01 Select the Client (1-3): 1 39

40 The defined FileSet resources are: 1: Backup Arc 2: Catalog 3: Full Set Select FileSet resource (1-3): JobId Level JobFiles StartTime VolumeName StartFile VolSessionId VolSessionTime F :31:39 NETLINK_backup 0 1 1,119,605, You have selected the following JobId: 73 Building directory tree for JobId Job, 81 files inserted into the tree. You are now entering file selection mode where you add (mark) and remove (unmark) files to be restored. No files are initially added, unless you used the "all" keyword on the command line. Enter "done" to leave this mode. cwd is: / $mark * 80 files marked. $count 81 total files/dirs. 80 marked to be restored. $ estimate 81 total files; 80 marked to be restored; 173,135,806 bytes. $ exit The job will require the following Volumes: NETLINK_backup 80 files selected to be restored. The defined Restore Job resources are: 1: RestoreFiles 2: RestoreArc 3: RestoreClient 4: RestoreDebian Select Restore Job (1-4): Select Restore Job (1-4): 2 Run Restore job JobName: RestoreArc Bootstrap: /var/bacula/working/restore.bsr Where: /tmp/bacula-restores Replace: always FileSet: Backup Arc Client: server2-fd Storage: File When: :51:07 Catalog: MyCatalog Priority: 10 OK to run? (yes/mod/no): yes In base alla direttiva Where ed al Client di destinazione troveremo i dati restorati La direttiva replace=always può ovviamente essere modificata come per gli altri parametri evitando magari la sovrascrittura di file più recenti con file più vecchi presenti nel backup. Le opzioni possibili sono: Select parameter to modify (1-11): 10 Replace: 40

41 1: always sovrascrive sempre (presenta dei rischi di sovrascrittura indesiderata) 2: ifnewer sovrascrive solo se il backup è più recente 3: ifolder sovrascrive solo se il backup è più vecchio 4: never non sovrascrive mai (molto protettivo) Per il restore di file da filesystem Windows (WinXP/2000), se il backup è stato fatto impostando il Fileset con i path corretti si potrà fare tranquillamente un restore selettivo selezionando i file desiderati, scelti sfogliando il filesystem. cwd is: / $ dir root root :00:00 D:/ $ cd C:/ cwd is: C:/ $ dir drwxrwxrwx 1 root root :09:33 D:/CORSI/ $ cd C:/DISPENSE/ cwd is: C:/DiSPENSE $ dir drwxrwxrwx 1 root root :47:30 c:/dispense/linux drwxrwxrwx 1 root root :47:30 c:/dispense/rete I path devono essere rigorosamente con lo slash al posto del backslash DOS. FileSet { Name = "Win Set" Include { Options { signature = MD5 File = C:/DISPENSE Restore Locale di sistemi remoti Spesso c è la necessità di effettuare il restore sul sistema locale di dati backuppati da sistemi remoti. Per poter effettuare questa operazione è sufficiente utilizzare la funzione restore in bconsole e specificare che si vuole usare come client l host locale e non l originale host remoto. *restore First you select one or more JobIds that contain files to be restored. You will be presented several methods of specifying the JobIds. Then you will be allowed to select which files from those JobIds are to be restored. To select the JobIds, you have the following choices: 1: List last 20 Jobs run 2: List Jobs where a given File is saved 3: Enter list of comma separated JobIds to select 4: Enter SQL list command 5: Select the most recent backup for a client 6: Select backup for a client before a specified time 7: Enter a list of files to restore 8: Enter a list of files to restore before a specified time 9: Cancel Select item: (1-9): 5 Defined Clients: 41

42 1: server2-fd 2: client10 Select the Client (1-3): 3 Automatically selected FileSet: Debian Set JobId Level JobFiles StartTime VolumeName StartFile VolSessionId VolSessionTime F 1, :01:20 NETLINK_backup 0 2 1,119,621, You have selected the following JobId: 92 Building directory tree for JobId Job, 1,255 files inserted into the tree. You are now entering file selection mode where you add (mark) and remove (unmark) files to be restored. No files are initially added, unless you used the "all" keyword on the command line. Enter "done" to leave this mode. cwd is: / $ mark * 1,270 files marked. $ exit Bootstrap records written to /var/bacula/working/restore.bsr The job will require the following Volumes: NETLINK_backup 1270 files selected to be restored. The defined Restore Job resources are: 1: RestoreFiles 2: RestoreArc 3: RestoreClient10 4: RestoreClient10Loc 5: RestoreDebian 6: RestoreDebianLoc Select Restore Job (1-6): 5 Run Restore job JobName: RestoreDebian Bootstrap: /var/bacula/working/restore.bsr Where: /tmp/bacula-restores/debian Replace: always FileSet: Debian Set Client: sarge01 Storage: File When: :25:56 Catalog: MyCatalog Priority: 10 OK to run? (yes/mod/no): mod Parameters to modify: 1: Level 2: Storage 3: Job 4: FileSet 5: Client 6: When 7: Priority 8: Bootstrap 9: Where 10: Replace 11: JobId Select parameter to modify (1-11): 5 The defined Client resources are: 1: server2-fd # host locale 42

43 2: client10 3: sarge01 Select Client (File daemon) resource (1-3): 1 Run Restore job JobName: RestoreDebian Bootstrap: /var/bacula/working/restore.bsr Where: /tmp/bacula-restores/debian Replace: always FileSet: Debian Set Client: server2-fd Storage: File When: :25:56 Catalog: MyCatalog Priority: 10 OK to run? (yes/mod/no): yes Job started. JobId=115 In questo caso il mio client remoto viene sostituito da server2-fd, che è il mio backup server (director). Il backup fatto sul client remoto sarge01 verrà in questo modo estratto nella directory del server locale /tmp/bacula-restores/debian. Se volessimo effettuare il restore di un client win su filesystem Linux è necessario specificare un opzione in più, ovvero portable=yes, questa opzione permette di effettuare il restore su qualsiasi filesystem. In sua assenza il restore potrà avvenire solo sul filesystem di provenienza (FAT o NTFS). FileSet { Name = "Client10 Set" Include { Options { portable=yes signature = MD5 File = "C:/cygwin" A questo punto occorre predisporre un job di restore oppure modificarne uno a mano che dirotti il restore dal client originale all host Linux di destinazione: The defined Client resources are: 1: server2-fd 2: Client10 Select Client (File daemon) resource (1-2): 1 Run Restore job JobName: Client10Restore Bootstrap: /var/bacula/working/restore.bsr Where: /disco3/bacula-restores Replace: always FileSet: Client10 Set Client: server2-fd il restore avviene sul server Linux Storage: File When: :19:28 Catalog: MyCatalog Priority: 10 OK to run? (yes/mod/no):yes In questo caso il restore viene fatto nella directory specificata dall opzione Where: /disco3/bacula-restores. Il restore avviene in questa directory: 43

44 # cd /disco3/bacula-restores/c:/cygwin # ls -la total 60 drwxrwxrwx 9 root root :00./ drwxrwxrwx 3 root root :19../ -rwxrwx--t 1 root root :12 Thumbs.db* drwxrwxrwx 2 root root :09 bin/ -rwxrwxrwx 1 root root :10 cygwin.bat* -rwxrwxrwx 1 root root :10 cygwin.ico* Consiglio di condividere via samba la directory dei restore di Bacula in modo da poter scegliere e verificare o copiare i file estratti dal restore. E possibile anche effettuare l operazione contraria ovvero effettuare il restore su WinXP/2000 di un backup Linux, esiste comunque una tabella delle compatibilità di backup/restore tra sistema source e destination che consiglio di consultare, Per questa ed altre informazioni sulla versione di bacula per Windows: Il periodo di retention per i restore Il valore di Retention, sia per i Job che per i file è determinante durante la fase di restore. In effetti questo valore rappresenta il periodo entro cui sarà possibile recuperare i file per un eventuale restore dal DB di bacula. Ipotizziamo una schedulazione settimanale per un backup: File Retention = 7 days Job Retention = 6 months AutoPrune = yes In questo caso oltre i 7 giorni i file non saranno più recuperabili dal DB di Bacula visto che ne verrà effettuato automaticamente il pruning dal DB. Per i Job, che occupano decisamente meno spazio nel DB, il periodo di retention può essere decisamente più ampio. Select FileSet resource (1-5): JobId Level JobFiles StartTime VolumeName StartFile VolSessionId VolSessionTime F 75, :44:21 SERVER ,131,014, F 75, :44:21 SERVER ,131,014, F 75, :44:21 SERVER ,131,014, F 75, :44:21 SERVER ,131,014, I :05:09 SERVER ,131,014, I :05:11 SERVER ,131,014, You have selected the following JobIds: 191,197,221 Building directory tree for JobId Building directory tree for JobId Building directory tree for JobId Jobs, 74,270 files inserted into the tree. You are now entering file selection mode where you add (mark) and remove (unmark) files to be restored. No files are initially added, unless 44

45 you used the "all" keyword on the command line. Enter "done" to leave this mode. cwd is: / Se il periodo di File Retention è di una settimana io potrò recuperare i miei backup fino ad una settimana addietro. In effetti bacula effettua il building del nostro tree utilizzando proprio questo periodo. Questo ci permette di recuperare file che sono inclusi nel periodo di retention. Attenzione quindi a fare bene la schedulazione dei backup per essere certi di avere il totale nell intervallo di retention specificato. I Job invece verranno conservati per 6 mesi, oltre i quali venogno rimossi dal Catalogo. Esistono 3 tipo di retention: File Retention: occupano molto spazio nel DB e vengono rimossi allo scadere del periodo impostato. Job Retention: occupano poco spazio e vengono rimossi allo scadere del periodo impostato. Volume Retention: fino a che questo intervallo di tempo non è scaduto I dati contenuti possono sempre essere recuperati Opzioni di restore Select Restore Job (1-7): 1 Run Restore job JobName: RestoreFiles Bootstrap: /var/bacula/working/restore.bsr Where: /disco3/bacula-restores Replace: always FileSet: Server2 Set Client: server2-fd Storage: File When: :40:12 Catalog: MyCatalog Priority: 10 OK to run? (yes/mod/no): I dati per il restore possono essere variati in modo da ottenere il restore desiderato. In modo particolare si possono modificare: Client: server2-fd FileSet: Server2 Set Storage: File Note sulle tempistiche di restore Il processo di restore può essere molto lungo specie nel caso di volumi molto grossi. Questa procedura è il tallone di achille di bacula, che richiede spesso ore per ripristinare i dati. Si può comunque seguire lo stato della procedura analizzando lo storage e lo stato di lettura (read) dei blocchi: *statu Status available for: 1: Director 2: Storage 45

46 3: Client 4: All Select daemon type for status (1-4): 2 Automatically selected Storage: File Connecting to Storage daemon File at :9103 bacula-sd Version: (28 February 2005) i386-pc-linux-gnu debian 3.1 Daemon started 24-Nov-05 14:02, 0 Jobs run since started. Running Jobs: Full Restore job Restore_Bacula JobId=532 Volume="BACKUP-VENERE0008" device="/dati/bacula" Files=0 Bytes=0 Bytes/sec=0 FDReadSeqNo=32 in_msg=31 out_msg=6 fd=5 ==== Terminated Jobs: JobId Level Files Bytes Status Finished Name ====================================================================== 522 Incr 13,728 3,903,929,866 OK 24-Nov-05 04:52 Trinity_Job 523 Incr 6 107,239,132 OK 24-Nov-05 04:54 Lsql_Job 524 Incr 16 10,977 OK 24-Nov-05 04:54 Ns_Job 525 Incr 1,734 1,346,426 OK 24-Nov-05 04:55 Ns3_Job 526 Incr ,416 OK 24-Nov-05 04:56 Smtp_Job 527 Incr ,594 OK 24-Nov-05 04:56 Relay_Job 529 Incr ,017,493 OK 24-Nov-05 04:59 Geko_Job 530 Incr 2, ,887,156 OK 24-Nov-05 05:03 Kilo_Job 528 Incr 0 0 Other 24-Nov-05 05:27 Tomcat_Job 531 Incr 858 8,488,435,741 OK 24-Nov-05 07:36 Venere_Job ==== Device status: Device "/dati/bacula" is mounted with Volume "BACKUP-VENERE0008" Total Bytes Read=8,893,495,296 Blocks Read=137,858 Bytes/block=64,512 Positioned at File=2 Block=303,431,110 Il valore Blocks Read è quello che ci indica il procedere della lettura dei dati che verranno poi ripristinati. Restore di un Backup su di un altro sistema Utilizzando il bootstrap file è possibile copiare una parte di un archivio, associato ad esempio ad uno specifico job, su di un altro archivio. Questo fiel si crea con la direttiva Write Bootstrap = "/var/lib/bacula/client1.bsr" Ecco per esempio un file di bootstrap con la mappa dell archivio: # cd /var/lib/bacula # less Client1.bsr Volume="FILE01" VolSessionId=8 VolSessionTime= VolFile=3-3 VolBlock= FileIndex= Volume="FILE01" VolSessionId=9 VolSessionTime= VolFile=3-3 46

47 VolBlock= FileIndex=1-241 Volume="CATALOG_01" VolSessionId=1 VolSessionTime= VolFile=0-0 VolBlock= FileIndex=1-558 Restore usando i bootstrap file Una funzionalità eccezionale di bacula è quella di permettere id recuperare (estrarre) i dati da un archivio partendo dal bootstrap file. La cosa migliore consiste nel predisporre la crezione di questo file per ogni Job di backup: Write Bootstrap = "/var/lib/bacula/client.bsr" Il comando che si può utilizzare direttamente dalla console del directory è bextract. La sua sintassi generica: # bextract bextract: bextract.c:177 Wrong number of arguments: Copyright (C) Kern Sibbald. Version: (28 February 2005) Usage: bextract <options> <bacula-archive-device-name> <directory-to-store-files> -b <file> specify a bootstrap file -c <file> specify a configuration file -d <nn> set debug level to nn -e <file> exclude list -i <file> include list -p proceed inspite of I/O errors -v verbose -V <volumes> specify Volume names (separated by ) -? print this message Un esempio concreto di utilizzo di un bootstrap file per il restore dei dati: # bextract -b /var/lib/bacula/client.bsr -c /etc/bacula/bacula-sd.conf FileStorage /tmp/recupero -b specifica il file di bootstrap con tutti I parametri necessari al restore -c path di configurazione dei file di bacula (bacula-sd) FileStorage è il Device (bacula-archive-device-name) da cui provengono i dati /tmp/recupero è la directory dove vengono effettivamente estratti i dati 17-Oct 19:14 bextract: End of Volume at file 1 on device /BACULA, Volume "TEST0001" 17-Oct 19:14 bextract: End of all volumes files restored. Quale è la grande utilità di questi file e di questo metodo di restore? Permette di effettuare il restore sul altri sistemi su cui sia stato installato bacula. Basta procedere in questo modo: Copiate sul server remoto (da un eventuale copia su CD) i file bacula-sd.conf il file di bootstrap relativo al client o al job specifico 47

48 ed il Volume in cui è salvato il backup Adattate il file bacula-sd.conf (direttiva FileStorage) al nuovo sistema, occorre specificare il nuovo path in cui è stato copiato il Volume. A questo punto avendo salvato tutto in una directory basta dare il comando: # bextract -b client.bsr -c bacula-sd.conf FileStorage /tmp/bacula/ Attenzione prima di eseguire questa operazione è bene leggere con cura i file di bootstrap la cui sintassi è comprensibile, ed elenca gli elementi essenziali per ricostruire un backup, o meglio i parametri necessari per il restore. In particolare occorre verificare quali siano i volumi interessati nel backup e quanti e quali vadano copiati. Questo è necessario nel caso di backup schedulati complessi (totali/differenziali/incrementali). Può darsi che per un restore completo siano necessari tutti. E anche possibile ricavare i dati da Volumi vecchi con tempi retention che magari impediscono l accesso dalla bconsole e recuperare i dati. Procedere in questo modo: # bextract -V DEBIAN-FD0002 FileStorage /tmp/bacula -c /etc/bacula/bacula-sd.conf In questo caso viene specificato con l opzione V un volume particolare da cui estrarre i dati. In pratica con i bootstrap file i dati possono comunque sempre essere recuperati anche da volumi vecchi. Maggiori informazioni: Se invece di effettuare l estrazione (extract) dei file si volesse solo listare il contenuto dei volumi, è possibile utilizzare un altro comodo comando bls: # bls Copyright (C) Kern Sibbald. Version: (28 February 2005) Usage: bls [options] <device-name> -b <file> specify a bootstrap file -c <file> specify a config file -d <level> specify debug level -e <file> exclude list -i <file> include list -j list jobs -k list blocks (no j or k option) list saved files -L dump label -p proceed inspite of errors -v be verbose -V specify Volume names (separated by ) -? print this message # bls FileStorage -b /var/lib/bacula/test.bsr -c /etc/bacula/bacula-sd.conf lista tutto il Contenuto per il pool TEST ottenuto del file di bootstrap test.bsr 48

49 # bls FileStorage -c /etc/bacula/bacula-sd.conf -V CLIENT v lista solo il contenuto del file CLIENT per recuperi da specifici volumi Con il comando bcopy è invece possibile trasferire i dati di un backup da un device ad un altro, tra quelli specificati nel file bacula-sd.conf Il comando utilizzato per la copia dell archivio è bcopy: # bcopy Copyright (C) Kern Sibbald and John Walker. Version: (28 February 2005) Usage: bcopy [-d debug_level] <input-archive> <output-archive> -b bootstrap specify a bootstrap file -c <file> specify configuration file -d <nn> set debug level to nn -i specify input Volume names (separated by ) -o specify output Volume names (separated by ) -p proceed inspite of errors -v verbose -w <dir> specify working directory (default /tmp) -? print this message Permette di trasferire da esempio daun DAT al file system, utilizzando una sintassi di questo tipo: # bcopy -d 3 DDS-4 FileStorage -b /var/lib/bacula/test.bsr -c /etc/bacula/bacula-sd.conf v TEST0001 Esiste un altro utile comando bscan, presente nella versione installata da sorgenti. Permette di effettuare la scansione dei volumi e verificarne i dati contenuti: # bscan -c /etc/bacula/bacula-sd.conf -v -V TEST0001 FileStorage -n bacula -u bacula -P bacula bscan: butil.c:258 Using device: "FileStorage" for reading. 05-Nov 21:20 bscan: Ready to read from volume "TEST0001" on device /BACULA. bscan: bscan.c:274 Using Database: bacula, User: bacula bscan: bscan.c:403 Pool record for TEST found in DB. bscan: bscan.c:417 Pool type "Backup" is OK. bscan: bscan.c:427 Media record for TEST0001 found in DB. bscan: bscan.c:445 Media type "File" is OK. bscan: bscan.c:454 VOL_LABEL: OK for Volume: TEST0001 bscan: bscan.c:472 SOS_LABEL: Found Job record for JobId: 0 05-Nov 21:20 bscan: Got EOF at file 1 on device /BACULA, Volume "TEST0001" 05-Nov 21:20 bscan: End of Volume at file 1 on device /BACULA, Volume "TEST0001" 05-Nov 21:20 bscan: End of all volumes. bscan: bscan.c:600 End of all Volumes. VolFiles=1 VolBlocks=0 VolBytes=64,532,817 Records would have been added or updated in the catalog: 1 Media 1 Pool 1 Job 2389 File 49

50 Questo comando è davvero potente, basti pensare al caso in cui i file o job siano stati eliminati dal DB (pruned /purged). I file letti dal volume in questione vengono riaggiunti al DB Catalog (added) permettendone di nuovo il ripristino dalla bconsole. Una delle sue funzioni più utili è quella di ricostruire il catalog partendo dal Volume. # bscan v -V TEST0001 -v -s -m -c /etc/bacula/bacula-sd.conf FileStorage -n bacula -u bacula -P bacula In questo caso il catalog viene riscritto utilizzando le informazioni presenti nel volume e nel bootstrap file. Restore con la WX-Console Usando la WX-Console o la Gnome Console da remoto, il restore diventa semplice e si effettua con pochi colpi di mouse. Basta scegliere la scheda Restore e cliccare su Enter Restore Mode, impostare i parametri necessari come Job, FileSet, Client e Storage e a questo punto basta selezionare il file o la directory navigando nel filesystem Windows o Linux graficamente. Il restore avverrà nella destinazione (Where) prevista dal job di Restore. Ovviamente i parametri di restore possono essere modificati a piacere, la wx-console impartirà i comandi al bacula server (opzione mod della console) e alla fine eseguirà il restore previsto. CONFIGURAZIONI AVANZATE Note sulla configurazione di Bacula Importante capire la differenza tra JobDefs e Job: JobDefs: definisce gli elementi essenziali per il Backup 50

51 Job: permette di definire maggiormente nel dettaglio il backup Per un corretto uso e debug del programma verificare l impostazione delle direttive relative alla messaggistica. Messages { Name = Standard # # NOTE! If you send to two or more addresses, you will need # to replace the %r in the from field (-f part) with a single valid # address in both the mailcommand and the operatorcommand. # mailcommand = "/sbin/bsmtp -h localhost -f \"\(Bacula\) %r\" -s \"Bacula: %t %e of %c %l\" %r" operatorcommand = "/sbin/bsmtp -h localhost -f \"\(Bacula\) %r\" -s \"Bacula: Intervention needed for %j\" %r" mail = paolo@netlink.it = all,!skipped operator = paolo@netlink.it = mount console = all,!skipped,!saved # # WARNING! the following will create a file that you must cycle from # time to time as it will grow indefinitely. However, it will # also keep all your messages if they scroll off the console. # append = "/var/bacula/working/log" = all,!skipped # Message delivery for daemon messages (no job). Messages { Name = Daemon mailcommand = "/sbin/bsmtp -h localhost -f \"\(Bacula\) %r\" -s \"Bacula daemon message\" %r" mail = paolo@netlink.it = all,!skipped console = all,!skipped,!saved append = "/var/bacula/working/log" = all,!skipped Oltre ad inviare gli esiti per posta all amministratore I log si possono consultare nel file di log sotto la directory working: # tail -f /var/bacula/working/log End time: 24-Jun :34:20 Files Expected: 0 Files Restored: 1,774 Bytes Restored: 327,690,491 Rate: KB/s FD Errors: 242 FD termination status: Error SD termination status: OK Termination: *** Restore Error *** Schedulazione dei Backup Eseguire manualmente i backup è il modo migliore per capire come funziona questo programma, ma non è ovviamente il fine ultimo. Un backup server deve lavorare silenziosamente in modo automatizzato ed efficace, garantendoci la disponibilità nel momento del restore. Ovviamente le procedure di backup, come noto, vanno studiate, pesate nei volumi e nel traffico e poi schedulate con attenzione. La politica di pianificazione di un backup non è mai cosa semplice, specie in reti complesse ed eterogenee dove un sistema di questo tipo trova il massimo della sua sfruttabilità. 51

52 E proprio sui grandi network che Bacula dà il meglio, lavorando con efficacia nel gestire un grande volume di client e di dati copiati ed eventualmente recuperati. Grande attenzione però, come già detto, va posta nella definizione della tabella temporale dei backup. In pratica nella configurazione di questo programma, per schedulare nel tempo i backup occorre definire dei cicli temporali. L opzione che ci permette di fare questo è Schedule: Schedule = "WeeklyCycle" nei JobDefs Schedule = "WeeklyCycleAfterBackup" nei Job Questa direttiva imposta per tutti i backup schedulati con questo modo (WeeklyCycle) un backup completo (full) ogni prima domenica del mese, un backup differenziale (ovvero un incrementale rispetto al totale) ogni altra domenica del mese, e il backup incrementale (rispetto al precedente totale o incrementale) per tutti gli altri giorni all ora prefissata (1:05). Schema del Backup Backup Totale - (la 1 domenica di ogni mese) Backup Incrementale1 - (ogni giorno) Backup Incrementale2 - (ogni giorno) Backup IncrementaleN - (ogni giorno) Backup Differenziale - (la 2,3,4 domenica del mese) Backup Totale - (la 1 domenica di ogni mese) Schedule { Name = "WeeklyCycle" Run = Full 1st sun at 1:05 Run = Differential 2nd-5th sun at 1:05 Run = Incremental mon-sat at 1:05 # Effettua il backup del Catalogo di bacula. Viene avviato dopo i backup dei dati Schedule { Name = "WeeklyCycleAfterBackup" Run = Full sun-sat at 1:10 Questo tipo di impostazione, che è quella che si trova già preimpostata nei file di configurazione, è piuttosto valida e sicura, permette infatti di ottimizzare le operazioni di backup lavorando sia a livello incrementale che differenziale, ma rieffettuando comunque a periodi più lunghi dei backup completi. Può ovviamente essere modificata ed adattate alle proprie esigenze, pur ricordando che è buona norma utilizzare uno schema che, sempre e comunque, preveda ad intervalli di tempo regolari un backup totale dei dati. Nel caso in cui si volesse invece agire manualmente, partendo da una politica di Job schedulati come backup Full (totali) si può tranquillamente modificare il job durante la procedura di backup e cambiare il Level del backup ad esempio verso l Incremental: Select Job resource (1-10): 3 Run Backup job JobName: Etc Job 52

53 FileSet: Etc Set Level: Full Client: server2-fd Storage: DDS-4 Pool: Default When: :27:20 Priority: 11 OK to run? (yes/mod/no): mod Parameters to modify: 1: Level 2: Storage 3: Job 4: FileSet 5: Client 6: When 7: Priority 8: Pool Select parameter to modify (1-8): 1 Levels: 1: Base 2: Full 3: Incremental 4: Differential 5: Since Select level (1-5): 3 Run Backup job JobName: Etc Job FileSet: Etc Set Level: Incremental Client: server2-fd Storage: DDS-4 Pool: Default When: :27:20 Priority: 11 OK to run? (yes/mod/no): yes In questo caso il job che prima veniva backuppato come Full (la prima volta è necessario) viene adesso backuppato come Incremental. Se osserviamo lo status del Director * status Dir Terminated Jobs: JobId Level Files Bytes Status Finished Name ========================================================== 11 Full 11,769 2,534,937,942 OK 30-Jun-05 23:49 Homepaolo_Job 12 Full 1, ,214,549 OK 01-Jul-05 00:18 Netlink_Job 13 Full 2, ,126,593 OK 01-Jul-05 00:29 Etc_Job 14 Incr 6 2,472,610 OK 01-Jul-05 00:34 Homepaolo_Job 15 Incr 0 0 OK 01-Jul-05 00:38 Netlink_Job 16 Incr 4 1,698 OK 01-Jul-05 00:39 Etc_Job Il backup ha copiato solo i file modificati dal precedente backup, totale o differenziale che sia. Se avessimo scelto differenziale il backup sarebbe stato fatto per tutti i file modificati dall ultimo backup completo (Full) e non dall ultimo incrementale. Attenzione, nel caso in cui venga schedulato un backup incrementale o differenziale, ma il sistema non trovi traccia del Full Backup di riferimento, eseguirà comunque un backup totale. A tale proposito nei log si dovrebbe trovare un indicazione di questo tipo: 26-Aug 02:09 server2-dir: No prior Full backup Job record found. 26-Aug 02:09 server2-dir: No prior or suitable Full backup found. Doing FULL backup. 53

54 I comandi di Purge e Prune Ho pensato di inserire alcune note su questi importanti e pericolosi comandi necessari nelle operazioni di rietichettature e pulizia del nostro Catalogo. Qual è la differenza tra questi comandi: Il comando prune permette di eliminare dal database vecchi record dai Jobs e dal Volume. Questo comando funziona solo sul database Catalog e non agisce sui dati, rispettando comunque il periodo di retention associato. La sintassi è: prune files jobs volume client=<client-name> volume=<volume-name> Il comando purge invece elimina i record del nostro database Catalog associati a Job o al nostro Volume. Questo comando è molto più pericoloso perché non tiene conto del periodo di retention dei dati, e può comunque eliminare dei record associati a dei dati presenti nel nostri Volumi di backup. La sintassi è: o purge jobs client=<client-name> (of all jobs) o purge volume volume=<vol-name> (of all jobs) Messaggistica e reportistica Bacula spedisce mail all utente amministratore in modo continuo per avvisare degli avvenuti backup/restore e di eventuali problemi. Gli stessi messaggi sono consultabili via bconsole con il comando messages. I log vengono comunque salvati nel file /var/bacula/working/log # tail -f /var/bacula/working/log FD termination status: OK SD termination status: OK Termination: Backup OK 01-Jul 09:57 server2-dir: Begin pruning Jobs. 01-Jul 09:57 server2-dir: No Jobs found to prune. 01-Jul 09:57 server2-dir: Begin pruning Files. 01-Jul 09:57 server2-dir: No Files found to prune. 01-Jul 09:57 server2-dir: End auto prune. Lo status dei backup sul Director e gli eventuali problemi od errori può essere meglio accertato usando il comando status Director sulla bconsole: *status Director Using default Catalog name=mycatalog DB=bacula server2-dir Version: (22 April 2005) i686-pc-linux-gnu slackware Slackware Daemon started 01-Jul-05 09:51, 2 Jobs run since started. Scheduled Jobs: Level Type Pri Scheduled Name Volume ========================================================================= ========== Incremental Backup Jul-05 01:05 Client1 Netlink_DAT Incremental Backup Jul-05 01:05 Etc Job Netlink_DAT Incremental Backup Jul-05 01:05 Mysql Job Netlink_DAT Incremental Backup Jul-05 01:05 Netlink Job Netlink_DAT Incremental Backup Jul-05 01:05 Client10 Job Netlink_DAT Incremental Backup Jul-05 01:05 Labtel Job Netlink_DAT 54

55 Incremental Backup Jul-05 01:05 Colt Job Netlink_DAT Incremental Backup Jul-05 01:05 Homepaolo Job Netlink_DAT Full Backup Jul-05 01:10 BackupCatalog Netlink_DAT ==== Running Jobs: No Jobs running. ==== Terminated Jobs: JobId Level Files Bytes Status Finished Name ======================================================================== 20 Incr 0 0 OK 01-Jul-05 01:05 Homepaolo_Job 21 Incr ,309,610 OK 01-Jul-05 01:06 Mysql_Job 22 Incr 0 0 OK 01-Jul-05 01:12 Colt_Job 23 Incr 0 0 OK 01-Jul-05 01:12 Netlink_Job 24 Incr 0 0 OK 01-Jul-05 01:12 Labtel_Job 25 Incr 0 0 OK 01-Jul-05 01:12 Client10_Job 26 Full 1 37,524,099 OK 01-Jul-05 01:13 BackupCatalog 27 Incr 922 1,664,928,796 OK 01-Jul-05 09:47 Colt_Job 28 Incr 5 12,334 OK 01-Jul-05 09:56 Etc_Job 29 Incr 0 0 OK 01-Jul-05 09:57 Client10_Job ==== Quelli indicati in alto (Scheduled Jobs), sono i nostri Job schedulati, ovvero quelli che vengono eseguiti automaticamente dal sistema ad intervalli prefissati, al Livello previsto, in questo caso quasi tutti a Incremental. La lista completa dei jobs invece la si ottiene con il comando: *list jobs JobId Name StartTime Type Level JobFiles JobBytes JobStatus etc :54:40 B F 0 0 A 2 ServerJob :03:01 B F ,135,806 T 3 WinJob :04:02 B F 128 6,863,280 T 4 etc :05:30 B F 2, ,126,868 T 5 Mysql Job :54:27 B F 5, ,367,895 T 6 Client Job :00:21 B F 2, ,965,847 T Questa tabella ci fornisce una serie di informazioni tra cui il Type, B sta per Backup ed R sta per Restore, il numero di file e di bytes copiati, e lo status del Job, T sta per Terminated, R per Running E per Error. Sicurezza e Bacula Per rendere sicuro bacula è opportuno criptare le password per la connessione tra client e director, proprio perché le password viaggiano in chiaro sulla nostra rete. E prevista una futura implementazione della criptazione dei dati in transito Per quel che riguarda il firewalling occorre aprire alcune porte in INPUT ed in OUTPUT: Director OUTPUT tcp 9101/9102/9103 INPUT tcp 9103 Client 55

56 OUTPUT tcp 9103 INPUT tcp 9102 INTERFACCE WEB Bacula WEB Indispensabile, questa comoda interfaccia per tenere sotto controllo lo stato dei job e visualizzare l andamento generale dei nostri backup (Pools e Volumes). # wget Questo programma Richiede una specifica compilazione del PHP. Su Debian basta installare i pacchetti richiesti (php4-gd, php4-pear, php4-mysql), su Slackware occorre ricompilare il PHP. Esiste comunque un file test.php che verifica che i requirements siano rispettati. Sono comunque necessari: Apache PHP (Tested with php.4.3.4) Gettext (Optional) GD 2.x TrueType (optional) Pear DB ( MySQL,SQLite or PgSQL Per la compilazione del PHP usare una sintassi simile: #./configure \ --with-mysql=/usr/local/mysql \ --with-apache=../apache_ \ --enable-track-vars \ --with-gd \ --with-zlib-dir=/usr/include \ --with-jpeg-dir=/usr/src/php /jpeg-6b \ --with-gettext=/usr/lib # make && make install Per la compilazione dai Apache usare: #./configure --prefix=/usr/lib/apache --enable-module=rewrite \ --enable-module=ssl \ --enable-module=rewrite \ --activate-module=src/modules/php4/libphp4.a \ --enable-module=so # make && make install A compilazione terminata il file test.php dovrà darvi: Checking system for dependencies... Checking gettext: YES Language support enabled Checking Pear(DB): YES Pear DB enabled Checking GD: YES GD support enabled 56

57 A questo punto siamo pronti per visualizzare in forma grafica i dati estratti dal DB MySQL di bacula. Il programma ricava i dati dal DB MySQL bacula per cui occorre specificare i parametri per poter accedervi nel file di configurazione bacula.conf. Questo programma interpreta il database MySQL di bacula ed in grado di darci l andamento di ogni singolo Job per i diversi Fileset, specificando il tipo di backup (Full o Incrementale in questo caso) ed i bytes trasferiti ogni volta. Fornisce inoltre dati riepilogativi sulla quantità totale di file e di Bytes backuppati. Per ogni Job schedulato si può creare un report specifico: Una visione d insieme dei diversi Job ed il peso in percentuale che ognuno occupa sul totale dei bytes trasferiti può essere ottenuta visualizzando il relativo grafico a Torta. 57

58 Bifi Questa utile interfaccia permette di tenere sotto controllo i vari elementi di Bacula, dai job a Client, dai Pool ai File, tutto attraverso il browser. In modo particolare si possono verificare i singoli job nell arco di tempo interessato, navigando in un comodo calendario. Risulta decisamente più utile dalla bconsole, spesso più difficile da maneggiare, ma più integrata del sistema di mail, che in alcuni casi può sembrare ridondante. Facile da installare permette una rapida visione dello status dei job evitando di accedere direttamente al sistema. 58

59 Il pacchetto è disponibile presso: Bacula Webmin Il modulo di webmin permette di effettuare i restore, selezionando attraverso della finestre i file interessati, per eventuali restore parziali. La stessa operazione è fattibile con la Gnomeconsole direttamente sul sistema Linux oppure con la WX-Console da un sistema Windows. Diciamo che attraverso questo modulo chiunque, da qualsiasi sistema munito di browser può effettuare un restore dei dati. L installazione si fa direttamente dal sistema ed è immediata. Permette anche di effettuare il test del dispositivo esterno come il DAT. Quest ultimo deve ovviamente essere smontato per permettere l accesso al dispositivo. NOTE FINALI Disaster Recovery Using Bacula Sappiamo che la procedure di Disaster Recovery si rende necessaria quando abbiamo perso completamente il sistema. Con Bacula il problema si può affrontare con una specifica procedura descritta in questo documento: In pratica la procedura permette di creare un Bacula Rescue CDROM da cui partire per recuperare i dati su DAT ed effettuare il restore dei dati in esso contenuti. 59