Si vous \^etes comme moi, vous voulez faire fonctionner Bacula imm\'ediatement
pour en avoir un aper{\c c}u, puis, plus tard, vous reviendrez en arri\`ere
pour lire et conna{\^\i}tre tous les d\'etails. C'est exactement ce que ce
-chapitre se propose d'accomplir: vous faire avancer rapidement sans tous les
+chapitre se propose d'accomplir : vous faire avancer rapidement sans tous les
d\'etails. Si vous voulez sauter la section sur les Pools, Volumes et Labels,
vous pourrez toujours y revenir, mais s'il vous pla\^it, veuillez lire ce
chapitre jusqu'\`a la fin, et en particulier suivre les instructions pour
sinon, vous devriez d'abord jeter un oeil aux
\ilink{Pr\'erequis (syst\`eme)}{SysReqs} puis au chapitre
\ilink{Compiler et installer Bacula}{_ChapterStart17} de ce manuel.
+
+\label{JobsandSchedules}
+\subsection*{Comprendre les Jobs et Schedules}
+\index[general]{Jobs!Comprendre}
+\index[general]{Schedules!Comprendre}
+\addcontentsline{toc}{subsection}{Comprendre les Jobs et Schedules}
+
+Afin de rendre Bacula aussi flexible que possible, les directives lui sont
+donn\'ees en plusieurs endroits. L'instruction principale est la ressource Job,
+qui d\'efinit un job. Un job de type sauvegarde consiste en g\'en\'eral en un
+FileSet, un client, un Schedule pour un ou plusieurs niveaux ou horaires de sauvegardes,
+un Pool, ainsi que des instructions additionnelles. Un autre point de vue
+est de consid\'erer le FileSet comme "Que sauvegarder ?", le Client comme
+"Qui sauvegarder ?", le Schedule comme "Quand sauvegarder ?" et le Pool
+comme "O\`u sauvegarder ?" (c'est \`a dire, "Sur quel volume ?)
+
+Typiquement, une combinaison FileSet/Client aura un job correspondant. La plupart
+des directives, telles que les FileSets, Pools, Schedules, peuvent \^etre
+m\'elang\'ees et partag\'ees entre les jobs. Ainsi, vous pouvez avoir deux d\'efinitions
+(ressources) de jobs sauvegardant diff\'erents serveurs et utilisant les m\^emes
+Schedule, FileSet (sauvegardant donc les m\^emes r\'epertoires sur les deux
+machines) et peut-\^etre m\^eme les m\^emes Pools. Le Schedule d\'efinira quel
+type de sauvegarde sera ex\'ecut\'e et \`a quel moment (par exemple les Full le
+mercredi, les incr\'ementales le reste de la semaine), et lorsque plus d'un job
+utilise le m\^eme Schedule la priorit\'e du job d\'etermine lequel d\'emarre en premier.
+Si vous avez de nombreux jobs, vous devriez utiliser la directive JobDefs,
+qui vous permet de d\'efinir des param\`etres par d\'efaut pour vos jobs, qui peuvent \^etre
+chang\'es au sein de la ressource Job, mais qui vous \'evitent de r\'e\'ecrire les m\^emes
+param\`etres pour chaque job. En plus des FileSets que vous voulez sauvegarder,
+vous devriez aussi avoir un job qui sauvegarde votre catalogue.
+
+Enfin, sachez qu'en plus des jobs de type Backup, vous pouvez aussi utiliser
+des jobs de type restore, verify, admin, qui ont chacun des exigences
+diff\'erentes.
+
\label{PoolsVolsLabels}
\subsection*{Comprendre les Pools, Volumes et Labels}
\`a franchir, et elles vous permettent d'utiliser plusieurs Volumes (plut\^ot
que d'\^etre limit\'e \`a la capacit\'e d'un seul). Les Pools vous procurent
aussi une flexibilit\'e importante pour votre politique de sauvegarde. Par
-exemple, vous pouvez avoir un Pool de Volumes ``Daily'' pour vos sauvegardes
-Incr\'ementales et un Pool de Volumes ``Weekly'' pour vos sauvegardes
+exemple, vous pouvez avoir un Pool de Volumes "Daily" pour vos sauvegardes
+Incr\'ementales et un Pool de Volumes "Weekly" pour vos sauvegardes
compl\`etes (Full). En sp\'ecifiant le Pool appropri\'e dans les Jobs de
sauvegarde quotidiens et hebdomadaires, vous garantissez qu'aucun Job
quotidien n'\'ecrira jamais sur un Volume du Pool r\'eserv\'e aux sauvegardes
Le programme console est utilis\'e par l'administrateur pour interagir avec le
Director et pour arr\^eter et d\'emarrer manuellement des jobs, ou encore pour
obtenir des informations sur les jobs en cours d'ex\'ecution ou programm\'es.
+
Le fichier de configuration de la Console se trouve dans le r\'epertoire que
vous avez sp\'ecifi\'e au niveau de l'option {\bf \verb{--{sysconfdir} de la commande
{\bf ./configure} et par d\'efaut se nomme {\bf console.conf}.
Si vous avez choisi de construire la Console GNOME avec l'option {\bf
-\verb{--{enable-gnome}, vous y trouverez aussi son fichier de configuration par
+\verb{--{enable-gnome}, vous y trouverez \'egalement son fichier de configuration par
d\'efaut, nomm\'e {\bf gnome-console.conf}.
Il en va de m\^eme pour la console wxWidgets, qui est construite par l'option
-{\bf \verb{--{enable-wx-console}, et le nom du fichier de configuration par d\'efaut
-est, dans ce cas, {\bf wx-console.conf}. Normalement, pour les nouveaux
+{\bf \verb{--{enable-bwx-console}, et le nom du fichier de configuration par d\'efaut
+est, dans ce cas, {\bf bwx-console.conf}.
+
+Normalement, pour les nouveaux
utilisateurs, aucune modification n'est requise pour ces fichiers. Les
r\'eglages par d\'efaut sont raisonnables.
\`a corriger les erreurs. Ainsi, si votre syst\`eme est {\bf foobaz}, vous
nommerez le {\it daemon} {\bf foobaz-fd}. Pour le Director, vous pourriez
utiliser {\bf foobaz-dir}, et {\bf foobaz-sd} pour le Storage Daemon.
+Chacun de vos composants de Bacula {\bf doit} avoir un nom unique
+Si vous les nommez tous \`a l'identique, en plus de ne jamais savoir
+quel {\it daemon} envoie quel message, s'ils partagent le m\^eme r\'epertoire
+de travail (working directory), les noms de fichiers temporaires des {\it daemons}
+ne seront pas uniques et vous aurez d'\'etranges erreurs.
\subsubsection*{
\ilink{Configurer le Storage Daemon}{_ChapterStart31}}
fichier pour accorder les noms de p\'eriph\'eriques de stockage \`a ceux que
vous poss\'edez. Si le processus d'installation a convenablement d\'etect\'e
votre syst\`eme, elles seront d\'ej\`a correctement r\'egl\'ees. Ces
-ressources de stockage ``Name'' et ``Media Type'' doivent \^etre les m\^emes
+ressources de stockage "Name" et "Media Type" doivent \^etre les m\^emes
que leurs correspondantes du fichier de configuration du Director {\bf
bacula-dir.conf}. Si vous souhaitez sauvegarder vers un fichier plut\^ot que
sur des bandes, la ressource Device doit pointer vers un r\'epertoire o\`u des
./bacula-sd -t -c bacula-sd.conf
./bconsole -t -c bconsole.conf
./gnome-console -t -c gnome-console.conf
-./wx-console -t -c wx-console.conf
+./bwx-console -t -c wx-console.conf
su <normal user> -c "./bacula-tray-monitor -t -c tray-monitor.conf"
\end{verbatim}
\normalsize
valable sur votre syst\`eme. Si vous avez install\'e les binaires dans les
r\'epertoires traditionnels d'Unix plut\^ot que dans un simple r\'epertoire,
il vous faudra modifier les commandes ci-dessus en cons\'equence (pas de
-``./'' devant les commandes, et un chemin devant les fichiers de
+"./" devant les commandes, et un chemin devant les fichiers de
configuration).
\label{TapeTesting}
syst\`emes Red Hat r\'ecents (kernels 2.4.x) est d\'efectueuse. Vous devez la
supprimer ou la renommer, puis rebooter votre syst\`eme avant d'ex\'ecuter
Bacula, faute de quoi, apr\`es environ une semaine de fonctionnement, Bacula
-se bloquera pour de longues p\'eriodes, voire d\'efinitivement. Les retours
-que nous avons concernant les noyaux 2.6 sont identiques. Cependant, sur les
-syst\`emes en noyaux 2.6, vous pouvez pr\'ef\'erer utiliser le chargeur de
-variable d'environnement (the loader environment variable override) plut\^ot
-que de supprimer /lib/tls. Veuillez consulter le chapitre
-\ilink{Syst\`emes support\'es}{SupportedOSes} pour plus
+se bloquera pour de longues p\'eriodes, voire d\'efinitivement. Veuillez consulter
+le chapitre \ilink{Syst\`emes support\'es}{SupportedOSes} pour plus
d'informations sur ce probl\`eme.
+
+Ce probl\`eme n'existe plus avec les noyaux 2.6.
+
\label{Running1}
\subsection*{Ex\'ecuter Bacula}
mensuelle et seront conserv\'es pour une dur\'ee maximum de cinq mois. Vous
pouvez \'editer ce fichier pour adapter la rotation \`a votre convenance.
+\subsection*{Log Watch}
+\index[general]{Watch!Log}
+\index[general]{Log Watch}
+\addcontentsline{toc}{subsection}{Log Watch}
+Certains syst\`emes tels que RedHat et Fedora ex\'ecutent le programme
+logwatch chaque nuit pour analyser vos fichiers de log et vous
+envoyer un rapport par mail. Si vous souhaitez inclure la sortie
+de vos jobs Bacula dans ce rapport, veuillez regarder dans le r\'epertoire
+{\bf scripts/logwatch}. Le fichier {\bf README} fournit une br\`eve
+explication sur la fa\\ 3on d'installer le script, et quelle genre
+de r\'esultats en attendre.
+
\subsection*{Reprise d'activit\'e apr\`es un d\'esastre (disaster recovery)}
\index[general]{Recovery!Reprise d'activit\'e apr\`es un d\'esastre disaster }
\index[general]{Reprise d'activit\'e apr\`es un d\'esastre (disaster recovery)
projects / bacula / docs / blobdiff