Truedoc

h1. Backup con Bacula

"Bacula":http://www.bacula.org/ è un potente sistema che consente la centralizzazione dei backup di varie macchine all'interno di una rete, e la gestione automatica degli stessi.

L'architettura di bacula è composta da tre componenti principali:

* il _File Daemon_, che va installato sulle macchine di cui si vuole effettuare il backup ed ha il compito di gestire i file di cui deve essere eseguito il backup.

* lo _Storage Daemon_ che va installato sulla macchina su cui è presente il dispositivo di registrazione dei dati (nastro, disco o quant'altro).

* il _Director_ che va installato su una macchina qualsiasi (ma in genere si usa quella dove sta il dispositivo di backup) e che è il servizio che controlla tutti gli altri e gestisce i backup.

Ciascuno di questi tre servizi ha un suo script di avvio ed un suo file di configurazione, come illustrato nella seguente tabella:

|_.Servizio|_.File di configurazione|_.Script di avvio|

|File Daemon|@bacula-fd.conf@|bacula-fd|

|Storage Daemon|@bacula-sd.conf@|bacula-sd|

|Director|@bacula-dir.conf@|bacula-director|

a questi si aggiuinge poi la console di comando, @bconsole@. 

h2. Installazione e configurazione

Tratteremo dell'installazione e della configurazione di base con Debian Lenny. Una delle caratteristiche di "Bacula":http://www.bacula.org/ è quella di salvare su un database il suo stato, mantenendo quello che viene chiamato dal programma stesso il _catalogo_. Il programma supporta tre tipi di database, _MySQL_, _PostgreSQL_ e _SQLite_. Dato che la versione ufficiale di Debian Lenny non aveva abilitato (per questioni di licenza con OpenSSL) il supporto per le connessioni cifrate, useremo la versione ottenuta da backports (la 5.0.2 al momento della ultima revisione di queste note) che usa _GnuTLS_. 

Per installare il necessario sul server di backup occorre anzitutto inserire la seguente riga in @/etc/apt/sources.list@: 

<pre>

deb http://www.backports.org/debian lenny-backports main contrib

</pre>

e poi installare la versione per il database scelto con:

<pre>

apt-get install bacula-director-sqlite3 bacula-sd bacula-fd

</pre>

h2. Configurazione con SSL

Con la versione 1.38 _Bacula _ha il supporto nativo per l'uso di SSL per il trasferimento dei dati. In precedenza era necessario impostare gli opportuni tunnel SSL con @stunnel@, in questo caso la cosa si semplifica leggermente. In caso di presenza di un firewall occorre comunque ricordare che la struttura di Bacula prevede che il _File Daemon_ deve poter contattare lo _Storage Daemon_ ed occorrerà pertanto prevedere gli opportuni _"pin-holes"_ per eventuali accessi dai server esterni o dalla DMZ (si presuppone ovviamente che il server di backup sia nella rete interna).

Il primo passo è quello di procurarsi i certificati necessari, questi andranno anzitutto installati sul Director per quanto riguarda tutti i vari servizi: il _Director_ stesso, che viene contattato dalla console, ed il _File Daemon_, che viene contattato dai vari File Daemon. Occorre allora anzitutto configurare l'accesso al Director definendo la relativa voce in @bacula-dir.conf@:

<pre>

Director {                            # define myself

  Name = backup1-dir

  DIRport = 9101                # where we listen for UA connections

  QueryFile]] = "/etc/bacula/scripts/query.sql"

  WorkingDirectory = "/var/lib/bacula"

  PidDirectory = "/var/run/bacula"

  Maximum Concurrent Jobs = 1

  Password = "xxx"         # Console password (lunga e complicata)

  Messages = Daemon

  TLS Enable = yes

  TLS Require = yes

  TLS CA Certificate File = /etc/ssl/certs/Truelite-cacert.pem

  TLS Certificate = /etc/ssl/certs/bacula.fi.trl-cert.pem

  TLS Key = /etc/ssl/private/bacula.fi.trl-key.pem

  TLS Verify Peer = yes

  TLS DH File = /etc/bacula/dh1024.pem

}

</pre>

in questo caso le varie direttive servono a dichiarare chiave e certificato SSL usato dal _Director_, ed indicare la CA con cui vengono verificati le connessioni dai client verso il _Director_. Devono poi essere configurate le modalità di accesso SSL client del _Director_ verso gli altri servizi indicando con quali certificato e chiave ci si vuole collegare ad essi (nel caso useremo sempre gli stessi). In particolare per le varie voci rispetto alla configurazione installata di default si dovranno inserire delle configurazioni del tipo:

<pre>

Client {

...

  TLS Enable = yes

  TLS Require = yes

  TLS CA Certificate File = /etc/ssl/certs/Truelite-cacert.pem

  TLS Certificate = /etc/ssl/certs/bacula.fi.trl-cert.pem

  TLS Key = /etc/ssl/private/bacula.fi.trl-key.pem

}

...

...

Storage {

...

  TLS Enable = yes

  TLS Require = yes

  TLS CA Certificate File = /etc/ssl/certs/Truelite-cacert.pem

  TLS Certificate = /etc/ssl/certs/bacula.fi.trl-cert.pem

  TLS Key = /etc/ssl/private/bacula.fi.trl-key.pem

}

</pre>

per ciascuna istanza di un _File Daemon_ (@Client@) o di uno _Storage Daemon_ (@Storage@).

Una volta configurato il _Director_ occorrerrà fare altrettanto per gli altri servizi, e sempre, qualora questo sia previsto (la cosa vale per il _File Daemon_) per le due direzioni, quella in cui il singolo servizio può essere contattato e quella in cui il servizio contatta un altro servizio. Si avranno pertanto in @bacula-sd.conf@ configurazioni del tipo: 

<pre>

Storage {

...

  TLS Enable = yes

  TLS Require = yes

  TLS CA Certificate File = /etc/ssl/certs/Truelite-cacert.pem

  TLS Certificate = /etc/ssl/certs/bacula.fi.trl-cert.pem

  TLS Key = /etc/ssl/private/bacula.fi.trl-key.pem

}

</pre>

per definire il certificato usato per le connessioni allo _Storage Daemon_, mentre per le connessioni effettuate verso l'esterno (in questo caso solo il _Director_ per rispondere ad interrogazioni dalla console) si dovrà mettere qualcosa del tipo:

<pre>

Director {

...

  TLS Enable = yes

  TLS Require = yes

  TLS CA Certificate File = /etc/ssl/certs/Truelite-cacert.pem

  TLS Certificate = /etc/ssl/certs/bacula.fi.trl-cert.pem

  TLS Key = /etc/ssl/private/bacula.fi.trl-key.pem

  TLS Verify Peer = yes

  TLS Allowed CN = "bacula.fi.trl"

}

</pre>

dove si richiede anche la verifica del certificato e che questo abbia uno specifico _Common Name_. La stessa configurazione si ritroverà sostanzialmente identica anche in @bacula-fd.conf@ (con @FileDaemon@ al posto di @Storage@). 

h2. Uso dell'autochanger

Perché sia possibile utilizzare un dispositivo cambianastri (quello che in gergo viene chiamato _Autochanger_), deve essere disponibile e funzionante lo script @/etc/bacula/scripts/mtx-changer@.

Normalmente i dispositivi cambianastri sono pilotati direttamente attraverso l'interfaccia SCSI, utilizzando il dispositivo generico (se avete solo il nastro SCSI questo sarà @/dev/sg0@, in generale va verificato). Per inviare i comandi viene usato un programma apposito, @mtx@, cui lo script installato di default si appoggia. Esistono però anche cambianastri pilotati con modalità diverse, nel qual caso occorrerà uno script dedicato, un esempio per un _IBM Ultrium LTO 3581 L28_, che viene comandato via @telnet@, è allegato alla pagina.

Per poter utilizzare il cambianastri si deve anzitutto segnalarne la presenza nella sezione Device del file @bacula-sd.conf@, ed indicare il file di dispositivo da usare, un possibile esempio è il seguente: 

<pre>

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/scripts/mtx-changer %c %o %S %a %d"

  Changer Device = /dev/sg1

  AutoChanger = yes

  Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'"

}

</pre>

inoltre deve essere reso noto al _Director_ che lo storage supporta l'_autochanger_; questo si fa con una analoga riga @AutoChanger = yes@ nella sua configurazione; cioè si dovrà avere dentro @bacula-dir.conf@ qualcosa del tipo: 

<pre>

Storage {

  Name = File

  Address = bacula.truelite.it   # N.B. Use a fully qualified name here

  SDPort = 9103

  Password = "xxxxxxx"

  Device = DDS-4

  Media Type = DDS-4

  Autochanger = yes

}

</pre>

Fatto questo diventa possibile usare l'attributo @slot@ nel comando @label@ da console. Con questo diventa possibile etichettare i vari nastri dell'autochanger con una serie di comandi del tipo: 

<pre>

*label slot=5

Using default Catalog name=MyCatalog DB=bacula

Automatically selected Storage: File

Enter new Volume name: Volume005

Automatically selected Pool: Default

Connecting to Storage daemon File at bacula.truelite.it:9103 ...

Sending label command for Volume "Volume005" Slot 5 ...

3301 Issuing autochanger "loaded drive 0" command.

3302 Autochanger "loaded drive 0", result is Slot 4.

3303 Issuing autochanger "unload slot 4, drive 0" command.

3304 Issuing autochanger "load slot 5, drive 0" command.

3305 Autochanger "load slot 5, drive 0", status is OK.

block.c:264 Volume data error at 0:0! Wanted ID: "BB02", got "". Buffer discarded.

3000 OK label. Volume=Volume005 Device=/dev/nst0

Catalog record for Volume "Volume005", Slot 5  successfully created.

Requesting to mount DDS-4 ...

3001 Device /dev/nst0 is mounted with Volume "Volume005"

</pre>

da ripetere per tutti i nastri disponibili. 

Una volta inizializzati i vari nastri si può rendere noto al _Director_ la presenza dei vari nastri con il comando:

<pre>

update slots scan

</pre>

h2. Come gestire manualmente i nastri

Per la rimozione dei dati presenti sui nastri si devono seguire i seguenti passi:

* rimuovere i dati dal catalogo con @purge@, scegliendo il volume da cancellare,

* inserire il nastro nel dispositivo, se si dispone dell'autochanger ed N è il numero dello slot questo si può fare con:

<pre>

/etc/bacula/scripts/mtx-changer /dev/sg1 load N

</pre> 

* cancellarne il contenuto a mano con @btape test@ o scrivendoci direttamente 

* usare @label@ per modificarne l'etichetta

Se invece si è configurato correttamente il periodo di ritenzione dei dati, sarà _Bacula_ che provvederà a cercare il primo nastro libero, posto che il periodo non sia eccessivo e lo spazio disponibile esaurito, 

Nel qual caso si potrà ridurre il periodo di ritenzione con il comando:

<pre>

update volume=VolumeXXX VolRetention=ddd

</pre>

si tenga presente che cambiare il periodo di ritenzione direttamente dentro @bacula-dir.con@f non è sufficiente in quanto questi dati sono registrati all'interno del singolo volume e non cambiano fintanto che non se ne aggiorna il valore. 

h2. Cosa fare quando si esaurisce lo spazio disponibile

La maggiore forza di "Bacula":http://www.bacula.org/ è quella, una volta configurato correttamente, di essere in grado di gestire tutta la procedura di backup in maniera automatica. In genere questo funziona correttamente senza nessun intervento manuale. L'incidente più comune che può capitare è che si esaurisca lo spazio (disco o nastro) disponibile per i backup, nel qual caso il comportamento di "Bacula":http://www.bacula.org/ è quello di bloccare i backup rispettando i termini del periodo di ritenzione dei dati impostato. 

Perciò se si desidera che i backup proseguano sovrascrivendo i vecchi dati occorrerà liberare lo spazio necessario. Questo dovrà essere fatto andando a rimuovere i dati più vecchi; per questo su può utilizzare il comando @purge@, ma occorrerà individuare opportunamente cosa rimuovere. Un esempio di utilizzo allora potrebbe essere il seguente; prima si potrà verificare lo stato dei volumi utilizzati con il comando: 

<pre>

*list volumes

Using default Catalog name=MyCatalog DB=bacula

Pool: Default

+---------+------------+-----------+-------------+----------+--------------+---------+------+-----------+-----------+---------------------+

| [[MediaId]] | [[VolumeName]] | [[VolStatus]] | [[VolBytes]]    | [[VolFiles]] | [[VolRetention]] | Recycle | Slot | [[InChanger]] | [[MediaType]] | [[LastWritten]]         |

+---------+------------+-----------+-------------+----------+--------------+---------+------+-----------+-----------+---------------------+

| 1       | Volume0013 | Full      | 13156318147 | 0        | 1814400      | 1       | 0    | 0         | File      | 2006-08-06 02:53:16 |

| 2       | Volume0014 | Full      | 15260956061 | 0        | 1814400      | 1       | 0    | 0         | File      | 2006-08-15 01:12:48 |

| 3       | Volume0015 | Full      | 10288088510 | 0        | 1814400      | 1       | 0    | 0         | File      | 2006-07-30 02:03:26 |

| 4       | Volume0016 | Full      | 28805889791 | 0        | 1814400      | 1       | 0    | 0         | File      | 2006-08-06 01:26:31 |

| 5       | Volume0017 | Full      | 14412428094 | 0        | 1814400      | 1       | 0    | 0         | File      | 2006-07-29 01:27:50 |

+---------+------------+-----------+-------------+----------+--------------+---------+------+-----------+-----------+---------------------+

</pre>

dopo di che, considerato che i dati più vecchi si trovano sul Volume0017, se potrà cancellare il contenuto con:

<pre>

* purge volume=Volume0017

This command is can be DANGEROUS!!!

It purges (deletes) all Files from a Job,

[[JobId]], Client or Volume; or it purges (deletes)

all Jobs from a Client or Volume without regard

for retention periods. Normally you should use the

PRUNE command, which respects retention periods.

</pre>

(il comando impiegherà un certo tempo per eseguire l'operazione), a questo punto si potrà verificare che il volume è diventato disponibile con:

<pre>

*list volumes

Using default Catalog name=MyCatalog DB=bacula

Pool: Default

+---------+------------+-----------+-------------+----------+--------------+---------+------+-----------+-----------+---------------------+

| [[MediaId]] | [[VolumeName]] | [[VolStatus]] | [[VolBytes]]    | [[VolFiles]] | [[VolRetention]] | Recycle | Slot | [[InChanger]] | [[MediaType]] | [[LastWritten]]         |

+---------+------------+-----------+-------------+----------+--------------+---------+------+-----------+-----------+---------------------+

| 1       | Volume0013 | Full      | 13156318147 | 0        | 1814400      | 1       | 0    | 0         | File      | 2006-08-06 02:53:16 |

| 2       | Volume0014 | Full      | 15260956061 | 0        | 1814400      | 1       | 0    | 0         | File      | 2006-08-15 01:12:48 |

| 3       | Volume0015 | Full      | 10288088510 | 0        | 1814400      | 1       | 0    | 0         | File      | 2006-07-30 02:03:26 |

| 4       | Volume0016 | Full      | 28805889791 | 0        | 1814400      | 1       | 0    | 0         | File      | 2006-08-06 01:26:31 |

| 5       | Volume0017 | Purged    | 968063348   | 0        | 1814400      | 1       | 0    | 0         | File      | 2006-08-21 11:59:28 |

+---------+------------+-----------+-------------+----------+--------------+---------+------+-----------+-----------+---------------------+

</pre>

h2. Configurazione Webacula

"Webacula":http://webacula.sourceforge.net/ è una interfaccia di gestione via Web di _Bacula_, basata su PHP e _Zendframework_, pertanto per installarla si sono preventivamente installati i seguenti pacchetti con:

<pre>

apt-get install zendframework php5-gd

</pre>

Occorre poi scaricare la versione corrente ed installarla in posizione opportuna, che potrà essere @/var/www/webacula@ o @/usr/local/share/webacula@ e i seguenti pathname saranno considerati relativi a tale directory. Le istruzioni per Debian indicate sotto @docs@ sono alquanto imprecise, prevedono operazioni non necessarie e indicano path sbagliati, pertanto e non le seguiremo direttamente.

La configurazione del programma, che indica quale tipo di database usare e le varie directory per i file temporanei, si trova nel file @application/config.ini@. In detto file vanno specificate le modalità di accesso al database, sia quello di _Bacula_ che quello proprio dell'interfaccia web. Il primo dovrà essere ripreso dalla configurazione di bacula stesso, il secondo dovrà essere creato ad hoc. Inoltre nella stessa configurazione si dovrà specificare come accedere al programma @bconsole@, ed impostare configurazioni minori, come la timezone o la lingua e la directory per i file temporanei (che deve essere scrivibile da @www-data@). 

<pre>

[general]

db.adapter = PDO_SQLITE 

db.config.dbname = /var/lib/bacula/bacula.db

def.timezone = "Europe/Rome"

bacula.sudo = ""

bacula.bconsole = "/usr/bin/bconsole"

[webacula]

db.adapter = PDO_SQLITE

db.config.dbname = /var/www/webacula/webacula.db

</pre>

<pre>

chown www-data /var/www/webacula/webacula.db

usermod -aG bacula www-data

usermod -aG ssl-cert www-data

</pre>

Per la configurazione di Apache, si sposti anzitutto il _Virtual Host_ di default in @/var/www/apache-default/@ per evitare accessi indiretti agli altri file di _Webacula_, poi si crei un _Virtual Host_ dedicato in @/etc/apache2/sites-available/webacula@, dato che per il funzionamento è necessario @mod_rewrite@ lo si dovrà abilitare con: 

<pre>

a2enmod rewrite

</pre>

la configurazione necessaria si può ottenere dal file @install/webacula.conf@ fornito con _Webacula_, senza necessità di definire un file  @.htaccess,@ in cui si abbia l'accortezza di sostituire la directory di installazione, in sostanza si potrà ottenere una configurazione comune con: 

<pre>

# [[RewriteLog]] "/var/log/httpd/rewrite.log"

# [[RewriteLogLevel]] 3

# [[SetEnv]] APPLICATION_ENV development

[[SetEnv]] APPLICATION_ENV production

Alias /webacula  /var/www/webacula/html

<Directory /var/www/webacula/html>

   [[RewriteEngine]] On

   [[RewriteBase]]   /webacula

   [[RewriteCond]] %{REQUEST_FILENAME} -s [OR]

   [[RewriteCond]] %{REQUEST_FILENAME} -l [OR]

   [[RewriteCond]] %{REQUEST_FILENAME} -d

   [[RewriteRule]] ^.*$ - [NC,L]

   [[RewriteRule]] ^.*$ index.php [NC,L]

   php_flag magic_quotes_gpc off

   php_flag register_globals off

   Options Indexes [[FollowSymLinks]]

   [[AllowOverride]] All

   Order deny,allow

#   [[AuthType]] Basic

#   [[AuthName]] "Webacula"

#   [[AuthUserFile]]       /etc/httpd/conf/webacula.users

#   Require valid-user

</Directory>

</pre>