Lolokai – Supervision, systèmes, réseaux, base de données…

4

Configuration Bacula coté serveur et client

Said ASSOUMANI 20 avril 2012

Introduction

Cet article est la suite logique de mon article précedent , à savoir l’installation d’un serveur Bacula.

Lors de cet article je vais vous montrer comment configurer les différents composants de Bacula sur un serveur Linux puis comment configurer le  client bacula pour un Windows. Le but est de réussir à lancer une sauvegarde en réseaux et de faire une restauration. Let’s go :p

Configuration de Bacula Server

Pour des raisons de simplicité le mot de passe sera toujours le même à savoir : p@ssw0rd

Passer en utilisateur root, nous allons sécuriser les différents fichiers de configuration :

chmod 600 /etc/bacula/bacula-dir.conf –> Director-Daemon’s config file

chmod 600 /etc/bacula/bacula-sd.conf –> Storage-Daemon’s config file

Dans les fichiers de configuration , nous avons plusieurs parties à configurer. Chaque partie est appelée « Ressource ». Dans la suite je vais vous montrer un exemple de configuration pour chaque ressource dans l’optique de réaliser une sauvegarde/restauration avec un client.

Configuration du bacula director

cd /etc/bacula

vim bacula-dir.conf

La ressource Director

Cette ressource va nous permettre de definir le Director , c’est à dire le serveur qui va jouer le chef d’orchestre , qui va gérer les différents composants de Bacula.

Voici un exemple d’une ressource Director valide :


Director {

Name = BACULA_DIR

DIRport = 9101

QueryFile = "/usr/bacula/query.sql"

WorkingDirectory = "/var/lib/bacula"

PidDirectory = "/var/run"

Maximum Concurrent Jobs =15

Password = " p@ssw0rd " # mot de passe de la console

Messages =  Standard #voir ressource message

}

  1. Name : Le nom du Director
  2. Password : Mot de passe qui doit être fourni par la Console Bacula .Le même mot de passe dot être utilisé coté client (configuration de la console)
  3. Working Directory : Repértoitre où le Director peut déposer ses fichiers d’états.
  4. Pid Directory : Répertoire où le Director peut déposer son fichier d’Id de processus (utilisé pour stopper Bacula…)
  5. QueryFile : le Director peut retrouver les requêtes SQL préétablies pour la commande Query de la Console.
  6. Maximum Concurrent Jobs : Le nombre maximal de jobs qui peuvent être exécutés simultanément par le Director.
  7. DIRport : Spécifie le port (un entier positif) sur lequel le Director est à l’écoute d’une ou de plusieurs  connections de Consoles Bacula. (le même lors de la configuration du client)

La ressource Job

La ressource Job définit un Job (sauvegarde, restauration,…) que Bacula doit exécuter.

Voici un exemple de définition de deux ressources Job valides , une pour la sauvegarde et une pour la restauration :


Job {

Name = "Totale"

Type = Backup

Level = Full

FileSet = "Totale"  #(voir ressource fileset)

Schedule = "WeeklyCycle"

Storage = BACULA_SD

Pool = SauvegardeTotale #(voir ressource pool)

Client = CLIENT1

Max Wait Time= 2 minutes

Messages = Standard #(voir ressource message)

}

Job {

Name = "Restauration"

Type = Restore

Client= CLIENT1

FileSet = "Totale" #(voir ressource fileset)

Storage = BACULA_SD

Messages = Standard #(voir ressource message)

Pool = SauvegardeTotale #(voir ressource pool)

Where = "C:/restauration"

}

  1. Name : Le nom du Job.
  2. Type : Backup, Restore….
  3. Level : Spécifie le niveau d’exécution du job

Par exemple pour un Backup , on peut avoir les niveaux suivants :

  • Full(Tous les fichiers du FileSet, qu’ils aient été modifiés ou non seront sauvegardés.)
  • Incremental(Tous les fichiers modifiés depuis la dernière sauvegarde valide du FileSet spécifié pour le même job seront sauvegardés. Si le Director ne peut trouver une sauvegarde Full antérieure, ce niveau sera élevé en une sauvegarde Full.)…
  • Client : On définit ici le client sur lequel le Director va agir (la machine à sauvegarder…)
  • FileSet : Le FileSet définit les répertoires et fichiers que l’on devra sauvegarder, ainsi que les options à utiliser pour les sauvegarder (par exemple la compression,…). Un Job ne peut contenir qu’un seul FileSet.
  • Pool : Le jeu de volumes qui devra être utilisé pour sauvegarder nos données
  • Schedule : Le schedule détermine la date et l’instant où le job doit être lancé automatiquement, et le niveau (Full, Différentiel, Incrémental…)
  • Storage : Le nom du service storage que vous souhaitez utiliser pour sauvegarder les données du FileSet.
  • Max Wait Time : Le délai maximum durant lequel un job peut rester bloqué en attente d’une ressource depuis son lancement jusqu’à sa fin.
  • Where : Utilisé pour les type Restauration. Elle permet de spécifier un préfixe au nom du répertoire où tous les fichiers sont restaurés
  • Maximum Concurrent Jobs : Nombre maximum de jobs de la ressource Job courrante qui peuvent être exécutés simultanément.

La ressource FileSet

La ressource FileSet définit les fichiers à inclure dans une sauvegarde , c’est ici qu’on va definir les dossiers , fichiers ,disques… qui vont être visés par le bacula storage( composant pour la sauvegarde)

Voici un exemple de définition de FileSet valide :


FileSet {

Name = "Totale"

Include {

Options {

signature = MD5

compression = GZIP9

aclsupport = yes

}

File = "C:/Asauvegarde" #sur l’ordinateur du client, ce qu’on doit sauvegarder est dans ce répertoire

}

}

  1. Name : Nom de la ressource FileSet.
  2. Include { [ Options {} ...] }
  3. Compression : Tous les fichiers sauvegardés sont compressés (GZIP, GZIP9…)
  4. Signature : La signature est calculée pour tous les fichiers sauvegardés(SHA1 ,MD5…)
  5. aclsupport=yes|no : Permet à Bacula de sauvegarder la liste des ACL UNIX des fichiers et répertoires

La ressource Schedule

La ressource Schedule offre le moyen de planifier automatiquement un Job , en effet il est plus simple pour un administrateur de planifier plusieurs jobs au lieu de les faire manuellement.

Voici deux exemples:


Schedule {

Name = "WeeklyCycle"

Run = Full 1st sun at 04:05

Run = Incremental mon-sat at 23:05

}

Ici on a un Schedule nommé WeeklyCycle qui exécute un job de niveau Full le premier Dimanche du mois à 4h05 et un job de niveau incrémental opérant du Lundi au Samedi à 23h05.


Schedule {

Name = "WeeklyCycleAfterBackup"

Run = Full sun-sat at 23:10

}

Ici on a un schedule nommé WeeklyCycleAfterBackup qui exécute un job de niveau Full tous les jours à 23 :10 (il s’agit d’un schedule lié au catalogue).

La ressource Client

Les clients qui seront gérés par le director doivent être definis dans le fichier de configuration. Pour chaque machine cliente,  il faut une ressource cliente appropriée.

Voici un exemple d’une définition de ressources pour un client valide :


Client {

Name = CLIENT1

Address = CLIENT1.lolokai.fr

FDPort = 9102

Catalog = Catalogue

Password = "p@ssw0rd" # password for FileDaemon

}

  1. Name : Le nom du client .
  2. Address : FQDN de notre client ou son IP.
  3. FD Port : Le port auquel le le File Daemon peut être contacté. La valeur par défaut est 9102.
  4. Catalog : Nom de la ressource catalog à utiliser pour ce client.
  5. Password : Mot de passe à utiliser lorsque le director voudra contacter la machine cliente (cela va de soit que sur la machine cliente on devrait retrouver ce mot de passe)

La ressource Storage

La ressource Storage définit les Storage Daemons disponibles pour le Director. Ici on indique au Bacula Director où est son Bacula storage (composant qui permet de gérer les sauvegardes …). Il est tout à fait possible d’installer le Bacula storage sur un autre serveur , mais dans notre cas le Bacula storage , le Bacula director sont installés sur un même serveur (voir configuration Bacula storage).

Voici un exemple de ressource Storage valide :


Storage {

Name = BACULA_SD

Address = 127.0.0.1 # (dans notre cas le bacula storage est installé sur ce serveur)

SDPort = 9103

Password = "p@ssw0rd"

Device = DeviceSauvegarde

Media Type = File

}

  1. Name : Le nom de la ressource Storage.
  2. Address : FQDN ou adresse IP du serveur.
  3. SD Port : Le port permettant de contacter de bacula storage. Le port par défaut est 9103.
  4. Password : Mot de passe à utiliser lorsque le director voudra contacter le bacula storage (même mot de passe dans les fichiers de configuration du bacula storage)
  5. Media Type : Type de média à utiliser pour stocker les données (par exemple :File, DAT,  »HP DLT8000″,…).
  6. Device : Nom du device que l’on utilisera (voir configuration bacula storage)

La ressource Catalog

La ressource Catalog précise quel catalogue utiliser pour le job courant.

Voici un exemple d’une définition de ressource Catalog valide :


Catalog {

Name = Catalogue

dbname = "bacula"; dbuser = "bacula"; dbpassword = "Mot_de_Passe_Mysql", DB Adress="localhost"

}

  1. Name : Le nom du Catalog
  2. dbpassword : mot de passe à utiliser pour se connecter au catalogue.
  3. dbname : nom de la base de données
  4. dbuser : L’utilisateur habilité à se connecter au catalogue.
  5. DB Address : Il s’agit de l’adresse du serveur de bases de données.

La ressource Pool

Voici un exemple de ressource Pool valide :


Pool {

Name = SauvegardeTotale

Pool Type = Backup

Label Format = "GZW-Full-${Year}-${Month:p/2/0/r}-${Day:p/2/0/r}_${Hour:p/2/0/r}:${Minute:p/2/0/r}"

}

  1. Name : Le nom du pool.
  2. Pool Type : type du pool, qui correspond au type du job exécuté (Backup|Archive|Cloned|Migration|Copy|Save…)
  3. Label Format : Le format des étiquettes des volumes de ce pool.
  4. Dans notre cas si on fait une sauvegarde totale : le 14 avril 2012 à 13h
  5. Le nom de la sauvegarde serait = “GZW-Full-2012 }-April-14-13:00”
La ressource Message
Ici cette ressource va nous permettre d’avoir des informations sur un job en cours (on aura un exemple de son utilisation , lorsque nous ferrons la sauvegarde dans la partie « Exploitation » de cet article)

Voici un exemple de ressource Message valide :


Messages {

Name = Standard

mail = [email protected] = all, !terminate

console = all

}

Ici tous les messages sont envoyés par email à [email protected] à l’exception  des messages d’arrêt de daemon (terminate). Enfin, tous les messages  sont envoyés vers la console.

Nous avons fini de configurer le fichier concernant  le Bacula Director , nous allons configurer le Bacula storage

Configuration du bacula storage:

Ici comme je l’ai dit précédemment, il est tout a fait possible d’installer le bacula storage sur un autre serveur. les options dans les exemples de configurations ont été pour la plupart expliqués lors de la configuration du bacula director .

vim bacula-sd.conf

Ressource Storage

On definit ici le Bacula storage , le nom du storage , sur quel port le storage est en écoute , combien de jobs simultanés le storage peut gérer…

Voici un exemple d’une ressource Storage du Storage Daemon :


Storage {

Name = BACULA_SD

SDPort = 9103 # Director's port

WorkingDirectory = "/var/lib/bacula"

Pid Directory = "/var/run"

Maximum Concurrent Jobs = 20

}

La ressource Director

On indique les informations utiles au storage pour s’authentifier avec le bacula director.

Voici un exemple d’une définition de ressource Director valide :


Director {

Name = BACULA_DIR

Password = "p@ssw0rd"

}

La Ressource Device

La ressource Device spécifie les détails de chaque périphérique utilisés pour la sauvegarde.

Voici un exemple d’une définition de ressource Device valide :


Device {

Name= DeviceSauvegarde

Media Type = File

Device Type= File

Archive Device = /home/bacula #ici on retrouvera les fichiers sauvegardés

LabelMedia = yes; # lets Bacula label unlabeled media

}

  1. Name : Nom du device
  2. Archive Device : Destination des fichiers sauvegardés.
  3. Device Type :
  • File (Indique à Bacula que le périphérique est un fichier. (disque dur (externe) )
  • tape (lecteur de bandes…)
  • DVD (Indique à Bacula que le périphérique est un DVD. …)

Configuration du bat.conf et bconsole.conf :

// même configuration pour ces deux fichiers

La ressource Director

Ici pour ces deux fichiers on indique a la bconsole et bat(gui) les informations sur le Bacula director.

Voici un exemple:


Director {

Name = BACULA_DIR

DIRport = 9101

address = 127.0.0.1

Password = "p@ssw0rd"

}

Configuration de Bacula Client  (windows 7)

=> Les différents options ont été pour la plupart expliquer précédemment.

Aller dans : Démarrer ? Tous les programmes ?Bacula ?Configuration ? Edit Client configuration

Ici on va configurer le client lui même , son nom , sur quel port il écoute … , les informations pour s’authentifier avec le director et tous les messages logs du clients sont envoyés au director.


FileDaemon { # this is me

Name = CLIENT1

FDport = 9102

WorkingDirectory = "C:\\Program Files\\Bacula\\working"

Pid Directory = "C:\\Program Files\\Bacula\\working"

Maximum Concurrent Jobs = 10

}

Director {

Name = BACULA_DIR

Password = "p@ssw0rd"

}

Messages {

Name = Standard

director = BACULA_DIR = all, !skipped, !restored

}

Pour l’interface graphique de bacula (BAT) et la console (Bconsole) il faut indiquer comment contacter le bacula director pour cela

dans : Démarrer ? Tous les programmes ?Bacula ?Configuration ? Edit BAT configuration

et

dans : Démarrer ? Tous les programmes ?Bacula ?Configuration ? Edit Command console configuration

on devra avoir ceci :


Director {

Name = BACULA_DIR

DIRport = 9101

address = 192.168.1.5

Password = "p@ssw0rd"

}

Exploration du Bat et de la Bconsole 

Maintenant qu’on a installé nos différents composants et qu’on les a configurés…explorons-les.

Nous allons commencer par la BCONSOLE et allons simuler une sauvegarde Totale.

Dans le terminal de CentOS , en tant qu’utilisateur Root :

==> attendre quelques temps, pour voir où en est la sauvegarde puis taper:

Messages

==>vous aurez un certain nombre d’informations, si la sauvegarde est terminé vous aurez une ligne de ce type:

Termination: Backup OK –

Nous allons vérifier que la sauvegarde a était faites, rendez-vous dans le dossier /home/bacula :

cd /home/bacula
ls –l

==>normalement si tout va bien, vous avez un fichier qui se nomme à peu prés comme cela :

GWZ-Full-2012-04-12_09 :44

Nous allons voir maintenant une restauration avec BAT :

Dans le terminal de CentOS , en tant qu’utilisateur  Root :

bat –c bat.conf

Vous avez une interface graphique qui s’ouvre :

Pour la Restauration, sur la barre des taches cliquer sur le bouton « Restore » :

Une fenêtre s’ouvre à vous de choisir vos différentes options :

Vous pouvez par la suite spécifier les dossiers ou fichiers que vous voulez récupérer. Et comme pour la sauvegarde il vous suffira de taper « messages » pour avoir une idée de l’avancement de la restauration.

==> les fichiers restaurés sont normalement dans « C:/restauration » (comme on l’a spécifié dans le job de restauration)

Conclusion

Nous avons vu comment configurer Bacula du coté serveur et aussi coté client. Tout au long de cet article je vous ai presenté quelques options de configuration , pour pouvoir lancer ensemble une sauvegarde en utilisant la BCONSOLE et une restauration en utilisant le BAT de bacula(GUI).

Pour ceux ou celles qui veulent aller plus loin ou qui  aimerait connaitre les autres options qui sont  utilisables pour configurer leur serveur, voici le site de Bacula: http://www.bacula.org/fr/

Avez-vous déjà configuré Bacula ?  Que pensez vous de ce logiciel ?Said ASSOUMANI

Comments (4)

  1. Comme déjà dit dans le précédent article : configuré, utilisé et déployé en entreprise sur quelques 70 serveurs Linux et Windows.

    La possibilité la plus intéressante reste que l’on peut manipuler complètement le logiciel via quelques scripts Python qui peuvent se déclencher avant/après/pendant les sauvegardes, pendant le calcul automatique des noms des volumes de sauvegarde (histoire de les générer), etc…

    C’est vraiment un logiciel complet et bien foutu. Le seul truc que je n’ai jamais réussi à faire, c’est sauvegarder sur disque et passer automatiquement sur bande après (pour une hebdomadaire par exemple).

    Répondre
  2. Bonjour Gibbon ,
    merci pour ton commentaire , je suis carrément du même avis que toi BACULA est un logiciel assez complet , surtout que là ou j’ai fait mon stage avant il utilisait un logiciel payant (je ne donne pas le nom).
    Pour ma part j’avais reussi à lancer des sauvegardes sur des bandes…

    Sauvegarder sur disque et passer sur bande , a mon avis faudrait un job hebdomadaire qui vise le disque …. ça doit être faisable

    Répondre
  3. OracleBoy a dit : « Sauvegarder sur disque et passer sur bande , a mon avis faudrait un job hebdomadaire qui vise le disque …. ça doit être faisable »
    Ca s’appelle un job de duplication. On a un job de sauvegarde – sur disque bien sur – et un job de duplication (qui prend sur disque et envoie sur bandes). Traditionnellement, le job de duplication commence quand le job de sauvegarde est terminé mais cela peut être aussi différé. A ma connaissance Bacula ne gère pas ça (BackupToDiskToTape) ou alors seulement au travers d’un tampon sur disque. Or quand on fait du BtDtT, les données sur disque ne sont pas en « retention free » obligatoirement après la duplication sur bandes (les donnée sur bandes ont elles aussi leur propre rétention qui peut être différente). Bacula ne sait pas gérer cela … ou alors au travers de bidouillages compliqués.

    Répondre
  4. salut, j’aimerais savoir comment configurer un file set automatiquement à un client, c’est-à-dire que lorsque l’on restaure une sauvegarde du client 2, son file set est automatiquement sélectionné.
    J’aimerais savoir comment configurer.
    Cordialement.

    Répondre

Laisser un commentaire

 

Login to your account

Can't remember your Password ?

Register for this site!