L'ensemble des informations sont extraites de la documentation officielle de BACULA (http://www.bacula.org/fr/rel-manual)

Bacula est une solution de sauvegarde très complète permettant de répondre précisément à de nombreux besoins. Elle est composée de divers éléments qui peuvent être installés sur plusieurs machines afin de répartir les traitements, mais surtout afin de s'adapter à une infrastructure déjà existante.

Nous verrons dans ce document les différents constituants de Bacula, comment l'installer ?, le configurer ? mais surtout comment Bacula peut répondre à des besoins particuliers comme le scripting, la reprise de tâches après échec ? etc. Je tenterais d'expliquer comment Bacula peut répondre à des besoins tels que le backup mutualisé qui peut être utilisé chez certain hébergeur.

Bacula repose sur 5 composants (ou services) :

• Bacula Director ou DIR : est le programme qui supervise toutes les opérations de sauvegarde, de restauration, de vérification et d'archivage. L'administrateur système utilise le Bacula Director pour planifier les sauvegardes et restaurer les fichiers.

• Bacula Console : est le programme qui permet à l'administrateur ou à l'utilisateur de communiquer avec le Bacula Director. Il existe plusieurs consoles disponibles, cependant celle qui propose le plus de possibilités est la Console Shell.

• Bacula File ou FD (File Daemon) : est le programme installé sur la machine qui doit être sauvegardée. Il est spécifique au système d'exploitation sur lequel il est exécuté. Il est aussi chargé des propriétés des fichiers lors de la restauration.

• Bacula Storage ou SD (Storage Daemon) : est le programme qui gère les médias (bande de sauvegarde, disque dur…) qui vont accueillir les sauvergardes.

• Le Catalogue : est un index en base de données qui répertorie l'ensemble des fichiers sauvegardés. Il est très utile lors de la restauration car il localise rapidement les données à restaurer.

La méthode utilisant les packages de la distribution me paraît la plus simple. C'est ce que je recommande. Cela va vous permettre de gagner du temps. Cependant vous n'aurez pas forcément les derniers packages. Suivant la distribution que vous utilisez, vous n'aurez pas exactement le même nom de package.

apt-get install bacula-fd bacula-sd  bacula-director-mysql bacula-console

utiliser la commande rpm -Uvh <package>.rpm

• mysql (source : opendoc.net) :
  • bacula-client-5.0.3-1.i386.rpm
  • bacula-debuginfo-5.0.3-1.i386.rpm
  • bacula-libs-5.0.3-1.i386.rpm
  • bacula-mysql-5.0.3-1.i386.rpm
  • bacula-updatedb-5.0.3-1.i386.rpm

• sqlite (source : pbone.net ) :
  • bacula-5.0.3-1.el5.pp.i386.rpm
  • bacula-server-sqlite-5.0.3-1.el5.pp.i386.rpm
  • bacula-client-5.0.3-1.el5.pp.i386.rpm
  • bacula-console-5.0.3-1.el5.pp.i386.rpm

• mysql (source : opendoc.net) :
  • bacula-updatedb-5.0.3-1.x86_64.rpm
  • bacula-client-5.0.3-1.x86_64.rpm
  • bacula-libs-5.0.3-1.x86_64.rpm
  • bacula-mysql-5.0.3-1.x86_64.rpm

• sqlite (source : pbone.net) :
  • bacula-5.0.3-1.el5.pp.x86_64.rpm
  • bacula-server-sqlite-5.0.3-1.el5.pp.x86_64.rpm
  • bacula-client-5.0.3-1.el5.pp.x86_64.rpm
  • bacula-console-5.0.3-1.el5.pp.x86_64.rpm

• Installation de votre SGBD ¹⁾ préféré : MySQL, SQLite, PostgreSQL…

• Récupération de Bacula :

  wget "http://downloads.sourceforge.net/bacula/bacula-2.4.3.tar.gz"

  /!\ Attention cette version est obsolete.

• Installation de Bacula : dans notre cas, nous allons utiliser le DIR, le SD, la console et le SQL sur la même machine.

./configure --prefix=/usr --sbindir=/usr/sbin--sysconfdir=/etc/bacula --with-scriptdir=/etc/bacula --with-mysql --with-working-dir=/var/bacula --with-pid-dir=/var/run --with-subsys-dir=/var/lock/subsys --enable-smartalloc  --enable-conio --with-baseport=9101

–enable-smartalloc : Permet l'inclusion du code Smartalloc de détection de tampons orphelins (NDT : orphaned buffer). Cette option est vivement recommandée car elle aide à détecter les fuites de mémoire. Ce paramètre est utilisé lors de la compilation de Bacula.

–enable-conio : Cette option permet la compilation d'une petite et légère routine en alternative à readline, beaucoup plus facile à configurer, même si elle nécessite aussi les librairies termcap ou ncurses.

–with-baseport=9101 : : Notez que le port est fixé à 9101, ce qui signifie que Bacula utilisera le port 9101 pour la console Director, le port 9102 pour le File Daemon, et le 9103 pour le Storage Daemon. Ces ports devraient être disponibles sur tous les systèmes étant donné qu'ils ont été officiellement attribués à Bacula par l'IANA ²⁾. Il est fortement recommandé de n'utiliser que ces ports pour éviter tout conflit avec d'autres programmes. Ceci est en fait la configuration par défaut si vous n'utilisez pas l'option –with-baseport.

• finir par :

make 
make install

Pour démarrer automatiquement les services SD et DIR :

make install-autostart-sd
make install-autostart-dir

Il faut récupérer la même archive : wget “http://downloads.sourceforge.net/bacula/bacula-2.4.3.tar.gz“
Après l'avoir détarer nous allons installer seulement le File Daemon (FD) pour le client :

./configure --enable-client-only
make
make install
make install-autostart-sd

Récupérer l'exécutable (http://downloads.sourceforge.net/bacula/winbacula-2.4.3.exe) et sélectionner l'installation “client”. Exécuter le binaire et répondre aux questions (je ne m'y attarderais pas car c'est très facile).

La configuration du Client (ou File Daemon) est l’une des plus simples à effectuer. En principe, vous n’aurez rien à modifier au fichier par défaut en dehors du nom du Client afin d’identifier clairement les messages d’erreur.

• Director : pour définir le nom du Director et son mot de passe.
• File Daemon : pour définir le nom du client.
• Messages : pour définir où les messages d’erreur et d’information doivent être envoyés.

Director 	{
  		Name = BACULA_DIR
  		Password = "82c3600c04db8048a761be36a43f55c3"
		}

FileDaemon 	{                          # this is me
  		Name = CLIENT_1
  		FDport = 9102                  # where we listen for the director
  		WorkingDirectory = /var/bacula/working
  		Pid Directory = /var/run
  		Maximum Concurrent Jobs = 20
		}

Messages 	{
  		Name = Standard
  		director = BACULA_DIR = all, !skipped, !restored
		}

Lors de l'installation de l'agent pour windows, il faut indiquer les mêmes informations.

• démarrer la base sql :

  • /etc/init.d/mysqld start

• connectez-vous avec un utilisateur ayant suffisamment de droit :

  •  mysql -u root -p 

• créer la base bacula :

  • create database bacula

• créer l'utilisateur bacula ayant tous les droits sur cette base :

  • grant all privileges on bacula.* to 'bacula'@'localhost' identified by 'bacula';

• créer le contenu de la base :

  • /etc/bacula/make_mysql_tables;

Nous abordons ici la configuration du Storage Daemon. Il est question de déclarer les éléments qui vont permettre le stockage des données (bande, disque, DVD…). 4 rubriques doivent apparaître :

• Storage : Pour définir le nom du Storage Daemon.
• Director : Pour définir le nom du Director et le mot de passe.
• Device : Pour définir les caractéristiques du périphérique de stockage.
• Messages : Pour définir où les messages d’erreur et d’information doivent être expédiés

Storage 	{                         
  		Name = BACULA_SD
  		SDPort = 9103                       
  		WorkingDirectory = "/var/bacula"
  		Pid Directory = "/var/run"
  		Maximum Concurrent Jobs = 20
		}

Director 	{
  		Name = BACULA_DIR
  		Password = "82c3600c04db8048a761be36a43f55c3"
		}

Device 		{
  		Name = File_storage
  		Media Type = File
  		Archive Device = /home/backup/
  		LabelMedia = yes;                   # lets Bacula label unlabeled media
  		Random Access = Yes;
  		AutomaticMount = yes;               # when device opened, read it
  		RemovableMedia = no;
  		AlwaysOpen = no;
		}

Messages 	{
  		Name = Standard
  		director = BACULA_DIR = all
		}

Parmi tous les fichiers de configuration requis pour exécuter Bacula, celui du Director est le plus compliqué, et c’est celui que vous modifierez le plus souvent, en y ajoutant des clients ou en modifiant les FileSets.

voici les informations obligatoires :

• Director : Pour définir le nom du Director et son mot de passe pour authentification du programme Console. Il ne doit y avoir qu’une seule définition de ressource Director dans le fichier de configuration.

• Job : Pour définir les Jobs de types sauvegarde et restauration, et pour lier les ressources Client, FileSet et Schedules à utiliser conjointement pour chaque Job.

• Schedule : Pour définir le moment où un Job doit être lancé automatiquement par le scheduler interne de Bacula.

• FileSet : Pour définir l’ensemble des fichiers à sauvegarder pour chaque client.

• Client : Pour définir quel Client est à sauvegarder.

• Storage : Pour définir sur quel périphérique physique les volumes seront montés.

• Pool : Pour définir quel pool de volumes peut être utilisé pour un Job donné.

• Catalog : Pour définir la base de données où sont conservées les listes des fichiers sauvegardés et les volumes utilisés.

• Messages : Pour définir les destinataires (ou les fichiers de logs) des messages d’erreur et d’information.

Director 	{                            
  		Name = BACULA_DIR
  		DIRport = 9101                
  		QueryFile = "/etc/bacula/query.sql"
  		WorkingDirectory = "/var/bacula"
  		PidDirectory = "/var/run"
  		Maximum Concurrent Jobs = 1
  		Password = "82c3600c04db8048a761be36a43f55c3"         # Console password
  		Messages = Daemon
		}

Job     	{
                Name = "backup_client_1"
                Type = Backup
		Level = Full
                Client = CLIENT_1
                FileSet = "File set CLIENT_1"
		Schedule = "WeeklyCycle"
                Storage = BACULA_SD              
                Pool = Default
		Write Bootstrap = /var/bacula/client_1.bsr
                Messages = Standard
        	}

FileSet         {
                Name = "File set CLIENT_1"
                Include         {
                                Options {
                                        signature = MD5
                                        }
                                        File = /
                                }

                Exclude 	{
                        	File = /proc
                        	File = /tmp
                        	File = /.journal
                        	File = /.fsck
                        	}
                }	

Schedule 	{
  		Name = "WeeklyCycle"
  		Run = Full 1st sun at 23:05
  		Run = Differential 2nd-5th sun at 23:05
  		Run = Incremental mon-sat at 23:05
		}

Client 		{
  		Name = CLIENT_1
  		Address = 172.16.176.20
  		FDPort = 9102
  		Catalog = MyCatalog
  		Password = "82c3600c04db8048a761be36a43f55c3"          # password for FileDaemon
  		File Retention = 30 days            # 30 days
  		Job Retention = 6 months            # six months
  		AutoPrune = yes                     # Prune expired Jobs/Files
		}

Storage         {
                Name = BACULA_SD # Do not use "localhost" here    
                Address = stor.dom.loc              # N.B. Use a fully qualified name here
                SDPort = 9103
                Password = "82c3600c04db8048a761be36a43f55c3"
                Device = Storage_clients
                Media Type = File
                }


Catalog 	{
  		Name = MyCatalog
  		dbname = "bacula"; dbuser = "bacula"; dbpassword = "bacula"
		}

Messages 	{
  		Name = Daemon
  		mailcommand = "/usr/sbin/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula daemon message\" %r"
  		mail = root@localhost = all, !skipped
  		console = all, !skipped, !saved
  		append = "/var/bacula/log" = all, !skipped
		}

Vous allez déterminer ici comment joindre vos différents Files Daemon.

Client 		{
  		Name = CLIENT_1
  		Address = 172.16.176.20
  		FDPort = 9102
  		Catalog = MyCatalog
  		Password = "82c3600c04db8048a761be36a43f55c3"          # password for FileDaemon
  		File Retention = 30 days            # 30 days
  		Job Retention = 6 months            # six months
  		AutoPrune = yes                     # Prune expired Jobs/Files
		}

Le filset permet de déterminer ce que l'on souhaite sauvegarder.

FileSet         {
                Name = "File set CLIENT_1"
                Include         {
                                Options {
                                        signature = MD5
                                        compression = GZIP
                                        }
                                        File = /
                                        File = /var/backup/db-mysql/
                                }

                Exclude 	{
                        	File = /proc
                        	File = /tmp
                        	File = /.journal
                        	File = /.fsck
                        	}
                }

Vous pouvez très bien créer un filset par client mais aussi vous pouvez créer un filset “générique” si vous avez des machines identiques et réutiliser ce filset pour plusieurs jobs.

filset Windows

FileSet         {
                Name = "win-filset"
                Include         {
                                Options {
                                        signature = MD5
                                        compression = GZIP
                                        }
                                        File = "C:\\Documents and Settings"
                                        File = "E:\\"
                                }

                }

Vous allez indiquer ici comment contacter le(s) Storage Daemon.

Storage         {
                Name = BACULA_SD    
                Address = stor.dom.loc  
                SDPort = 9103
                Password = "82c3600c04db8048a761be36a43f55c3"
                Device = File_storage
                Media Type = File
                }

A travers le “Pool”, Bacula gère la durée de validité des données. Vous allez me dire mais pourquoi faire ? Suivant le plan de sauvegarde que vous serez amené à choisir, vous allez déterminer ce que vous allez sauvegarder, jusqu'à combien de temps vous souhaitez revenir en arrière, et ce que vous êtes potentiellement prêt à perdre.

Plusieurs niveaux de sauvegarde s'offre à vous :

• Totale : cela peut être considéré comme un point d'arrêt. C'est une image “valide” (cela reste relatif, les données peuvent être modifiées pendant la sauvegarde) d'un moment T.

• Différentiel : la différence entre T et T+1 sera sauvegardée. Potentiellement, au file du temps cette différence peut être plus grande que le contenu du backup total. Le backup est plus long car plus volumineux mais l'avantage est que lors de la restauration il faut seulement le contenu du backup total et de la dernière différentielle.

• Incrémentiel : la différence entre Tn+2 et Tn+1 sera sauvegardée. Le backup est plus court mais la restauration nécessite les T+n backup entre notre dernière totale et le moment où l'on souhaite restaurer.

Maintenant que nous savons cela, vous comprendrez qu'il est important d'utiliser ces 3 niveaux afin d'ajuster au mieux la capacité de restauration (ex : 1 an) et la place occupée qui n'est pas infinie.

Voici un exemple de configuration :

Pool            {
                Name = pool-full
                Pool Type = Backup
                Recycle = yes
                AutoPrune = yes
                Volume Retention = 365 days
                #Storage = BACULA-SD-LOC         
                #label Format = full-
                }

Pool            {
                Name = pool-incre
                Pool Type = Backup
                Recycle = yes                      
                AutoPrune = yes
                Volume Retention = 90 days
                #Maximum Volume Jobs = 2
                #Storage = BACULA-SD-LOC
                #Label Format = incre-
                }

Pool            {
                Name = pool-diff
                Pool Type = Backup
                Recycle = yes
                AutoPrune = yes
                Volume Retention = 30 days
                #Maximum Volume Jobs = 2
                #Storage = BACULA-SD-LOC
                #Label Format = diff-
                }

Je ne dis pas que cela va répondre à votre besoin. La durée de validitée de ma Totale (Full) est donc d'un an. Ensuite il faut jongler entre la DIFF et l'INCRE. Si vos données bougent beaucoup, un backup incrémentiel régulier peut être une bonne solution car cela permettra de créer un potentiel versioning avec une période assez longue. Le backup DIFF est pratiqué moins souvent et c'est pour moi de la restauration de masse rapide. Mais cela dépend encore de vos besoins.

La section job permet de faire le lien entre les différents éléments que nous avons configuré précédemment.

1. le Client
2. le FileSet
3. le Storage
4. le Pool

Il existe deux types de jobs :

1. sauvegarde
2. restauration

sauvegarde : Comme vous pouvez le constater, il existe d'autres paramètres lors de la sauvegarde, comme le “Level” qui détermine le niveau du backup (full, diff, incre). Si aucun niveau est spécifié lors du lancement du job, le “level” par défaut est celui défini par le fichier de configuration. L'option “Priority” permet de gérer les priorités entre les différentes sauvegardes concurrentes. Plus le chiffre est faible, plus la priorité est haute.

Job     	{
                Name = "backup_client_1"
                Type = Backup
		Level = Full
                Client = CLIENT_1
                FileSet = "File set CLIENT_1"
		Schedule = "WeeklyCycle"
                Storage = BACULA_SD              
                Pool = pool-full
		Write Bootstrap = /var/bacula/client_1.bsr
                Messages = Standard
                Priority = 20
        	}

restauration :

Job {
  Name = "restore-client_1"
  Client = CLIENT_1
  Pool = pool-full
  Storage = BACULA_SD
  Type = Restore
  FileSet="File set CLIENT_1"
  Messages = Standard
  Where = /home/client_1/restore/
}

Comme vous pouvez le constater le job est de type “restore”. Si ce job est lancé, la restauration aura lieu sur le client nommé “CLIENT_1” dans le répertoire /home/client_1/restore/ .

Vous allez pouvoir déterminer le déclenchement de vos sauvegardes.

Schedule {
  Name = "WeeklyCycle"
  #Run = Level=Full Pool=pool-full 1st sun at 23:00
  Run = Level=Differential Pool=pool-diff 2nd-4th sun at 03:00
  Run = Level=Incremental Pool=pool-incre mon-sat at 03:00
}

Je ne planifie pas le backup FULL car il est fait manuellement (voir console Bacula). Cependant, je planifie un backup différentiel le deuxième et quatrième dimanche de chaque mois avec son pool associé. Je planifie un backup incrémentiel du lundi au samedi de chaque semaine avec son pool associé.

Dans certains cas il peut être utile d'interagir avec le système avant ou après la sauvegarde. Dans le cas où nous souhaitons sauvegarder le répertoire /var/www/ nous pourrions très bien stopper le service web avant de sauvegarder et redémarrer le service une fois la sauvegarde réalisée. Bacula implémente cette notion. Il suffit d'indiquer le script à exécuter sur l'hôte distant et lui donner en paramètre les bons arguments.

Job             {
                Name = "Backupweb"
                Type = Backup
                Level = Full
                FileSet="web"
                Schedule = "WeeklyCycleAfterBackup"
                Client = SRV_BACKUP
                RunBeforeJob = "/etc/init.d/httpd stop"
                RunAfterJob  = "/etc/init.d/httpd start"
                Write Bootstrap = "/var/bacula/web.bsr"
                Storage = BACULA_SD
                Pool = Default
                Messages = Standard
                Priority = 11                   # run after main backup
                }

Comme vous l'avez compris cela peux fonctionner avec tous les services (sql, samba …)

Il y a une option très pratique : “JobDefs”. Imaginer que vous ayez plus job utilisant des instructions communes (type, level, storage). Vous pouvez regrouper ces instructions de la manière suivante :

JobDefs {
   Name = "job-defs-1"
   Type = Backup
   Level = Full
   Schedule = "WeeklyCycle"
   Storage = local-file-str
   Messages = Standard
   Pool = pool-full
   }

Vous maintenant retirer les doublons dans vos instruction de “Job” et y ajouter “JobDefs = job-defs-1”.

De base la console shell doit être correctement configuré. Pour en être certain, assurez vous de la cohérence de données dans le fichier du director et le fichier de console. Exemples :

fichier de conf : /etc/bacula/bconsole.conf

Director {
  Name = nom_du_director
  DIRport = 9101
  address = xxx.xxx.xxx.xxx
  Password = "password du director"
}

Après avoir lancer votre SGBD et les différents services de Bacula, tapez /usr/sbin/bconsole , le menu qui va apparaître permettra la gestion des tâches de sauvagardes et restaurations. Voici quelques commandes :

Pour lancer un job manuellement, il faut tout d'abord lancer la console /usr/sbin/bconsole . Tapez la commande run et choisissez le numéro de job correspondant à votre sauvegarde. Vous pouvez taper la commande status et choisissez un des daemon de bacula dont vous souhaitez obtenir les informations.

[root@srv_backup ~]# bconsole
Connecting to Director dir.dom.loc:9101
1000 OK: BACULA_DIR Version: 2.4.3 (10 October 2008)
Enter a period to cancel a command.
*run
Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"
A job name must be specified.
The defined Job resources are:
     1: BackupCatalog
     2: Backupweb
     3: backup_client_1
     4: backup_client_2
     5: restore_client_1
     6: restore_client_2
Select Job resource (1-6): 1
Run Backup job
JobName:  BackupCatalog
Level:    Full
Client:   SRV_BACKUP
FileSet:  Catalog
Pool:     Default (From Job resource)
Storage:  BACULA_SD (From Job resource)
When:     2009-01-14 09:44:33
Priority: 11
OK to run? (yes/mod/no): yes
Job queued. JobId=120

Pour restaurer avec bacula il faut taper la commande restore dans la console. Un menu apparaît vous permettant de sélectionner votre numéro de Job de plusieurs manières.

[root@srv_backup ~]# bconsole
Connecting to Director dir.dom.loc:9101
1000 OK: BACULA_DIR Version: 2.4.3 (10 October 2008)
Enter a period to cancel a command.
*restore
Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"

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: Find the JobIds of the most recent backup for a client
    10: Find the JobIds for a backup for a client before a specified time
    11: Enter a list of directories to restore for found JobIds
    12: Cancel

Il peut être intéressant de choisir le numéro 5 car il détermine la sauvegarde la plus récente pour un client.

Select item:  (1-12): 5
Defined Clients:
     1: CLIENT_1
     2: CLIENT_2
     3: SRV_BACKUP

Sélectionner le client que le l'on souhaite restaurer

Select the Client (1-3): 2
Automatically selected FileSet: File set CLIENT_2
+-------+-------+----------+------------+---------------------+------------------+
| JobId | Level | JobFiles | JobBytes   | StartTime           | VolumeName
|
+-------+-------+----------+------------+---------------------+------------------+
|    40 | F     |      268 | 16,139,189 | 2008-12-29 17:04:10 |
bacula_sd_volume |
|    64 | I     |       15 |  7,247,330 | 2009-01-06 16:34:39 |
bacula_sd_volume |
|   110 | I     |       56 |  3,262,977 | 2009-01-12 10:45:04 |
bacula_sd_volume |
|   112 | I     |        4 |    789,194 | 2009-01-12 13:59:34 |
bacula_sd_volume |
|   117 | I     |        1 |      1,200 | 2009-01-13 13:17:46 |
bacula_sd_volume |
+-------+-------+----------+------------+---------------------+------------------+
You have selected the following JobIds: 40,64,110,112,117

Building directory tree for JobId 40 ...
++++++++++++++++++++++++++++++++++++++++++
Building directory tree for JobId 64 ...  
Building directory tree for JobId 110 ...  ++++++
Building directory tree for JobId 112 ...  
Building directory tree for JobId 117 ...  
5 Jobs, 293 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: /
$                 

1. Si vous souhaitez restaurer l'intégralité de la sauvegarde tapez mark *
2. Si vous souhaitez restaurer des fichiers spécifiques, naviguer dans l'arborescence comme dans un shell.

exemple : je souhaite restaurer mon répertoire “bureau” d'un profil windows

cwd is: /
$ ls              
c:/
$ cd c:
cwd is: c:/
$ ls
Documents and Settings/
$ cd "Documents and Settings"
cwd is: c:/Documents and Settings/
$ ls
alex/
$ cd alex
cwd is: c:/Documents and Settings/alex/
$ ls
Application Data/
Bureau/
Cookies/
Favoris/
Local Settings/
Menu Démarrer/
Mes documents/
Modèles/
NTUSER.DAT
Nouveau dossier
Nouveau dossier (2)
Recent/
SendTo/
Voisinage d'impression
Voisinage réseau
ntuser.dat.LOG
ntuser.ini
$ mark Bureau
4 files marked.
$ 

tapez done et selectionnez le job de type “restore”

$ done
Bootstrap records written to /var/bacula/BACULA_DIR.restore.2.bsr

The job will require the following
   Volume(s)                 Storage(s)                SD Device(s)
===========================================================================
   
   bacula_sd_volume          BACULA_SD                 Storage_clients          


4 files selected to be restored.

The defined Restore Job resources are:
     1: restore_client_1
     2: restore_client_2
Select Restore Job (1-2): 2
Run Restore job
JobName:         restore_client_2
Bootstrap:       /var/bacula/BACULA_DIR.restore.2.bsr
Where:           /bacula_restores/
Replace:         always
FileSet:         File set CLIENT_2
Backup Client:   CLIENT_2
Restore Client:  CLIENT_2
Storage:         BACULA_SD
When:            2009-01-14 11:01:35
Catalog:         MyCatalog
Priority:        10
OK to run? (yes/mod/no): y
Job queued. JobId=122

Le serveur de sauvegarde peut être amené un jour à crasher. Si rien n'a été fait en amont, cela peut être problèmatique suivant le contexte. Néanmoins il est possible de remonter très rapidement le service.

Tout d'abord pour pouvoir restaurer le service de sauvegarde, il faut avoir sauvegardé :

1. les fichiers de configuration /etc/bacula/
2. un dump de la base SQL (mysqldump bacula > dumpbacula.sql)
3. le fichier contenant l'ensemble des données de sauvegarde

La restauration sera très difficile voir impossible si des éléments manquent.

Remonter le système grâce à clonezilla.

Une fois le système remonté il faut restaurer les éléments sauvegardés précédemment :

1. restaurer l'intégralité des fichiers de configuration
2. recopier le fichier contenant les sauvegardes.
3. restaurer la base sql. Pour cela connectez vous à votre base, créer la base sql (create database bacula;) et restaurer le contenu du dump (source /tmp/dumpbacula.sql)

Redemarrer le service Director, et reprenez vos travaux!

Le but étant de crypter les communications entre les éléments de Bacula. Tout d'abord il faut créer une CA ainsi qu'une paire de clé pour chaque élément de bacula. Il peut être utile d'utiliser easy-rsa. Dans tous les cas il faut absolument harmoniser le nom indiqué dans le “Common Name” lors de la création du certificat et les noms indiqués dans les fichiers de configurations car c'est la méthode de résolution de nom qui fera le lien. Il est donc impératif de remplire son fichier host ou d'avoir un serveur DNS correctement implémenté.

Dans notre cas nous allons choisir comme domaine local “dom.loc”. Il n'est pas nécessaire de d'intégrer le TLS entre tous les éléments de Bacula si vous faites fonctionner certains service sur la même machine.

bconsole

Director        {
                Name = BACULA_DIR
                DIRport = 9101
                address = dir.dom.loc 				#il faut absolument indiquer le nom du director et non l'@ip comme vu
								#précédemment. Ce nom devra figurer dans le fichier host.
                Password = "82c3600c04db8048a761be36a43f55c3"
                TLS Enable = yes
                TLS Require = yes
                TLS CA Certificate File = /etc/bacula/easy-rsa/keys/ca.crt
                TLS Certificate = /etc/bacula/easy-rsa/keys/con.dom.loc.crt
                TLS Key = /etc/bacula/easy-rsa/keys/con.dom.loc.key
                }

director

Director        {
                Name = BACULA_DIR
                DIRport = 9101
                QueryFile = "/etc/bacula/query.sql"
                WorkingDirectory = "/var/bacula"
                PidDirectory = "/var/run"
                Maximum Concurrent Jobs = 1
                Password = "82c3600c04db8048a761be36a43f55c3"         #Console password
                Messages = Daemon
                #---bacula-tls---
                TLS Enable = yes 				#activation dutls
                TLS Require = yes 				#on impose le tls
                TLS Verify Peer = yes
                TLS Allowed CN = "con.dom.loc" 			#une partiet rès importante, il faut indiquer le contenu du champs
								#common name du certicat de la console
                TLS CA Certificate File = /etc/bacula/easy-rsa/keys/ca.crt  #certificat de la CA
                TLS Certificate = /etc/bacula/easy-rsa/keys/dir.dom.loc.crt #certificat du director
                TLS Key = /etc/bacula/easy-rsa/keys/dir.dom.loc.key         #clé du director
                }

director

Client          {
                Name = SRV_BACKUP
                Address = client.dom.loc
                FDPort = 9102
                Catalog = MyCatalog
                Password = "82c3600c04db8048a761be36a43f55c3"          #password for FileDaemon
                File Retention = 30 days            # 30 days
                Job Retention = 6 months            # six months
                AutoPrune = yes                     # Prune expired Jobs/Files
                TLS Enable = yes
                TLS Require = yes
                TLS CA Certificate File = /etc/bacula/easy-rsa/keys/ca.crt
                TLS Certificate = /etc/bacula/easy-rsa/keys/dir.dom.loc.crt
                TLS Key = /etc/bacula/easy-rsa/keys/dir.dom.loc.key
                }

file daemon

Director        {
                Name = BACULA_DIR
                Password = "82c3600c04db8048a761be36a43f55c3"
                TLS Enable = yes
                TLS Require = yes
                TLS Verify Peer = yes
                TLS Allowed CN = "dir.dom.loc"
                TLS CA Certificate File = /etc/bacula/easy-rsa/keys/ca.crt
                TLS Certificate = /etc/bacula/easy-rsa/keys/client.dom.loc.crt
                TLS Key = /etc/bacula/easy-rsa/keys/client.dom.loc.key
                }

director

Storage         {
                Name = BACULA_SD 			# Do not use "localhost" here    
                Address = stor.dom.loc              	# N.B. Use a fully qualified name here
                SDPort = 9103
                Password = "82c3600c04db8048a761be36a43f55c3"
                Device = Storage_clients
                Media Type = File
                TLS Enable = yes
                TLS Require = yes
                TLS CA Certificate File = /etc/bacula/easy-rsa/keys/ca.crt
                TLS Certificate = /etc/bacula/easy-rsa/keys/dir.dom.loc.crt
                TLS Key = /etc/bacula/easy-rsa/keys/dir.dom.loc.key
                }

storage daemon

Director        {
                Name = BACULA_DIR
                Password = "82c3600c04db8048a761be36a43f55c3"
                TLS Enable = yes
                TLS Require = yes
                TLS Verify Peer = yes
                TLS Allowed CN = "dir.dom.loc"
                TLS CA Certificate File = /etc/bacula/easy-rsa/keys/ca.crt
                TLS Certificate = /etc/bacula/easy-rsa/keys/stor.dom.loc.crt
                TLS Key = /etc/bacula/easy-rsa/keys/stor.dom.loc.key
                }

File daemon

FileDaemon      {                          	# this is me
                Name = SRV_BACKUP
                FDport = 9102                  	# where we listen for the director
                WorkingDirectory = /var/bacula
                Pid Directory = /var/run
                Maximum Concurrent Jobs = 20
                TLS Enable = yes
                TLS Require = yes
                TLS CA Certificate File = /etc/bacula/easy-rsa/keys/ca.crt
                TLS Certificate = /etc/bacula/easy-rsa/keys/client.dom.loc.crt
                TLS Key = /etc/bacula/easy-rsa/keys/client.dom.loc.key
                }

Storage daemon

Storage         {                             # definition of myself
                Name = BACULA_SD
                SDPort = 9103                  # Director's port      
                WorkingDirectory = "/var/bacula"
                Pid Directory = "/var/run"
                Maximum Concurrent Jobs = 20
                TLS Enable = yes
                TLS Require = yes
                TLS Verify Peer = no
                #TLS Allowed CN = "dir.dom.loc"
                TLS CA Certificate File = /etc/bacula/easy-rsa/keys/ca.crt
                TLS Certificate = /etc/bacula/easy-rsa/keys/stor.dom.loc.crt
                TLS Key = /etc/bacula/easy-rsa/keys/stor.dom.loc.key
                }

L'exécutable de bacula pour windows intègre déjà le module TLS. Les champs sont les même mais la syntaxe change. Voici un exemple d'un file daemon sous windows. Néanmoins il faut respecter les même contraintes du “common name” du certificat. Il faut aussi éditer le fichier host (C:\WINDOWS\system32\drivers\etc\hosts) ou le serveur DNS.

FileDaemon 	{                            # this is me
  		Name = CLIENT_2
  		FDport = 9102                # where we listen for the director
  		WorkingDirectory = "C:\\Documents and Settings\\All Users\\Application Data\\Bacula\\Work"
  		Pid Directory = "C:\\Documents and Settings\\All Users\\Application Data\\Bacula\\Work"
  		Maximum Concurrent Jobs = 2
  		TLS Enable = yes
  		TLS Require = yes
  		TLS CA Certificate File = "C:\\keys\\ca.crt"
  		TLS Certificate = "C:\\keys\\client2.dom.loc.crt"
  		TLS Key = "C:\\keys\\client2.dom.loc.key"
		}

#
# List Directors who are permitted to contact this File daemon
#
Director 	{
  		Name = BACULA_DIR
  		Password = "82c3600c04db8048a761be36a43f55c3"
  		TLS Enable = yes
  		TLS Require = yes
  		TLS Verify Peer = yes
  		TLS Allowed CN = "dir.dom.loc"
  		TLS CA Certificate File = "C:\\keys\\ca.crt"
  		TLS Certificate = "C:\\keys\\client2.dom.loc.crt"
  		TLS Key = "C:\\keys\\client2.dom.loc.key"
		}

Director 	{
  		Name = BCULA_DIR
  		DIRport = 9101
  		address = dir.dom.loc
  		Password = "82c3600c04db8048a761be36a43f55c3"
  		TLS Enable = yes
  		TLS Require = yes
  		TLS CA Certificate File = "C:\\keys2\\ca.crt"
  		TLS Certificate = "C:\\keys2\\CA7YU5JR.crt"
  		TLS Key = "C:\\keys2\\CAS9Q3O1.key"
		}

Je vais tenter d'exprimer un besoin que certains hébergeurs peuvent avoir : Le backup mutualisé des clients dédiés. Un hébergeur propose généralement 2 offres :

hébergement mutualisé : une grappe de serveurs hébergent les sites des différents clients. Ils n'ont généralement pas accès au système et utilisent les services mutualisés (stockage, web, mail, sql …).

hébergement dédiés : l'herbergeur met à dispositions des machines à des clients précis. Il fournis l'infrastructure (routage, firewalling, haute disponibilité des liens …). Dans certains car le client souhaite mettre ses propres machines dans les locaux de l'hébergeur.

Dans le cardre des clients mutilisés, l'hébergeur maîtrise la partie applicative et peux donc gérer ses backup. Pour les clients dédiés c'est différents. Chaque clients accèdent à ses proposes machines, cependant il n'est pas pensable que chaque clients effectuent la sauvegarde de ses données sur la même machine car si le système venait a être défaillant (problème matériel, intrusion …) il ne serait pas possible de restaurer la partie DATAS. Il faut donc fournir, aux clients, un système de sauvegarde/restauration externe. Mais comment ? Mettre un lecteur de bande pour chaque client ? Non ce n'est pas envisageable. C'est ici qu'intervient Bacula par la flexibilité de son fonctionnement. Nous avons vu comment nous pouvions sauvegarder avec Bacula. Nous pourrions très bien imaginer qu'un hébergeur investisse dans un serveur suffisamment robuste pouvant accueillir l'ensemble des sauvegardes des différents clients dédiés. Jusqu'ici rien de difficile, il suffit d'installer un “Bacula File Daemon” sur chaque client et appliquer la configuration vue dans la procédure. Mais comment donner aux clients la gestion de la restauration de ses propres données sans qu'il puisse atteindre les données des autres clients dédiés. La réponse : une console personnalisable.

Si vous souhaitez déléguer la gestion des restaurations à vos clients, il est intéressant de sélectionner les informations qui seront envoyées à chacune de leurs consoles. En effet, la gestion des informations empêchera le client de restaurer les données d'un autre client sur sa machine. Pour cela il faut déclarer une console restreinte au niveau du DIRECTOR. En voici un exemple :

Console         {
                Name = console-client2
                Password = "1234
                CommandACL =status, .status, restore, .jobs, .clients, .filesets, .pools, .storage, .messages, autodisplay, .defaults, .backups, unmark, cd, .dir, mark, time
                ClientACL = CLIENT_2
                JobACL = "restore_client_2", "backup_client_2"
                FileSetACL = "File set CLIENT_2"
                ScheduleACL = *all*
                PoolACL = *all*
                StorageACL = BACULA_SD
                CatalogACL = MyCatalog
                }

Ajoutez les informations suivantes dans le fichier “bconsole.conf” côté client :

Director        {
                Name = BACULA_DIR
                DIRport = 9101
                address = dir.dom.loc
                Password = "xxxxx"
                
                }

Console {
   Name = console-client2
   Password = "1234"
}

De cette manière, le client en question n'a accès qu'aux informations qui le concerne (filset, job, …) et peux gérer aisément ses sauvegardes.

Dans notre contexte du backup mutualisé des client dédiés, il peut être intéressant d'envoyer le résumé du backup au client concerné. Pour cela créé une nouvelle rubrique :

Messages {
  Name = Standard-client1
  mailcommand = "/usr/sbin/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula: %e - %l - %j\" %r"
  operatorcommand = "/usr/sbin/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula: Intervention needed for %j\" %r"
  mail = client1@domain.xx = all, !skipped
  operator =  admin@domain.xx = mount
  console = all, !skipped, !saved
  append = "/var/lib/bacula/log" = all, !skipped
}

Il vous faut maintenant modifier votre partie bacula-dir-job.conf en ajoutant pour le job du client :

Messages = Standard-client1

Dorénavant, les mails de résumé de backup seront envoyés au client.

15-avr 23:02 kubiak-dir JobId 950: shell command: run BeforeJob "/etc/bacula/scripts/make_catalog_backup bacula bacula"
15-avr 23:02 kubiak-dir JobId 950: Start Backup JobId 950, Job=backup-catalog.2010-04-15_23.00.01_12
15-avr 23:02 kubiak-dir JobId 950: Using Device "bacula-file"
15-avr 23:02 kubiak-sd JobId 950: Volume "str-incre" previously written, moving to end of data.
15-avr 23:02 kubiak-sd JobId 950: Ready to append to end of Volume "str-incre" size=63895518084
15-avr 23:02 kubiak-sd JobId 950: Job write elapsed time = 00:00:01, Transfer rate = 23.52 M bytes/second
15-avr 23:02 kubiak-dir JobId 950: Bacula kubiak-dir 3.0.2 (18Jul09): 15-avr-2010 23:02:28
  Build OS:               i686-redhat-linux-gnu redhat 
  JobId:                  950
  Job:                    backup-catalog.2010-04-15_23.00.01_12
  Backup Level:           Incremental, since=2010-04-14 23:02:38
  Client:                 "kubiak-fd" 3.0.2 (18Jul09) i686-redhat-linux-gnu,redhat,
  FileSet:                "Catalog" 2009-10-18 13:00:00
  Pool:                   "pool-incre" (From Run pool override)
  Catalog:                "MyCatalog" (From Client resource)
  Storage:                "local-file-str" (From Job resource)
  Scheduled time:         15-avr-2010 23:00:01
  Start time:             15-avr-2010 23:02:28
  End time:               15-avr-2010 23:02:28
  Elapsed time:           0 secs
  Priority:               20
  FD Files Written:       1
  SD Files Written:       1
  FD Bytes Written:       23,521,574 (23.52 MB)
  SD Bytes Written:       23,521,687 (23.52 MB)
  Rate:                   0.0 KB/s
  Software Compression:   None
  VSS:                    no
  Encryption:             no
  Accurate:               no
  Volume name(s):         str-incre
  Volume Session Id:      11
  Volume Session Time:    1271250331
  Last Volume Bytes:      63,919,057,621 (63.91 GB)
  Non-fatal FD errors:    0
  SD Errors:              0
  FD termination status:  OK
  SD termination status:  OK
  Termination:            Backup OK

15-avr 23:02 kubiak-dir JobId 950: Begin pruning Jobs.
15-avr 23:02 kubiak-dir JobId 950: No Jobs found to prune.
15-avr 23:02 kubiak-dir JobId 950: Begin pruning Files.
15-avr 23:02 kubiak-dir JobId 950: No Files found to prune.
15-avr 23:02 kubiak-dir JobId 950: End auto prune.

15-avr 23:02 kubiak-dir JobId 950: shell command: run AfterJob "/etc/bacula/scripts/delete_catalog_backup"

Le Bacula Admin Tool est une interface graphique permettant de gérer visuellement les options de Bacula. Néanmoins rien ne vous empêche d'utiliser directement les options en ligne de commande. Cependant la BAT est un vrai plus comparé a la console classique bconsole surtout pour la restauration de fichiers précis. Découvrons cette console par la pratique.

Il peut arrivé qu'un backup échoue car le client était indisponible. Il est tout à fait possible de relancer ce backup manuellement avec le même niveau (exemple : incrémentiel). Pour cela vous avez un icône “run jobs” vous permettant de lancer un backup manuel.

Commentaires	Supports visuel
Comme vous pouvez le constater je n'ai pas utilisé les options par défaut. J'ai souhaité relancer un backup de type incémentiel. Pour cela j'ai choisi: - type de job : ici du backup - le client : ici sole - le niveau : incrémentiel - le fileset associé au client - le pool : ici incré car je relance un backup de type incrémentiel - le bon storage, cela dépend où vous souhaitez écrire vos données.
La commande associée	run job="backup-sole" fileset="filset-sole" level="Incremental" client="sole-fd" pool="pool-incre" storage="local-file-str" priority="10" when="2010-04-06 18:21:45" yes"
Résultat avec un status dir	06-avr 18:55 kubiak-dir JobId 888: Start Backup JobId 888, Job=backup-sole.2010-04-06_18.55.28_05 06-avr 18:55 kubiak-dir JobId 888: Using Device "bacula-file" 06-avr 18:55 kubiak-sd JobId 888: Volume "str-incre" previously written, moving to end of data. 06-avr 18:55 kubiak-sd JobId 888: Ready to append to end of Volume "str-incre" size=26054118248 06-avr 18:55 kubiak-sd JobId 888: Job write elapsed time = 00:00:01, Transfer rate = 1.971 K bytes/second 06-avr 18:55 kubiak-dir JobId 888: Bacula kubiak-dir 3.0.2 (18Jul09): 06-avr-2010 18:55:31 Build OS: i686-redhat-linux-gnu redhat JobId: 888 Job: backup-sole.2010-04-06_18.55.28_05 Backup Level: Incremental, since=2010-04-05 03:00:18 Client: "sole-fd" 2.4.4 (28Dec08) i486-pc-linux-gnu,debian,5.0 FileSet: "filset-sole" 2009-12-31 15:47:28 Pool: "pool-incre" (From User input) Catalog: "MyCatalog" (From Client resource) Storage: "local-file-str" (From command line) Scheduled time: 06-avr-2010 18:21:45 Start time: 06-avr-2010 18:55:31 End time: 06-avr-2010 18:55:31 Elapsed time: 0 secs Priority: 10 FD Files Written: 6 SD Files Written: 6 FD Bytes Written: 1,451 (1.451 KB) SD Bytes Written: 1,971 (1.971 KB) Rate: 0.0 KB/s Software Compression: None VSS: no Encryption: no Accurate: no Volume name(s): str-incre Volume Session Id: 2 Volume Session Time: 1270548934 Last Volume Bytes: 26,054,120,769 (26.05 GB) Non-fatal FD errors: 0 SD Errors: 0 FD termination status: OK SD termination status: OK Termination: Backup OK 06-avr 18:55 kubiak-dir JobId 888: Begin pruning Jobs. 06-avr 18:55 kubiak-dir JobId 888: No Jobs found to prune. 06-avr 18:55 kubiak-dir JobId 888: Begin pruning Files. 06-avr 18:55 kubiak-dir JobId 888: Pruned Files from 1 Jobs for client sole-fd from catalog. 06-avr 18:55 kubiak-dir JobId 888: End auto prune.

Cliquer sur pour pour naviguer dans vos fichier. Dans notre exemple, j'ai restaurer un fichier de conf nagios pour la supervision du serveur opendoc.

Commentaires	Supports visuel
sélectionner : - Job - Client - Filset et cliquer sur “refresh”
La liste des jobs concernés vont s'afficher avec leur niveau - I : incrémentale - D : différentiel - F : totale
Naviguer dans votre arbre, ici nous sélectionnons le répertoire de nagios.
Vous pouvez constater le versioning pour le fichier de conf opendoc. Dans mon cas je sélectionne la plus vielle.
Sélectionner votre job de restauration.
Vérifier la cohérence des information entre le filset, job, storage …
La restauration c'est correctement déroulée.	09-avr 18:57 kubiak-dir JobId 907: Start Restore Job restore-sole.2010-04-09_18.57.36_30 09-avr 18:57 kubiak-dir JobId 907: Using Device "bacula-file" 09-avr 18:57 kubiak-sd JobId 907: Ready to read from volume "str-incre" on device "bacula-file" (/var/lib/bacula/storage/). 09-avr 18:57 kubiak-sd JobId 907: Forward spacing Volume "str-incre" to file:block 3:26687535. 09-avr 18:57 kubiak-sd JobId 907: End of Volume at file 3 on device "bacula-file" (/var/lib/bacula/storage/), Volume "str-incre" 09-avr 18:57 kubiak-sd JobId 907: End of all volumes. 09-avr 18:57 kubiak-dir JobId 907: Bacula kubiak-dir 3.0.2 (18Jul09): 09-avr-2010 18:57:38 Build OS: i686-redhat-linux-gnu redhat JobId: 907 Job: restore-sole.2010-04-09_18.57.36_30 Restore Client: sole-fd Start time: 09-avr-2010 18:57:38 End time: 09-avr-2010 18:57:38 Files Expected: 1 Files Restored: 1 Bytes Restored: 5,856 Rate: 0.0 KB/s FD Errors: 0 FD termination status: OK SD termination status: OK Termination: Restore OK 09-avr 18:57 kubiak-dir JobId 907: Begin pruning Jobs. 09-avr 18:57 kubiak-dir JobId 907: No Jobs found to prune. 09-avr 18:57 kubiak-dir JobId 907: Begin pruning Files. 09-avr 18:57 kubiak-dir JobId 907: Pruned Files from 1 Jobs for client sole-fd from catalog. 09-avr 18:57 kubiak-dir JobId 907: End auto prune.

Récupérez l'archive directement sur le site de webacula http://webacula.sourceforge.net/download.php

Vous devez avoir installé :

• apache
• php 5
• MySQL ou PosgreSQL

déplacer le répertoire déziper dans /var/www/

éditer le fichier de configuration : /var/www/webacula/application/config.ini

[general]
db.adapter = PDO_MYSQL
db.config.host = localhost
db.config.username = bacula
db.config.password = bacula
db.config.dbname = bacula

def.timezone = "Europe/Minsk"

bacula.sudo = ""
bacula.bconsole = "/usr/sbin/bconsole"

bacula.bconsolecmd = "-n -c /etc/bacula/bconsole.conf"

tmpdir = "/tmp"

[timeline]
gdfontpath = "/usr/share/fonts/dejavu-lgc"
fontname   = "DejaVuLGCSansMono"
fontsize   = 10

[webacula]
; support only MySQL
db.adapter = PDO_MYSQL
db.config.host = localhost
db.config.username = wbuser
db.config.password = "wbpass"
db.config.dbname = webacula
email.to_admin = root@localhost
email.from = webacula@localhost

gestion des droits :

créer un groupe bacula :

groupadd bacula

ajouter le user apache au groupe bacula :

usermod -G bacula apache 

gérer les droits sur les fichiers de configuration :

chown root:bacula /usr/sbin/bconsole
chmod u=rwx,g=rx,o=  /usr/sbin/bconsole
chown root:bacula /etc/bacula/bconsole.conf
chmod u=rw,g=r,o= /etc/bacula/bconsole.conf

Créez un fichier webacula.conf dans /etc/httpd/cond.d/

Alias "/webacula"  "/var/www/webacula/html"
<Directory "/var/www/webacula/html">
        Options Indexes FollowSymLinks
        AllowOverride All
        Order deny,allow
        Allow from 127.0.0.1
        # your network
        Allow from 172.16.176.0/255.255.255.0
        AuthType Basic
        AuthName "Webacula"
        AuthUserFile       /etc/httpd/conf/webacula.users
        Require valid-user
</Directory>