From: Kern Sibbald Date: Thu, 13 Dec 2007 12:39:01 +0000 (+0000) Subject: Make build for French manual X-Git-Tag: Release-3.0.0~2153 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=459acface48a3ff30c1adc95488b887ee984e94f;p=bacula%2Fdocs Make build for French manual --- diff --git a/docs/Makefile.in b/docs/Makefile.in index cc383604..451e35e2 100644 --- a/docs/Makefile.in +++ b/docs/Makefile.in @@ -20,6 +20,11 @@ en_dirs = manuals/en/catalog manuals/en/concepts manuals/en/console \ manuals/en/developers manuals/en/install manuals/en/problems \ manuals/en/utility +fr_dirs = manuals/fr/catalog manuals/fr/concepts manuals/fr/console \ + manuals/fr/developers manuals/fr/install manuals/fr/problems \ + manuals/fr/utility + + DIST = Makefile.in #------------------------------------------------------------------------- @@ -33,6 +38,12 @@ all: (cd bacula-web; make) @echo "All manuals built ..." +french: + @for I in ${fr_dirs}; \ + do (cd $$I; echo "==>Entering directory `pwd`"; \ + $(MAKE) $@ || (echo ""; echo ""; echo " ====== Error in `pwd` ======"; \ + echo ""; echo "";)); \ + done configure: autoconf/configure.in autoconf/aclocal.m4 autoconf/acconfig.h cd $(srcdir); @@ -67,9 +78,8 @@ $(basedir)/$(VERNAME).lsm: LSM.in $(srcdir)/../autoconf/Make.common.in $(srcdir) clean: $(RMF) *~ 1 2 3 bacula-doc*.tar.gz (cd manual-de; make clean) - (cd manual-fr; make clean) (cd bacula-web; make clean) - @for I in ${en_dirs}; \ + @for I in ${en_dirs} ${fr_dirs}; \ do (cd $$I; echo "==>Entering directory `pwd`"; ${MAKE} $@ || exit 1); done @@ -81,9 +91,8 @@ distclean: clean $(RMF) -rf autom4te.cache bacula-doc-* config.log config.out $(RMF) -f config.status kernsconfig (cd manual-de; make distclean) - (cd manual-fr; make distclean) (cd bacula-web; make distclean) - @for I in ${en_dirs}; \ + @for I in ${en_dirs} ${fr_dirs}; \ do (cd $$I; echo "==>Entering directory `pwd`"; ${MAKE} $@ || exit 1); done diff --git a/docs/autoconf/configure.in b/docs/autoconf/configure.in index d57a5668..48e7cba6 100644 --- a/docs/autoconf/configure.in +++ b/docs/autoconf/configure.in @@ -111,12 +111,30 @@ AC_OUTPUT([ \ manuals/en/utility/Makefile \ manuals/en/utility/update_version \ manuals/en/utility/version.tex \ + manuals/fr/catalog/Makefile \ + manuals/fr/catalog/update_version \ + manuals/fr/catalog/version.tex \ + manuals/fr/concepts/Makefile \ + manuals/fr/concepts/update_version \ + manuals/fr/concepts/version.tex \ + manuals/fr/console/Makefile \ + manuals/fr/console/update_version \ + manuals/fr/console/version.tex \ + manuals/fr/developers/Makefile \ + manuals/fr/developers/update_version \ + manuals/fr/developers/version.tex \ + manuals/fr/install/Makefile \ + manuals/fr/install/update_version \ + manuals/fr/install/version.tex \ + manuals/fr/problems/Makefile \ + manuals/fr/problems/update_version \ + manuals/fr/problems/version.tex \ + manuals/fr/utility/Makefile \ + manuals/fr/utility/update_version \ + manuals/fr/utility/version.tex \ manual-de/Makefile \ manual-de/version.tex \ manual-de/update_version \ - manual-fr/Makefile \ - manual-fr/version.tex \ - manual-fr/update_version \ bacula-web/Makefile \ bacula-web/version.tex \ $PFILES ], @@ -130,7 +148,13 @@ chmod 766 manuals/en/developers/update_version chmod 766 manuals/en/install/update_version chmod 766 manuals/en/problems/update_version chmod 766 manuals/en/utility/update_version -chmod 766 manual-fr/update_version +chmod 766 manuals/fr/catalog/update_version +chmod 766 manuals/fr/concepts/update_version +chmod 766 manuals/fr/console/update_version +chmod 766 manuals/fr/developers/update_version +chmod 766 manuals/fr/install/update_version +chmod 766 manuals/fr/problems/update_version +chmod 766 manuals/fr/utility/update_version chmod 766 manual-de/update_version echo " diff --git a/docs/configure b/docs/configure index 85a86b1f..994c6498 100755 --- a/docs/configure +++ b/docs/configure @@ -1768,7 +1768,7 @@ MCOMMON=./autoconf/Make.common - ac_config_files="$ac_config_files autoconf/Make.common Makefile manuals/en/catalog/Makefile manuals/en/catalog/update_version manuals/en/catalog/version.tex manuals/en/concepts/Makefile manuals/en/concepts/update_version manuals/en/concepts/version.tex manuals/en/console/Makefile manuals/en/console/update_version manuals/en/console/version.tex manuals/en/developers/Makefile manuals/en/developers/update_version manuals/en/developers/version.tex manuals/en/install/Makefile manuals/en/install/update_version manuals/en/install/version.tex manuals/en/problems/Makefile manuals/en/problems/update_version manuals/en/problems/version.tex manuals/en/utility/Makefile manuals/en/utility/update_version manuals/en/utility/version.tex manual-de/Makefile manual-de/version.tex manual-de/update_version manual-fr/Makefile manual-fr/version.tex manual-fr/update_version bacula-web/Makefile bacula-web/version.tex $PFILES" + ac_config_files="$ac_config_files autoconf/Make.common Makefile manuals/en/catalog/Makefile manuals/en/catalog/update_version manuals/en/catalog/version.tex manuals/en/concepts/Makefile manuals/en/concepts/update_version manuals/en/concepts/version.tex manuals/en/console/Makefile manuals/en/console/update_version manuals/en/console/version.tex manuals/en/developers/Makefile manuals/en/developers/update_version manuals/en/developers/version.tex manuals/en/install/Makefile manuals/en/install/update_version manuals/en/install/version.tex manuals/en/problems/Makefile manuals/en/problems/update_version manuals/en/problems/version.tex manuals/en/utility/Makefile manuals/en/utility/update_version manuals/en/utility/version.tex manuals/fr/catalog/Makefile manuals/fr/catalog/update_version manuals/fr/catalog/version.tex manuals/fr/concepts/Makefile manuals/fr/concepts/update_version manuals/fr/concepts/version.tex manuals/fr/console/Makefile manuals/fr/console/update_version manuals/fr/console/version.tex manuals/fr/developers/Makefile manuals/fr/developers/update_version manuals/fr/developers/version.tex manuals/fr/install/Makefile manuals/fr/install/update_version manuals/fr/install/version.tex manuals/fr/problems/Makefile manuals/fr/problems/update_version manuals/fr/problems/version.tex manuals/fr/utility/Makefile manuals/fr/utility/update_version manuals/fr/utility/version.tex manual-de/Makefile manual-de/version.tex manual-de/update_version bacula-web/Makefile bacula-web/version.tex $PFILES" ac_config_commands="$ac_config_commands default" cat >confcache <<\_ACEOF # This file is a shell script that caches the results of configure @@ -2347,12 +2347,30 @@ do "manuals/en/utility/Makefile" ) CONFIG_FILES="$CONFIG_FILES manuals/en/utility/Makefile" ;; "manuals/en/utility/update_version" ) CONFIG_FILES="$CONFIG_FILES manuals/en/utility/update_version" ;; "manuals/en/utility/version.tex" ) CONFIG_FILES="$CONFIG_FILES manuals/en/utility/version.tex" ;; + "manuals/fr/catalog/Makefile" ) CONFIG_FILES="$CONFIG_FILES manuals/fr/catalog/Makefile" ;; + "manuals/fr/catalog/update_version" ) CONFIG_FILES="$CONFIG_FILES manuals/fr/catalog/update_version" ;; + "manuals/fr/catalog/version.tex" ) CONFIG_FILES="$CONFIG_FILES manuals/fr/catalog/version.tex" ;; + "manuals/fr/concepts/Makefile" ) CONFIG_FILES="$CONFIG_FILES manuals/fr/concepts/Makefile" ;; + "manuals/fr/concepts/update_version" ) CONFIG_FILES="$CONFIG_FILES manuals/fr/concepts/update_version" ;; + "manuals/fr/concepts/version.tex" ) CONFIG_FILES="$CONFIG_FILES manuals/fr/concepts/version.tex" ;; + "manuals/fr/console/Makefile" ) CONFIG_FILES="$CONFIG_FILES manuals/fr/console/Makefile" ;; + "manuals/fr/console/update_version" ) CONFIG_FILES="$CONFIG_FILES manuals/fr/console/update_version" ;; + "manuals/fr/console/version.tex" ) CONFIG_FILES="$CONFIG_FILES manuals/fr/console/version.tex" ;; + "manuals/fr/developers/Makefile" ) CONFIG_FILES="$CONFIG_FILES manuals/fr/developers/Makefile" ;; + "manuals/fr/developers/update_version" ) CONFIG_FILES="$CONFIG_FILES manuals/fr/developers/update_version" ;; + "manuals/fr/developers/version.tex" ) CONFIG_FILES="$CONFIG_FILES manuals/fr/developers/version.tex" ;; + "manuals/fr/install/Makefile" ) CONFIG_FILES="$CONFIG_FILES manuals/fr/install/Makefile" ;; + "manuals/fr/install/update_version" ) CONFIG_FILES="$CONFIG_FILES manuals/fr/install/update_version" ;; + "manuals/fr/install/version.tex" ) CONFIG_FILES="$CONFIG_FILES manuals/fr/install/version.tex" ;; + "manuals/fr/problems/Makefile" ) CONFIG_FILES="$CONFIG_FILES manuals/fr/problems/Makefile" ;; + "manuals/fr/problems/update_version" ) CONFIG_FILES="$CONFIG_FILES manuals/fr/problems/update_version" ;; + "manuals/fr/problems/version.tex" ) CONFIG_FILES="$CONFIG_FILES manuals/fr/problems/version.tex" ;; + "manuals/fr/utility/Makefile" ) CONFIG_FILES="$CONFIG_FILES manuals/fr/utility/Makefile" ;; + "manuals/fr/utility/update_version" ) CONFIG_FILES="$CONFIG_FILES manuals/fr/utility/update_version" ;; + "manuals/fr/utility/version.tex" ) CONFIG_FILES="$CONFIG_FILES manuals/fr/utility/version.tex" ;; "manual-de/Makefile" ) CONFIG_FILES="$CONFIG_FILES manual-de/Makefile" ;; "manual-de/version.tex" ) CONFIG_FILES="$CONFIG_FILES manual-de/version.tex" ;; "manual-de/update_version" ) CONFIG_FILES="$CONFIG_FILES manual-de/update_version" ;; - "manual-fr/Makefile" ) CONFIG_FILES="$CONFIG_FILES manual-fr/Makefile" ;; - "manual-fr/version.tex" ) CONFIG_FILES="$CONFIG_FILES manual-fr/version.tex" ;; - "manual-fr/update_version" ) CONFIG_FILES="$CONFIG_FILES manual-fr/update_version" ;; "bacula-web/Makefile" ) CONFIG_FILES="$CONFIG_FILES bacula-web/Makefile" ;; "bacula-web/version.tex" ) CONFIG_FILES="$CONFIG_FILES bacula-web/version.tex" ;; "$PFILES" ) CONFIG_FILES="$CONFIG_FILES $PFILES" ;; @@ -2855,7 +2873,13 @@ chmod 766 manuals/en/developers/update_version chmod 766 manuals/en/install/update_version chmod 766 manuals/en/problems/update_version chmod 766 manuals/en/utility/update_version -chmod 766 manual-fr/update_version +chmod 766 manuals/fr/catalog/update_version +chmod 766 manuals/fr/concepts/update_version +chmod 766 manuals/fr/console/update_version +chmod 766 manuals/fr/developers/update_version +chmod 766 manuals/fr/install/update_version +chmod 766 manuals/fr/problems/update_version +chmod 766 manuals/fr/utility/update_version chmod 766 manual-de/update_version echo " diff --git a/docs/manual-fr/LISEZ-MOI b/docs/manual-fr/LISEZ-MOI deleted file mode 100644 index 8bfef083..00000000 --- a/docs/manual-fr/LISEZ-MOI +++ /dev/null @@ -1,66 +0,0 @@ -Bonjour, - - Je regroupe ici quelques conseils pour les personnes qui souhaitent - participer a la traduction de la documentation. - - * Pour obtenir un acces au CVS, contactez Kern : kern@sibbald.com. - * Si vous ne connaissez pas CVS, documentez-vous. Ce tutoriel vous - permettra de demarrer rapidement : - http://www.gentoo.org/doc/fr/cvs-tutorial.xml - * IMPORTANT : PAS DE COMMIT EN DEHORS DU REPERTOIRE LATEX-FR !!! - * Choisissez un fichier du repertoire - docs/manual-fr correspondant a un chapitre que - vous avez envie de traduire, verifiez sur cette liste qu'il n'est - pas affecte a quelqu'un d'autre, et annoncez sur cette liste que - vous en commencez la traduction. - * Faites une mise a jour de votre repertoire - docs/manual-fr en vous placant dans celui-ci et - en utilisant cvs update. - * Traduisez directement le fichier .tex, sans vous preoccuper du - fichier .html correspondant. - * Vous pouvez a tout moment voir le resultat de votre traduction : - - le plus rapide : make tex puis xdvi bacula ; - - pour avoir tout le manuel dans un seul grand fichier html : - make tex html. Ouvrez le fichier bacula.html avec un navigateur. - - pour avoir le manuel tel que sur le site web : make tex web, - puis ouvrez index.html avec un navigateur. - Il est important de relire votre travail de cette facon avant - publication pour voir les defauts qui vous ont echappe. - * Refaites une mise a jour cvs update. - * Publiez avec commit. - - Lorque vous avez un doute sur un point de traduction, n'hesitez pas a - faire appel a cette liste. Je ne sais pas quelle est la meilleure - methode pour demander de l'aide, mais je vais essayer ce qui suit : - - * Insertion d'un lien interne a la page a l'emplacement du probleme - rencontre : /dev/null - makeindex bacula.ddx -o bacula.dnd >/dev/null 2>/dev/null - makeindex bacula.fdx -o bacula.fnd >/dev/null 2>/dev/null - makeindex bacula.sdx -o bacula.snd >/dev/null 2>/dev/null - makeindex bacula.cdx -o bacula.cnd >/dev/null 2>/dev/null - -latex -interaction=batchmode bacula.tex - -latex -interaction=batchmode bimagemgr.tex - -pdf: - @echo "Making pdfm" - @cp -fp ${IMAGES}/hires/*.eps . - dvipdfm -p a4 bacula.dvi - dvipdfm -p a4 bimagemgr.dvi - -dvipdf: - @echo "Making dvi to pdf" - @cp -fp ${IMAGES}/hires/*.eps . - dvipdf bacula.dvi bacula.pdf - dvipdf bimagemgr.dvi bimagemgr.pdf - -html: - @echo " " - @echo "Making html" - @cp -fp ${IMAGES}/*.eps . - @rm -f next.eps next.png prev.eps prev.png up.eps up.png - @(if [ -f imagename_translations ] ; then \ - ./translate_images.pl --from_meaningful_names bacula.html; \ - fi) - latex2html -white -no_subdir -split 0 -toc_stars -white -notransparent \ - -init_file latex2html-init.pl bacula >tex.out 2>&1 - ./translate_images.pl --to_meaningful_names bacula.html - @echo "Done making html" - -web: - @echo "Making web" - @mkdir -p bacula - @cp -fp ${IMAGES}/*.eps . - @rm -f next.eps next.png prev.eps prev.png up.eps up.png - @cp -fp ${IMAGES}/*.eps *.txt bacula - @cp -fp ${IMAGES}/*.eps *.txt ${IMAGES}/*.png bacula - @rm -f bacula/xp-*.png - @rm -f bacula/next.eps bacula/next.png bacula/prev.eps bacula/prev.png bacula/up.eps bacula/up.png - @rm -rf bacula/*.html - latex2html -split 4 -local_icons -t "Bacula User's Guide" -long_titles 4 \ - -toc_stars -contents_in_nav -init_file latex2html-init.pl -white -notransparent bacula >tex.out 2>&1 - ./translate_images.pl --to_meaningful_names bacula/Bacula_Users_Guide.html - cp -f bacula/Bacula_Freque_Asked_Questi.html bacula/faq.html - @echo "Done making web" -show: - xdvi bacula - -texcheck: - ./check_tex.pl bacula.tex - -main_configs: - pic2graph -density 100 main_configs.png - -mini-clean: - @rm -f 1 2 3 *.tex~ - @rm -f *.gif *.jpg *.eps - @rm -f *.aux *.cp *.fn *.ky *.log *.pg - @rm -f *.backup *.ilg *.lof *.lot - @rm -f *.cdx *.cnd *.ddx *.ddn *.fdx *.fnd *.ind *.sdx *.snd - @rm -f *.dnd *.old *.out - @rm -f bacula/*.gif bacula/*.jpg bacula/*.eps - @rm -f bacula/*.aux bacula/*.cp bacula/*.fn bacula/*.ky bacula/*.log bacula/*.pg - @rm -f bacula/*.backup bacula/*.ilg bacula/*.lof bacula/*.lot - @rm -f bacula/*.cdx bacula/*.cnd bacula/*.ddx bacula/*.ddn bacula/*.fdx bacula/*.fnd bacula/*.ind bacula/*.sdx bacula/*.snd - @rm -f bacula/*.dnd bacula/*.old bacula/*.out - @rm -f bacula/WARNINGS - - -clean: - @rm -f 1 2 3 *.tex~ - @rm -f *.png *.gif *.jpg *.eps - @rm -f *.pdf *.aux *.cp *.fn *.ky *.log *.pg - @rm -f *.html *.backup *.ps *.dvi *.ilg *.lof *.lot - @rm -f *.cdx *.cnd *.ddx *.ddn *.fdx *.fnd *.ind *.sdx *.snd - @rm -f *.dnd imagename_translations - @rm -f *.old WARNINGS *.out *.toc *.idx - @rm -f baculai-dir.tex baculai-fd.tex baculai-sd.tex \ - baculai-console.tex baculai-general.tex images.tex - - -distclean: - @rm -f 1 2 3 *.tex~ - @rm -f *.gif *.jpg *.eps - @rm -f *.aux *.cp *.fn *.ky *.log *.pg - @rm -f *.backup *.ps *.dvi *.ilg *.lof *.lot - @rm -f *.cdx *.cnd *.ddx *.ddn *.fdx *.fnd *.ind *.sdx *.snd - @rm -f *.dnd imagename_translations - @rm -f *.old WARNINGS *.out *.toc *.idx - @rm -f images.pl labels.pl internals.pl - @rm -f baculai-dir.tex baculai-fd.tex baculai-sd.tex \ - baculai-console.tex baculai-general.tex images.tex diff --git a/docs/manual-fr/ansi-labels.tex b/docs/manual-fr/ansi-labels.tex deleted file mode 100644 index 0cb4f680..00000000 --- a/docs/manual-fr/ansi-labels.tex +++ /dev/null @@ -1,61 +0,0 @@ - -\section*{ANSI and IBM Tape Labels} -\label{_ChapterStart62} -\index[general]{ANSI and IBM Tape Labels} -\index[general]{Labels!Tape} -\addcontentsline{toc}{section}{ANSI and IBM Tape Labels} - -Bacula supports ANSI or IBM tape labels as long as you -enable it. In fact, with the proper configuration, you can -force Bacula to require ANSI or IBM labels. - -Bacula can create an ANSI or IBM label, but if Check Labels is -enabled (see below), Bacula will look for an existing label, and -if it is found, it will keep the label. Consequently, you -can label the tapes with programs other than Bacula, and Bacula -will recognize and support them. - -Even though Bacula will recognize and write ANSI and IBM labels, -it always writes its own tape labels as well. - -When using ANSI or IBM tape labeling, you must restrict your Volume -names to a maximum of 6 characters. - -If you have labeled your Volumes outside of Bacula, then the -ANSI/IBM label will be recognized by Bacula only if you have created -the HDR1 label with {\bf BACULA.DATA} in the Filename field (starting -with character 5). If Bacula writes the labels, it will use -this information to recognize the tape as a Bacula tape. This allows -ANSI/IBM labeled tapes to be used at sites with multiple machines -and multiple backup programs. - - -\subsection*{Director Pool Directive} -\addcontentsline{toc}{section}{Director Pool Directive} - -\begin{description} -\item [ Label Type = ANSI | IBM | Bacula] - This directive is implemented in the Director Pool resource and in the SD Device - resource. If it is specified in the SD Device resource, it will take - precedence over the value passed from the Director to the SD. The default - is Label Type = Bacula. -\end{description} - -\subsection*{Storage Daemon Device Directives} -\addcontentsline{toc}{section}{Storage Daemon Device Directives} - -\begin{description} -\item [ Label Type = ANSI | IBM | Bacula] - This directive is implemented in the Director Pool resource and in the SD Device - resource. If it is specified in the the SD Device resource, it will take - precedence over the value passed from the Director to the SD. - -\item [Check Labels = yes | no] - This directive is implemented in the the SD Device resource. If you intend - to read ANSI or IBM labels, this *must* be set. Even if the volume is - not ANSI labeled, you can set this to yes, and Bacula will check the - label type. Without this directive set to yes, Bacula will assume that - labels are of Bacula type and will not check for ANSI or IBM labels. - In other words, if there is a possibility of Bacula encountering an - ANSI/IBM label, you must set this to yes. -\end{description} diff --git a/docs/manual-fr/autochangerres.tex b/docs/manual-fr/autochangerres.tex deleted file mode 100644 index 670a9c36..00000000 --- a/docs/manual-fr/autochangerres.tex +++ /dev/null @@ -1,109 +0,0 @@ -\chapter*{La ressource Autochanger} -\label{Autochangerres} -\index[sd]{Autochanger Ressource } -\index[sd]{Ressource!Autochanger } - -La ressource Autochanger supporte les librairies \`a un ou plusieurs -lecteurs en regroupant une ou plusieurs ressources Device en une -unit\'e nomm\'ee Autochanger dans Bacula (souvent d\'esign\'ee en tant que -librairie de bandes par les constructeurs). Si vous poss\'edez une -librairie, et si vous voulez qu'elle fonctionne correctement, vous -{\bf devez} avoir une ressource Autochanger dans le fichier de -configuration de votre Storage Daemon, et les directives Storage -de votre Director {\bf doivent} se r\'ef\'erer au nom de la ressource -Autochanger si elles sont suppos\'ees utiliser la librairie. Dans les -versions ant\'erieures \`a 1.38.0, les directives Storage du Director -se r\'ef\'eraient directement aux ressources Device qui \'etaient des -librairies. D\'esormais, ce type de r\'ef\'erence directe ne fonctionne -plus avec les librairies. - -\begin{description} -\item [Name = \lt{}Autochanger-Name\gt{}] - \index[sd]{Name} - Sp\'ecifie le nom de la librairie. Ce nom est utilis\'e dans la - la d\'efinition de ressource Storage du Director afin de d\'esigner - la librairie. Cette directive est requise. - -\item [Device = \lt{}Device-name1, device-name2, ...\gt{}] - Sp\'ecifie le nom de la (ou des) ressource(s) Device associ\'ees \`a la - librairie. Si votre librairie contient plusieurs lecteurs, vous - devez sp\'ecifier plusieurs noms de ressources Device, chacun d\'esignant - une ressource Device distincte qui comporte un - Drive Index correspondant au num\'ero de lecteur. Vous pouvez sp\'ecifier - plusieurs noms en une seule ligne s\'epar\'es par des virgules ou/et utiliser - plusieurs fois la directive Device. Cette directive est requise. - -\item [Changer Device = {\it name-string}] - \index[sd]{Changer Device} - La cha\^ine {\bf name-string} sp\'ecifi\'ee indique le nom du fichier syst\`eme - d\'esignant la librairie. S'il est sp\'ecifi\'e dans cette ressource, ce nom - n'est pas requis dans la ressource Device. Le nom \'eventuellement sp\'ecifi\'e - dans la ressource Device prend le pas sur celui sp\'ecifi\'e dans la ressource - Autochanger. - -\item [Changer Command = {\it name-string}] - \index[sd]{Changer Command } - La cha\^ine {\bf name-string} sp\'ecifie un programme externe appel\'e pour - changer de volume automatiquement \`a la demande de Bacula. La plupart du - temps, vous renseignerez ce champ avec le script fourni {\bf mtx-changer} - comme suit. Si cette commande est sp\'ecifi\'ee ici, elle n'a pas besoin de - l'\^etre dans la ressource Device. Dans le cas o\`u elle le serait dans les deux - ressources, la sp\'ecification de la ressource Device prendrait le pas sur celle - de la ressource Autochanger. - -\end{description} - -Voici un exemple de d\'efinition de ressource Autochanger valide : - -\footnotesize -\begin{verbatim} -Autochanger { - Name = "DDS-4-changer" - Device = DDS-4-1, DDS-4-2, DDS-4-3 - Changer Device = /dev/sg0 - Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d" -} -Device { - Name = "DDS-4-1" - Drive Index = 0 - Autochanger = yes - ... -} -Device { - Name = "DDS-4-2" - Drive Index = 1 - Autochanger = yes - ... -Device { - Name = "DDS-4-3" - Drive Index = 2 - Autochanger = yes - Autoselect = no - ... -} -\end{verbatim} -\normalsize - -Notez l'importance de la directive {\bf Autochanger = yes} dans chaque d\'efinition -de p\'eriph\'erique appartenant \`a une librairie. Un p\'eriph\'erique ne devrait pas \^etre -d\'efini comme appartenant \`a plusieurs librairies. Aussi, votre directive Device -dans la ressource Storage du Director devrait comporter le nom de la ressource -Autochanger plut\^ot que le nom de l'un des lecteurs. - -Si vous avez un lecteur qui appartient physiquement \`a une librairie mais que -vous ne souhaitez pas que Bacula puisse l'utiliser automatiquement (par exemple, -si vous voulez le r\'eserver pour les restaurations) vous pouvez utiliser la -directive : - -\footnotesize -\begin{verbatim} -Autoselect = no -\end{verbatim} -\normalsize - -\`a la ressource Device de ce lecteur. Dans ce cas, Bacula ne le s\'electionnera pas -automatiquement en acc\'edant \`a la librairie. Vous pouvez encore utiliser le lecteur en -le d\'esignant par son nom de ressource device plut\^ot que par celui de la ressource -Autochanger. Un exemple d'une telle d\'efinition est montr\'e ci-dessus pour le -lecteur DDS-4-3, qui ne sera pas s\'electionn\'e si le nom DDS-4-changer est utilis\'e -dans une ressource Storage, mais le sera si DDS-4-3 est utilis\'e. diff --git a/docs/manual-fr/autochangers.tex b/docs/manual-fr/autochangers.tex deleted file mode 100644 index 29a82b7b..00000000 --- a/docs/manual-fr/autochangers.tex +++ /dev/null @@ -1,936 +0,0 @@ -%% -%% - -\chapter*{Support des librairies} -\label{AutochangersChapter} -\index[general]{Support!Librairies} -\index[general]{Autochanger Support } -\addcontentsline{toc}{section}{Support des librairies} - -Bacula supporte les librairies pour les op\'erations de lecture et \'ecriture. -Plusieurs conditions sont requises pour que Bacula puisse utiliser une librairie. -Celles-ci sont expliqu\'ees en d\'etail ci-dessous. -Mais voyons d'abord la liste de ces conditions : - -\begin{itemize} -\item Un script charg\'e de piloter la librairie en accord avec les commandes - envoy\'ees par Bacula est requis. Nous fournissons un tel script pr\'evu pour fonctionner - avec le programme {\bf mtx} disponible dans les paquets {\bf depkgs}. ce script ne - fonctionne qu'avec les librairies \`a un seul lecteur. -\item Chaque volume \`a utiliser doit \^etre d\'efini dans le catalogue et avoir - un num\'ero de slot (NDT : emplacement dans la librairie) assign\'e, de sorte - que Bacula puisse savoir o\`u se trouve le volume dans la librairie. Cet - enregistrement se fait la plupart du temps gr\^ace \`a la commande {\bf label}. - Voyez ci-dessous pour plus de d\'etails. Vous devez \'etiqueter manuellement - vos cartouches avant de pouvoir les utiliser. -\item Vous devez avoir modifi\'e le fichier de configuration de votre Storage - Daemon afin que la ressource Device identifie votre p\'eriph\'erique en tant - que librairie. Quelques autres param\`etres doivent \^etre d\'efinis. -\item Vous devriez aussi modifier la d\'efinition de ressource Storage dans le -fichier de configuration du Director en sorte que le slot vous soit automatiquement -demand\'e lorque vous \'etiquetez un volume. -\item Si vous n'ex\'ecutez pas le Storage Daemon en tant que root, vous devez - vous assurer qu'il d\'etient les droits requis pour acc\'eder au lecteur et au - bras robotis\'e de la librairie. -\item Vous devez placer la directive {\bf Autochanger = yes} dans la - ressource Storage de votre fichier bacula-dir.conf, de sorte que vous soyez - interrog\'e au sujet du slot \`a chaque \'etiquetage de cartouche. -\end{itemize} - -Dans les versions ult\'erieures \`a 1.37, la nouvelle directive -\ilink{Autochanger resource}{AutochangerRes} permet de grouper les ressources -Device pour cr\'eer des librairies avec plusieurs lecteurs. Si vous avez une -librairie, vous devez utiliser cette ressource. - -Bacula utilise son propre script {\bf mtx-changer} pour interagir avec un -programme qui effectue r\'eellement les changement de cartouches. Ainsi, -{\bf mtx-changer} peut \^etre adapt\'e pour fonctionner avec n'importe quel -programme de prise en chgarge de librairie. La version actuelle de -{\bf mtx-changer} fonctionne avec le programme {\bf mtx} . Cependant, -des utilisateurs de FreeBSD ont r\'ealis\'e un script, disponible dans -le r\'epertoire {\bf examples/autochangers}, qui permet \`a Bacula de fonctionner -avec le programme {\bf chio}. - -Bacula supporte aussi les librairies \'equip\'ees de lecteurs de codes barres. -Ce support inclut deux commandes de la console Bacula : {\bf label barcodes} -et {\bf update slots}. Pour plus de d\'etails au sujet de ces commandes, -voyez la section "Support des lecteurs de codes barres" plus loin. - -Le support des librairies dans Bacula n'inclue pas, pour le moment, la gestion -du nettoyage des lecteurs, ni celle des bacs de cartouches ou des silos. - -Le support des librairies \`a un ou plusieurs lecteurs requiert la ressource -\ilink{Autochanger resource}{AutochangerRes}. - -En principe, si {\bf mtx} fonctionne correctement avec votre librairie, ce -n'est qu'une question d'adaptation du script {\bf mtx-changer} pour que -Bacula s'interface correctement avec la librairie. Vous pouvez trouver une -liste des librairies support\'ees par {\bf mtx} en suivant le lien suivant : -\elink{http://mtx.opensource-sw.net/compatibility.php} -{http://mtx.opensource-sw.net/compatibility.php}. -Le site officiel du projet {\bf mtx} se trouve ici : -\elink{http://mtx.opensource-sw.net/}{http://mtx.opensource-sw.net/}. - -Si vous avez des difficult\'es, veuillez utiliser la commande {\bf auto} du -programme {\bf btape} pour tester le fonctionnement de votre librairie -avec Bacula. Lorsque Bacula fonctionne, souvenez vous que pour beaucoup de -distributions (par exemple FreeBSD, Debian,...), le Storage Daemon est -ex\'ecut\'e en tant que {\bf bacula.tape} plut\^ot que {\bf root.root}, aussi -vous devrez vous assurer que le Storage Daemon dispose de droits suffisants pour -acc\'eder \`a la librairie. - -\label{SCSI devices} -\section*{D\'eterminer vos p\'eriph\'eriques SCSI} -\index[general]{D\'eterminer!p\'eriph\'eriques SCSI} -\index[general]{D\'eterminer vos p\'eriph\'eriques SCSI} -\index[general]{P\'eriph\'eriques} -\index[general]{p\'eriph\'eriques!SCSI} - -Sous Linux, vous pouvez lire le fichier /proc/scsi/scsi : - -\footnotesize -\begin{verbatim} -cat /proc/scsi/scsi -\end{verbatim} -\normalsize - -pour conna\^itre vos p\'eriph\'eriques SCSI. Vous pouvez aussi examiner les fichiers -/proc/scsi/sg/device\_hdr et /proc/scsi/sg/devices : - -footnotesize -\begin{verbatim} -cat /proc/scsi/sg/device_hdr /proc/scsi/sg/devices -\end{verbatim} -\normalsize - -pour d\'eterminer comment sp\'ecifier leur nom de p\'eriph\'erique ({\bf /dev/sg0} -pour le premier, {\bf /dev/sg1} pour le second, ...) au niveau de -la directive {\bf Changer Device} - -Pour des informations plus d\'etaill\'ees sur le sujet, veuillez consulter la -section \ilink{Linux SCSI Tricks}{SCSITricks} du chapitre sur les tests -de lecteurs de ce manuel. - -Sous FreeBSD, vous disposez de la commande : - -\footnotesize -\begin{verbatim} -camcontrol devlist -\end{verbatim} -\normalsize - -pour afficher la liste des p\'eriph\'eriques SCSI ainsi que le {\bf /dev/passn} -que vous utiliserez pour renseigner la directive {\bf Changer Device} - -Assurez-vous que votre Storage Daemon dispose bien des privil\`eges requis -pour acc\'eder \`a ce p\'eriph\'erique. - -L'astuce suivante, destin\'ee aux utilisateurs de FreeBSD, provient de -Danny Butroyd. Au red\'emarrage, Bacula n'aura PLUS les permissions -requises pour contr\^oler le p\'eriph\'erique /dev/pass0. Pour vous -affanchir de cette difficult\'e, \'editez le fichier /etc/devfs.conf et -ajoutez lui ceci : - -\footnotesize -\begin{verbatim} -own pass0 root:bacula -perm pass0 0666 -own nsa0.0 root:bacula -perm nsa0.0 0666 -\end{verbatim} -\normalsize - -Nous avons ainsi donn\'e au groupe Bacula la permission d'\'ecrire -sur le p\'eriph\'erique nsa0.0. Pour activer ces modifications, ex\'ecutez : -/etc/rc.d/devfs restart - -Vous n'aurez plus \`a modifier les permissions sur ces p\'eriph\'eriques -pour que Bacula continue d'utiliser la librairie apr\`es un red\'emarrage. - -\label{scripts} - -\section{Exemples de scripts} -\index[general]{Scripts!Exemples } -\index[general]{Exemples de scripts } - -Veuillez lire les sections ci-dessous pour bien comprendre comment -les librairies fonctionnent avec Bacula. Bien que nous fournissions -un script {\bf mtx-changer} par d\'efaut, il se peut que votre librairie -n\'ecessite quelques am\'enagements de ce script. Si vous voulez voir des -exemples de fichiers de configuration et de scripts, jetez un oeil -au r\'epertoire \lt{}bacula-src\gt{}/examples/devices o\`u vous -trouverez un exemple de ressource Device Bacula : {\bf HP-autoloader.conf} -ainsi que plusieurs scripts {\bf mtx-changer} modifi\'es pour fonctionner -avec diverses librairies. - -\label{Slots} - -\section*{Slots} -\index[general]{Slots } - -Pour utiliser convenablement une librairie, Bacula doit savoir quel volume -se trouve dans quel {\bf slot} de la librairie. Les slots sont les -emplacements o\`u sont rang\'ees les cartouches lorsqu'elles ne sont pas dans un -lecteur. Bacula num\'erote ces slots de un jusqu'au nombre de cartouches -contenues dans la librairie. - -Bacula n'utilisera pas automatiquement une cartouche pr\'esente dans la librairie -si elle ne porte pas d'\'etiquette (label) Bacula et si son num\'ero de slot n'est pas -r\'ef\'erenc\'e dans le catalogue. Vous devez, \`a l'aide de la console, assigner un -slot \`a chaque cartouche pr\'esente dans la librairie. Cette information est -conserv\'ee dans le catalogue avec les autres donn\'ees relatives au volume. -Si le slot n'est pas pr\'ecis\'e, ou s'il est \'egal \`a z\'ero, alors Bacula ne tentera -pas d'utiliser la librairie, m\^eme si tous les enregistrements de configuration -sont pr\'esents. De m\^eme, la commande {\bf mount} de la console Bacula ne -provoque pas non plus l'utilisation de la librairie, mais se contente d'ordonner -\`a Bacula de lire toute cartouche \'eventuellement pr\'esente dans le lecteur. - -Vous pouvez contr\^oler le num\'ero de slot et le drapeau InChanger avec la commande : - -\begin{verbatim} -list Volumes -\end{verbatim} - -dans la console. - -\label{mult} -\section*{Lecteurs multiples} -\index[general]{Lecteurs!Multiples } -\index[general]{Lecteurs ultiples} - -Certaines librairies comportent plusieurs p\'eriph\'eriques de lecture/\'ectriture -(lecteurs). La nouvelle \ilink{ressource Autochanger}{AutochangerRes} -apparue avec la version 1.37 vous permet de grouper des ressources Devices -(repr\'esentant chacune un lecteur). Le Director est toujours en mesure -d'adresser directement un lecteur, mais ce faisant, il outrepasse -le fonctionnement propre aux groupements de lecteurs. Il est pr\'ef\'erable -que la Ressource Storage du Director d\'efinisse une ressource -Autochanger, permettant ainsi au Storage Daemon de s'assurer qu'un seul -lecteur \`a la fois utilise le script mtx-changer, et que deux lecteurs ne tentent -pas de lire le m\^eme volume. - -Les librairies \`a lecteurs multiples n\'ecessitent d'utiliser la directive -{\bf Drive Index} dans la ressource Device du Storage Daemon. Les -lecteurs sont num\'erot\'es \`a partir de z\'ero, ce qui constitue la valeur par -d\'efaut. Pour utiliser un deuxi\`eme lecteur dans une librairie, vous devez -d\'efinir une seconde ressource Device et lui attribuer le Drive Index 1. -En g\'en\'eral, le second p\'eriph\'erique aura le m\^eme {\bf Changer Device} -(canal de contr\^ole) que le premier, mais une {\bf Archive Device} diff\'erente. - -Par d\'efaut, les jobs Bacula pr\'ef\`erent \'ecrire sur un volume d\'ej\`a mont\'e. -Si vous avez une librairie avec plusieurs lecteurs, et si vous souhaitez que -Bacula \'ecrive sur plusieurs volumes du m\^eme pool en m\^eme temps, vous devez -d\'esactiver la directive \ilink{Prefer Mounted Volumes} {PreferMountedVolumes} -dans la ressource Job du Director. Ainsi le Storage Daemon pourra maximiser -l'usage des lecteurs. - -\label{ConfigRecords} -\subsection*{Directives de la ressource Device} -\index[general]{Directives!ressource Device} -\index[general]{Directives de la ressource Device} - -La configuration des librairies s'effectue dans Bacula au niveau de le ressource -Device du Storage Daemon. Quatre directives permettent de d\'efinir l'usage de -la librairie par Bacula : {\bf Autochanger}, {\bf Changer Device}, -{\bf Changer Command} et {\bf Maximum Changer Wait} - -Ces quatre directives sont d\'ecrites en d\'etail ci-dessous. Notez cependant -que les directives {\bf Changer Device} et {\bf Changer Command} ne sont pas -requises dans la ressource Device si elles figurent dans la ressource -{\bf Autochanger}. - -\begin{description} - -\item [Autochanger = {\it Yes|No} ] - \index[sd]{Autochanger} - La directive {\bf Autochanger} stipule que le p\'eriph\'erique ainsi d\'efini est, ou - n'est pas, une librairie. La valeur par d\'efaut est {\bf no}. - -\item [Changer Device = \lt{}device-name\gt{}] - \index[sd]{Changer Device} - En plus du nom d'Archive Device, vous devez sp\'ecifier un nom de - librairie {\bf Changer Device}, ceci parce que la plupart des librairies - sont control\'ees via un pseudo-fichier diff\'erent de celui utilis\'e pour - lire et \'ecrire sur les cartouches. Par exemple, sur les syst\`emes Linux, - on utilise g\'en\'eralement l'interface SCSI g\'en\'erique pour contr\^oler le bras - de la librairie, soit {\bf Changer Device = /dev/sg0} et l'interface SCSI - standard pour lire et \'ecrire sur les bandes, soit {\bf Archive Device = /dev/nst0}. - Notez que certaines librairies \'evolu\'ees localiseront le bras sur - {\bf /dev/sg1}. De telles librairies ont souvent plusieurs lecteurs et un - nombre important de cartouches. - - Sur FreeBSD, on sp\'ecifiera typiquement {\bf Changer Device = /dev/pass0} ou - {\bf Changer Device = /dev/passn}. - - Sur Solaris, ce sera {\bf Changer Device = /dev/rdsk}. - - Assurez vous que votre Storage Daemon poss\`ede les permissions d'acc\'eder \`a - ce p\'eriph\'erique. - -\item [Changer Command = \lt{}command\gt{}] - \index[sd]{Changer Command } - Cette directive est utilis\'ee pour sp\'ecifier le programme externe \`a appeler - et les arguments \`a lui fournir. La commande est suppos\'ee \^etre un programme - ou un script shell standard qui peut \^etre ex\'ecut\'e par le syst\`eme. cette - commande est invoqu\'ee chaque fois que Bacula manipule le bras de la librairie. - Les substitutions suivantes sont effectu\'ees dans la ligne {\bf command} - avant qu'elle ne soit envoy\'ee au syst\`eme d'exploitation pour ex\'ecution. - -\footnotesize -\begin{verbatim} - %% = % - %a = archive device name - %c = changer device name - %d = changer drive index base 0 - %f = Client's name - %j = Job name - %o = command (loaded, load, or unload) - %s = Slot base 0 - %S = Slot base 1 - %v = Volume name -\end{verbatim} -\normalsize - -Voici un exemple d'utilisation de {\bf mtx} avec le script {\bf mtx-changer} : - -\footnotesize -\begin{verbatim} -Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d" -\end{verbatim} -\normalsize - -O\`u vous devrez adapter le chemin {\bf /etc/bacula} pour qu'il co\''incide \`a -la r\'ealit\'e de votre installation. Les d\'etails des trois commandes (loaded, -load, unload) utilis\'ees par Bacula ainsi que la sortie qui en est attendue -sont donn\'es dans la section {\bf Interface entre Bacula et les librairies} -ci-dessous. - -\item [Maximum Changer Wait = \lt{}time\gt{}] - \index[sd]{Maximum Changer Wait} - Cette directive sert \`a d\'efinir le d\'elai maximal durant lequel Bacula - attendra la r\'eponse d'une librairie \`a une commande (par exemple, load). - La valeur par d\'efaut est 120 secondes. Si votre librairie est lente, vous - pouvez avoir int\'er\^et \`a allonger ce d\'elai. - - Au del\`a de ce d\'elai, le programme de chargement est tu\'e et Bacula - sollicite l'intervention d'un op\'erateur. - -\item [Drive Index = \lt{}number\gt{}] - \index[sd]{Drive Index} - Cette directive vous permet d'indiquer \`a Bacula d'utiliser le second - lecteur et les \'eventuels suivants dans une librairie qui en contient - plusieurs. Etant donn\'e que les lecteurs sont num\'erot\'es \`a partir de - z\'ero, le second est d\'efini par : - -\footnotesize -\begin{verbatim} -Device Index = 1 -\end{verbatim} -\normalsize - -Pour utiliser le second lecteur, vous devez avoir une seconde d\'efinition -de ressource Device dans le fichier bacula-sd.conf. Voyez la section -concernant les lecteurs multiples plus haut dans ce chapitre pour plus -de plus amples informations. -\end{description} - -De plus, pour un fonctionnement correct de la librairie, vous devez d\'efinir -une ressource Autochanger. -\input{autochangerres} - -\label{example} -\section{Un exemple de fichier de configuration} -\index[general]{exemple fichier configuration} -\index[general]{fichier!exemple configuration} - -Les deux ressource suivantes impl\'ementent une librairie : - -\footnotesize -\begin{verbatim} -Autochanger { - Name = "Autochanger" - Device = DDS-4 - Changer Device = /dev/sg0 - Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d" -} - -Device { - Name = DDS-4 - Media Type = DDS-4 - Archive Device = /dev/nst0 # Normal archive device - Autochanger = yes - LabelMedia = no; - AutomaticMount = yes; - AlwaysOpen = yes; -} -\end{verbatim} -\normalsize - -o\`u vous adapterez les directives {\bf Archive Device}, {\bf Changer Device} et -{\bf Changer Command} pour qu'elles conviennent \`a votre syst\`eme. - -\section{Un exemple de fichier de configuration multi-lecteurs} -\index[general]{Multi-lecteurs exemple fichier de configuration} - -Les ressources suivantes impl\'ementent une librairie multi-lecteurs : - -\footnotesize -\begin{verbatim} -Autochanger { - Name = "Autochanger" - Device = Drive-1, Drive-2 - Changer Device = /dev/sg0 - Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d" -} - -Device { - Name = Drive-1 - Drive Index = 0 - Media Type = DDS-4 - Archive Device = /dev/nst0 # Normal archive device - Autochanger = yes - LabelMedia = no; - AutomaticMount = yes; - AlwaysOpen = yes; -} - -Device { - Name = Drive-2 - Drive Index = 1 - Media Type = DDS-4 - Archive Device = /dev/nst1 # Normal archive device - Autochanger = yes - LabelMedia = no; - AutomaticMount = yes; - AlwaysOpen = yes; -} - -\end{verbatim} -\normalsize - -o\`u vous adapterez les directives {\bf Archive Device}, {\bf Changer Device} et -{\bf Changer Command} pour qu'elles conviennent \`a votre syst\`eme. - -\label{SpecifyingSlots} -\section{Sp\'ecifier des slots lors de l'\'etiquetage} -\index[general]{Sp\'ecifier des slots lors de l'\'etiquetage} -\index[general]{Etiquetage!Sp\'ecifier des slots lors de} - -Si vous utilisez la directive {\bf Autochanger = yes} \`a la ressource Storage -du fichier de configuration de votre Director, la console Bacula vous -demandera automatiquement le num\'ero de slot lors de l'utilisation des -commandes {\bf add} ou {\bf label} pour ce p\'eriph\'erique de stockage. Si -votre script {\bf mtx-changer} est correctement install\'e, Bacula -chargera la bonne cartouche \`a l'ex\'ecution de la commande {\bf label}. - -Vous devez aussi sp\'ecifier {\bf Autochanger = yes} dans la ressource -Device du Storage Daemon ainsi que nous l'avons d\'ecrit plus haut pour -que la librairie soit utilis\'ee. Veuillez consulter la section -\ilink{Ressource Storage}{Autochanger1} dans le chapitre sur la configuration -du Director pour plus de d\'etails sur ce sujet. - -Ainsi, toutes les phases de l'utilisation des cartouches peuvent \^etre -int\'egralement automatis\'ees. Il est aussi possible de param\'etrer ou -modifier la valeur du slot en utilisant le sous-menu {\bf Volume Parameters} -de la commande {\bf update} de la console. - -M\^eme si tous les param\`etres ci-dessus sont correctement sp\'ecifi\'es, Bacula ne -tentera d'acc\'eder \`a la librairie que s'il existe un {\bf slot} non-nul parmi -les volumes enregistr\'es dans le catalogue. - -Si votre librairie est \'equip\'ee d'un lecteur de codes barres, vous pouvez -\'etiqueter vos volumes l'un apr\`es l'autre en utilisant la commande -{\bf label barcodes}. Bacula montera et \'etiquettera chaque cartouche porteuse -d'un code barres contenue dans la librairie avec le nom sp\'ecifi\'e par le -code barres. L'enregistrement apropri\'e sera aussi cr\'e\'e dans le catalogue. -Toute cartouche dont le code barres commence par les caract\`eres sp\'ecifi\'es par -la directive {\bf Cleaning Prefix} est consid\'er\'ee comme une cartouche de -nettoyage, et ne sera pas \'etiquet\'ee. Par exemple, avec : - -\footnotesize -\begin{verbatim} -Pool { - Name ... - Cleaning Prefix = "CLN" -} -\end{verbatim} -\normalsize - -toute cartouche de code barres CLNxxxx sera trait\'ee en tant que cartouche de -nettoyage, et ne sera pas mont\'ee. - -\section{Changer des cartouches} -\index[general]{Changer des cartouches} -Si vous voulez ins\'erer ou retirer des cartouches de votre librairie, ou encore -ex\'ecuter manuellement le programme {\bf mtx}, vous devez "informer" Bacula de ces op\'erations : - -\footnotesize -\begin{verbatim} -unmount -(changez vos cartouches et/ou ex\'ecutez mtx) -mount -\end{verbatim} -\normalsize - -Si vous omettez de faire "unmount" avant de telles changements, Bacula ne saura plus -ce qui est dans la librairie, et ce qui n'y est pas, et peut m\^eme cesser de fonctionner -parce qu'il s'attend \`a avoir le contr\^ole exclusif de la librairie tandis quie le lecteur -est mont\'e. - -Notez que les volumes doivent \^etre pr\'e-\'etiquet\'es pour pouvoir \^etre utilis\'es -automatiquement dans la librairie lors d'une sauvegarde. Si vous ne disposez -pas d'un lecteur de code barres, ceci se fait manuellement, ou \`a l'aide d'un -script. - -\label{Magazines} -\section{Travailler avec plusieurs magasins} -\index[general]{Travailler avec plusieurs magasins} -\index[general]{magasins!Travailler avec plusieurs} - -Si vous avez plusieurs magasins ou si vous ins\'erez ou retirez des -cartouches d'un magasin, vous devriez en informer Bacula. Ainsi, Bacula -sera en mesure d'utiliser pr\'ef\'erentiellement des cartouches qu'il sait \^etre -dans la librairie, pr\'evenant ainsi des interventions humaines inutiles. - -Si votre librairie est \'equip\'ee d'un lecteur de codes barres, il est ais\'e -de tenir Bacula inform\'e : chaque fois que vous changez un magasin, ajoutez -ou pr\'elevez une cartouche, faites simplement : - -\footnotesize -\begin{verbatim} -unmount -(remove magazine) -(insert new magazine) -update slots -mount -\end{verbatim} -\normalsize - -dans la console. Avec cette commande, Bacula se renseigne aupr\`es de la librairie -pour conna\^itre les volumes qu'elle contient. Ceci ne n\'ecessite pas d'acc\'eder -aux volumes car la librairie se charge de faire son inventaire lors de sa -mise sous tension. Bacula s'assure alors que tout volume pr\'esent dans la -librairie est marqu\'e pr\'esent dans le catalogue et que tout volume absent de la -librairie est marqu\'e absent dans le catalogue. En outre, les num\'eros de slots -des volumes sont corrig\'es dans le catalogue s'ils sont inexacts. - -Si vous ne disposez pas d'un lecteur de codes barres, vous avez plusieurs alternatives : - -\begin{enumerate} -\item Vous pouvez attribuer manuellement les num\'eros de slots et les drapeaux - InChanger \`a l'aide de la commande {\bf update volume} dans la console. Cette - m\'ethode est assez p\'enible. - -\item Vous pouvez lancer la commande - -\footnotesize -\begin{verbatim} -update slots scan -\end{verbatim} -\normalsize - - qui ordonne \`a Bacula de lire l'\'etiquette (label) de chacune des cartouches - dans la librairie par montage successif, et de mettre \`a jour les informations - (Slot, drapeau InChanger) dans le catalogue. Cette m\'ethode est efficace, mais - prend du temps pour charger chaque cartouche et en lire l'\'etiquette. - -\item Vous pouvez modifier le script mtx-changer en sorte qu'il simule une - librairie \'equip\'ee d'un lecteur de codes barres. Voyez ce qui suit pour plus de - d\'etails -\end{enumerate} - -\label{simulating} -\section{Simuler un lecteur de codes barres dans votre librairie} -\index[general]{Librairie!Simuler un lecteur de codes barres dans votre} -\index[general]{Simuler un lecteur de codes barres dans votre} - -Vous pouvez simuler un lecteur de codes barres dans votre librairie en faisant -en sorte que le script {\bf mtx-changer} retourne les informations que -retournerait une librairie avec lecteur de codes barres. Pour cela, commentez -la ligne ci-dessous dans le "case" aux alentours de la ligne 99 : - -\footnotesize -\begin{verbatim} - ${MTX} -f $ctl status | grep " *Storage Element [0-9]*:.*Full" | awk "{print \$3 \$4}" | sed "s/Full *\(:VolumeTag=\)*//" -\end{verbatim} -\normalsize - -en ajoutant un \# au d\'ebut de cette ligne (vous pouvez aussi supprimer la ligne). -A sa place, ajoutez une nouvelle ligne dont le r\^ole est d'imprimer le contenu -d'un fichier. Par exemple : - -\footnotesize -\begin{verbatim} -cat /etc/bacula/changer.volumes -\end{verbatim} -\normalsize - -Le nom du fichier est libre, mais assurez vous d'utiliser un chemin absolu. -Le contenu du fichier doit avoir le format : - -\footnotesize -\begin{verbatim} -1:Volume1 -2:Volume2 -3:Volume3 -... -\end{verbatim} -\normalsize - -O\`u 1, 2, 3 sont les num\'eros de slots et Volume1, Volume2, Volume3 sont les -noms de volumes dans ces slots. Vous pouvez utiliser plusieurs fichiers -repr\'esentant les contenus de plusieurs magasins, ainsi, lorsque vous -changez de magasin, contentez vous de copier le contenu du fichier associ\'e -dans le fichier {\bf /etc/bacula/changer.volumes}. Il n'est pas utile de -stopper et red\'emarrer Bacula lors d'un changement de magasins, mettez simplement -les bonnes valeurs dans le fichier avant de lancer la commande {\bf update slots}. -Votre librairie appara\^itra \`a Bacula comme \'equip\'ee d'un lecteur de codes barres. - -\label{updateslots} - -\section{La forme compl\`ete de la commande Update Slots} -\index[general]{La forme compl\`ete de la commande Update Slots} -\index[general]{Command!La forme compl\`ete de la commande Update Slots} - -Si vous ne changez qu'une cartouche, vous ne voulez peut-\^etre pas passer au crible -tous vos volumes, c'est pourquoi la commande {\bf update slots} (de m\^eme que la -commande {\bf update slots scan}) poss\`ede la forme additionnelle : - -\footnotesize -\begin{verbatim} -update slots=n1,n2,n3-n4, ... -\end{verbatim} -\normalsize - -o\`u le mot-clef {\bf scan} peut \'eventuellement \^etre ajout\'e. n1, n2, n3-n4 -repr\'esentent respectivement les num\'eros et la plage de slots que vous souhaitez -mettre \`a jour. - -Cette forme est particuli\`erement utile si vous voulez utiliser "scan" (couteux en temps) -en restrignant l'op\'eration \`a quelques slots. - -Par exemple, si vous lancez la commande : - -\footnotesize -\begin{verbatim} -update slots=1,6 scan -\end{verbatim} -\normalsize - -Bacula va charger le volume du slot 6, lire son \'etiquette logicielle (label) et -mettre \`a jour le catalogue, avant de faire de m\^eme avec la cartouche du slot 6. -Avec la commande : - -\footnotesize -\begin{verbatim} -update slots=1-3,6 -\end{verbatim} -\normalsize - -il va lire les codes barres des volumes dans les slots 1,2,3 et 6, et faire les -mises \`a jour approri\'ees dans le catalogue. Si vous n'avez pas de lecteur de -codes barres, ni n'en simulez comme d\'ecrit plus haut, la commande ci-dessus -ne trouvera aucun nom de volume et ne fera donc rien. - -\label{FreeBSD} - -\section{Sp\'ecificit\'es FreeBSD} -\index[general]{Sp\'ecificit\'es!FreeBSD } -\index[general]{Sp\'ecificit\'es FreeBSD} - -Si vous rencontrez des probl\`emes sur FreeBSD lorsque Bacula tente de s\'electionner -une cartouche, et si le message est {\bf Device not configured}, c'est -parce que FreeBSD a fait dispara\^itre le fichier de p\'eriph\'erique {\bf /dev/nsa1} -lorsqu'il n'y avait plus de cartouche mont\'ee dans le lecteur. Par cons\'equent, -Bacula ne peut ouvrir le p\'eriph\'erique. Une solution consiste \`a charger une -cartouche avant le lancement de Bacula. Ce probl\`eme est corrig\'e dans les -versions de Bacula ult\'erieures \`a 1.32f-5. - -Veuillez consulter le chapitre -\ilink{Tester votre lecteur}{FreeBSDTapes} de ce manuel pour d'{\bf importantes} -informations sur votre lecteur avant de passer au test de la librairie. -\label{AutochangerTesting} - -\section{Tester la librairie et adapter le script mtx-changer} -\index[general]{Tester la librairie et adapter le script mtx-changer} -\index[general]{Script!Tester la librairie et adapter le script mtx-changer} - -Avant d'essayer d'utiliser une librairie avec Bacula, il est pr\'ef\'erable de v\'erifier -"\`a la main" que le bras robotis\'e fonctionne. Pour ce faire, utilisez les commandes -suivantes (\`a supposer que le script {\bf mtx-changer} est install\'e dans -{\bf /etc/bacula/mtx-changer}) : - -\begin{description} - -\item [Assurez vous que Bacula est stopp\'e] - -\item [/etc/bacula/mtx-changer \ /dev/sg0 \ list \ 0 \ /dev/nst0 \ 0] -\index[sd]{mtx-changer list} - -Cette commande devrait afficher : - -\footnotesize -\begin{verbatim} - 1: - 2: - 3: - ... - -\end{verbatim} -\normalsize - -soit un num\'ero suivi de deux points pour chacun des slots occup\'e dans la librairie. -Si votre librairie a un lecteur de codes barres, celui-ci sera affich\'e apr\`es les -deux points. Si un message d'erreur s'affiche, vous devez r\'esoudre le probl\`eme -(par exemple, essayez un autre nom de p\'eriph\'erique si {\bf /dev/sg0} n'est pas -le bon. PAr exemple, sur FreeBSD c'est g\'en\'eralement {\bf /dev/pass2}). - -\item [/etc/bacula/mtx-changer \ /dev/sg0 \ slots \ 0 \ /dev/nst0 \ 0] -\index[sd]{mtx-changer slots} - -Cette commande devrait retourner le nombre de slots de votre librairie. - -\item [/etc/bacula/mtx-changer \ /dev/sg0 \ unload \ ] -\index[sd]{mtx-changer unload} - -Si une cartouche est charg\'ee, cette commande devrait la d\'echarger. - -\item [/etc/bacula/mtx-changer \ /dev/sg0 \ load \ 3 \ /dev/nst0 \ 0 ] -\index[sd]{mtx-changer load} - -Si vous avez une cartouche dans le slot 3, elle sera charg\'ee dans le slot -de lecture (0). - -\item [/etc/bacula/mtx-changer \ /dev/sg0 \ loaded \ 0 \ /dev/nst0 \ 0] -\index[sd]{mtx-changer loaded} - -devrait afficher "3" - -\item [/etc/bacula/mtx-changer \ /dev/sg0 \ unload] -\end{description} - -Une fois que toutes les commandes ci-dessus fonctionnent correctement, Bacula -devrait \^etre capable d'utiliser la librairie, pourvu que votre configuration -comporte la bonne commande {\bf Changer Command}. A ce stade, il ne peut subsister -qu'un probl\`eme : si votre librairie requiert un certain d\'elai pour charger la cartouche -apr\`es l'ex\'ecution de la commande. Imm\'ediatement apr\`es avoir obtenu le retour -du script {\bf mtx-changer}, Bacula commande le rembobinage et la lecture de la bande. -S'il obtient une erreur I/O, vous devriez probablement ins\'erer une pause ({\bf sleep 20}) -apr\`es la commande {\bf mtx}, mais prenez soin de terminer le script avec un -code de sortie 0 en ajoutant {\bf exit 0} apr\`es toute commande que vous ajoutez -au script, car Bacula contr\^ole le code de sortie du script qui devrait \^etre 0 si -tout s'est bien pass\'e. - -Vous pouvez tester si vous avez ou non besoin d'une telle pause en -ex\'ecutant le script suivant : - -\footnotesize -\begin{verbatim} -#!/bin/sh -/etc/bacula/mtx-changer /dev/sg0 unload -/etc/bacula/mtx-changer /dev/sg0 load 3 -mt -f /dev/st0 rewind -mt -f /dev/st0 weof -\end{verbatim} -\normalsize - -S'il fonctionne correctement, vous n'\^etes sans doute pas concern\'e par ce -probl\`eme. Sinon, commencez par ajouter {\bf sleep 30} voire {\bf sleep 60} -juste apr\`es la commande "/etc/bacula/mtx-changer /dev/sg0 load 3". Si -\c{c}a marche, vous pouvez alors int\'egrer cette pause dans le script -{\bf mtx-changer} afin qu'elle soit effective lorsque Bacula est ex\'ecut\'e. - -Quelques rares librairies exigent l'\'ejection de la cartouche avant de pouvoir -la d\'echarger. Dan ce cas, la commande /etc/bacula/mtx-changer /dev/sg0 load 3 -ne fonctionne jamais, quel que soit la dur\'ee de la pause. Si vous pensez -avoir ce probl\`eme, ins\'erez une commande "eject" juste avant la commande -/etc/bacula/mtx-changer /dev/sg0 unload : - -\footnotesize -\begin{verbatim} -#!/bin/sh -/etc/bacula/mtx-changer /dev/sg0 unload -mt -f /dev/st0 offline -/etc/bacula/mtx-changer /dev/sg0 load 3 -mt -f /dev/st0 rewind -mt -f /dev/st0 weof -\end{verbatim} -\normalsize - -Naturellement, si vous avez besoin de la commande {\bf offline}, vous devriez -l'int\'egrer au script mtx-changer, en n'oubliant pas de pr\'eserver le code de -sortie du script par l'ajout de {\bf exit 0}. - -Comme indiqu\'e pr\'ec\'edemment, plusieurs scripts qui impl\'ementent ces fonctions -sont regroup\'es dans {\bf \lt{}bacula-source\gt{}/examples/devices}, ils -peuvent vous inspirer pour faire en sorte que le votre fonctionne. - -Si Bacula affiche "Rewind error on /dev/nst0. ERR=Input/output error." vous -avez probablement besoin d'accro\^itre la pause dans le script {\bf mtx-changer} - -\label{using} - -\section{Utiliser la librairie} -\index[general]{Utiliser la librairie} -\index[general]{Librairie!Utiliser la } - -Supposons que vous ayez convenablement d\'efini les directives Device du -Storage Daemon, et que vous ayez ajout\'e la directive {\bf Autochanger = yes} -dans la ressource Storage de votre fichier bacula-dir.conf. - -Maintenant, alimentez votre librairie avec quelques cartouches vierges. - -Que faire pour que Bacula acc\`ede \`a ces cartouches ? - -Une strat\'egie consiste \`a pr\'e-\'etiqueter chacune des cartouches. Pour cela, -d\'emarrez Bacula, puis utilisez la commande {\bf label} dans la console : - -\footnotesize -\begin{verbatim} -./console -Connecting to Director rufus:8101 -1000 OK: rufus-dir Version: 1.26 (4 October 2002) -*label -\end{verbatim} -\normalsize - -l'affichage devrait \^etre : - -\footnotesize -\begin{verbatim} -Using default Catalog name=BackupDB DB=bacula -The defined Storage resources are: - 1: Autochanger - 2: File -Select Storage resource (1-2): 1 -\end{verbatim} -\normalsize - -Choisissez la librairie (choix 1), vous obtenez : - -\footnotesize -\begin{verbatim} -Enter new Volume name: TestVolume1 -Enter slot (0 for none): 1 -\end{verbatim} -\normalsize - -Ici saisissez {\bf TestVolume1} en guise de nom, et {\bf 1} pour le slot. -On vous demande alors : - -\footnotesize -\begin{verbatim} -Defined Pools: - 1: Default - 2: File -Select the Pool (1-2): 1 -\end{verbatim} -\normalsize - -S\'electionnez le pool Default (ce qui est fait automatiquement si vous -n'avez que celui-l\`a). Bacula poursuit en d\'echargeant toute cartouche -charg\'ee, en chargeant celle du slot 1 et en l'\'etiquetant. Dans cet exemple, -le lecteur \'etait vide, il en r\'esulte l'affichage : - -\footnotesize -\begin{verbatim} -Connecting to Storage daemon Autochanger at localhost:9103 ... -Sending label command ... -3903 Issuing autochanger "load slot 1" command. -3000 OK label. Volume=TestVolume1 Device=/dev/nst0 -Media record for Volume=TestVolume1 successfully created. -Requesting mount Autochanger ... -3001 Device /dev/nst0 is mounted with Volume TestVolume1 -You have messages. -* -\end{verbatim} -\normalsize - -Vous pouvez continuer \`a \'etiqueter les autres volumes, les messages -changeront l\'eg\`erement du fait qu'il y aura cette fois une cartouche -\`a d\'echarger avant de charger la suivante. - -Une fois que tous vos volumes sont \'etiquet\'es, Bacula est en mesure de les -charger lorsqu'il en a besoin. - -Pour "voir" votre \'etiquetage, saisissez la commande {\bf list volumes} dans -la console, vous devriez obtenir quelque chose comme : - -\footnotesize -\begin{verbatim} -*{\bf list volumes} -Using default Catalog name=BackupDB DB=bacula -Defined Pools: - 1: Default - 2: File -Select the Pool (1-2): 1 -+-------+----------+--------+---------+-------+--------+----------+-------+------+ -| MedId | VolName | MedTyp | VolStat | Bites | LstWrt | VolReten | Recyc | Slot | -+-------+----------+--------+---------+-------+--------+----------+-------+------+ -| 1 | TestVol1 | DDS-4 | Append | 0 | 0 | 30672000 | 0 | 1 | -| 2 | TestVol2 | DDS-4 | Append | 0 | 0 | 30672000 | 0 | 2 | -| 3 | TestVol3 | DDS-4 | Append | 0 | 0 | 30672000 | 0 | 3 | -| ... | -+-------+----------+--------+---------+-------+--------+----------+-------+------+ -\end{verbatim} -\normalsize - -\label{Barcodes} - -\section{Support des codes barres} -\index[general]{Support!codes barres} -\index[general]{Support des codes barres} - -Bacula utilise les codes barres \`a travers deux commandes de la console : -{\bf label barcodes} et {\bf update slots}. - -La commande {\bf label barcodes} ordonne \`a Bacula de lire tous les codes -barres de toutes les cartouches pr\'esentes dans la librairie \`a l'aide de la -commande {\bf mtx-changer} {\bf list}. Les cartouches sont ensuite mont\'ees -l'une apr\`es l'autre pour \^etre \'etiquet\'e du nom de leur code barres. - -La commande {\bf update slots} commence par obtenir du script {\bf mtx-changer} -la liste des cartouches et de leurs codes barres. Ensuite, il confronte -chacune des valeurs du catalogues \`a cette liste afin de le mettre \`a jour. -Notez que si un volume ne figure pas dans le catalogue, il n'y a rien a faire. -Cette commande est utile pour synchroniser Bacula avec le contenu de la librairie -si vous avez chang\'e de magasin ou d\'eplac\'e des cartouches. - -La directive {\bf Cleaning Prefix} peut \^etre utilis\'ee dans la ressource Pool pour -d\'efinir un pr\'efixe de nom de volume qui, s'il correspond au code barres d'un volume -conf\`ere \`a ce volume le statut (VolStatus) {\bf Cleaning}. Ceci \'evite que Bacula -tente d'\'ecrire sur une cartouche de nettoyage. - -\label{interface} - -\section{Interface entre Bacula et les librairies} -\index[general]{Interface!Bacula et les librairies} -\index[general]{Interface entre Bacula et les librairies} - -Bacula appelle le script mtx-changer que vous sp\'ecifiez au niveau de la -directive {\bf Changer Command}. En principe, ce sera le script {\bf mtx-changer} -que nous fournissons, mais ce pourrait \^etre n'importe quel programme -qui impl\'emente les commandes {\bf loaded}, {\bf load}, {\bf unload}, {\bf list}, -et {\bf slots} qu'utilise Bacula. Voici le format sous lequel ces commandes -doivent retourner les informations : - -\footnotesize -\begin{verbatim} -- Currently the changer commands used are: - loaded -- retourne le num\'ero du slot d'origine de la cartouche charg\'ee, - avec pour base 1 et 0 pour le lecteur. - load -- charge la cartouche du slot sp\'ecifi\'e dans le lecteur.(notez que certains - mat\'eriels requi\`erent une pause de 30 secondes apr\`es cette commande) - unload -- d\'echarge le lecteur (la cartouche retourne dans son slot d'origine). - list -- retourne une ligne par cartouche pr\'esente dans la librairie - au format : o\`u {\bf slot} est un entier non-nul - repr\'esentant le num\'ero du slot, et {\bf barcode} est le code barres, - s'il existe et si la librairie le prend en charge, associ\'e \`a la cartouche - (dans le cas contraire, le champ "barcode" est laiss\'e blanc. - slots -- retourne le nombre total de slots dans la librairie. -\end{verbatim} -\normalsize - -Bacula contr\^ole le code de sortie du programme appel\'e. Si ce code est 0, les -informations sont accept\'ees. Dans le cas contraire, elles sont ignor\'ees -et le lecteur est trait\'e comme s'il n'\'etait pas dans une librairie. diff --git a/docs/manual-fr/bimagemgr-chapter.tex b/docs/manual-fr/bimagemgr-chapter.tex deleted file mode 100644 index 095cca9e..00000000 --- a/docs/manual-fr/bimagemgr-chapter.tex +++ /dev/null @@ -1,143 +0,0 @@ -%% -%% -%% The following characters must be preceded by a backslash -%% to be entered as printable characters: -%% -%% # $ % & ~ _ ^ \ { } -%% - -\subsection*{bimagemgr} -\label{bimagemgr} -\index[general]{Bimagemgr } -\addcontentsline{toc}{subsection}{bimagemgr} - -{\bf bimagemgr} is a utility for those who backup to disk volumes in order to -commit them to CDR disk, rather than tapes. It is a web based interface -written in Perl and is used to monitor when a volume file needs to be burned to -disk. It requires: - -\begin{itemize} -\item A web server running on the bacula server -\item A CD recorder installed and configured on the bacula server -\item The cdrtools package installed on the bacula server. -\item perl, perl-DBI module, and either DBD-MySQL DBD-SQLite or DBD-PostgreSQL modules - \end{itemize} - -DVD burning is not supported by {\bf bimagemgr} at this -time, but both are planned for future releases. - -\subsubsection*{bimagemgr installation} -\index[general]{bimagemgr!Installation } -\index[general]{bimagemgr Installation } -\addcontentsline{toc}{subsubsection}{bimagemgr Installation} - -Installation from tarball: -1. Examine the Makefile and adjust it to your configuration if needed. -2. Edit config.pm to fit your configuration. -3. Do 'make install' as root. -4. Edit httpd.conf and change the Timeout value. The web server must not time -out and close the connection before the burn process is finished. The exact -value needed may vary depending upon your cd recorder speed and whether you are -burning on the bacula server on on another machine across your network. In my -case I set it to 1000 seconds. Restart httpd. -5. Make sure that cdrecord is setuid root. - -Installation from rpm package: -1. Install the rpm package for your platform. -2. Edit /cgi-bin/config.pm to fit your configuration. -3. Edit httpd.conf and change the Timeout value. The web server must not time -out and close the connection before the burn process is finished. The exact -value needed may vary depending upon your cd recorder speed and whether you are -burning on the bacula server on on another machine across your network. In my -case I set it to 1000 seconds. Restart httpd. -4. Make sure that cdrecord is setuid root. - -For bacula systems less than 1.36: -1. Edit the configuration section of config.pm to fit your configuration. -2. Run /etc/bacula/create\_cdimage\_table.pl from a console on your bacula -server (as root) to add the CDImage table to your bacula database. - -Accessing the Volume files: -The Volume files by default have permissions 640 and can only be read by root. -The recommended approach to this is as follows (and only works if bimagemgr and -apache are running on the same host as bacula. - -For bacula-1.34 or 1.36 installed from tarball - -1. Create a new user group bacula and add the user apache to the group for -Red Hat or Mandrake systems. For SuSE systems add the user wwwrun to the -bacula group. -2. Change ownership of all of your Volume files to root.bacula -3. Edit the /etc/bacula/bacula startup script and set SD\_USER=root and -SD\_GROUP=bacula. Restart bacula. - -Note: step 3 should also be done in /etc/init.d/bacula-sd but released versions -of this file prior to 1.36 do not support it. In that case it would be necessary after -a reboot of the server to execute '/etc/bacula/bacula restart'. - -For bacula-1.38 installed from tarball - -1. Your configure statement should include: - --with-dir-user=bacula - --with-dir-group=bacula - --with-sd-user=bacula - --with-sd-group=disk - --with-fd-user=root - --with-fd-group=bacula -2. Add the user apache to the bacula group for Red Hat or Mandrake systems. -For SuSE systems add the user wwwrun to the bacula group. -3. Check/change ownership of all of your Volume files to root.bacula - -For bacula-1.36 or bacula-1.38 installed from rpm - -1. Add the user apache to the group bacula for Red Hat or Mandrake systems. -For SuSE systems add the user wwwrun to the bacula group. -2. Check/change ownership of all of your Volume files to root.bacula - -bimagemgr installed from rpm > 1.38.9 will add the web server user to the -bacula group in a post install script. Be sure to edit the configuration -information in config.pm after installation of rpm package. - -bimagemgr will now be able to read the Volume files but they are still not -world readable. - -If you are running bimagemgr on another host (not recommended) then you will -need to change the permissions on all of your backup volume files to 644 in -order to access them via nfs share or other means. This approach should only -be taken if you are sure of the security of your environment as it exposes -the backup Volume files to world read. - -\subsubsection*{bimagemgr usage} -\index[general]{bimagemgr!Usage } -\index[general]{bimagemgr Usage } -\addcontentsline{toc}{subsubsection}{bimagemgr Usage} - -Calling the program in your web browser, e.g. {\tt -http://localhost/cgi-bin/bimagemgr.pl} will produce a display as shown below -in Figure 1. The program will query the bacula database and display all volume -files with the date last written and the date last burned to disk. If a volume -needs to be burned (last written is newer than last burn date) a "Burn" -button will be displayed in the rightmost column. - -\addcontentsline{lof}{figure}{Bacula CD Image Manager} -\includegraphics{./bimagemgr1.eps} \\Figure 1 - -Place a blank CDR disk in your recorder and click the "Burn" button. This will -cause a pop up window as shown in Figure 2 to display the burn progress. - -\addcontentsline{lof}{figure}{Bacula CD Image Burn Progress Window} -\includegraphics{./bimagemgr2.eps} \\Figure 2 - -When the burn finishes the pop up window will display the results of cdrecord -as shown in Figure 3. Close the pop up window and refresh the main window. The -last burn date will be updated and the "Burn" button for that volume will -disappear. Should you have a failed burn you can reset the last burn date of -that volume by clicking its "Reset" link. - -\addcontentsline{lof}{figure}{Bacula CD Image Burn Results} -\includegraphics{./bimagemgr3.eps} \\Figure 3 - -In the bottom row of the main display window are two more buttons labeled -"Burn Catalog" and "Blank CDRW". "Burn Catalog" will place a copy of -your bacula catalog on a disk. If you use CDRW disks rather than CDR then -"Blank CDRW" allows you to erase the disk before re-burning it. Regularly -committing your backup volume files and your catalog to disk with {\bf -bimagemgr} ensures that you can rebuild easily in the event of some disaster -on the bacula server itself. diff --git a/docs/manual-fr/bootstrap.tex b/docs/manual-fr/bootstrap.tex deleted file mode 100644 index e343b105..00000000 --- a/docs/manual-fr/bootstrap.tex +++ /dev/null @@ -1,388 +0,0 @@ -%% -%% - -\section*{The Bootstrap File} -\label{_ChapterStart43} -\index[general]{File!Bootstrap } -\index[general]{Bootstrap File } -\addcontentsline{toc}{section}{Bootstrap File} - -The information in this chapter is provided so that you may either create your -own bootstrap files, or so that you can edit a bootstrap file produced by {\bf -Bacula}. However, normally the bootstrap file will be automatically created -for you during the -\ilink{restore}{_ChapterStart13} command in the Console program, or -by using a -\ilink{ Write Bootstrap}{writebootstrap} record in your Backup -Jobs, and thus you will never need to know the details of this file. - -The {\bf bootstrap} file contains ASCII information that permits precise -specification of what files should be restored. It is a relatively compact -form of specifying the information, is human readable, and can be edited with -any text editor. - -\subsection*{File Format} -\index[general]{Format!File } -\index[general]{File Format } -\addcontentsline{toc}{subsection}{File Format} - -The general format of a {\bf bootstrap} file is: - -{\bf \lt{}keyword\gt{}= \lt{}value\gt{}} - -Where each {\bf keyword} and the {\bf value} specify which files to restore. -More precisely the {\bf keyword} and their {\bf values} serve to limit which -files will be restored and thus act as a filter. The absence of a keyword -means that all records will be accepted. - -Blank lines and lines beginning with a pound sign (\#) in the bootstrap file -are ignored. - -There are keywords which permit filtering by Volume, Client, Job, FileIndex, -Session Id, Session Time, ... - -The more keywords that are specified, the more selective the specification of -which files to restore will be. In fact, each keyword is {\bf AND}ed with -other keywords that may be present. - -For example, - -\footnotesize -\begin{verbatim} -Volume = Test-001 -VolSessionId = 1 -VolSessionTime = 108927638 -\end{verbatim} -\normalsize - -directs the Storage daemon (or the {\bf bextract} program) to restore only -those files on Volume Test-001 {\bf AND} having VolumeSessionId equal to one -{\bf AND} having VolumeSession time equal to 108927638. - -The full set of permitted keywords presented in the order in which they are -matched against the Volume records are: - -\begin{description} - -\item [Volume] - \index[fd]{Volume } - The value field specifies what Volume the following commands apply to. Each -Volume specification becomes the current Volume, to which all the following -commands apply until a new current Volume (if any) is specified. If the -Volume name contains spaces, it should be enclosed in quotes. - -\item [Count] - \index[fd]{Count } - The value is the total number of files that will be restored for this Volume. -This allows the Storage daemon to know when to stop reading the Volume. - -\item [VolFile] - \index[fd]{VolFile } - The value is a file number, a list of file numbers, or a range of file -numbers to match on the current Volume. The file number represents -the physical file on the Volume where the data is stored. For a tape volume, -this record is used to position to the correct starting file, and once the -tape is past the last specified file, reading will stop. - -\item [VolBlock] - \index[fd]{VolBlock } - The value is a block number, a list of block numbers, or a range of block -numbers to match on the current Volume. The block number represents -the physical block on the Volume where the data is stored. This record is -currently not used. - -\item [VolSessionTime] - \index[fd]{VolSessionTime } - The value specifies a Volume Session Time to be matched from the current -volume. - -\item [VolSessionId] - \index[fd]{VolSessionId } - The value specifies a VolSessionId, a list of volume session ids, or a range -of volume session ids to be matched from the current Volume. Each -VolSessionId and VolSessionTime pair corresponds to a unique Job that is -backed up on the Volume. - -\item [JobId] - \index[fd]{JobId } - The value specifies a JobId, list of JobIds, or range of JobIds to be -selected from the current Volume. Note, the JobId may not be unique if you -have multiple Directors, or if you have reinitialized your database. The -JobId filter works only if you do not run multiple simultaneous jobs. - -\item [Job] - \index[fd]{Job } - The value specifies a Job name or list of Job names to be matched on the -current Volume. The Job corresponds to a unique VolSessionId and -VolSessionTime pair. However, the Job is perhaps a bit more readable by -humans. Standard regular expressions (wildcards) may be used to match Job -names. The Job filter works only if you do not run multiple simultaneous -jobs. - -\item [Client] - \index[fd]{Client } - The value specifies a Client name or list of Clients to will be matched on -the current Volume. Standard regular expressions (wildcards) may be used to -match Client names. The Client filter works only if you do not run multiple -simultaneous jobs. - -\item [FileIndex] - \index[fd]{FileIndex } - The value specifies a FileIndex, list of FileIndexes, or range of FileIndexes -to be selected from the current Volume. Each file (data) stored on a Volume -within a Session has a unique FileIndex. For each Session, the first file -written is assigned FileIndex equal to one and incremented for each file -backed up. - -This for a given Volume, the triple VolSessionId, VolSessionTime, and -FileIndex uniquely identifies a file stored on the Volume. Multiple copies of -the same file may be stored on the same Volume, but for each file, the triple -VolSessionId, VolSessionTime, and FileIndex will be unique. This triple is -stored in the Catalog database for each file. - -\item [Slot] - \index[fd]{Slot } - The value specifies the autochanger slot. There may be only a single {\bf -Slot} specification for each Volume. - -\item [Stream] - \index[fd]{Stream } - The value specifies a Stream, a list of Streams, or a range of Streams to be -selected from the current Volume. Unless you really know what you are doing -(the internals of {\bf Bacula}, you should avoid this specification. - -\item [*JobType] - \index[fd]{*JobType } - Not yet implemented. - -\item [*JobLevel] - \index[fd]{*JobLevel } - Not yet implemented. -\end{description} - -The {\bf Volume} record is a bit special in that it must be the first record. -The other keyword records may appear in any order and any number following a -Volume record. - -Multiple Volume records may be specified in the same bootstrap file, but each -one starts a new set of filter criteria for the Volume. - -In processing the bootstrap file within the current Volume, each filter -specified by a keyword is {\bf AND}ed with the next. Thus, - -\footnotesize -\begin{verbatim} -Volume = Test-01 -Client = "My machine" -FileIndex = 1 -\end{verbatim} -\normalsize - -will match records on Volume {\bf Test-01} {\bf AND} Client records for {\bf -My machine} {\bf AND} FileIndex equal to {\bf one}. - -Multiple occurrences of the same record are {\bf OR}ed together. Thus, - -\footnotesize -\begin{verbatim} -Volume = Test-01 -Client = "My machine" -Client = "Backup machine" -FileIndex = 1 -\end{verbatim} -\normalsize - -will match records on Volume {\bf Test-01} {\bf AND} (Client records for {\bf -My machine} {\bf OR} {\bf Backup machine}) {\bf AND} FileIndex equal to {\bf -one}. - -For integer values, you may supply a range or a list, and for all other values -except Volumes, you may specify a list. A list is equivalent to multiple -records of the same keyword. For example, - -\footnotesize -\begin{verbatim} -Volume = Test-01 -Client = "My machine", "Backup machine" -FileIndex = 1-20, 35 -\end{verbatim} -\normalsize - -will match records on Volume {\bf Test-01} {\bf AND} {\bf (}Client records for -{\bf My machine} {\bf OR} {\bf Backup machine}{\bf )} {\bf AND} {\bf -(}FileIndex 1 {\bf OR} 2 {\bf OR} 3 ... {\bf OR} 20 {\bf OR} 35{\bf )}. - -As previously mentioned above, there may be multiple Volume records in the -same bootstrap file. Each new Volume definition begins a new set of filter -conditions that apply to that Volume and will be {\bf OR}ed with any other -Volume definitions. - -As an example, suppose we query for the current set of tapes to restore all -files on Client {\bf Rufus} using the {\bf query} command in the console -program: - -\footnotesize -\begin{verbatim} -Using default Catalog name=MySQL DB=bacula -*query -Available queries: - 1: List Job totals: - 2: List where a file is saved: - 3: List where the most recent copies of a file are saved: - 4: List total files/bytes by Job: - 5: List total files/bytes by Volume: - 6: List last 10 Full Backups for a Client: - 7: List Volumes used by selected JobId: - 8: List Volumes to Restore All Files: -Choose a query (1-8): 8 -Enter Client Name: Rufus -+-------+------------------+------------+-----------+----------+------------+ -| JobId | StartTime | VolumeName | StartFile | VolSesId | VolSesTime | -+-------+------------------+------------+-----------+----------+------------+ -| 154 | 2002-05-30 12:08 | test-02 | 0 | 1 | 1022753312 | -| 202 | 2002-06-15 10:16 | test-02 | 0 | 2 | 1024128917 | -| 203 | 2002-06-15 11:12 | test-02 | 3 | 1 | 1024132350 | -| 204 | 2002-06-18 08:11 | test-02 | 4 | 1 | 1024380678 | -+-------+------------------+------------+-----------+----------+------------+ -\end{verbatim} -\normalsize - -The output shows us that there are four Jobs that must be restored. The first -one is a Full backup, and the following three are all Incremental backups. - -The following bootstrap file will restore those files: - -\footnotesize -\begin{verbatim} -Volume=test-02 -VolSessionId=1 -VolSessionTime=1022753312 -Volume=test-02 -VolSessionId=2 -VolSessionTime=1024128917 -Volume=test-02 -VolSessionId=1 -VolSessionTime=1024132350 -Volume=test-02 -VolSessionId=1 -VolSessionTime=1024380678 -\end{verbatim} -\normalsize - -As a final example, assume that the initial Full save spanned two Volumes. The -output from {\bf query} might look like: - -\footnotesize -\begin{verbatim} -+-------+------------------+------------+-----------+----------+------------+ -| JobId | StartTime | VolumeName | StartFile | VolSesId | VolSesTime | -+-------+------------------+------------+-----------+----------+------------+ -| 242 | 2002-06-25 16:50 | File0003 | 0 | 1 | 1025016612 | -| 242 | 2002-06-25 16:50 | File0004 | 0 | 1 | 1025016612 | -| 243 | 2002-06-25 16:52 | File0005 | 0 | 2 | 1025016612 | -| 246 | 2002-06-25 19:19 | File0006 | 0 | 2 | 1025025494 | -+-------+------------------+------------+-----------+----------+------------+ -\end{verbatim} -\normalsize - -and the following bootstrap file would restore those files: - -\footnotesize -\begin{verbatim} -Volume=File0003 -VolSessionId=1 -VolSessionTime=1025016612 -Volume=File0004 -VolSessionId=1 -VolSessionTime=1025016612 -Volume=File0005 -VolSessionId=2 -VolSessionTime=1025016612 -Volume=File0006 -VolSessionId=2 -VolSessionTime=1025025494 -\end{verbatim} -\normalsize - -\subsection*{Automatic Generation of Bootstrap Files} -\index[general]{Files!Automatic Generation of Bootstrap } -\index[general]{Automatic Generation of Bootstrap Files } -\addcontentsline{toc}{subsection}{Automatic Generation of Bootstrap Files} - -One thing that is probably worth knowing: the bootstrap files that are -generated automatically at the end of the job are not as optimized as those -generated by the restore command. This is because the ones created at the end -of the file, contain all files written to the Volume for that job. As a -consequence, all the files saved to an Incremental or Differential job will be -restored first by the Full save, then by any Incremental or Differential -saves. - -When the bootstrap file is generated for the restore command, only one copy -(the most recent) of each file is restored. - -So if you have spare cycles on your machine, you could optimize the bootstrap -files by doing the following: - -\footnotesize -\begin{verbatim} - ./console - restore client=xxx select all - no - quit - Backup bootstrap file. -\end{verbatim} -\normalsize - -The above will not work if you have multiple FileSets because that will be an -extra prompt. However, the {\bf restore client=xxx select all} builds the -in-memory tree, selecting everything and creates the bootstrap file. - -The {\bf no} answers the {\bf Do you want to run this (yes/mod/no)} question. - -\subsection*{A Final Example} -\index[general]{Example!Final } -\index[general]{Final Example } -\addcontentsline{toc}{subsection}{Final Example} - -If you want to extract or copy a single Job, you can do it by selecting by -JobId (code not tested) or better yet, if you know the VolSessionTime and the -VolSessionId (printed on Job report and in Catalog), specifying this is by far -the best. Using the VolSessionTime and VolSessionId is the way Bacula does -restores. A bsr file might look like the following: - -\footnotesize -\begin{verbatim} -Volume="Vol001" -VolSessionId=10 -VolSessionTime=1080847820 -\end{verbatim} -\normalsize - -If you know how many files are backed up (on the job report), you can -enormously speed up the selection by adding (let's assume there are 157 -files): - -\footnotesize -\begin{verbatim} -FileIndex=1-157 -Count=157 -\end{verbatim} -\normalsize - -Finally, if you know the File number where the Job starts, you can also cause -bcopy to forward space to the right file without reading every record: - -\footnotesize -\begin{verbatim} -VolFile=20 -\end{verbatim} -\normalsize - -There is nothing magic or complicated about a BSR file. Parsing it and -properly applying it within Bacula *is* magic, but you don't need to worry -about that. - -If you want to see a *real* bsr file, simply fire up the {\bf restore} command -in the console program, select something, then answer no when it prompts to -run the job. Then look at the file {\bf restore.bsr} in your working -directory. diff --git a/docs/manual-fr/bugs.tex b/docs/manual-fr/bugs.tex deleted file mode 100644 index 42df829d..00000000 --- a/docs/manual-fr/bugs.tex +++ /dev/null @@ -1,21 +0,0 @@ -%% -%% - -\section{Bacula Bugs} -\label{BugsChapter} -\index[general]{Bacula Bugs } -\index[general]{Bugs!Bacula } - -Well fortunately there are not too many bugs, but thanks to Dan Langille, we -have a -\elink{bugs database}{http://bugs.bacula.org} where bugs are reported. -Generally, when a bug is fixed, a patch for the currently released version will -be attached to the bug report. - -The directory {\bf patches} in the current SVN always contains a list of -the patches that have been created for the previously released version -of Bacula. In addition, the file {\bf patches-version-number} in the -{\bf patches} directory contains a summary of each of the patches. - -A "raw" list of the current task list and known issues can be found in {\bf -kernstodo} in the main Bacula source directory. diff --git a/docs/manual-fr/catalog.tex b/docs/manual-fr/catalog.tex deleted file mode 100644 index eebe59bc..00000000 --- a/docs/manual-fr/catalog.tex +++ /dev/null @@ -1,929 +0,0 @@ -%% -%% - -\section*{Catalog Services} -\label{_ChapterStart30} -\index[general]{Services!Catalog } -\index[general]{Catalog Services } -\addcontentsline{toc}{section}{Catalog Services} - -\subsection*{General} -\index[general]{General } -\addcontentsline{toc}{subsection}{General} - -This chapter is intended to be a technical discussion of the Catalog services -and as such is not targeted at end users but rather at developers and system -administrators that want or need to know more of the working details of {\bf -Bacula}. - -The {\bf Bacula Catalog} services consist of the programs that provide the SQL -database engine for storage and retrieval of all information concerning files -that were backed up and their locations on the storage media. - -We have investigated the possibility of using the following SQL engines for -Bacula: Beagle, mSQL, GNU SQL, PostgreSQL, SQLite, Oracle, and MySQL. Each -presents certain problems with either licensing or maturity. At present, we -have chosen for development purposes to use MySQL, PostgreSQL and SQLite. -MySQL was chosen because it is fast, proven to be reliable, widely used, and -actively being developed. MySQL is released under the GNU GPL license. -PostgreSQL was chosen because it is a full-featured, very mature database, and -because Dan Langille did the Bacula driver for it. PostgreSQL is distributed -under the BSD license. SQLite was chosen because it is small, efficient, and -can be directly embedded in {\bf Bacula} thus requiring much less effort from -the system administrator or person building {\bf Bacula}. In our testing -SQLite has performed very well, and for the functions that we use, it has -never encountered any errors except that it does not appear to handle -databases larger than 2GBytes. - -The Bacula SQL code has been written in a manner that will allow it to be -easily modified to support any of the current SQL database systems on the -market (for example: mSQL, iODBC, unixODBC, Solid, OpenLink ODBC, EasySoft -ODBC, InterBase, Oracle8, Oracle7, and DB2). - -If you do not specify either {\bf \verb{--{with-mysql} or {\bf \verb{--{with-postgresql} or -{\bf \verb{--{with-sqlite} on the ./configure line, Bacula will use its minimalist -internal database. This database is kept for build reasons but is no longer -supported. Bacula {\bf requires} one of the three databases (MySQL, -PostgreSQL, or SQLite) to run. - -\subsubsection*{Filenames and Maximum Filename Length} -\index[general]{Filenames and Maximum Filename Length } -\index[general]{Length!Filenames and Maximum Filename } -\addcontentsline{toc}{subsubsection}{Filenames and Maximum Filename Length} - -In general, either MySQL, PostgreSQL or SQLite permit storing arbitrary long -path names and file names in the catalog database. In practice, there still -may be one or two places in the Catalog interface code that restrict the -maximum path length to 512 characters and the maximum file name length to 512 -characters. These restrictions are believed to have been removed. Please note, -these restrictions apply only to the Catalog database and thus to your ability -to list online the files saved during any job. All information received and -stored by the Storage daemon (normally on tape) allows and handles arbitrarily -long path and filenames. - -\subsubsection*{Installing and Configuring MySQL} -\index[general]{MySQL!Installing and Configuring } -\index[general]{Installing and Configuring MySQL } -\addcontentsline{toc}{subsubsection}{Installing and Configuring MySQL} - -For the details of installing and configuring MySQL, please see the -\ilink{Installing and Configuring MySQL}{_ChapterStart} chapter of -this manual. - -\subsubsection*{Installing and Configuring PostgreSQL} -\index[general]{PostgreSQL!Installing and Configuring } -\index[general]{Installing and Configuring PostgreSQL } -\addcontentsline{toc}{subsubsection}{Installing and Configuring PostgreSQL} - -For the details of installing and configuring PostgreSQL, please see the -\ilink{Installing and Configuring PostgreSQL}{_ChapterStart10} -chapter of this manual. - -\subsubsection*{Installing and Configuring SQLite} -\index[general]{Installing and Configuring SQLite } -\index[general]{SQLite!Installing and Configuring } -\addcontentsline{toc}{subsubsection}{Installing and Configuring SQLite} - -For the details of installing and configuring SQLite, please see the -\ilink{Installing and Configuring SQLite}{_ChapterStart33} chapter of -this manual. - -\subsubsection*{Internal Bacula Catalog} -\index[general]{Catalog!Internal Bacula } -\index[general]{Internal Bacula Catalog } -\addcontentsline{toc}{subsubsection}{Internal Bacula Catalog} - -Please see the -\ilink{Internal Bacula Database}{_ChapterStart42} chapter of this -manual for more details. - -\subsubsection*{Database Table Design} -\index[general]{Design!Database Table } -\index[general]{Database Table Design } -\addcontentsline{toc}{subsubsection}{Database Table Design} - -All discussions that follow pertain to the MySQL database. The details for the -PostgreSQL and SQLite databases are essentially identical except for that all -fields in the SQLite database are stored as ASCII text and some of the -database creation statements are a bit different. The details of the internal -Bacula catalog are not discussed here. - -Because the Catalog database may contain very large amounts of data for large -sites, we have made a modest attempt to normalize the data tables to reduce -redundant information. While reducing the size of the database significantly, -it does, unfortunately, add some complications to the structures. - -In simple terms, the Catalog database must contain a record of all Jobs run by -Bacula, and for each Job, it must maintain a list of all files saved, with -their File Attributes (permissions, create date, ...), and the location and -Media on which the file is stored. This is seemingly a simple task, but it -represents a huge amount interlinked data. Note: the list of files and their -attributes is not maintained when using the internal Bacula database. The data -stored in the File records, which allows the user or administrator to obtain a -list of all files backed up during a job, is by far the largest volume of -information put into the Catalog database. - -Although the Catalog database has been designed to handle backup data for -multiple clients, some users may want to maintain multiple databases, one for -each machine to be backed up. This reduces the risk of confusion of accidental -restoring a file to the wrong machine as well as reducing the amount of data -in a single database, thus increasing efficiency and reducing the impact of a -lost or damaged database. - -\subsection*{Sequence of Creation of Records for a Save Job} -\index[general]{Sequence of Creation of Records for a Save Job } -\index[general]{Job!Sequence of Creation of Records for a Save } -\addcontentsline{toc}{subsection}{Sequence of Creation of Records for a Save -Job} - -Start with StartDate, ClientName, Filename, Path, Attributes, MediaName, -MediaCoordinates. (PartNumber, NumParts). In the steps below, ``Create new'' -means to create a new record whether or not it is unique. ``Create unique'' -means each record in the database should be unique. Thus, one must first -search to see if the record exists, and only if not should a new one be -created, otherwise the existing RecordId should be used. - -\begin{enumerate} -\item Create new Job record with StartDate; save JobId -\item Create unique Media record; save MediaId -\item Create unique Client record; save ClientId -\item Create unique Filename record; save FilenameId -\item Create unique Path record; save PathId -\item Create unique Attribute record; save AttributeId - store ClientId, FilenameId, PathId, and Attributes -\item Create new File record - store JobId, AttributeId, MediaCoordinates, etc -\item Repeat steps 4 through 8 for each file -\item Create a JobMedia record; save MediaId -\item Update Job record filling in EndDate and other Job statistics - \end{enumerate} - -\subsection*{Database Tables} -\index[general]{Database Tables } -\index[general]{Tables!Database } -\addcontentsline{toc}{subsection}{Database Tables} - -\addcontentsline{lot}{table}{Filename Table Layout} -\begin{longtable}{|l|l|l|} - \hline -\multicolumn{3}{|l| }{\bf Filename } \\ - \hline -\multicolumn{1}{|c| }{\bf Column Name } & \multicolumn{1}{l| }{\bf Data Type } -& \multicolumn{1}{l| }{\bf Remark } \\ - \hline -{FilenameId } & {integer } & {Primary Key } \\ - \hline -{Name } & {Blob } & {Filename } -\\ \hline - -\end{longtable} - -The {\bf Filename} table shown above contains the name of each file backed up -with the path removed. If different directories or machines contain the same -filename, only one copy will be saved in this table. - -\ - -\addcontentsline{lot}{table}{Path Table Layout} -\begin{longtable}{|l|l|l|} - \hline -\multicolumn{3}{|l| }{\bf Path } \\ - \hline -\multicolumn{1}{|c| }{\bf Column Name } & \multicolumn{1}{c| }{\bf Data Type -} & \multicolumn{1}{c| }{\bf Remark } \\ - \hline -{PathId } & {integer } & {Primary Key } \\ - \hline -{Path } & {Blob } & {Full Path } -\\ \hline - -\end{longtable} - -The {\bf Path} table contains shown above the path or directory names of all -directories on the system or systems. The filename and any MSDOS disk name are -stripped off. As with the filename, only one copy of each directory name is -kept regardless of how many machines or drives have the same directory. These -path names should be stored in Unix path name format. - -Some simple testing on a Linux file system indicates that separating the -filename and the path may be more complication than is warranted by the space -savings. For example, this system has a total of 89,097 files, 60,467 of which -have unique filenames, and there are 4,374 unique paths. - -Finding all those files and doing two stats() per file takes an average wall -clock time of 1 min 35 seconds on a 400MHz machine running RedHat 6.1 Linux. - -Finding all those files and putting them directly into a MySQL database with -the path and filename defined as TEXT, which is variable length up to 65,535 -characters takes 19 mins 31 seconds and creates a 27.6 MByte database. - -Doing the same thing, but inserting them into Blob fields with the filename -indexed on the first 30 characters and the path name indexed on the 255 (max) -characters takes 5 mins 18 seconds and creates a 5.24 MB database. Rerunning -the job (with the database already created) takes about 2 mins 50 seconds. - -Running the same as the last one (Path and Filename Blob), but Filename -indexed on the first 30 characters and the Path on the first 50 characters -(linear search done there after) takes 5 mins on the average and creates a 3.4 -MB database. Rerunning with the data already in the DB takes 3 mins 35 -seconds. - -Finally, saving only the full path name rather than splitting the path and the -file, and indexing it on the first 50 characters takes 6 mins 43 seconds and -creates a 7.35 MB database. - -\ - -\addcontentsline{lot}{table}{File Table Layout} -\begin{longtable}{|l|l|l|} - \hline -\multicolumn{3}{|l| }{\bf File } \\ - \hline -\multicolumn{1}{|c| }{\bf Column Name } & \multicolumn{1}{c| }{\bf Data Type -} & \multicolumn{1}{c| }{\bf Remark } \\ - \hline -{FileId } & {integer } & {Primary Key } \\ - \hline -{FileIndex } & {integer } & {The sequential file number in the Job } \\ - \hline -{JobId } & {integer } & {Link to Job Record } \\ - \hline -{PathId } & {integer } & {Link to Path Record } \\ - \hline -{FilenameId } & {integer } & {Link to Filename Record } \\ - \hline -{MarkId } & {integer } & {Used to mark files during Verify Jobs } \\ - \hline -{LStat } & {tinyblob } & {File attributes in base64 encoding } \\ - \hline -{MD5 } & {tinyblob } & {MD5 signature in base64 encoding } -\\ \hline - -\end{longtable} - -The {\bf File} table shown above contains one entry for each file backed up by -Bacula. Thus a file that is backed up multiple times (as is normal) will have -multiple entries in the File table. This will probably be the table with the -most number of records. Consequently, it is essential to keep the size of this -record to an absolute minimum. At the same time, this table must contain all -the information (or pointers to the information) about the file and where it -is backed up. Since a file may be backed up many times without having changed, -the path and filename are stored in separate tables. - -This table contains by far the largest amount of information in the Catalog -database, both from the stand point of number of records, and the stand point -of total database size. As a consequence, the user must take care to -periodically reduce the number of File records using the {\bf retention} -command in the Console program. - -\ - -\addcontentsline{lot}{table}{Job Table Layout} -\begin{longtable}{|l|l|p{2.5in}|} - \hline -\multicolumn{3}{|l| }{\bf Job } \\ - \hline -\multicolumn{1}{|c| }{\bf Column Name } & \multicolumn{1}{c| }{\bf Data Type -} & \multicolumn{1}{c| }{\bf Remark } \\ - \hline -{JobId } & {integer } & {Primary Key } \\ - \hline -{Job } & {tinyblob } & {Unique Job Name } \\ - \hline -{Name } & {tinyblob } & {Job Name } \\ - \hline -{PurgedFiles } & {tinyint } & {Used by Bacula for purging/retention periods -} \\ - \hline -{Type } & {binary(1) } & {Job Type: Backup, Copy, Clone, Archive, Migration -} \\ - \hline -{Level } & {binary(1) } & {Job Level } \\ - \hline -{ClientId } & {integer } & {Client index } \\ - \hline -{JobStatus } & {binary(1) } & {Job Termination Status } \\ - \hline -{SchedTime } & {datetime } & {Time/date when Job scheduled } \\ - \hline -{StartTime } & {datetime } & {Time/date when Job started } \\ - \hline -{EndTime } & {datetime } & {Time/date when Job ended } \\ - \hline -{JobTDate } & {bigint } & {Start day in Unix format but 64 bits; used for -Retention period. } \\ - \hline -{VolSessionId } & {integer } & {Unique Volume Session ID } \\ - \hline -{VolSessionTime } & {integer } & {Unique Volume Session Time } \\ - \hline -{JobFiles } & {integer } & {Number of files saved in Job } \\ - \hline -{JobBytes } & {bigint } & {Number of bytes saved in Job } \\ - \hline -{JobErrors } & {integer } & {Number of errors during Job } \\ - \hline -{JobMissingFiles } & {integer } & {Number of files not saved (not yet used) } -\\ - \hline -{PoolId } & {integer } & {Link to Pool Record } \\ - \hline -{FileSetId } & {integer } & {Link to FileSet Record } \\ - \hline -{PurgedFiles } & {tiny integer } & {Set when all File records purged } \\ - \hline -{HasBase } & {tiny integer } & {Set when Base Job run } -\\ \hline - -\end{longtable} - -The {\bf Job} table contains one record for each Job run by Bacula. Thus -normally, there will be one per day per machine added to the database. Note, -the JobId is used to index Job records in the database, and it often is shown -to the user in the Console program. However, care must be taken with its use -as it is not unique from database to database. For example, the user may have -a database for Client data saved on machine Rufus and another database for -Client data saved on machine Roxie. In this case, the two database will each -have JobIds that match those in another database. For a unique reference to a -Job, see Job below. - -The Name field of the Job record corresponds to the Name resource record given -in the Director's configuration file. Thus it is a generic name, and it will -be normal to find many Jobs (or even all Jobs) with the same Name. - -The Job field contains a combination of the Name and the schedule time of the -Job by the Director. Thus for a given Director, even with multiple Catalog -databases, the Job will contain a unique name that represents the Job. - -For a given Storage daemon, the VolSessionId and VolSessionTime form a unique -identification of the Job. This will be the case even if multiple Directors -are using the same Storage daemon. - -The Job Type (or simply Type) can have one of the following values: - -\addcontentsline{lot}{table}{Job Types} -\begin{longtable}{|l|l|} - \hline -\multicolumn{1}{|c| }{\bf Value } & \multicolumn{1}{c| }{\bf Meaning } \\ - \hline -{B } & {Backup Job } \\ - \hline -{V } & {Verify Job } \\ - \hline -{R } & {Restore Job } \\ - \hline -{C } & {Console program (not in database) } \\ - \hline -{D } & {Admin Job } \\ - \hline -{A } & {Archive Job (not implemented) } -\\ \hline - -\end{longtable} - -The JobStatus field specifies how the job terminated, and can be one of the -following: - -\addcontentsline{lot}{table}{Job Statuses} -\begin{longtable}{|l|l|} - \hline -\multicolumn{1}{|c| }{\bf Value } & \multicolumn{1}{c| }{\bf Meaning } \\ - \hline -{C } & {Created but not yet running } \\ - \hline -{R } & {Running } \\ - \hline -{B } & {Blocked } \\ - \hline -{T } & {Terminated normally } \\ - \hline -{E } & {Terminated in Error } \\ - \hline -{e } & {Non-fatal error } \\ - \hline -{f } & {Fatal error } \\ - \hline -{D } & {Verify Differences } \\ - \hline -{A } & {Canceled by the user } \\ - \hline -{F } & {Waiting on the File daemon } \\ - \hline -{S } & {Waiting on the Storage daemon } \\ - \hline -{m } & {Waiting for a new Volume to be mounted } \\ - \hline -{M } & {Waiting for a Mount } \\ - \hline -{s } & {Waiting for Storage resource } \\ - \hline -{j } & {Waiting for Job resource } \\ - \hline -{c } & {Waiting for Client resource } \\ - \hline -{d } & {Wating for Maximum jobs } \\ - \hline -{t } & {Waiting for Start Time } \\ - \hline -{p } & {Waiting for higher priority job to finish } -\\ \hline - -\end{longtable} - -\ - -\addcontentsline{lot}{table}{File Sets Table Layout} -\begin{longtable}{|l|l|l|} - \hline -\multicolumn{3}{|l| }{\bf FileSet } \\ - \hline -\multicolumn{1}{|c| }{\bf Column Name } & \multicolumn{1}{c| }{\bf Data Type\ -\ \ } & \multicolumn{1}{c| }{\bf Remark } \\ - \hline -{FileSetId } & {integer } & {Primary Key } \\ - \hline -{FileSet } & {tinyblob } & {FileSet name } \\ - \hline -{MD5 } & {tinyblob } & {MD5 checksum of FileSet } \\ - \hline -{CreateTime } & {datetime } & {Time and date Fileset created } -\\ \hline - -\end{longtable} - -The {\bf FileSet} table contains one entry for each FileSet that is used. The -MD5 signature is kept to ensure that if the user changes anything inside the -FileSet, it will be detected and the new FileSet will be used. This is -particularly important when doing an incremental update. If the user deletes a -file or adds a file, we need to ensure that a Full backup is done prior to the -next incremental. - -\ - -\addcontentsline{lot}{table}{JobMedia Table Layout} -\begin{longtable}{|l|l|p{2.5in}|} - \hline -\multicolumn{3}{|l| }{\bf JobMedia } \\ - \hline -\multicolumn{1}{|c| }{\bf Column Name } & \multicolumn{1}{c| }{\bf Data Type\ -\ \ } & \multicolumn{1}{c| }{\bf Remark } \\ - \hline -{JobMediaId } & {integer } & {Primary Key } \\ - \hline -{JobId } & {integer } & {Link to Job Record } \\ - \hline -{MediaId } & {integer } & {Link to Media Record } \\ - \hline -{FirstIndex } & {integer } & {The index (sequence number) of the first file -written for this Job to the Media } \\ - \hline -{LastIndex } & {integer } & {The index of the last file written for this -Job to the Media } \\ - \hline -{StartFile } & {integer } & {The physical media (tape) file number of the -first block written for this Job } \\ - \hline -{EndFile } & {integer } & {The physical media (tape) file number of the -last block written for this Job } \\ - \hline -{StartBlock } & {integer } & {The number of the first block written for -this Job } \\ - \hline -{EndBlock } & {integer } & {The number of the last block written for this -Job } \\ - \hline -{VolIndex } & {integer } & {The Volume use sequence number within the Job } -\\ \hline - -\end{longtable} - -The {\bf JobMedia} table contains one entry for each volume written for the -current Job. If the Job spans 3 tapes, there will be three JobMedia records, -each containing the information to find all the files for the given JobId on -the tape. - -\ - -\addcontentsline{lot}{table}{Media Table Layout} -\begin{longtable}{|l|l|p{2.4in}|} - \hline -\multicolumn{3}{|l| }{\bf Media } \\ - \hline -\multicolumn{1}{|c| }{\bf Column Name } & \multicolumn{1}{c| }{\bf Data Type\ -\ \ } & \multicolumn{1}{c| }{\bf Remark } \\ - \hline -{MediaId } & {integer } & {Primary Key } \\ - \hline -{VolumeName } & {tinyblob } & {Volume name } \\ - \hline -{Slot } & {integer } & {Autochanger Slot number or zero } \\ - \hline -{PoolId } & {integer } & {Link to Pool Record } \\ - \hline -{MediaType } & {tinyblob } & {The MediaType supplied by the user } \\ - \hline -{FirstWritten } & {datetime } & {Time/date when first written } \\ - \hline -{LastWritten } & {datetime } & {Time/date when last written } \\ - \hline -{LabelDate } & {datetime } & {Time/date when tape labeled } \\ - \hline -{VolJobs } & {integer } & {Number of jobs written to this media } \\ - \hline -{VolFiles } & {integer } & {Number of files written to this media } \\ - \hline -{VolBlocks } & {integer } & {Number of blocks written to this media } \\ - \hline -{VolMounts } & {integer } & {Number of time media mounted } \\ - \hline -{VolBytes } & {bigint } & {Number of bytes saved in Job } \\ - \hline -{VolErrors } & {integer } & {Number of errors during Job } \\ - \hline -{VolWrites } & {integer } & {Number of writes to media } \\ - \hline -{MaxVolBytes } & {bigint } & {Maximum bytes to put on this media } \\ - \hline -{VolCapacityBytes } & {bigint } & {Capacity estimate for this volume } \\ - \hline -{VolStatus } & {enum } & {Status of media: Full, Archive, Append, Recycle, -Read-Only, Disabled, Error, Busy } \\ - \hline -{Recycle } & {tinyint } & {Whether or not Bacula can recycle the Volumes: -Yes, No } \\ - \hline -{VolRetention } & {bigint } & {64 bit seconds until expiration } \\ - \hline -{VolUseDuration } & {bigint } & {64 bit seconds volume can be used } \\ - \hline -{MaxVolJobs } & {integer } & {maximum jobs to put on Volume } \\ - \hline -{MaxVolFiles } & {integer } & {maximume EOF marks to put on Volume } -\\ \hline - -\end{longtable} - -The {\bf Volume} table (internally referred to as the Media table) contains -one entry for each volume, that is each tape, cassette (8mm, DLT, DAT, ...), -or file on which information is or was backed up. There is one Volume record -created for each of the NumVols specified in the Pool resource record. - -\ - -\addcontentsline{lot}{table}{Pool Table Layout} -\begin{longtable}{|l|l|p{2.4in}|} - \hline -\multicolumn{3}{|l| }{\bf Pool } \\ - \hline -\multicolumn{1}{|c| }{\bf Column Name } & \multicolumn{1}{c| }{\bf Data Type -} & \multicolumn{1}{c| }{\bf Remark } \\ - \hline -{PoolId } & {integer } & {Primary Key } \\ - \hline -{Name } & {Tinyblob } & {Pool Name } \\ - \hline -{NumVols } & {Integer } & {Number of Volumes in the Pool } \\ - \hline -{MaxVols } & {Integer } & {Maximum Volumes in the Pool } \\ - \hline -{UseOnce } & {tinyint } & {Use volume once } \\ - \hline -{UseCatalog } & {tinyint } & {Set to use catalog } \\ - \hline -{AcceptAnyVolume } & {tinyint } & {Accept any volume from Pool } \\ - \hline -{VolRetention } & {bigint } & {64 bit seconds to retain volume } \\ - \hline -{VolUseDuration } & {bigint } & {64 bit seconds volume can be used } \\ - \hline -{MaxVolJobs } & {integer } & {max jobs on volume } \\ - \hline -{MaxVolFiles } & {integer } & {max EOF marks to put on Volume } \\ - \hline -{MaxVolBytes } & {bigint } & {max bytes to write on Volume } \\ - \hline -{AutoPrune } & {tinyint } & {yes|no for autopruning } \\ - \hline -{Recycle } & {tinyint } & {yes|no for allowing auto recycling of Volume } -\\ - \hline -{PoolType } & {enum } & {Backup, Copy, Cloned, Archive, Migration } \\ - \hline -{LabelFormat } & {Tinyblob } & {Label format } -\\ \hline - -\end{longtable} - -The {\bf Pool} table contains one entry for each media pool controlled by -Bacula in this database. One media record exists for each of the NumVols -contained in the Pool. The PoolType is a Bacula defined keyword. The MediaType -is defined by the administrator, and corresponds to the MediaType specified in -the Director's Storage definition record. The CurrentVol is the sequence -number of the Media record for the current volume. - -\ - -\addcontentsline{lot}{table}{Client Table Layout} -\begin{longtable}{|l|l|l|} - \hline -\multicolumn{3}{|l| }{\bf Client } \\ - \hline -\multicolumn{1}{|c| }{\bf Column Name } & \multicolumn{1}{c| }{\bf Data Type -} & \multicolumn{1}{c| }{\bf Remark } \\ - \hline -{ClientId } & {integer } & {Primary Key } \\ - \hline -{Name } & {TinyBlob } & {File Services Name } \\ - \hline -{UName } & {TinyBlob } & {uname -a from Client (not yet used) } \\ - \hline -{AutoPrune } & {tinyint } & {yes|no for autopruning } \\ - \hline -{FileRetention } & {bigint } & {64 bit seconds to retain Files } \\ - \hline -{JobRetention } & {bigint } & {64 bit seconds to retain Job } -\\ \hline - -\end{longtable} - -The {\bf Client} table contains one entry for each machine backed up by Bacula -in this database. Normally the Name is a fully qualified domain name. - -\ - -\addcontentsline{lot}{table}{Unsaved Files Table Layout} -\begin{longtable}{|l|l|l|} - \hline -\multicolumn{3}{|l| }{\bf UnsavedFiles } \\ - \hline -\multicolumn{1}{|c| }{\bf Column Name } & \multicolumn{1}{c| }{\bf Data Type -} & \multicolumn{1}{c| }{\bf Remark } \\ - \hline -{UnsavedId } & {integer } & {Primary Key } \\ - \hline -{JobId } & {integer } & {JobId corresponding to this record } \\ - \hline -{PathId } & {integer } & {Id of path } \\ - \hline -{FilenameId } & {integer } & {Id of filename } -\\ \hline - -\end{longtable} - -The {\bf UnsavedFiles} table contains one entry for each file that was not -saved. Note! This record is not yet implemented. - -\ - -\addcontentsline{lot}{table}{Counter Table Layout} -\begin{longtable}{|l|l|l|} - \hline -\multicolumn{3}{|l| }{\bf Counter } \\ - \hline -\multicolumn{1}{|c| }{\bf Column Name } & \multicolumn{1}{c| }{\bf Data Type -} & \multicolumn{1}{c| }{\bf Remark } \\ - \hline -{Counter } & {tinyblob } & {Counter name } \\ - \hline -{MinValue } & {integer } & {Start/Min value for counter } \\ - \hline -{MaxValue } & {integer } & {Max value for counter } \\ - \hline -{CurrentValue } & {integer } & {Current counter value } \\ - \hline -{WrapCounter } & {tinyblob } & {Name of another counter } -\\ \hline - -\end{longtable} - -The {\bf Counter} table contains one entry for each permanent counter defined -by the user. - -\ - -\addcontentsline{lot}{table}{Version Table Layout} -\begin{longtable}{|l|l|l|} - \hline -\multicolumn{3}{|l| }{\bf Version } \\ - \hline -\multicolumn{1}{|c| }{\bf Column Name } & \multicolumn{1}{c| }{\bf Data Type -} & \multicolumn{1}{c| }{\bf Remark } \\ - \hline -{VersionId } & {integer } & {Primary Key } -\\ \hline - -\end{longtable} - -The {\bf Version} table defines the Bacula database version number. Bacula -checks this number before reading the database to ensure that it is compatible -with the Bacula binary file. - -\ - -\addcontentsline{lot}{table}{Base Files Table Layout} -\begin{longtable}{|l|l|l|} - \hline -\multicolumn{3}{|l| }{\bf BaseFiles } \\ - \hline -\multicolumn{1}{|c| }{\bf Column Name } & \multicolumn{1}{c| }{\bf Data Type -} & \multicolumn{1}{c| }{\bf Remark } \\ - \hline -{BaseId } & {integer } & {Primary Key } \\ - \hline -{BaseJobId } & {integer } & {JobId of Base Job } \\ - \hline -{JobId } & {integer } & {Reference to Job } \\ - \hline -{FileId } & {integer } & {Reference to File } \\ - \hline -{FileIndex } & {integer } & {File Index number } -\\ \hline - -\end{longtable} - -The {\bf BaseFiles} table contains all the File references for a particular -JobId that point to a Base file -- i.e. they were previously saved and hence -were not saved in the current JobId but in BaseJobId under FileId. FileIndex -is the index of the file, and is used for optimization of Restore jobs to -prevent the need to read the FileId record when creating the in memory tree. -This record is not yet implemented. - -\ - -\subsubsection*{MySQL Table Definition} -\index[general]{MySQL Table Definition } -\index[general]{Definition!MySQL Table } -\addcontentsline{toc}{subsubsection}{MySQL Table Definition} - -The commands used to create the MySQL tables are as follows: - -\footnotesize -\begin{verbatim} -USE bacula; -CREATE TABLE Filename ( - FilenameId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, - Name BLOB NOT NULL, - PRIMARY KEY(FilenameId), - INDEX (Name(30)) - ); -CREATE TABLE Path ( - PathId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, - Path BLOB NOT NULL, - PRIMARY KEY(PathId), - INDEX (Path(50)) - ); -CREATE TABLE File ( - FileId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, - FileIndex INTEGER UNSIGNED NOT NULL DEFAULT 0, - JobId INTEGER UNSIGNED NOT NULL REFERENCES Job, - PathId INTEGER UNSIGNED NOT NULL REFERENCES Path, - FilenameId INTEGER UNSIGNED NOT NULL REFERENCES Filename, - MarkId INTEGER UNSIGNED NOT NULL DEFAULT 0, - LStat TINYBLOB NOT NULL, - MD5 TINYBLOB NOT NULL, - PRIMARY KEY(FileId), - INDEX (JobId), - INDEX (PathId), - INDEX (FilenameId) - ); -CREATE TABLE Job ( - JobId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, - Job TINYBLOB NOT NULL, - Name TINYBLOB NOT NULL, - Type BINARY(1) NOT NULL, - Level BINARY(1) NOT NULL, - ClientId INTEGER NOT NULL REFERENCES Client, - JobStatus BINARY(1) NOT NULL, - SchedTime DATETIME NOT NULL, - StartTime DATETIME NOT NULL, - EndTime DATETIME NOT NULL, - JobTDate BIGINT UNSIGNED NOT NULL, - VolSessionId INTEGER UNSIGNED NOT NULL DEFAULT 0, - VolSessionTime INTEGER UNSIGNED NOT NULL DEFAULT 0, - JobFiles INTEGER UNSIGNED NOT NULL DEFAULT 0, - JobBytes BIGINT UNSIGNED NOT NULL, - JobErrors INTEGER UNSIGNED NOT NULL DEFAULT 0, - JobMissingFiles INTEGER UNSIGNED NOT NULL DEFAULT 0, - PoolId INTEGER UNSIGNED NOT NULL REFERENCES Pool, - FileSetId INTEGER UNSIGNED NOT NULL REFERENCES FileSet, - PurgedFiles TINYINT NOT NULL DEFAULT 0, - HasBase TINYINT NOT NULL DEFAULT 0, - PRIMARY KEY(JobId), - INDEX (Name(128)) - ); -CREATE TABLE FileSet ( - FileSetId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, - FileSet TINYBLOB NOT NULL, - MD5 TINYBLOB NOT NULL, - CreateTime DATETIME NOT NULL, - PRIMARY KEY(FileSetId) - ); -CREATE TABLE JobMedia ( - JobMediaId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, - JobId INTEGER UNSIGNED NOT NULL REFERENCES Job, - MediaId INTEGER UNSIGNED NOT NULL REFERENCES Media, - FirstIndex INTEGER UNSIGNED NOT NULL DEFAULT 0, - LastIndex INTEGER UNSIGNED NOT NULL DEFAULT 0, - StartFile INTEGER UNSIGNED NOT NULL DEFAULT 0, - EndFile INTEGER UNSIGNED NOT NULL DEFAULT 0, - StartBlock INTEGER UNSIGNED NOT NULL DEFAULT 0, - EndBlock INTEGER UNSIGNED NOT NULL DEFAULT 0, - VolIndex INTEGER UNSIGNED NOT NULL DEFAULT 0, - PRIMARY KEY(JobMediaId), - INDEX (JobId, MediaId) - ); -CREATE TABLE Media ( - MediaId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, - VolumeName TINYBLOB NOT NULL, - Slot INTEGER NOT NULL DEFAULT 0, - PoolId INTEGER UNSIGNED NOT NULL REFERENCES Pool, - MediaType TINYBLOB NOT NULL, - FirstWritten DATETIME NOT NULL, - LastWritten DATETIME NOT NULL, - LabelDate DATETIME NOT NULL, - VolJobs INTEGER UNSIGNED NOT NULL DEFAULT 0, - VolFiles INTEGER UNSIGNED NOT NULL DEFAULT 0, - VolBlocks INTEGER UNSIGNED NOT NULL DEFAULT 0, - VolMounts INTEGER UNSIGNED NOT NULL DEFAULT 0, - VolBytes BIGINT UNSIGNED NOT NULL DEFAULT 0, - VolErrors INTEGER UNSIGNED NOT NULL DEFAULT 0, - VolWrites INTEGER UNSIGNED NOT NULL DEFAULT 0, - VolCapacityBytes BIGINT UNSIGNED NOT NULL, - VolStatus ENUM('Full', 'Archive', 'Append', 'Recycle', 'Purged', - 'Read-Only', 'Disabled', 'Error', 'Busy', 'Used', 'Cleaning') NOT NULL, - Recycle TINYINT NOT NULL DEFAULT 0, - VolRetention BIGINT UNSIGNED NOT NULL DEFAULT 0, - VolUseDuration BIGINT UNSIGNED NOT NULL DEFAULT 0, - MaxVolJobs INTEGER UNSIGNED NOT NULL DEFAULT 0, - MaxVolFiles INTEGER UNSIGNED NOT NULL DEFAULT 0, - MaxVolBytes BIGINT UNSIGNED NOT NULL DEFAULT 0, - InChanger TINYINT NOT NULL DEFAULT 0, - MediaAddressing TINYINT NOT NULL DEFAULT 0, - VolReadTime BIGINT UNSIGNED NOT NULL DEFAULT 0, - VolWriteTime BIGINT UNSIGNED NOT NULL DEFAULT 0, - PRIMARY KEY(MediaId), - INDEX (PoolId) - ); -CREATE TABLE Pool ( - PoolId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, - Name TINYBLOB NOT NULL, - NumVols INTEGER UNSIGNED NOT NULL DEFAULT 0, - MaxVols INTEGER UNSIGNED NOT NULL DEFAULT 0, - UseOnce TINYINT NOT NULL, - UseCatalog TINYINT NOT NULL, - AcceptAnyVolume TINYINT DEFAULT 0, - VolRetention BIGINT UNSIGNED NOT NULL, - VolUseDuration BIGINT UNSIGNED NOT NULL, - MaxVolJobs INTEGER UNSIGNED NOT NULL DEFAULT 0, - MaxVolFiles INTEGER UNSIGNED NOT NULL DEFAULT 0, - MaxVolBytes BIGINT UNSIGNED NOT NULL, - AutoPrune TINYINT DEFAULT 0, - Recycle TINYINT DEFAULT 0, - PoolType ENUM('Backup', 'Copy', 'Cloned', 'Archive', 'Migration', 'Scratch') NOT NULL, - LabelFormat TINYBLOB, - Enabled TINYINT DEFAULT 1, - ScratchPoolId INTEGER UNSIGNED DEFAULT 0 REFERENCES Pool, - RecyclePoolId INTEGER UNSIGNED DEFAULT 0 REFERENCES Pool, - UNIQUE (Name(128)), - PRIMARY KEY (PoolId) - ); -CREATE TABLE Client ( - ClientId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, - Name TINYBLOB NOT NULL, - Uname TINYBLOB NOT NULL, /* full uname -a of client */ - AutoPrune TINYINT DEFAULT 0, - FileRetention BIGINT UNSIGNED NOT NULL, - JobRetention BIGINT UNSIGNED NOT NULL, - UNIQUE (Name(128)), - PRIMARY KEY(ClientId) - ); -CREATE TABLE BaseFiles ( - BaseId INTEGER UNSIGNED AUTO_INCREMENT, - BaseJobId INTEGER UNSIGNED NOT NULL REFERENCES Job, - JobId INTEGER UNSIGNED NOT NULL REFERENCES Job, - FileId INTEGER UNSIGNED NOT NULL REFERENCES File, - FileIndex INTEGER UNSIGNED, - PRIMARY KEY(BaseId) - ); -CREATE TABLE UnsavedFiles ( - UnsavedId INTEGER UNSIGNED AUTO_INCREMENT, - JobId INTEGER UNSIGNED NOT NULL REFERENCES Job, - PathId INTEGER UNSIGNED NOT NULL REFERENCES Path, - FilenameId INTEGER UNSIGNED NOT NULL REFERENCES Filename, - PRIMARY KEY (UnsavedId) - ); -CREATE TABLE Version ( - VersionId INTEGER UNSIGNED NOT NULL - ); --- Initialize Version -INSERT INTO Version (VersionId) VALUES (7); -CREATE TABLE Counters ( - Counter TINYBLOB NOT NULL, - MinValue INTEGER, - MaxValue INTEGER, - CurrentValue INTEGER, - WrapCounter TINYBLOB NOT NULL, - PRIMARY KEY (Counter(128)) - ); -\end{verbatim} -\normalsize diff --git a/docs/manual-fr/catmaintenance.tex b/docs/manual-fr/catmaintenance.tex deleted file mode 100644 index 295cedb0..00000000 --- a/docs/manual-fr/catmaintenance.tex +++ /dev/null @@ -1,509 +0,0 @@ -%% -%% - -\section*{Catalog Maintenance} -\label{_ChapterStart12} -\index[general]{Maintenance!Catalog } -\index[general]{Catalog Maintenance } -\addcontentsline{toc}{section}{Catalog Maintenance} - -Without proper setup and maintenance, your Catalog may continue to grow -indefinitely as you run Jobs and backup Files. How fast the size of your -Catalog grows depends on the number of Jobs you run and how many files they -backup. By deleting records within the database, you can make space available -for the new records that will be added during the next Job. By constantly -deleting old expired records (dates older than the Retention period), your -database size will remain constant. - -If you started with the default configuration files, they already contain -reasonable defaults for a small number of machines (less than 5), so if you -fall into that case, catalog maintenance will not be urgent if you have a few -hundred megabytes of disk space free. Whatever the case may be, some knowledge -of retention periods will be useful. -\label{Retention} - -\subsection*{Setting Retention Periods} -\index[general]{Setting Retention Periods } -\index[general]{Periods!Setting Retention } -\addcontentsline{toc}{subsection}{Setting Retention Periods} - -{\bf Bacula} uses three Retention periods: the {\bf File Retention} period, -the {\bf Job Retention} period, and the {\bf Volume Retention} period. Of -these three, the File Retention period is by far the most important in -determining how large your database will become. - -The {\bf File Retention} and the {\bf Job Retention} are specified in each -Client resource as is shown below. The {\bf Volume Retention} period is -specified in the Pool resource, and the details are given in the next chapter -of this manual. - -\begin{description} - -\item [File Retention = \lt{}time-period-specification\gt{}] - \index[dir]{File Retention } - The File Retention record defines the length of time that Bacula will keep -File records in the Catalog database. When this time period expires, and if -{\bf AutoPrune} is set to {\bf yes}, Bacula will prune (remove) File records -that are older than the specified File Retention period. The pruning will -occur at the end of a backup Job for the given Client. Note that the Client -database record contains a copy of the File and Job retention periods, but -Bacula uses the current values found in the Director's Client resource to do -the pruning. - -Since File records in the database account for probably 80 percent of the -size of the database, you should carefully determine exactly what File -Retention period you need. Once the File records have been removed from -the database, you will no longer be able to restore individual files -in a Job. However, with Bacula version 1.37 and later, as long as the -Job record still exists, you will be able to restore all files in the -job. - -Retention periods are specified in seconds, but as a convenience, there are -a number of modifiers that permit easy specification in terms of minutes, -hours, days, weeks, months, quarters, or years on the record. See the -\ilink{ Configuration chapter}{Time} of this manual for additional details -of modifier specification. - -The default File retention period is 60 days. - -\item [Job Retention = \lt{}time-period-specification\gt{}] - \index[dir]{Job Retention } - The Job Retention record defines the length of time that {\bf Bacula} -will keep Job records in the Catalog database. When this time period -expires, and if {\bf AutoPrune} is set to {\bf yes} Bacula will prune -(remove) Job records that are older than the specified Job Retention -period. Note, if a Job record is selected for pruning, all associated File -and JobMedia records will also be pruned regardless of the File Retention -period set. As a consequence, you normally will set the File retention -period to be less than the Job retention period. - -As mentioned above, once the File records are removed from the database, -you will no longer be able to restore individual files from the Job. -However, as long as the Job record remains in the database, you will be -able to restore all the files backuped for the Job (on version 1.37 and -later). As a consequence, it is generally a good idea to retain the Job -records much longer than the File records. - -The retention period is specified in seconds, but as a convenience, there -are a number of modifiers that permit easy specification in terms of -minutes, hours, days, weeks, months, quarters, or years. See the \ilink{ -Configuration chapter}{Time} of this manual for additional details of -modifier specification. - -The default Job Retention period is 180 days. - -\item [AutoPrune = \lt{}yes/no\gt{}] - \index[dir]{AutoPrune } - If AutoPrune is set to {\bf yes} (default), Bacula will automatically apply -the File retention period and the Job retention period for the Client at the -end of the Job. - -If you turn this off by setting it to {\bf no}, your Catalog will grow each -time you run a Job. -\end{description} - -\label{CompactingMySQL} - -\subsection*{Compacting Your MySQL Database} -\index[general]{Database!Compacting Your MySQL } -\index[general]{Compacting Your MySQL Database } -\addcontentsline{toc}{subsection}{Compacting Your MySQL Database} - -Over time, as noted above, your database will tend to grow. I've noticed that -even though Bacula regularly prunes files, {\bf MySQL} does not effectively -use the space, and instead continues growing. To avoid this, from time to -time, you must compact your database. Normally, large commercial database such -as Oracle have commands that will compact a database to reclaim wasted file -space. MySQL has the {\bf OPTIMIZE TABLE} command that you can use, and SQLite -version 2.8.4 and greater has the {\bf VACUUM} command. We leave it to you to -explore the utility of the {\bf OPTIMIZE TABLE} command in MySQL. - -All database programs have some means of writing the database out in ASCII -format and then reloading it. Doing so will re-create the database from -scratch producing a compacted result, so below, we show you how you can do -this for MySQL, PostgreSQL and SQLite. - -For a {\bf MySQL} database, you could write the Bacula database as an ASCII -file (bacula.sql) then reload it by doing the following: - -\footnotesize -\begin{verbatim} -mysqldump -f --opt bacula > bacula.sql -mysql bacula < bacula.sql -rm -f bacula.sql -\end{verbatim} -\normalsize - -Depending on the size of your database, this will take more or less time and a -fair amount of disk space. For example, if I cd to the location of the MySQL -Bacula database (typically /opt/mysql/var or something similar) and enter: - -\footnotesize -\begin{verbatim} -du bacula -\end{verbatim} -\normalsize - -I get {\bf 620,644} which means there are that many blocks containing 1024 -bytes each or approximately 635 MB of data. After doing the {\bf msqldump}, I -had a bacula.sql file that had {\bf 174,356} blocks, and after doing the {\bf -mysql} command to recreate the database, I ended up with a total of {\bf -210,464} blocks rather than the original {\bf 629,644}. In other words, the -compressed version of the database took approximately one third of the space -of the database that had been in use for about a year. - -As a consequence, I suggest you monitor the size of your database and from -time to time (once every 6 months or year), compress it. -\label{RepairingMySQL} - -\subsection*{Repairing Your MySQL Database} -\index[general]{Database!Repairing Your MySQL } -\index[general]{Repairing Your MySQL Database } -\addcontentsline{toc}{subsection}{Repairing Your MySQL Database} - -If you find that you are getting errors writing to your MySQL database, or -Bacula hangs each time it tries to access the database, you should consider -running MySQL's database check and repair routines. The program you need to -run depends on the type of database indexing you are using. If you are using -the default, you will probably want to use {\bf myisamchk}. For more details -on how to do this, please consult the MySQL document at: -\elink{ -http://www.mysql.com/doc/en/Repair.html} -{http://www.mysql.com/doc/en/Repair.html}. - -If the errors you are getting are simply SQL warnings, then you might try -running dbcheck before (or possibly after) using the MySQL database repair -program. It can clean up many of the orphaned record problems, and certain -other inconsistencies in the Bacula database. -\label{RepairingPSQL} - -\subsection*{Repairing Your PostgreSQL Database} -\index[general]{Database!Repairing Your PostgreSQL } -\index[general]{Repairing Your PostgreSQL Database } -\addcontentsline{toc}{subsection}{Repairing Your PostgreSQL Database} - -The same considerations apply that are indicated above for MySQL. That is, -consult the PostgreSQL documents for how to repair the database, and also -consider using Bacula's dbcheck program if the conditions are reasonable for -using (see above). -\label{CompactingPostgres} - -\subsection*{Performance Issues} -\index[general]{Database Performance Issues} -\index[general]{Performance!Database} -\addcontentsline{toc}{subsection}{Database Performance Issues} - -There are a considerable number of ways each of the databases can be -tuned to improve the performance. Going from an untuned database to one -that is properly tuned can make a difference of a factor of 100 or more -in the time to insert or search for records. - -For each of the databases, you may get significant improvements by adding -additional indexes. The comments in the Bacula make\_xxx\_tables give some -indications as to what indexes may be appropriate. - -For MySQL, what seems to be very important is to use the examine the -my.cnf file. You may obtain significant performances by switching to -the my-large.cnf or my-huge.cnf files that come with the MySQL source -code. - -For SQLite3, one significant factor in improving the performance is -to ensure that there is a "PRAGMA synchronous = NORMAL;" statement. -This reduces the number of times that the database flushes the in memory -cache to disk. There are other settings for this PRAGMA that can -give even further performance improvements at the risk of a database -corruption if your system crashes. - -For PostgreSQL, you might want to consider turning fsync off. Of course -doing so can cause corrupted databases in the even of a machine crash. -There are many different ways that you can tune PostgreSQL, the -following document discusses a few of them: -\elink{ -http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html} -{http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html}. - -There is also a PostgreSQL FAQ question number 3.3 that may -answer some of your questions about how to improve performance -of the PostgreSQL engine: -\elink{ -http://www.postgresql.org/docs/faqs.FAQ.html\#3.3} -{http://www.postgresql.org/docs/faqs.FAQ.html\#3.3}. - - - - -\subsection*{Compacting Your PostgreSQL Database} -\index[general]{Database!Compacting Your PostgreSQL } -\index[general]{Compacting Your PostgreSQL Database } -\addcontentsline{toc}{subsection}{Compacting Your PostgreSQL Database} - -Over time, as noted above, your database will tend to grow. I've noticed that -even though Bacula regularly prunes files, PostgreSQL has a {\bf VACUUM} -command that will compact your database for you. Alternatively you may want to -use the {\bf vacuumdb} command, which can be run from a cron job. - -All database programs have some means of writing the database out in ASCII -format and then reloading it. Doing so will re-create the database from -scratch producing a compacted result, so below, we show you how you can do -this for PostgreSQL. - -For a {\bf PostgreSQL} database, you could write the Bacula database as an -ASCII file (bacula.sql) then reload it by doing the following: - -\footnotesize -\begin{verbatim} -pg_dump bacula > bacula.sql -cat bacula.sql | psql bacula -rm -f bacula.sql -\end{verbatim} -\normalsize - -Depending on the size of your database, this will take more or less time and a -fair amount of disk space. For example, you can {\bf cd} to the location of -the Bacula database (typically /usr/local/pgsql/data or possible -/var/lib/pgsql/data) and check the size. - -\subsection*{Compacting Your SQLite Database} -\index[general]{Compacting Your SQLite Database } -\index[general]{Database!Compacting Your SQLite } -\addcontentsline{toc}{subsection}{Compacting Your SQLite Database} - -First please read the previous section that explains why it is necessary to -compress a database. SQLite version 2.8.4 and greater have the {\bf Vacuum} -command for compacting the database. - -\footnotesize -\begin{verbatim} -cd {\bf working-directory} -echo 'vacuum;' | sqlite bacula.db -\end{verbatim} -\normalsize - -As an alternative, you can use the following commands, adapted to your system: - - -\footnotesize -\begin{verbatim} -cd {\bf working-directory} -echo '.dump' | sqlite bacula.db > bacula.sql -rm -f bacula.db -sqlite bacula.db < bacula.sql -rm -f bacula.sql -\end{verbatim} -\normalsize - -Where {\bf working-directory} is the directory that you specified in the -Director's configuration file. Note, in the case of SQLite, it is necessary to -completely delete (rm) the old database before creating a new compressed -version. - -\subsection*{Migrating from SQLite to MySQL} -\index[general]{MySQL!Migrating from SQLite to } -\index[general]{Migrating from SQLite to MySQL } -\addcontentsline{toc}{subsection}{Migrating from SQLite to MySQL} - -You may begin using Bacula with SQLite then later find that you want to switch -to MySQL for any of a number of reasons: SQLite tends to use more disk than -MySQL, SQLite apparently does not handle database sizes greater than 2GBytes, -... Several users have done so by first producing an ASCII "dump" of the -SQLite database, then creating the MySQL tables with the {\bf -create\_mysql\_tables} script that comes with Bacula, and finally feeding the -SQLite dump into MySQL using the {\bf -f} command line option to continue past -the errors that are generated by the DDL statements that SQLite's dump -creates. Of course, you could edit the dump and remove the offending -statements. Otherwise, MySQL accepts the SQL produced by SQLite. - -\label{BackingUpBacula} -\subsection*{Backing Up Your Bacula Database} -\index[general]{Backing Up Your Bacula Database } -\index[general]{Database!Backing Up Your Bacula } -\addcontentsline{toc}{subsection}{Backing Up Your Bacula Database} - -If ever the machine on which your Bacula database crashes, and you need to -restore from backup tapes, one of your first priorities will probably be to -recover the database. Although Bacula will happily backup your catalog -database if it is specified in the FileSet, this is not a very good way to do -it, because the database will be saved while Bacula is modifying it. Thus the -database may be in an instable state. Worse yet, you will backup the database -before all the Bacula updates have been applied. - -To resolve these problems, you need to backup the database after all the backup -jobs have been run. In addition, you will want to make a copy while Bacula is -not modifying it. To do so, you can use two scripts provided in the release -{\bf make\_catalog\_backup} and {\bf delete\_catalog\_backup}. These files -will be automatically generated along with all the other Bacula scripts. The -first script will make an ASCII copy of your Bacula database into {\bf -bacula.sql} in the working directory you specified in your configuration, and -the second will delete the {\bf bacula.sql} file. - -The basic sequence of events to make this work correctly is as follows: - -\begin{itemize} -\item Run all your nightly backups -\item After running your nightly backups, run a Catalog backup Job -\item The Catalog backup job must be scheduled after your last nightly backup - -\item You use {\bf RunBeforeJob} to create the ASCII backup file and {\bf - RunAfterJob} to clean up - \end{itemize} - -Assuming that you start all your nightly backup jobs at 1:05 am (and that they -run one after another), you can do the catalog backup with the following -additional Director configuration statements: - -\footnotesize -\begin{verbatim} -# Backup the catalog database (after the nightly save) -Job { - Name = "BackupCatalog" - Type = Backup - Client=rufus-fd - FileSet="Catalog" - Schedule = "WeeklyCycleAfterBackup" - Storage = DLTDrive - Messages = Standard - Pool = Default - RunBeforeJob = "/home/kern/bacula/bin/make_catalog_backup" - RunAfterJob = "/home/kern/bacula/bin/delete_catalog_backup" - Write Bootstrap = "/home/kern/bacula/working/BackupCatalog.bsr" -} -# This schedule does the catalog. It starts after the WeeklyCycle -Schedule { - Name = "WeeklyCycleAfterBackup - Run = Full sun-sat at 1:10 -} -# This is the backup of the catalog -FileSet { - Name = "Catalog" - Include = signature=MD5 { - @working_directory@/bacula.sql - } -} -\end{verbatim} -\normalsize - -Be sure to write a bootstrap file as in the above example. It is preferable -to write or copy the bootstrap file to another computer. It will allow -you to quickly recover the database backup should that be necessary. If -you do not have a bootstrap file, it is still possible to recover your -database backup, but it will be more work and take longer. - -\label{BackingUPOtherDBs} -\subsection*{Backing Up Third Party Databases} -\index[general]{Backing Up Third Party Databases } -\index[general]{Databases!Backing Up Third Party } -\addcontentsline{toc}{subsection}{Backing Up Third Party Databases} - -If you are running a database in production mode on your machine, Bacula will -happily backup the files, but if the database is in use while Bacula is -reading it, you may back it up in an unstable state. - -The best solution is to shutdown your database before backing it up, or use -some tool specific to your database to make a valid live copy perhaps by -dumping the database in ASCII format. I am not a database expert, so I cannot -provide you advice on how to do this, but if you are unsure about how to -backup your database, you might try visiting the Backup Central site, which -has been renamed Storage Mountain (www.backupcentral.com). In particular, -their -\elink{ Free Backup and Recovery -Software}{http://www.backupcentral.com/toc-free-backup-software.html} page has -links to scripts that show you how to shutdown and backup most major -databases. -\label{Size} - -\subsection*{Database Size} -\index[general]{Size!Database } -\index[general]{Database Size } -\addcontentsline{toc}{subsection}{Database Size} - -As mentioned above, if you do not do automatic pruning, your Catalog will grow -each time you run a Job. Normally, you should decide how long you want File -records to be maintained in the Catalog and set the {\bf File Retention} -period to that time. Then you can either wait and see how big your Catalog -gets or make a calculation assuming approximately 154 bytes for each File -saved and knowing the number of Files that are saved during each backup and -the number of Clients you backup. - -For example, suppose you do a backup of two systems, each with 100,000 files. -Suppose further that you do a Full backup weekly and an Incremental every day, -and that the Incremental backup typically saves 4,000 files. The size of your -database after a month can roughly be calculated as: - -\footnotesize -\begin{verbatim} - Size = 154 * No. Systems * (100,000 * 4 + 10,000 * 26) -\end{verbatim} -\normalsize - -where we have assumed 4 weeks in a month and 26 incremental backups per month. -This would give the following: - -\footnotesize -\begin{verbatim} - Size = 154 * 2 * (100,000 * 4 + 10,000 * 26) -or - Size = 308 * (400,000 + 260,000) -or - Size = 203,280,000 bytes -\end{verbatim} -\normalsize - -So for the above two systems, we should expect to have a database size of -approximately 200 Megabytes. Of course, this will vary according to how many -files are actually backed up. - -Below are some statistics for a MySQL database containing Job records for five -Clients beginning September 2001 through May 2002 (8.5 months) and File -records for the last 80 days. (Older File records have been pruned). For these -systems, only the user files and system files that change are backed up. The -core part of the system is assumed to be easily reloaded from the RedHat rpms. - - -In the list below, the files (corresponding to Bacula Tables) with the -extension .MYD contain the data records whereas files with the extension .MYI -contain indexes. - -You will note that the File records (containing the file attributes) make up -the large bulk of the number of records as well as the space used (459 Mega -Bytes including the indexes). As a consequence, the most important Retention -period will be the {\bf File Retention} period. A quick calculation shows that -for each File that is saved, the database grows by approximately 150 bytes. - -\footnotesize -\begin{verbatim} - Size in - Bytes Records File - ============ ========= =========== - 168 5 Client.MYD - 3,072 Client.MYI - 344,394,684 3,080,191 File.MYD - 115,280,896 File.MYI - 2,590,316 106,902 Filename.MYD - 3,026,944 Filename.MYI - 184 4 FileSet.MYD - 2,048 FileSet.MYI - 49,062 1,326 JobMedia.MYD - 30,720 JobMedia.MYI - 141,752 1,378 Job.MYD - 13,312 Job.MYI - 1,004 11 Media.MYD - 3,072 Media.MYI - 1,299,512 22,233 Path.MYD - 581,632 Path.MYI - 36 1 Pool.MYD - 3,072 Pool.MYI - 5 1 Version.MYD - 1,024 Version.MYI -\end{verbatim} -\normalsize - -This database has a total size of approximately 450 Megabytes. - -If we were using SQLite, the determination of the total database size would be -much easier since it is a single file, but we would have less insight to the -size of the individual tables as we have in this case. - -Note, SQLite databases may be as much as 50\% larger than MySQL databases due -to the fact that all data is stored as ASCII strings. That is even binary -integers are stored as ASCII strings, and this seems to increase the space -needed. diff --git a/docs/manual-fr/check_hyphens.pl b/docs/manual-fr/check_hyphens.pl deleted file mode 100755 index 96af5629..00000000 --- a/docs/manual-fr/check_hyphens.pl +++ /dev/null @@ -1,123 +0,0 @@ -#!/usr/bin/perl -w -# Finds multiple hyphens not inside a verbatim environment (or \verb). -# Places these inside a \verb{} contruct so they will not be converted -# to single hyphen by latex or latex2html. - -use strict; - -# The following builds the test string to identify and change multiple -# hyphens in the tex files. Several constructs are identified but only -# multiple hyphens are changed; the others are fed to the output -# unchanged. -my $b = '\\\\begin\\*?\\s*\\{\\s*'; # \begin{ -my $e = '\\\\end\\*?\\s*\\{\\s*'; # \end{ -my $c = '\\s*\\}'; # closing curly brace - -# This captures entire verbatim environments. These are passed to the output -# file unchanged. -my $verbatimenv = $b . "verbatim" . $c . ".*?" . $e . "verbatim" . $c; - -# This captures \verb{} constructs. They are passed to the output unchanged. -my $verb = '\\\\verb\\*?(.).*?\\1'; - -# This identifies multiple hyphens. -my $hyphens = '\\-{2,}'; - -# This builds the actual test string from the above strings. -#my $teststr = "$verbatimenv|$verb|$tocentry|$hyphens"; -my $teststr = "$verbatimenv|$verb|$hyphens"; - - -sub get_includes { - # Get a list of include files from the top-level tex file. - my (@list,$file); - - while (my $filename = shift) { - # Start with the top-level latex file so it gets checked too. - push (@list,$filename); - - # Get a list of all the html files in the directory. - open IF,"<$filename" or die "Cannot open input file $filename"; - while () { - chomp; - push @list,"$1.tex" if (/\\include\{(.*?)\}/); - } - - close IF; - } - return @list; -} - -sub convert_hyphens { - my (@files) = @_; - my ($filedata,$out,$this,$thiscnt,$before,$verbenv,$cnt); - - # Build the test string to check for the various environments. - # We only do the conversion if the multiple hyphens are outside of a - # verbatim environment (either \begin{verbatim}...\end{verbatim} or - # \verb{--}). Capture those environments and pass them to the output - # unchanged. - - $cnt = 0; - foreach my $file (@files) { - # Open the file and load the whole thing into $filedata. A bit wasteful but - # easier to deal with, and we don't have a problem with speed here. - $filedata = ""; - open IF,"<$file" or die "Cannot open input file $file"; - while () { - $filedata .= $_; - } - close IF; - - # Set up to process the file data. - $out = ""; - $verbenv = 0; - $thiscnt = 0; - - # Go through the file data from beginning to end. For each match, save what - # came before it and what matched. $filedata now becomes only what came - # after the match. - # Chech the match to see if it starts with a multiple-hyphen. If so - # change it to \verb{--}. The other possible matches in the pattern - # won't start with a hyphen, so we're ok with matching that. - while ($filedata =~ /$teststr/os) { - $this = $&; - $before = $`; - $filedata = $'; - # This is where the actual conversion is done. - - # Use this contruct for putting something in between each hyphen - #$thiscnt += ($this =~ s/^\-+/do {join('\\,',split('',$&));}/e); - - # Use this construct for putting something around each hyphen. - $thiscnt += ($this =~ s/^\-+/\\verb\{$&\{/); - - # Put what came before and our (possibly) changed string into - # the output buffer. - $out .= $before . $this; - } - - # If any hyphens were converted, save the file. - if ($thiscnt) { - open OF,">$file" or die "Cannot open output file $file"; - print OF $out . $filedata; - close OF; - } - $cnt += $thiscnt; - } - return $cnt; -} -################################################################## -# MAIN #### -################################################################## - -my (@includes); -my $cnt; - -# Examine the file pointed to by the first argument to get a list of -# includes to test. -@includes = get_includes(@ARGV); - -$cnt = convert_hyphens(@includes); - -print "$cnt Multiple hyphen", ($cnt == 1) ? "" : "s"," Found\n"; diff --git a/docs/manual-fr/check_tex.pl b/docs/manual-fr/check_tex.pl deleted file mode 100755 index e12d51be..00000000 --- a/docs/manual-fr/check_tex.pl +++ /dev/null @@ -1,152 +0,0 @@ -#!/usr/bin/perl -w -# Finds potential problems in tex files, and issues warnings to the console -# about what it finds. Takes a list of files as its only arguments, -# and does checks on all the files listed. The assumption is that these are -# valid (or close to valid) LaTeX files. It follows \include statements -# recursively to pick up any included tex files. -# -# -# -# Currently the following checks are made: -# -# -- Multiple hyphens not inside a verbatim environment (or \verb). These -# should be placed inside a \verb{} contruct so they will not be converted -# to single hyphen by latex and latex2html. - - -# Original creation 3-8-05 by Karl Cunningham karlc -at- keckec -dot- com -# -# - -use strict; - -# The following builds the test string to identify and change multiple -# hyphens in the tex files. Several constructs are identified but only -# multiple hyphens are changed; the others are fed to the output -# unchanged. -my $b = '\\\\begin\\*?\\s*\\{\\s*'; # \begin{ -my $e = '\\\\end\\*?\\s*\\{\\s*'; # \end{ -my $c = '\\s*\\}'; # closing curly brace - -# This captures entire verbatim environments. These are passed to the output -# file unchanged. -my $verbatimenv = $b . "verbatim" . $c . ".*?" . $e . "verbatim" . $c; - -# This captures \verb{..{ constructs. They are passed to the output unchanged. -my $verb = '\\\\verb\\*?(.).*?\\1'; - -# This captures multiple hyphens with a leading and trailing space. These are not changed. -my $hyphsp = '\\s\\-{2,}\\s'; - -# This identifies other multiple hyphens. -my $hyphens = '\\-{2,}'; - -# This identifies \hyperpage{..} commands, which should be ignored. -my $hyperpage = '\\\\hyperpage\\*?\\{.*?\\}'; - -# This builds the actual test string from the above strings. -#my $teststr = "$verbatimenv|$verb|$tocentry|$hyphens"; -my $teststr = "$verbatimenv|$verb|$hyphsp|$hyperpage|$hyphens"; - - -sub get_includes { - # Get a list of include files from the top-level tex file. The first - # argument is a pointer to the list of files found. The rest of the - # arguments is a list of filenames to check for includes. - my $files = shift; - my ($fileline,$includefile,$includes); - - while (my $filename = shift) { - # Get a list of all the html files in the directory. - open my $if,"<$filename" or die "Cannot open input file $filename\n"; - $fileline = 0; - $includes = 0; - while (<$if>) { - chomp; - $fileline++; - # If a file is found in an include, process it. - if (($includefile) = /\\include\s*\{(.*?)\}/) { - $includes++; - # Append .tex to the filename - $includefile .= '.tex'; - - # If the include file has already been processed, issue a warning - # and don't do it again. - my $found = 0; - foreach (@$files) { - if ($_ eq $includefile) { - $found = 1; - last; - } - } - if ($found) { - print "$includefile found at line $fileline in $filename was previously included\n"; - } else { - # The file has not been previously found. Save it and - # recursively process it. - push (@$files,$includefile); - get_includes($files,$includefile); - } - } - } - close IF; - } -} - - -sub check_hyphens { - my (@files) = @_; - my ($filedata,$this,$linecnt,$before); - - # Build the test string to check for the various environments. - # We only do the conversion if the multiple hyphens are outside of a - # verbatim environment (either \begin{verbatim}...\end{verbatim} or - # \verb{--}). Capture those environments and pass them to the output - # unchanged. - - foreach my $file (@files) { - # Open the file and load the whole thing into $filedata. A bit wasteful but - # easier to deal with, and we don't have a problem with speed here. - $filedata = ""; - open IF,"<$file" or die "Cannot open input file $file"; - while () { - $filedata .= $_; - } - close IF; - - # Set up to process the file data. - $linecnt = 1; - - # Go through the file data from beginning to end. For each match, save what - # came before it and what matched. $filedata now becomes only what came - # after the match. - # Chech the match to see if it starts with a multiple-hyphen. If so - # warn the user. Keep track of line numbers so they can be output - # with the warning message. - while ($filedata =~ /$teststr/os) { - $this = $&; - $before = $`; - $filedata = $'; - $linecnt += $before =~ tr/\n/\n/; - - # Check if the multiple hyphen is present outside of one of the - # acceptable constructs. - if ($this =~ /^\-+/) { - print "Possible unwanted multiple hyphen found in line ", - "$linecnt of file $file\n"; - } - $linecnt += $this =~ tr/\n/\n/; - } - } -} -################################################################## -# MAIN #### -################################################################## - -my (@includes,$cnt); - -# Examine the file pointed to by the first argument to get a list of -# includes to test. -get_includes(\@includes,@ARGV); - -check_hyphens(@includes); diff --git a/docs/manual-fr/configure.tex b/docs/manual-fr/configure.tex deleted file mode 100644 index e847e47d..00000000 --- a/docs/manual-fr/configure.tex +++ /dev/null @@ -1,434 +0,0 @@ -%% -%% - -\chapter{Adapter les fichiers de configuration} -\label{_ChapterStart16} -\index[general]{Adapter les fichiers de configuration } -\index[general]{Configuration!Adapter les fichiers de } - -Lors de son d\'emarrage, chacun des programmes qui composent Bacula lit un -fichier de configuration sp\'ecifi\'e sur la ligne de commande, ou par -d\'efaut {\bf bacula-dir.conf}, {\bf bacula-fd.conf}, {\bf bacula-sd.conf}, ou -{\bf console.conf} pour le Director Daemon, le File Daemon, le Storage Daemon, -et le programme Console respectivement. - -Chaque service (Director, Client, Storage, Console) poss\`ede son propre -fichier de configuration qui contient un groupe de directives. Dans la suite, -nous d\'esignerons ces groupes de directives par le mot {\bf Ressource}. Les -ressources son tr\`es similaires d'un service \`a l'autre, mais peuvent -contenir des directives diff\'erentes selon les services. Par exemple, dans le -fichier de configuration du Director, la ressource {\bf Director} d\'efinit le -nom du Director, quelques param\`etres g\'en\'eraux du Director et son mot de -passe. Dans le fichier de configuration du File Daemon, la ressource {\bf -Director} sp\'ecifie les Directors autoris\'es \`a utiliser le File Daemon. - -Avant de lancer Bacula pour la premi\`ere fois, vous devez adapter chaque -fichier de configuration. Des fichiers de configuration auront \'et\'e -cr\'e\'es par le processus d'installation, mais il doivent \^etre modifi\'es -pour correspondre \`a votre syst\`eme. Le sch\'ema suivant donne une vue -globale des ressources. - -\includegraphics{./bacula-objects.eps} -\\ -(Remerciements \`a Aristedes Maniatis pour ce sch\'ema.) -\label{ResFormat} - -\section{Jeu de caract\`eres} -\index[general]{Jeu de caract\`eres} -Bacula est con\c{c}u pour prendre en charge la plupart des jeux de caract\`eres -existant dans le monde : US ASCII, allemand, fran\c{c}ais, chinois... -Cependant, ceci est r\'ealis\'e en encodant tout en UTF-8, et Bacula s'attend \`a -ce que tous ses fichiers de configuration (y compris ceux r\'esidant sur les -machines Win32) soient r\'edig\'es en UTF-8. UTF-8 est le format par d\'efaut sur -la plupart des syst\`emes Linux, mais pas sur toutes les machines Unix, ni sur -les machines Windows, aussi vous devez vous assurer que vos param\`etres -locaux sont correctement r\'egl\'es avant d'utiliser Bacula. - -Vous pouvez v\'erifier que les fichiers de configuration sont lisibles, y compris -les caract\`eres \'etrangers en examinant votre variable d'environnement {bf LANG}. -Celle-ci doit se terminer par {\bf .UTF-8}. Par exemple {\bf en\_US.UTF-8}. -La syntaxe exacte pour la d\'efinir peut varier fortement d'unsyst\`eme d'exploitation -\`a l'autre. - -Bacula consid\`ere que tous les noms de fichiers sont au format UTF-8 sur les -machines Unix et Linux. Sur les machines Windows, ils sont en UTF-16 -et sont automatiquement convertis en UTF-8. - -\section{Format des directives} -\index[general]{Format des directives } -\index[general]{Directives!Format des } - -Bien qu'il ne soit pas n\'ecessaire de conna\^itre le d\'etail de toutes -les directives possibles, une connaissance basique des ressources Bacula est -indispensable. Chaque directive contenue dans une ressource (entre accollades) -est compos\'e d'un mot-clef suivi du signe "=", suivi d'une ou plusieurs -valeurs. Le mot clef doit \^etre l'un de ceux connus par Bacula, et peut -comporter des caract\`eres majuscules et minuscules ainsi que des espaces. - -Chaque d\'efinition de ressource {\bf doit} comporter la directive Name, et peut -optionnellement comporter la directive Description. La directive Name est -utilis\'ee pour identifier de fa\c {c}on unique la ressource. La directive -Description sera utilis\'e lors de l'affichage pour offrir une identification -plus ais\'ee de la ressource. Par exemple : - -\footnotesize -\begin{verbatim} -Director { - Name = "MyDir" - Description = "Main Bacula Director" - WorkingDirectory = "$HOME/bacula/bin/working" -} -\end{verbatim} -\normalsize - -D\'efinit la ressource Director avec le nom "MyDir'' et le r\'epertoire de -travail \$HOME/bacula/bin/working. En g\'en\'eral, si vous voulez utiliser des -espaces dans le nom \`a droite du signe "=", vous devez l'entourer de -doubles quotes. Sinon, les quotes ne sont g\'en\'eralement pas requises car -une fois d\'efinies, les cha\^ines quot\'ees et non quot\'ees sont toutes -\'equivalentes. -\label{Comments} - -\subsection{Commentaires} -\index[general]{Commentaires } - -Lors de la lecture d'un fichier de configuration, les lignes blanches sont -ignor\'ees, et tout ce qui suit le caract\`ere di\`ese (\#) jusqu'\`a la fin -de la ligne est consid\'er\'e comme commentaire. Un point virgule (;) indique -la fin logique d'une ligne et tout ce qui suit le point virgule est -consid\'er\'e comme le param\`etre suivant. Un param\`etre qui appara{\^\i}t -seul sur une ligne ne n\'ecessite pas de point virgule, vous ne verrez donc -pas beaucoup de points virgule dans les exemples de ce manuel. -\label{Case1} - -\subsection{Casse et espaces} -\index[general]{Espaces!Casse et } -\index[general]{Casse et espaces } - -La casse (majuscules/minuscules) et les espaces sont totalement ignor\'ees -dans les mots-clef des directives des ressources (la partie \`a gauche du -signe "=''). - -A l'int\'erieur des mots-clef (\`a gauche du signe "=''), les espaces ne sont -pas significatives. Ainsi, les mots-clef : {\bf name}, {\bf Name}, et {\bf N a -m e} sont tous identiques. - -Les espaces apr\`es le signe "='' et avant le premier caract\`ere de la -valeur son ignor\'ees. - -En g\'en\'eral, les espaces \`a l'int\'erieur d'une valeur sont significatives -(non ignor\'ees), et si la valeur est un nom, vous devez l'encadrer de doubles -quotes pour que l'espace soit accept\'ee. Les noms peuvent contenir jusqu'\`a -127 caract\`eres. Actuellement, un nom peut contenir n'importe quel -caract\`ere ASCII. A l'int\'erieur d'une cha{\^\i}ne quot\'ee, tout -caract\`ere pr\'ec\'ed\'e d'un backslash (\textbackslash{}) est pris tel quel -(utile pour ins\'erer des backslashes et doubles quotes (")). - -Veuillez cependant noter que les noms de ressource Bacula ainsi que certains -autres noms (par exemple les noms de volumes) ne doivent contenir que des -lettres (y compris accentu\'ees ISO), nombres, et une poign\'ee de -caract\`eres sp\'eciaux (espace, soulign\'e, ...). Tous les -autres carat\`eres et ponctuations sont prohib\'es. -\label{Includes} - -\subsection{Inclure d'autres fichiers de configuration} -\index[general]{Configuration!Inclure d'autres fichiers de } -\index[general]{Inclure d'autres fichiers de configuration } -\index[general]{Utiliser @ pour inclure d'autres fichiers de configuration} -\index[general]{@{\bf nom de fichier}} - -Si vous souhaitez \'eclater votre fichier de configuration en fichiers plus -petits, l'inclusion est possible avec la syntaxe @{\bf NomDeFichier} o\`u {\bf -nom de fichier} est le chemin absolu vers un le fichier \`a inclure. Toute -donn\'ee primitive peut \^etre remplac\'ee par une sp\'ecification -@NomDeFichier. Par exemple - -Director \{ Name=@xxx est valide et substituera le fichier xxx \`a @xxx, mais -Director \{ Name@xxx = something n'est pas valide puisque @xxx appara\^it -au milieu d'un (???mot clef/directive/...???) -\label{DataTypes} - -\subsection*{Types de donn\'ees primitives reconnus} -\index[general]{Types de donn\'ees primitives reconnus } -\index[general]{Reconnus!Types de donn\'ees primitives } - -Lorsqu'il parcourt les enregistrements de ressource, Bacula classe les -donn\'ees selon les types enum\'er\'es ci-dessous. En premi\`ere lecture, -cette liste peut vous para\^itre accablante, mais en r\'ealit\'e, tout y -est d'une logique \'el\'egante et directe. - -\begin{description} - -\item [name] - \index[console]{name } - Un mot-clef ou un nom constitu\'e de caract\`eres alphanum\'eriques, incluant - le trait d'union, underscore et dollar. Le premier caract\`ere d'un {\bf name} - doit \^etre une lettre. La longueur d'un {\bf name} est actuellement limit\'ee - \`a 127 caract\`eres. Typiquement, les mots-clef appara\^issent \`a gauche - d'un signe "=". Les mots-clef ne peuvent \^etre quot\'es. - -\item [name-string] - \index[console]{name-string } - Une {\bf name-string} est similaire \`a un {\bf name} except\'e qu'elle peut - \^etre quot\'ee et ainsi contenir des caract\`eres suppl\'ementaires. La - longueur des {\bf name-strings} est limit\'ee \`a 127 caract\`eres. - Typiquement, on les utilise \`a droite d'un signe ''=", (i.e. ce sont les - valeurs \`a associer aux mots-clef). - -\item [string] - \index[console]{string } - Une cha{\^\i}ne quot\'ee contenant potentiellement n'importe quel caract\`ere, - y compris les espaces, ou une cha\^ine non quot\'ee. Une {\bf string} peut - avoir une longueur quelconque. Typiquement, les {\bf strings} sont les - valeurs qui correspondent aux noms de fichiers, r\'epertoires, ou noms de - commandes syst\`eme. Un {\it Backslash} (\textbackslash{}) change le prochain - caract\`ere en lui m\^eme, de sorte que pour inclure une double quote dans une - cha\^ine, vous devez la pr\'eceder d'un {\it Backslash}. Il en va de - m\^eme pour inclure un {\it Backslash}. - -\item [directory] - \index[dir]{directory } - Un {\bf directory} (R\'epertoire) est une cha\^ine, quot\'ee ou non. Un - {\bf directory} est transmis \`a votre shell standard pour expansion lorsqu'il - est scann\'e. Ainsi, des constructions telles que {\bf \$HOME} sont - interpr\'et\'ees correctement. - -\item [password] - \index[dir]{password } - Il s'agit d'un mot de passe Bacula. Il est stock\'e en interne sous un format - brouill\'e par MD5. - -\item [integer] - \index[dir]{integer } - Une valeur enti\`ere relative (positive ou n\'egative) sur 32 bits. - -\item [positive integer] - \index[dir]{positive integer } - Une valeur enti\`ere positive sur 32 bits. - -\item [long integer] - \index[dir]{long integer } - Une valeur enti\`ere sur 64 bits. Typiquement, ce sont les valeurs telles que -le nombre de bytes, qui peuvent d\'epasser 4 milliards et ainsi n\'ecessitent -une valeur sur 64 bits. - -\item [yes|no] - \index[dir]{yes or no } - Soit {\bf yes}, soit {\bf no}. - -\item [ - \label{Size1} - size] -\index[dir]{a name } -Une taille specifi\'ee en bytes. Typiquement, il s'agit d'une entr\'ee au -format scientifique (avec virgule flottante) suivie d'un modificateur -optionnel. L'entr\'ee est stock\'ee en tant qu'entier sur 64 bits. Si un -modificateur est sp\'ecifi\'e, il doit suivre imm\'ediatement la valeur, sans -espace. Les modificateurs suivants sont reconnus: - -\begin{description} - -\item [k] - 1 024 (kilobytes) - -\item [kb] - 1 000 (kilobytes) - -\item [m] - 1 048 576 (megabytes) - -\item [mb] - 1 000 000 (megabytes) - -\item [g] - 1 073 741 824 (gigabytes) - -\item [gb] - 1 000 000 000 (gigabytes) - \end{description} - -\item {\bf - \label{Time} - time} -\index[dir]{a name } -Une heure, ou une dur\'ee sp\'ecifi\'ee en secondes. Une valeur {\bf time} est -stock\'ee en interne en tant qu'entier sur 64 bits, mais il est sp\'ecifi\'e -en deux parties: un nombre et un modificateur. Le nombre peut \^etre un entier -ou un nombre \`a virgule flottante. S'il est sp\'ecifi\'e en virgule -flottante, il sera arrondi \`a l'entier le plus proche. Le modificateur est -obligatoire et suit le nombre avec ou sans espace intercal\'ee. Les -modificateurs suivants sont reconnus: - -\begin{description} - -\item [seconds] - \index[dir]{seconds } - secondes - -\item [minutes] - \index[dir]{minutes } - minutes (60 secondes) - -\item [hours] - \index[dir]{hours } - heures (3600 secondes) - -\item [days] - \index[dir]{days } - jours (3600*24 secondes) - -\item [weeks] - \index[dir]{weeks } - semaines (3600*24*7 secondes) - -\item [months] - \index[dir]{months } - mois (3600*24*30 secondes) - -\item [quarters] - \index[dir]{quarters } - trimestres (3600*24*91 secondes) - -\item [years] - \index[dir]{years } - ann\'ees (3600*24*365 secondes) -\end{description} - -Toute abbr\'eviation des ces modificateurs est aussi autoris\'ee (i.e. {\bf -seconds} peut \^etre sp\'ecifi\'e par {\bf sec} ou {\bf s}. Une -sp\'ecification {\bf m} sera interpr\'et\'ee en tant que mois. - -La sp\'ecification d'une dur\'ee peut comporter autant de couples -nombre/modificateur que vous le souhaitez. Par exemple: - -\footnotesize -\begin{verbatim} -1 week 2 days 3 hours 10 mins -1 month 2 days 30 sec - -\end{verbatim} -\normalsize - -sont des sp\'ecifications valides (\`a partir de la version 1.35.1). - -Note! Dans les versions de Bacula ant\'erieures \`a 1.31, le modificateur -\'etait optionnel. Il est d\'esormais obligatoire. -\end{description} - -\label{ResTypes} - -\section{Types de Ressources} -\index[general]{Types de Ressources } -\index[general]{Ressources!Types de } - -La table suivante \'enum\`ere tous les types de ressource de la version -courante de Bacula. Elle montre quelle ressource doit \^etre d\'efinie pour -chaque service ({\it daemon}). Les fichiers de configuration par d\'efaut -contiennent au moins un exemple de chaque ressource permise, aussi ne soyez -pas angoiss\'e \`a l'id\'ee d'avoir \`a cr\'eer toutes ces directives {\it ex -nihilo}. - -\begin{longtable}{|l|l|l|l|l|} - \hline -\multicolumn{1}{|c| }{\bf Resource } & \multicolumn{1}{c| }{\bf Director } & -\multicolumn{1}{c| }{\bf Client } & \multicolumn{1}{c| }{\bf Storage } & -\multicolumn{1}{c| }{\bf Console } \\ - \hline - {Autochanger } & {No } & {No } & {Yes } & {No } \\ - \hline - \hline -{Catalog } & {Oui } & {Non } & {Non } & {Non } \\ - \hline -{Client } & {Oui } & {Oui } & {Non } & {Non } \\ - \hline -{Console } & {Oui } & {Non } & {Non } & {Oui } \\ - \hline -{Device } & {Non } & {Non } & {Oui } & {Non } \\ - \hline -{Director } & {Oui } & {Oui } & {Oui } & {Oui } \\ - \hline -{FileSet } & {Oui } & {Non } & {Non } & {Non } \\ - \hline -{Job } & {Oui } & {Non } & {Non } & {Non } \\ - \hline -{JobDefs } & {Oui } & {Non } & {Non } & {Non } \\ - \hline -{Message } & {Oui } & {Oui } & {Oui } & {Non } \\ - \hline -{Pool } & {Oui } & {Non } & {Non } & {Non } \\ - \hline -{Schedule } & {Oui } & {Non } & {Non } & {Non } \\ - \hline -{Storage } & {Oui } & {Non } & {Oui } & {Non } -\\ \hline - -\end{longtable} - -\section{Noms, mots de passe et autorisations} -\label{Names} -\index[general]{Autorisations!Noms mots de passe et } -\index[general]{Noms, mots de passe et autorisations } -\index[general]{Mots de passe} - -Pour qu'un {\it daemon} puisse en contacter un autre, il lui faut -s'authentifier avec un mot de passe. Dans la plupart des cas, le mot de passe -est associ\'e \`a un nom particulier, de sorte que nom et mot de passe doivent -correspondre. - -Les fichiers de configuration par d\'efaut sont automatiquement d\'efinis avec -des autorisations correctes et des mots de passe al\'eatoires. Si vous -modifiez ces fichiers, vous devrez \^etre attentif \`a leur coh\'erence. - -Voici un sch\'ema des correspondances que doivent respecter les couples -''nom/mot de passe" des diff\'erents fichiers de configurations. - -\includegraphics{./Conf-Diagram.eps} - -Dans la colonne de gauche, vous trouverez les ressources Director, Storage et -Client, avec leurs noms et mots de passe -- ils sont tous dans le fichier {\bf -bacula-dir.conf}. Dans la colonne de droite figurent les valeurs -correspondantes dans les fichiers de configuration de la Console, du Storage -Daemon (SD) et du File Daemon (FD). - -Veuillez noter que l'adresse {\bf fd-sd}, qui appara{\^\i}t dans la ressource -Storage du Director, pr\'ec\'ed\'ee d'une at\'erisque est transmise au File -Daemon sous forme symbolique. Le File Daemon la r\'esout alors en une adresse -IP. Pour cette raison, vous devez utiliser soit une adresse IP, soit une -adresse pleinement qualifi\'ee. Une adresse telle que {\bf localhost}, -n'\'etant pas pleinement qualifi\'ee, sera r\'esolue par le File Daemon en -l'h\^ote local du File Daemon, ce qui n'est probablement pas le r\'esultat -d\'esir\'e. Le mot de passe utilis\'e par le File Daemon pour autoriser la -communication avec le Storage Daemon est temporaire et unique pour chaque {\it -job}. Il n'est sp\'ecifi\'e dans aucun fichier de configuration. - -\section{Informations d\'etaill\'ees sur chaque {\it daemon}} -\index[general]{Daemon!Informations d\'etaill\'ees sur chaque } -\index[general]{Informations d\'etaill\'ees sur chaque daemon } - - -Les d\'etails de chaque ressource et des directives permises sont d\'ecrits -dans les chapitres suivants. - -Les fichiers de configuration suivants doivent \^etre d\'efinis: - -\begin{itemize} -\item - \ilink{Console}{ConsoleConfChapter} -- Pour d\'efinir les - ressources pour le programme Console (interface utilisateur avec le Director). -Ce fichier d\'efinit quels sont les Directors disponibles avec lesquels vous -pouvez interagir. -\item - \ilink{Director}{DirectorChapter} -- Pour d\'efinir les ressources - n\'ecessaires au Director. Vous y d\'efinissez tous les Clients et Storage -Daemons que vous utilisez. -\item - \ilink{Client}{FiledConfChapter} -- Pour d\'efinir les ressources - de chaque client \`a sauvegarder. Vous aurez un fichier de ressources Client -pour chacune des machine qui ex\'ecute un File Daemon. -\item - \ilink{Storage}{StoredConfChapter} -- Pour d\'efinir les ressources - utilis\'ees par chaque Storage Daemon. En principe, vous aurez un seul -Storage Daemon qui contr\^olera votre (vos) lecteur(s). Quoi qu'il en soit, si -vous avez des lecteurs sur plusieurs machines, vous aurez au moins un Storage -Daemon par machine. -\end{itemize} diff --git a/docs/manual-fr/console.tex b/docs/manual-fr/console.tex deleted file mode 100644 index 08e35a83..00000000 --- a/docs/manual-fr/console.tex +++ /dev/null @@ -1,1568 +0,0 @@ -%% -%% - -\section*{La console Bacula} -\label{_ConsoleChapter} -\index[general]{Console!Bacula} -\index[general]{La console Bacula} -\index[console]{Console!Bacula} -\index[console]{LA console Bacula} -\addcontentsline{toc}{section}{La console Bacula} - -\subsection*{G\'en\'eralit\'es} -\index[general]{G\'en\'eralit\'es} -\addcontentsline{toc}{subsection}{G\'en\'eralit\'es} - -La {\bf console Bacula} (parfois d\'esign\'ee "Agent utilisateur") est un programme -qui permet \`a l'utilisateur autoris\'e ou \`a l'administrateur syst\`eme d'interagir -avec le Director. - -Actuellement, la console Bacula existe en deux versions : une interface shell -(fa\c{c}on TTY), et une interface graphique GNOME. Avec la console Bacula, vous -pouvez d\'eterminer l'\'etat d'un job particulier, examiner le contenu du -catalogue et effectuer certaines manipulations de cartouches. - -Il existe d'autre part un programme nomm\'e bwx-console, b\^atie avec wxWidgets qui -offre une interface graphique aux op\'erations de restauration. - -Etant donn\'e que la Console interagit avec le Director au travers du r\'eseau, -il n'est pas n\'ecessaire que les deux programmes r\'esident sur la m\^eme machine. - -Bacula a besoin d'un minimum de retour de la Console afin de pouvoir utiliser plus -d'une cartouche. En effet, lorsqu'il en r\'eclame une nouvelle, il attend jusqu'\`a -ce qu'un op\'erateur lui indique, via la Console, qu'une nouvelle cartouche est mont\'ee. - -\subsection*{Configuration de la Console} -\index[general]{Configuration de la Console} -\index[general]{Configuration!Console} -\index[console]{Configuration de la Console} -\index[console]{Configuration!Console} -\addcontentsline{toc}{subsection}{Configuration de la Console} - -Lors de son lancement, la Console lit le fichier de configuration standard -nomm\'e {\bf bconsole.conf} (ou {\bf gnome-console.conf} dans le cas de la version -GNOME) Ce fichier d\'efinit une configuration par d\'efaut de la Console et, \`a l'heure -actuelle, la seule ressource d\'efinie est la ressource Director, qui informe -la Console du nom et de l'adresse du Director. Pour plus d'informations sur la -configuration de la Console, voyez le chapitre \ilink{Configurer la Console}{_ChapterStart36} -de ce manuel. - -\subsection*{Utiliser la Console} -\index[general]{Utiliser la Console} -\index[general]{Console!Utiliser la} -\index[console]{Utiliser la Console} -\index[console]{Console!Utiliser la} -\addcontentsline{toc}{subsection}{Utiliser la Console} - -Le programme Console admet les options suivantes : -\footnotesize -\begin{verbatim} -Usage: bconsole [-s] [-c config_file] [-d debug_level] - -c set configuration file to file - -dnn set debug level to nn - -n no conio - -s no signals - -t test - read configuration and exit - -? print this message. -\end{verbatim} -\normalsize - -Apr\`es son d\'emarrage, la Console est en attente de vos commandes, ce qui -est indiqu\'e par une ast\'erisque (*) (ce n'est pas le cas dans la version -GNOME o\`u vous saisissez vos commandes dans la boite texte en bas de l'\'ecran). -Vous pouvez, pour toutes les commandes, vous contenter d'entrer le nom de la -commande, la Console se chargera de vous demander les arguments n\'ecessaires, -mais dans la plupart des cas, vous pouvez entrer les commandes suivies de leurs -arguments. Le format g\'en\'eral est : - -\footnotesize -\begin{verbatim} - [=] [=] ... -\end{verbatim} -\normalsize - -O\`u {\bf command} est l'une des commandes \'enum\'er\'ees ci-dessous, {\bf keyword} -est l'un des mots-clef \'enum\'er\'es ci-dessous (usuellement suivi d'un argument), -et {\bf argument} est la valeur du mot-clef. La commande peut \^etre abr\'eg\'ee -jusqu'\`a sa plus courte abr\'eviation unique. Si deux commandes commencent -par les m\^emes lettres, c'est celle qui appara\^it en t\^ete dans la liste fournie -par la commande {\bf help} qui sera s\'electionn\'ee si votre abr\'eviation est -ambig\"ue. Aucun des mots-clef suivant la commande ne peut \^etre abr\'eg\'e. - -Par exemple : - -\footnotesize -\begin{verbatim} -list files jobid=23 -\end{verbatim} -\normalsize - -\'enum\`ere les fichiers sauvegard\'es par le job de JobId 23. - -Cette autre commande : - -\footnotesize -\begin{verbatim} -show pools -\end{verbatim} -\normalsize - -affiche toutes les ressources Pool. - -\subsection*{Quitter la Console} -\index[general]{Console!Quitter} -\index[general]{Quitter la Console} -\index[console]{Console!Quitter} -\index[console]{Quitter la Console} -\addcontentsline{toc}{subsection}{Quitter la Console} - -Normalement, le programme Console se termine si vous saisissez {\bf quit} -ou {\bf exit}. Cependant, il il attend jusq"\`a ce que le Director ait pris -en compte la commande, ce qui peut prendre du temps si ce dernier est d\'ej\`a -occup\'e \`a une t\^ache longue (par exemple, un \'elagage du catalogue). Si vous voulez -quitter la Console imm\'ediatement, utilisez la commande {\bf .quit}. - -Il n'existe actuellement aucun moyen d'interrompre une commande de la Console -une fois lanc\'ee (Ctrl-C ne marche pas). En revanche, \`a l'invite d'une commande -vous demandant de choisir parmi plusieurs possibilit\'es, vous pouvez annuler -la commande en entrant un point ({\bf .}), vous serez dans la plupart des cas -ramen\'e \`a l'invite principal, ou \`a l'invite pr\'ec\'edente, dans le cas de choix -imbriqu\'es. En quelques endroits, comme celui o\`u l'on vous demande un -nom de volume, le point sera pris pour la r\'eponse (Bacula pensera que vous -voulez nommer votre volume "."). Dans cette situation, vous serez la plupart -du temps en mesure d'annuler \`a l'invite suivante. - -\label{keywords} -\subsection*{Index des mots-clef de la Console} -\index[general]{Mots-clef!Index Console} -\index[general]{Index des mots-clef de la Console} -\index[console]{Mots-clef!Index Console} -\index[console]{Index des mots-clef de la Console} -\addcontentsline{toc}{subsection}{Index des mots-clef de la Console} -Sauf sp\'ecification contraire, chacun des mots-clef suivant admet un argument, -qui est sp\'ecifi\'e apr\`es le mot-clef suivi du signe \'egale. Par exemple : - -\begin{verbatim} -jobid=536 -\end{verbatim} - -Notez que cette liste est probablement incompl\`ete, car le processus de cr\'eation -est toujours en cours. Il se peut aussi qu'elle ne soit pas dans l'ordre -alphab\'etique. - -\begin{description} -\item [restart] - Permis dans la commande {\it python}, provoque le red\'emarrage de - l'interpr\'eteur Python. Ne prend pas d'arguments. -\item [all] - Permis dans les commandes {\it status} et {\it show} pour sp\'ecifier, respectivement, tous les - composants ou toutes les ressources. -\item [before] - Utilis\'e dans la commande {\it restore}. -\item [bootstrap] - Utilis\'e dans la commande {\it restore}. -\item [catalog] - Permis dans la commande {\it use} pour sp\'ecifier le nom de catalogue \`a utiliser. -\item [catalogs] - Utilis\'e dans la commande {\it show}. Ne prend pas d'arguments -\item [client | fd] -\item [clients] - Utilis\'e dans les commandes {\it show}, {\it list}, et {\it llist}. ne prend pas d'arguments. -\item [counters] - Utilis\'e dans la commande {\it show}. Ne prend pas d'arguments. -\item [current] - Utilis\'e dans la commande {\it restore}. Ne prend pas d'arguments. -\item [days] - Utilisé pour définir le nombre de jours que la commande "list nextvol" doit - prendre en compte dans son évaluation des prochains jobs à exécuter. - Le mot-clef "day" peut aussi être utilisé avec la commande "status dir" - afin qu'elle affiche les jobs planifiés pour la période spécifiés. -\item [devices] - Utilis\'e dans la commande {\it show}. Ne prend pas d'arguments. -\item [dir | director] -\item [directors] - Utilis\'e dans la commande {\it show}. Ne prend pas d'arguments. -\item [directory] - Utilis\'e dans la commande {\it restore}. Son argument spécifie - le répertoire à restaurer. -\item [enabled] - Ce mot-clef peut être utilisé avec la commande {\bf update volume} et admet - l'un des arguments suivants : yes, true, no, false, archived, 0, 1, 2, où - 0 correspond à "no" ou "false", 1 à "yes" ou "true" et 2 à "archived". Les volumes - avec le statut "archived" ne seront pas utilisés, pas plus que ne seront élagués leurs - enregistrements dans le catalogue. Les volumes qui n'ont pas le statut "enabled" - ne seront pas utilisés pour des sauvegardes ou des restaurations. -\item [done] - Utilis\'e dans la commande {\it restore}. Ne prend pas d'arguments. -\item [file] - Utilis\'e dans la commande {\it restore}. -\item [files] - Utilis\'e dans les commandes {\it list}, et {\it llist}. ne prend pas d'arguments. -\item [fileset] -\item [filesets] - Utilis\'e dans la commande {\it show}. Ne prend pas d'arguments. -\item [help] - Utilis\'e dans la commande {\it show}. Ne prend pas d'arguments. -\item [jobs] - Utilis\'e dans les commandes {\it show}, {\it list} et {\it llist}. Ne prend pas d'arguments. -\item [jobmedia] - Utilis\'e dans les commandes {\it list}, et {\it llist}. ne prend pas d'arguments. -\item [jobtotals] - Utilis\'e dans les commandes {\it list}, et {\it llist}. ne prend pas d'arguments. -\item [jobid] - Le JobId est le num\'ero de job qui est affich\'e dans le rapport de job. - C'est l'index du catalogue pour le job donn\'e. Bien qu'il soit unique - pour tous les jobs existant dans le catalogue, le m\^eme JobId peut - \^etre r\'eutilis\'e une fois qu'un job a \'et\'e supprim\'e du catalogue. - Vous d\'esignerez certainement les jobs sp\'ecifiques par leur JobId. -\item [job | jobname] - Le mot-clef Job ou Jobname se r\'ef\`ere au nom que vous avez sp\'ecifi\'e - dans la ressource Job, et donc peut d\'esigner plusieurs jobs effectu\'es. - C'est particuli\`erement utile lorsque vous voulez la liste des jobs - execut\'es portant un nom particulier. -\item [level] -\item [listing] - Permis dans la commande {\it estimate}. Ne prend pas d'arguments. -\item [limit] -\item [messages] - Utilis\'e dans la commande {\it show}. Ne prend pas d'arguments. -\item [media] - Utilis\'e dans les commandes {\it list}, et {\it llist}. ne prend pas d'arguments. -\item [nextvol | nextvolume] - Utilis\'e dans les commandes {\it list}, et {\it llist}. ne prend pas d'arguments. -\item [on] - Ne prend pas d'arguments. -\item [off] - Ne prend pas d'arguments. -\item [pool] -\item [pools] - Utilis\'e dans les commandes, {\it show}, {\it list}, et {\it llist}. ne prend pas d'arguments. -\item [select] - Utilis\'e dans la commande {\it restore}. Ne prend pas d'arguments. -\item [storages] - Utilis\'e dans la commande {\it show}. Ne prend pas d'arguments. -\item [schedules] - Utilis\'e dans la commande {\it show}. Ne prend pas d'arguments. -\item [sd | store | storage] -\item [ujobid] - L'ujobid est un identificateur unique de job qui est affich\'e dans - le rapport du job. Actuellement, il consiste en le nom du job - (celui de la directive Name de ce job) suffix\'e de la date et de - l'heure d'ex\'ecution du job. Ce mot-clef est utile si vous voulez - identifier compl\`etement l'instance du job ex\'ecut\'e. -\item [volume] -\item [volumes] - Utilis\'e dans les commandes {\it list}, et {\it llist}. ne prend pas d'arguments. -\item [where] - Utilis\'e dans la commande {\it restore}. Ne prend pas d'arguments. -\item [yes] - Utilis\'e dans la commande {\it restore}. Ne prend pas d'arguments. -\end{description} - -\label{list} -\subsection*{Index des commandes de la Console} -\index[general]{Commandes!Index des commandes de la Console} -\index[general]{Index des commandes de la Console} -\index[console]{Commandes!Index des commandes de la Console} -\index[console]{Index des commandes de la Console} -\addcontentsline{toc}{subsection}{Index des commandes de la Console} - -Les commandes suivantes sont actuellement impl\'ement\'ees : - -\begin{description} -\item [{add [pool=\lt{}pool-name\gt{} storage=\lt{}storage\gt{} - jobid=\lt{}JobId\gt{}]} ] - \index[console]{add} -Cette commande sert \`a ajouter des volumes \`a un pool existant. Les noms des -volumes saisis sont plac\'es dans le catalogue et deviennent ainsi disponibles -pour les sauvegardes. Normalement, on pr\'ef\`er utiliser la commande {\bf label} -qui remplit les m\^emes fonctions en plus d'apposer une \'etiquette logicielle -(label) sur les bandes, par opposition \`a {\bf add} qui se contente de -r\'ef\'erencer le volume dans le catalogue. Ainsi, si vous utilisez {\bf add}, -le volume doit pr\'eexister et \^etre d\'ej\`a \'etiquet\'e. Cette commande peut -cependant \^etre utile si vous voulez ajouter plusieurs cartouches dans un -pool en ne les \'etiquettant que plus tard. Elle peut aussi se r\'ev\'eler utile -si vous importez des cartouches provenant d'un autre site. Consultez le -paragraphe sur la commande {\bf label} pour conna\^itre la liste des -caract\`eres autoris\'es dans un nom de volume. - -\item [autodisplay on/off] - \index[console]{autodisplay on/off} - Cette commande accepte les arguments {\bf on} ou {\bf off} et active ou - d\'esactive l'affichage automatique des messages. La valeur par d\'efaut dans - la Console est {\bf off}, ce qui signifie que les messages en attente - vous sont notifi\'es, mais qu'ils ne sont pas automatiquement affich\'es. - La valeur par d\'efaut pour la console GNOME est {\bf on}, ainsi les - messages sont affich\'es lorqu'ils sont re\c{c}us (habituellement dans les 5 secondes - apr\`es qu'ils aient \'et\'e g\'en\'er\'es). - - Lorsque l'affichage automatique est d\'esactiv\'e, vous devez explicitement - en demander l'affichage avec la commande {\bf messages}. - -\item [automount on/off] - \index[console]{automount on/off} - Cette commande accepte les arguments {\bf on} ou {\bf off} et active ou - d\'esactive le montage automatique de la cartouche apr\`es une commande {\bf label}. - La valeur par d\'efaut est {\bf on}. Si le montage automatique est d\'esactiv\'e, - vous devez explicitement monter la cartouche apr\`es avoir utilis\'e {\bf label} - pour pouvoir \'ecrire dessus. - -\item [{cancel [jobid=\lt{}number\gt{} job=\lt{}job-name\gt{} ujobid=\lt{}unique-jobid\gt{}]}] - \index[console]{cancel jobid} - Cette commande sert \`a supprimer un job et admet les arguments {\bf jobid=nnn} - ou {\bf job=xxx} o\`u nnn est \`a remplacer par le JobId et xxx par le nom de - job. Si vous lancez cette commande sans arguments, la Console vous propose - de choisir parmi les jobs actifs celui \`a supprimer. - - Une fois qu'un job est marqu\'e "A supprimer", il peut se passer quelques instants - (en g\'en\'eral, moins d'une minute) avant qu'il se termine, en fonction des - op\'erations en cours. - -\item [{ create [pool=\lt{}pool-name\gt{}]}] - \index[console]{create pool} - Cette commande sert \`a cr\'eer un enregistrement Pool dans le catalogue - selon les ressources Pool d\'efinis dans le fichier de configuration - du Director. En un sens, cette commande se content de transf\'erer - l'information depuis la ressource Pool dans le fichier de configuration - vers le catalogue. En principe, cete commande est automatiquement - ex\'ecut\'ee au lancement du Director, pourvu que le pool soit r\'ef\'erenc\'e - dans une ressource Job. Si vous utilisez cette commande sur un pool - existant, elle met \`a jour le catalogue en foction des informations de - la ressource Pool. Apr\`es avoir cr\'e\'e un pool, vous uiliserez - probablement la commande {\bf label} pour \'etiqueter un ou plusieurs - volumes et enregistrer leurs noms dans le catalogue. - - Si, au lancement d'un job, Bacula d\'etermine qu'il n'y a pas de pool - enregistr\'e dans le catalogue, mais qu'il existe une ressource Pool pour - le pool appropri\'e, alors il le cr\'e\'e pour vous. Si vous voulez le voir - appara\^itre imm\'ediatement dans le catalogue, utilisez cette commande pour - forcer sa cr\'eation imm\'ediate. - -\item [{ delete [volume=\lt{}vol-name\gt{} pool=\lt{}pool-name\gt{} job - jobid=\lt{}id\gt{}]}] - \index[console]{delete} - Cette commande s'utilise pour supprimer un volume, un pool ou un job - du catalogue, ainsi que tous les enregistrements du catalogue qui leur - sont associ\'es. Cette commande op\`ere exclusivement sur le catalogue - et n'a aucune r\'epercussion sur les donn\'ees \'ecrites sur les cartouches. - Elle peut \^etre dangereuse, et nous vous recommandons fortement de ne - pas l'utiliser si vous ne savez pas exactement ce que vous faites. - - Voici la forme compl\`ete de cette commande : - -\begin{verbatim} -delete pool=\lt{}pool-name\gt{} -\end{verbatim} - - supprime un pool du catalogue. - -\begin{verbatim} -delete volume=\lt{}volume-name\gt{} pool=\lt{}pool-name\gt{} -\end{verbatim} - - supprime du catalogue un volume du pool sp\'ecifi\'e. - -\begin{verbatim} -delete JobId=\lt{}job-id\gt{} JobId=\lt{}job-id2\gt{} ... -\end{verbatim} - - supprime du catalogue le job sp\'ecifi\'e. - -\begin{verbatim} -delete Job JobId=n,m,o-r,t ... -\end{verbatim} - - supprime les job de JobIds m,n,o,p,q,r et t (o\`u m,n,... sont, bien sur, des - nombres). Ainsi, la commande "delete jobid" accepte les listes et les plages - de jobids. - -\item [disable job\lt{}job-name\gt{}] - \index[console]{enable} - Cette commande vous permet de d\'esactiver un job normalement planifi\'e - pour ex\'ecution. Le job peut avoir \'et\'e pr\'ealablement activ\'e par la - directive {\bf Enabled} dans la ressource Job, ou avec la commande - {\bf enable} dans la Console. Au prochain d\'emarrage du Director, ou - si le fichier de configuration est recharg\'e, l'\'etat Enable/Disable sera - r\'etabli \`a celui sp\'ecifi\'e dans la ressource Job (la valeur par d\'efaut - est enabled). - -\item [enable job\lt{}job-name\gt{}] - \index[console]{enable} - Cette commande vous permet de d'activer un job planifi\'e - pour ex\'ecution automatique. Le job peut avoir \'et\'e pr\'ealablement d\'esactiv\'e par la - directive {\bf Disabled} dans la ressource Job, ou avec la commande - {\bf disable} dans la Console. Au prochain d\'emarrage du Director, ou - si le fichier de configuration est recharg\'e, l'\'etat Enable/Disable sera - r\'etabli \`a celui sp\'ecifi\'e dans la ressource Job (la valeur par d\'efaut - est enabled). - -\label{estimate} -\item [estimate] - \index[console]{estimate} - Avec cette commande, vous pouvez vous faire une id\'ee du nombre de fichier - seront sauvegard\'es. Vous pouvez aussi l'utiliser pour \'eprouver les - param\`etres Include de vos FileSets sans passer par une sauvegarde - r\'eelle. Par d\'efaut, l'estimation est faite pour une sauvegarde Full. - Cependant, vous pouvez passer outre ce comportement en sp\'ecifiant - {\bf level=Incremental} ou {\bf level=Differential} sur la ligne de - commande. Un nom de job doit \^etre sp\'ecifi\'e, faute de quoi il vous sera - demand\'e. Optionnellement, vous pouvez sp\'ecifier un client et un - FileSet sur la ligne de commande. Bacula contacte alors le client - et calcule le nombre de fichier et d'octets qui seraient - sauvegard\'es. Notez qu'il s'agit d'une estimation calcul\'ee d'apr\`es - le nombre de blocs dans les fichiers plut\^ot qu'en lisant le nombre - effectif d'octets. Aussi, la taille estim\'ee est g\'en\'eralement plus - importante que celle de la sauvegarde r\'eelle. - - Optionnellement, vous pouvez ajouter le mot-clef {\bf listing}, auquel cas - tous les fichiers \`a sauvegarder seront affich\'es. Notez qu'un tel affichage - peut prendre un certain temps s'il s'agit d'une grosse sauvegarde. - Voici la forme compl\`ete de cette commande : - -\begin{verbatim} -estimate job=\lt{}job-name\gt{} listing client=\lt{}client-name\gt{} - fileset=\lt{}fileset-name\gt{} level=\lt{}level-name\gt{} -\end{verbatim} - - La sp\'ecification du {\bf job} est suffisante, mais vous pouvez aussi - passer outre le client, le FileSet et/ou le niveau en les - sp\'ecifiant sur la ligne de commande. - - Par exemple, vous pourriez faire ceci : - -\footnotesize -\begin{verbatim} - @output /tmp/listing - estimate job=NightlySave listing level=Incremental - @output -\end{verbatim} -\normalsize - -ce qui produirait une liste compl\`ete de tous les fichiers \`a sauvegarder pour -le job {\bf NightlySave} au cours d'une sauvegarde incr\'ementale, et qui -consignerait cette liste dans le fichier {\bf /tmp/listing}. Notez que l'évaluation -produite par cette commande se base sur les tailles de fichiers contenues dans -l'objet "répertoire", aussi l'estimation peut être très éloignée de la réalité si vous -avez des fichiers creux (NDT : sparse files) sur votre système. Ce type de fichiers se -rencontre souvent sur les systèmes 64 bits avec certains systèmes de fichiers. -Le volume obtenu par l'évaluation est celui que sauvegardera Bacula si l'option -sparse est désactivée. Il n'y a actuellement aucun moyen d'évaluer le volume de -ce qui serait sauvegardé avec l'option sparse activée. - -\item [help] - \index[console]{help} - Cette commande affiche la liste des commandes disponibles. - -\item [label] - \index[console]{label} - \index[console]{relabel} - \index[general]{label} - \index[general]{relabel} - Cette commande est utilis\'ee pour \'etiqueter les volumes. La forme compl\`ete est : - -\begin{verbatim} - label storage=\lt{}storage-name\gt{} volume=\lt{}volume-name\gt{} - slot=\lt{}slot\gt{} -\end{verbatim} - - Si vous omettez l'un quelconque des arguments, il vous sera r\'eclam\'e. - Le type de m\'edia est automatiquement r\'ecup\'er\'e de la ressource Storage. - Une fois que les informations requises sont r\'eunies, la Console - contacte le Storage Daemon sp\'ecifi\'e et lui ordonne d'\'etiqueter la - cartouche sp\'ecifi\'ee. Si l'\'etiquetage s'effectue correctement, la - Console cr\'e\'e un nouvel enregistrement dans le catalogue pour le - volume dans le pool appropri\'e. - - Les noms de volumes ne doivent contenir que des lettres, chiffres et - les caract\`eres sp\'eciaux tiret ({\bf -}), sous-lign\'e ({\bf \_}), double-point - ({\bf :}), et point ({\bf .}). Tous les autres caract\`eres, y compris l'espace, - sont ill\'egaux. Cette restriction vise \`a assurer une bonne lisibilit\'e - des noms de volumes pour r\'eduire le risque d'erreurs humaines. - - Notez que lors de l'\'etiquetage d'une cartouche vierge, Bacula obtient des - erreurs {\bf read I/O error} lorqu'il tente de v\'erifier si la cartouche - a d\'ej\`a un label. Si vous voulez \'eviter ce genre de message, placez un - indicateur de fin de fichier sur votre cartouche avant son \'etiquetage : - -\footnotesize -\begin{verbatim} - mt rewind - mt weof - -\end{verbatim} -\normalsize - -La commande label peut \'echouer pour plusieurs raisons : - - -\begin{enumerate} -\item Le nom de volume que vous avez sp\'ecifi\'e figure d\'ej\`a dans le catalogue. -\item Le Storage Daemon a d\'ej\`a une cartouche mont\'ee dans le lecteur. Dans ce cas, - vous devez la d\'emonter ({\bf unmount}) et ins\'erer une cartouche vierge - avant de lancer la commande {\bf label}. -\item La cartouche dans le lecteur porte d\'ej\`a une \'etiquette Bacula. - (Bacula ne r\'e-\'etiquette jamais une cartouche \`a moins qu'elle soit recycl\'ee - et que vous utilisiez la commande {\bf relabel} ). -\item Il n'y a pas de cartouche dans le lecteur. -\end{enumerate} - -Il existe deux moyens pour r\'e-\'etiqueter un volume qui porte d\'ej\`a une -\'etiquette Bacula. La m\'ethode brutale consiste \`a \'ecrire une marque de fin de -fichier sur la cartouche vec la commande du syst\`eme d'exploitation {\bf mt}, -quelque chose dans ce style : - -\footnotesize -\begin{verbatim} - mt -f /dev/st0 rewind - mt -f /dev/st0 weof -\end{verbatim} -\normalsize - -puis d'utiliser la commande {\bf label} pour ajouter une nouvelle \'etiquette. -Cette m\'ethode peut cependant laisser des traces de l'ancien volume dans le -catalogue. - -Il est pr\'ef\'erable d'utiliser la commande {\bf relabel} d\'ecrite ci-dessous sur -un volume purg\'e (automatiquement ou avec la commande {\bf purge}). - -Si votre librairie comporte un lecteur de codes barres, vous pouvez -\'etiqueter tous les volumes qu'elle contient en -utilisant la commande {\bf label barcodes}. En effet, apr\`es le lancement de -cette commande, Bacula monte chaque cartouche l'une apr\`es l'autre et -l'\'etiquette du nom de son code barres. simultan\'ement, l'enregistrement -appropri\'e est cr\'e\'e dans le catalogue. Toute cartouche dont le code barres -commence par les m\^emes caract\`eres que ceux sp\'ecifi\'es par la directive -"CleaningPrefix" de la ressource Pool du director est consid\'er\'ee comme -une cartouche de nettoyage et ne re\c{c}oit donc pas d'\'etiquette, bien -qu'une entr\'ee dans le catalogue lui soit d\'edi\'ee. Par exemple avec : - -\footnotesize -\begin{verbatim} - Pool { - Name ... - Cleaning Prefix = "CLN" - } - -\end{verbatim} -\normalsize - -tout slot contenant une cartouche de code barres CLNxxxxx sera trait\'ee en tant -que cartouche de nettoyage et ne sera jamais mont\'ee. Notez que la forme -compl\`ete de la commande est : - -\footnotesize -\begin{verbatim} -update storage=xxx pool=yyy slots=1-5,10 barcodes -\end{verbatim} -\normalsize - -\item [list] - \index[console]{list} - La commande {\bf list} extrait du catalogue les informations demand\'ees. Les - diff\'erentes champs de chaque enregistrement sont \'enum\'er\'es sur une simple - ligne. Voici les diff\'erentes formes de la commande : - -\footnotesize -\begin{verbatim} - list jobs - - list jobid= (affiche le jobid id) - - list ujobid= (affiche le job dont le nom unique est ) - - list job= (Affiche tous les jobs dont le nom est "job-name") - - list jobname= (voir ci-dessus) - - Dans cette commande, vous pouvez ajouter "limit=nn" pour limiter la sortie \`a nn jobs. - - list jobmedia - - list jobmedia jobid= - - list jobmedia job= - - list files jobid= - - list files job= - - list pools - - list clients - - list jobtotals - - list volumes - - list volumes jobid= - - list volumes pool= - - list volumes job= - - list volume= - - list nextvolume job= - - list nextvol job= - - list nextvol job= days=nnn - - - -\end{verbatim} -\normalsize - - Ce que font la plupart des commandes ci-dessus devrait \^etre plus ou moins \'evident. - En g\'en\'eral, si vous ne sp\'ecifiez pas tous les arguments requis, la Console - vous sollicitera pour les arguments manquants. - - La commande {\bf list nextvol} affiche le nom du volume qui dera utilis\'e par - le job sp\'ecifi\'e. Soyez conscient que le prochain volume utilis\'e - pour un job d\'epend de nombreux facteurs dont le temps, et les autres - jobs qui seront ex\'ecut\'es avant celui sp\'ecifi\'e, qui peuvent remplir une - cartouche qui \'etait vide au moment de l'ex\'ecution de {\bf list nextvol}. - Aussi, consid\'erez la r\'eponse fournie par cette commande comme une bonne - estimation plut\^ot que comme une r\'eponse d\'efinitive. De plus, cette commande - a certains effets de bord : \'etant donn\'e qu'elle ex\'ecute le m\^eme algorithme - qu'un job, elle est susceptible de purger ou recycler un volume. Par d\'efaut, - le job sp\'ecifi\'e doit \^etre ex\'ecut\'e dans les deux jours ou aucun volume - ne sera trouv\'e. Vous pouvez cependant sp\'ecifier jusqu'\`a 50 jours en avant - avec la directive {\bf days=nnn}. Si, par exemple, un vendredi, vous voulez - savoir quel volume sera requis lundi pour le job MyJob, utilisez - {\bf list nextvol job=MyJob days=3}. - - Si vous souhaitez ajouter vos propres commandes pour interroger le - catalogue, vous pouvez les placer dans le fichier {\bf query.sql}. - Cela demande quelques connaissances du langage SQL. Voyez le - paragraphe sur la commande {\bf query} ci-dessous pour plus - d'informations. Voyez aussi le paragraphe sur la commande - {\bf llist} qui permet l'affichage complet des informations du - catalogue. - - Voici un exemple d'affichage produit par la commande {\bf list pools} : - -\footnotesize -\begin{verbatim} -+------+---------+---------+---------+----------+-------------+ -| PoId | Name | NumVols | MaxVols | PoolType | LabelFormat | -+------+---------+---------+---------+----------+-------------+ -| 1 | Default | 0 | 0 | Backup | * | -| 2 | Recycle | 0 | 8 | Backup | File | -+------+---------+---------+---------+----------+-------------+ -\end{verbatim} -\normalsize - - Comme mentionn\'e pr\'ec\'edemment, la commande {\bf list} affiche des - informations du catalogue. Certais \'el\'ements sont ajout\'es dans le catalogue - d\`es le d\'emarrage de Bacula, mais en g\'en\'eral, la plupart ne le sont que - lorsqu'ils sont utilis\'es pour la premi\`ere fois. C'est le cas des clients, - des jobs, etc. - - Bacula cr\'e\'e une entr\'ee relative \`a un nouveau client dans le catalogue - la premi\`ere fois que vous ex\'ecut\'ez un job pour ce client. L'entr\'ee est - cr\'e\'ee que le job aboutisse ou qu'il \'echoue, mais il doit au moins d\'emarrer. - Lorsque le client est contact\'e, des informations suppl\'ementaires sont - r\'ecup\'er\'ees du client (le r\'esultat d'un "uname -a") et ajout\'ees au - catalogue. Un {\bf status} n'entra\^ine pas l'enregistrement dans le catalogue. - - Si vous voulez visualiser les ressources Client disponibles dans votre - catalogue, utilisez la commande {\bf show clients}. - -\item [llist] - \index[console]{llist} - La commande {\bf llist} (pour "long list") admet les m\^emes arguments que la - commande list d\'ecrite ci-dessus. La diff\'erence est que {\bf llist} affiche - le contenu complet de chaque enregistrement du catalogue s\'electionn\'e. - L'affichage des diff\'erents champs est produit verticalement, un champ par - ligne. Cette commande peut \^etre tr\`es prolixe. - - Si, au lieu du {\bf list pools} de l'exemple pr\'ec\'edent, vous saisissez - {\bf llist pools}, vous obtiendrez un affichage de ce genre : - -\footnotesize -\begin{verbatim} - PoolId: 1 - Name: Default - NumVols: 0 - MaxVols: 0 - UseOnce: 0 - UseCatalog: 1 - AcceptAnyVolume: 1 - VolRetention: 1,296,000 - VolUseDuration: 86,400 - MaxVolJobs: 0 - MaxVolBytes: 0 - AutoPrune: 0 - Recycle: 1 - PoolType: Backup - LabelFormat: * - - PoolId: 2 - Name: Recycle - NumVols: 0 - MaxVols: 8 - UseOnce: 0 - UseCatalog: 1 - AcceptAnyVolume: 1 - VolRetention: 3,600 - VolUseDuration: 3,600 - MaxVolJobs: 1 - MaxVolBytes: 0 - AutoPrune: 0 - Recycle: 1 - PoolType: Backup - LabelFormat: File - -\end{verbatim} -\normalsize - -\item [messages] - \index[console]{messages} - Cette commande affiche imm\'ediatement tout message de la console en attente. - - -\item [mount] - \index[console]{mount} - - La commande {\bf mount} est utilis\'ee pour obtenir de Bacula qu'il lise - un volume charg\'e dans un lecteur. C'est un moyen d'indiquer \`a Bacula - que vous avez charg\'e une cartouche qu'il doit examiner. Cette commande - n'est utilis\'ee que lorsque Bacula a demand\'e votre intervention pour - charger un lecteur vide, ou lorsque vous avez explicitement d\'emont\'e - un volume avec la commande {\bf unmount} dans la Console, ce qui - provoque la fermeture du lecteur. Si vous avez une librairie, vous ne - ferez pas op\'erer Bacula dessus avec la commande mount. Voici les - diff\'erentes formes de cette commande : - -mount storage=\lt{}storage-name\gt{} - -mount [ jobid=\lt{}id\gt{} | job=\lt{}job-name\gt{} ] - - Si vous avez sp\'ecifi\'e {\bf Automatic Mount = yes} dans la ressource - Device du Storage Daemon, Alors Bacula pourra acc\'eder automatiquement - au volume, \`a moins que vous ne l'ayez explicitement d\'emont\'e ({\bf unmount}) - dans la Console. - -\item[python] - \index[console]{python} - La commande {\bf python} n'admet qu'un argument : {\bf restart}. - - La commande {\bf python} {\bf restart} r\'einitialise l'interpr\'eteur Python - du Director. Ceci peut \^etre tr\`es utile pour effectuer des tests, car une - fois que le Director est lanc\'e, et l'interpr\'eteur Python initialis\'e, - il n'y a pas d'autre moyen de lui faire int\'egrer des modifications - du script de d\'emarrage {\bf DirStartUp.py}. Pour plus de d\'etails sur - l'\'ecriture de scripts Python, consultez le chapitre \ilink{Ecrire des - scripts Python}{_ChapterStart60}. - -\label{ManualPruning} -\item [prune] - \index[console]{prune} - La commande {\bf prune} permet d'\'elaguer en toute s\'ecurit\'e les - enregistrements expir\'es du catalogue pour les jobs et les volumes. - Cette commande n'affecte que le catalogue, et non les donn\'ees - \'ecrites sur les volumes. Dans tous les cas, la commande {\bf prune} - respecte les p\'eriodes de r\'etention des enregistrements sp\'ecifi\'es. - Vous pouvez \'elaguer les jobs expir\'es, ainsi que les jobs et fichiers - d'un volume sp\'ecifi\'e. - -prune files|jobs|volume client=\lt{}client-name\gt{} -volume=\lt{}volume-name\gt{} - - Pour qu'un volume soit \'elagu\'e, son {\bf VolStatus} doit \^etre Full, - Used, ou Append, faute de quoi l'\'elagage sera sans effet. - -\item [purge] - \index[console]{purge} - La commande {\bf purge} efface les enregistrements sp\'ecifi\'es du catalogue - sans \'egards pour les p\'eriodes de r\'etention. {\bf Purge} n'affecte que le - catalogue, et non les donn\'ees \'ecrites sur les volumes. Cette commande - peut se r\'ev\'eler tr\`es dangereuse car vous pouvez parfaitement supprimer - les enregistrements relatifs \`a des sauvegardes valides et r\'ecentes. Aussi, - nous vous recommandons de ne pas l'utiliser \`a moins de savoir exactement - ce que vous faites. Voici les diff\'erentes formes de la commande {\bf purge} : - -purge files jobid=\lt{}jobid\gt{}|job=\lt{}job-name\gt{}|client=\lt{}client-name\gt{} - -purge jobs client=\lt{}client-name\gt{} (of all jobs) - -purge volume|volume=\lt{}vol-name\gt{} (of all jobs) - - - Pour qu'un volume puisse \^etre purg\'e, son {\bf VolStatus} doit \^etre Full, - Used, ou Append, faute de quoi la purge sera sans effet. - -\item [relabel] - \index[console]{relabel} - \index[general]{relabel} - Cette commande sert \`a r\'e-\'etiqueter physiquement un volume. En voici - la forme compl\`ete : - -relabel storage=\lt{}storage-name\gt{} oldvolume=\lt{}old-volume-name\gt{} - volume=\lt{}newvolume-name\gt{} - - Si vous omettez l'un quelconque des arguments, la console vous sollicitera - pour obtenir les informations manquantes. Pour qu'un volume puisse \^etre - r\'e-\'etiquet\'e, il doit figurer dans le catalogue, et avoir le statut - {\bf Purged} ou {\bf Recycle}. Cette situation peut se pr\'esenter - automatiquement par l'application des p\'eriodes de r\'etention, ou vous - pouvez l'obtenir par une {\bf purge} explicite du volume. - - Une fois que le volume a \'et\'e physiquement r\'e-\'etiquet\'e, les donn\'ees - qu'il contenait sont d\'efinitivement et irr\'em\'ediablement perdues. - -\item [release] - \index[console]{release} - Cette commande ordonne au Storage Daemon de rembobiner la cartouche - dans le lecteur, et de relire son \'etiquette \`a la prochaine utilisation - de la cartouche. - -release storage=\lt{}storage-name\gt{} - - Apr\`es cette commande, le lecteur est gard\'e \`a l'\'etat ouvert par Bacula - (sauf si l'option Always Open est d\'esactiv\'ee dans la configuration - du Storage Daemon), et il ne peut donc \^etre utilis\'e par un autre - programme. Toutefois, il est possible, avec certains lecteurs, de - changer la cartouche \`a ce stade. Lors du prochain job, Bacula saura - relire l'\'etiquette de la cartouche pour savoir laquelle est mont\'ee. - Si vous voulez \^etre en mesure d'utiliser le lecteur avec un autre - programme, par exemple {\bf mt}, vous devez uiliser la commande - {\bf unmount} pour que Bacula le lib\`ere compl\`etement. - -\item [reload] - \index[console]{reload} - Lorsqu'il re\c{c}oit la commande {\bf reload}, le Director relit ses fichiers - de configuration et applique les \'eventuelles modifications. Celles-ci - sont prises en compte imm\'ediatement, et donc effectives pour tous les - jobs \`a venir. Notez cependant qu'en ce qui concerne les modifications - apport\'ees aux Schedules, la prise en compte des nouvelles valeur peut - \^etre report\'ee au del\`a de l'ex\'ecution des jobs d\'ej\`a planifi\'es pour - les deux prochaines heures. Ceci est d\^u au planificateur qui pr\'evoit - "pr\'e-planifie" jusqu'\`a deux heures \`a l'avance les jobs \`a ex\'ecuter. - Ainsi, des jobs qui ont d\'ej\`a \'et\'e "pr\'e-planifi\'es" seront ex\'ecut\'es - suivant les valeurs sp\'ecifi\'ees par la ressource Schedule avant sa - modification. Les nouveaux jobs utiliseront les nouvelles valeurs. - A chaque fois que vous utilisez la commande {\bf reload} alors que - des jobs sont en cours d'ex\'ecution, les valeurs de la configuration - pr\'ec\'edente demeurent en vigueur jusqu'\`a ce que les ces jobs se terminent. - Le Director peut ainsi conserver jusqu'\`a 10 jeux de configurations - ant\'erieures avant de refuser une nouvelle commande {\bf reload}. - Une fois que l'un, au moins, des jeux de valeurs ant\'erieur a \'et\'e accept\'e, - il peut \`a nouveau accepter de nouvelles commandes {\bf reload}. - - Bien qu'il soit possible de recharger la configuration du Director - \`a la vol\'ee, alors m\^eme que des jobs sont en cours d'ex\'ecution, il faut - garder \`a l'esprit que c'est une op\'eration complexe, qui n'est pas d\'enu\'ee - d'effets de bords. C'est pourquoi il est recommand\'e, si vous \^etes amen\'e \`a - utiliser la commande {\bf reload}, de red\'emarrer le Director d\`es que vous - en aurez l'opportunit\'e. - -\label{restore_command} -\item [restore] - \index[console]{restore} - La commande {\bf restore} vous permet de s\'electionner un ou plusieurs jobs - (JobIds) \`a restaurer selon plusieurs m\'ethodes. Une fois que les JobIds ont - \'et\'e s\'electionn\'es, les enregistrements de fichiers sont plac\'es dans une - arborescence interne \`a Bacula, et la Console entre dans un mode de - s\'election interactif qui vous permet de naviguer dans cette arborescence - en s\'electionnant individuellement les fichiers ou r\'epertoires \`a restaurer. - Ce mode est assez similaire au mode de s\'election interactif du programme - Unix {\bf restore} standard. - -restore storage=\lt{}storage-name\gt{} client=\lt{}client-name\gt{} - where=\lt{}path\gt{} pool=\lt{}pool-name\gt{} fileset=\lt{}fileset-name\gt{} - select current all done - - O\`u l'option {\bf current}, si elle est sp\'ecifi\'ee, indique \`a la commande - {\bf restore} de s\'electionner automatiquement la sauvegarde la plus - r\'ecente (sinon, vous serez sollicit\'e \`a ce sujet). L'option {\bf all}, - si elle est sp\'ecifi\'ee, indique \`a la commande {\bf restore} de restaurer - tous les fichiers (sinon, vous serez sollicit\'e \`a ce sujet). Pour plus de - d\'etails concernant la commande {\bf restore}, consultez le chapitre - \ilink{Restaurations avec Bacula}{_ChapterStart13}. - -\item [run] - \index[console]{run} - Cette commande vous permet d'ex\'ecuter imm\'ediatement vos jobs. Voici la forme - compl\`ete de cette commande : - -run job=\lt{}job-name\gt{} client=\lt{}client-name\gt{} - fileset=\lt{}FileSet-name\gt{} level=\lt{}level-keyword\gt{} - storage=\lt{}storage-name\gt{} where=\lt{}directory-prefix\gt{} - when=\lt{}universal-time-specification\gt{} yes - - Toute information omise quoique requise fait l'objet d'une liste de s\'election, - et avant le lancement du job, un bilan des param\`etres vous est pr\'esent\'e avec - options d'accord, refus et modification, \`a moins que vous ayez sp\'ecifi\'e - {\bf yes}, auquel cas le job est imm\'ediatement envoy\'e vers le planificateur. - - Sur mon syst\`eme, j'obtiens ce qui suit lorsque je lance la commande run : - -\footnotesize -\begin{verbatim} -A job name must be specified. -The defined Job resources are: - 1: Matou - 2: Polymatou - 3: Rufus - 4: Minimatou - 5: Minou - 6: PmatouVerify - 7: MatouVerify - 8: RufusVerify - 9: Watchdog -Select Job resource (1-9): - -\end{verbatim} -\normalsize - -Si je choisis le num\'ero 5, j'obtiens : - -\footnotesize -\begin{verbatim} -Run Backup job -JobName: Minou -FileSet: Minou Full Set -Level: Incremental -Client: Minou -Storage: DLTDrive -Pool: Default -When: 2003-04-23 17:08:18 -OK to run? (yes/mod/no): - -\end{verbatim} -\normalsize - -Si maintenant j'entre {\bf yes}, le job est ex\'ecut\'e. Si je choisis {\bf mod}, -voici les otpions qui me sont propos\'ees : - -\footnotesize -\begin{verbatim} -Parameters to modify: - 1: Level - 2: Storage - 3: Job - 4: FileSet - 5: Client - 6: When - 7: Pool -Select parameter to modify (1-7): - -\end{verbatim} -\normalsize - -Vous pouvez, si vous le souhaitez, d\'emarrer un job plus tard, en utilisant le -param\`etre {\bf When}. Pour cela, faites le choix {\bf mod}, puis s\'electionnez -{\bf When} (no. 6) et enfin, saisissez l'heure et le jour de lancement -d\'esir\'es au format AAAA-MM-JJ HH:MM:SS. - -\item [setdebug] - \index[console]{setdebug} - \index[dir]{setdebug} - \index[dir]{debuggage} - \index[dir]{debuggage Win32} - \index[dir]{Windows!debuggage} - - Cette commande est utilis\'ee pour param\'etrer le niveau de d\'ebuggage de chaque - {\it daemon}. Voici la forme compl\`ete de cette commande. - -setdebug level=nn [trace=0/1 client=\lt{}client-name\gt{} | dir | director | - storage=\lt{}storage-name\gt{} | all] - - Si le param\`etre de tra\c{c}age est actif (trace=1), alors le {\it daemon} est - plac\'e en mode tra\c{c}age, ce qui signifie que toutes les informations de - d\'ebuggage sont envoy\'ees vers le fichier {\bf bacula.trace} dans le - r\'epertoire courant du {\it daemon}. En principe, ce n'est n\'ecessaire - que pour le d\'ebuggage des clients Win32 o\`u les informations ne peuvent - \^etre envoy\'ees vers un terminal ou redirig\'ees vers un fichier. en mode - tra\c{c}age, chaque message de d\'ebuggage est ajout\'e au fichier, que vous devez - supprimer explicitement lorsque vous avez fini. - -\item [show] - \index[console]{show} - \index[dir]{show} - LA commande {\bf show} \'enum\`ere les directives des ressources du Director - telles qu'ells sont d\'efinies dans son fichier de configuration. - Cette commande est surtout utilis\'ee par les d\'eveloppeurs \`a des fins - de d\'ebuggage. LEs mots-clef suivants sont accept\'es : - catalogs, clients, counters, devices, directors, - filesets, jobs, messages, pools, schedules, storages, all, help. - Ne confondez pas cette commande ave la commande {\bf list}, qui affiche - quand \`a elle le contenu du catalogue. - -\item [sqlquery] - \index[console]{sqlquery} - La commande {\bf sqlquery} place le programme Console en mode de - requ\^etes SQL, dans lequel chaque ligne que vousq tapez est concat\'en\'ee - \`a la pr\'ec\'edents jusqu'\`a ce qu'un point-virgule (;) soit rencontr\'e. Le - point-virgule termine la commande qui est alors directement envoy\'e au moteur - de base de donn\'ee SQL. Lorsque le r\'esultat issu de la base de donn\'ee SQL est - affich\'e, la Console est pr\`ete \`a recevoir une nouvelle commande SQL. - Pour sortir du mode {\bf sqlquery} et reevenir \`a l'invite de la Console, - entrez un point (.). - - Cette commande vous permet d'interroger directement le catalogue. Notez - que vous devriez savoir exactement ce que vous faites en utilisant cette - commande, car vous pouvez endommager s\'erieusement votre catalogue. - Consultez le paragraphe relatif \`a la commande {\bf query} qui offre un - moyen \`a la fois plus simple et plus sur de saisir des requ\^etes SQL. - - En fonction du moteur de base de donn\'ees que vous utilisez (MySQL, - PostgreSQL ou SQLite), vous disposerez de commandes quelque peu diff\'erentes. - Pour plus de d\'etails, r\'ef\'erez-vous aux documentations de MySQL, PostgreSQL - ou SQLite. - -\item [status] - \index[dir]{status} - Cette commande produit un \'etat des prochains jobs planifi\'es au cours des - 24 prochanes heures, ainsi que l'\'etat des jobs en cours d'ex\'ecution. Voici - la forme compl\`ete de cette commande : - -status [all | dir=\lt{}dir-name\gt{} | director | - client=\lt{}client-name\gt{} | storage=\lt{}storage-name\gt{} | - days=nnn] - - Si vous entrez {\bf status dir}, la Console \'enum\`ere tous les jobs en cours - d'ex\'ecution, un r\'esum\'e des jobs planifi\'e pour ex\'ecution au cours des prochaines - 24 heures incluant le volume qui sera probablement utilis\'e, et donne la liste - des dix derniers jobs ex\'ecut\'es avec leurs \'etats. Gardez \`a l'esprit les deux - \'el\'ements suivants : - \begin{itemize} - \item L'obtention du volume n\'ecessite d'appliquer le m\^eme algorithme que - celui utilis\'e lors de l'ex\'ecution d'un job, ce qui peut r\'esulter en un \'elagage - de cartouche. - \item Le volume affich\'e est, au mieux, une bonne supposition. En effet le - volume effectivement utilis\'e peut \^etre diff\'erent en raison du temps \'ecoul\'e - entre le status et l'ex\'ecution du job, un autre job ayant pu, entre temps, - remplir compl\`etement la cartouche. - \end{itemize} - - Dans la liste des jobs en cours d'ex\'ecutions, vous pouvez trouver ce type - d'informations : - -\footnotesize -\begin{verbatim} -2507 Catalog MatouVerify.2004-03-13_05.05.02 is waiting execution -5349 Full CatalogBackup.2004-03-13_01.10.00 is waiting for higher - priority jobs to finish -5348 Differe Minou.2004-03-13_01.05.09 is waiting on max Storage jobs -5343 Full Rufus.2004-03-13_01.05.04 is running -\end{verbatim} -\normalsize - - La liste ci-dessus indique que le job de JobId 5343 (Rufus) est en cours. - Le job de JobId 5348 (Minou) est en attente de la fin du job 5343 - qui utilise la m\^eme ressource Storage, ce qui provoque le "waiting - on max Storage jobs". Le job de JobId 5349 a une priorit\'e inf\'erieure - \`a celle de tous les autres jobs, aussi, il est en attente de la fin de - jobs de priorit\'es sup\'erieures. Finalement, le job de jobId 2508 (MatouVerify) - est en attente ("waiting execution") car un seul job peut \^etre ex\'ecut\'e - en m\^eme temps. - - Si vous faites un {\bf status dir}, Bacula affiche par d\'efaut les premi\`eres - occurrences de tous les jobs pr\'evus pour ex\'ecution aujourd'hui et demain. - Si vous voulez voir les jobs pr\'evus pour les trois prochains jours, - (Si, par exemple vendredi, vous voulez voir les premi\`eres occurrences - des cartouches \`a utiliser vendredi, samedi, dimanche et lundi), vous - pouvez ajouter l'option {\bf days=3}. Notez, {\bf days=0} montre les - premi\`eres occurrences des jobs planifi\'es pour \^etre ex\'ecut\'es aujourd'hui - seulement. Si vous avez plusieurs ex\'ecutions planifi\'ees, pour chaque - job, seule la premi\`ere occurrence sera affich\'e pour la p\'eriode sp\'ecifi\'ee. - - Si votre job para\^it bloqu\'e, vous pouvez avoir une id\'ee g\'en\'erale du probl\`eme - en utilisant {\bf status dir}, et obtenir une information plus sp\'ecifique - avec {\bf status storage=xxx}. Par exemple, si j'utilise cette derni\`ere - commande sur un syst\`eme inoccup\'e, j'obtiens : - -\footnotesize -\begin{verbatim} -status storage=File -Connecting to Storage daemon File at 192.168.68.112:8103 - -rufus-sd Version: 1.39.6 (24 March 2006) i686-pc-linux-gnu redhat (Stentz) -Daemon started 26-Mar-06 11:06, 0 Jobs run since started. - -Running Jobs: -No Jobs running. -==== - -Jobs waiting to reserve a drive: -==== - -Terminated Jobs: - JobId Level Files Bytes Status Finished Name -====================================================================== - 59 Full 234 4,417,599 OK 15-Jan-06 11:54 kernsave -==== - -Device status: -utochanger "DDS-4-changer" with devices: - "DDS-4" (/dev/nst0) -Device "DDS-4" (/dev/nst0) is mounted with Volume="TestVolume002" -Pool="*unknown*" - Slot 2 is loaded in drive 0. - Total Bytes Read=0 Blocks Read=0 Bytes/block=0 - Positioned at File=0 Block=0 -Device "Dummy" is not open or does not exist. -No DEVICE structure. - -Device "DVD-Writer" (/dev/hdc) is not open. -Device "File" (/tmp) is not open. -==== - -In Use Volume status: -==== -\end{verbatim} -\normalsize - -Ce qui r\'ev\`ele qu'aucun job n'est en cours d'ex\'ecution, et qu'aucun des -p\'eriph\'eriques n'est en cours d'utilisation. Si je d\'emonte la librairie -({\bf unmount}), qui ne sera plus utilis\'ee dans cet exemple, et que je lance -un job qui utilise le stockage File, le job se bloque. Si je demande \`a -nouveau {\bf status storage=xxx}, j'obtiens : - -\footnotesize -\begin{verbatim} -status storage=File -... -Device status: -Autochanger "DDS-4-changer" with devices: - "DDS-4" (/dev/nst0) -Device "DDS-4" (/dev/nst0) is not open. - Device is BLOCKED. User unmounted. - Drive 0 is not loaded. -Device "Dummy" is not open or does not exist. -No DEVICE structure. - -Device "DVD-Writer" (/dev/hdc) is not open. -Device "File" (/tmp) is not open. - Device is BLOCKED waiting for media. -==== -... -\end{verbatim} -\normalsize - -Il devrait maintenant \^etre clair que si un job n\'ecessitant la librairie -est ex\'ecut\'e, il bloquera en raison du d\'emontage de cette derni\`ere par -l'utilisateur. Mais le probl\`eme pour le job que j'ai lanc\'e avec le -p\'eriph\'erique "File" est que le p\'eriph\'erique est bloqu\'e en attente -d'un media : Bacula a besoin que vous \'etiquetiez un volume. - -\item [unmount] - \index[console]{unmount} - Cette commande sert \`a ordonner au Storage Daemon de d\'emonter le p\'eriph\'erique - sp\'ecifi\'e. Les formes de cette commande sont les m\^emes que celle de la commande - mount : - -\footnotesize -\begin{verbatim} -unmount storage= - -unmount [ jobid= | job= ] -\end{verbatim} -\normalsize - -\label{UpdateCommand} -\item [update] - \index[console]{update} - Cette commande met \`a jour le catalogue, que ce soit pour un pool sp\'ecifique, - un enregistrement de volume, ou les slots d'une librairie dot\'ee d'un lecteur - de codes barres. Dans le cas de la mise \`a jour d'un enregistrement de pool, - la nouvelle configuration est automatiquement r\'ecup\'er\'ee de la ressource - correspondante du fichier de configuration du Director. Cette commande peut - notamment servir \`a augmenter le nombre maxial de volumes dans un pool. Les - principaux mots-clef suivants peuvent \^etre utilis\'es : - -\footnotesize -\begin{verbatim} - media, volume, pool, slots -\end{verbatim} -\normalsize - -Dans le cas de la mise \`a jour d'un volume, vous serez interrog\'e sur le -param\`etre que vous voulez modifier. Voici ces param\`etres : - -\footnotesize -\begin{verbatim} - - Volume Status - Volume Retention Period - Volume Use Duration - Maximum Volume Jobs - Maximum Volume Files - Maximum Volume Bytes - Recycle Flag - Slot - InChanger Flag - Pool - Volume Files - Volume from Pool - All Volumes from Pool - -\end{verbatim} -\normalsize - - Pour le param\`etre slot, {\bf update slots}, Bacula obtient une liste - de tous les slots et de leurs codes barres du Storage Daemon, - pour chaque code barres trouv\'e, le slot est mis \`a jour dans - l'enregistrement Media du catalogue. C'est tr\`es pratique si vous - d\'eplacez des cartouches dans la librairie, ou si vous changez des - magasins de cartouches. Dans la foul\'ee, le drapeau InChanger est - aussi mis \`a jour.Ceci permet \`a BAcula de savoir quels cartouches sont - effectivement dans la librairie. - - Si vous n'avez pas de lecteur de codes barres, vous pouvez faire la - m\^eme chose depuis la version 1.33 gr\^ace \`a la commande {\bf update slots scan}. - Le mot-clef {\bf scan} ordonne \`a Bacula de monter physiquement chaque - cartouche afin de lire son VolumeName. - - Pour le param\`etre Pool, {\bf update pool}, Bacula d\'eplace le volume de - son pool courant vers le pool sp\'ecifi\'e. - - Pour les parm\`etres {\bf Volume from Pool} et {\bf All Volumes from Pool}, - les valeurs suivantes sont mises \`a jour depuis l'enregistrement - de pool : Recycle, VolRetention, VolUseDuration, MaxVolJobs, MaxVolFiles, - and MaxVolBytes. - - Voici la forme compl\`ete de la commande {\bf update} : - -\footnotesize -\begin{verbatim} - update volume=xxx pool=yyy slots volstatus=xxx VolRetention=ddd - VolUse=ddd MaxVolJobs=nnn MaxVolBytes=nnn Recycle=yes|no - slot=nnn enabled=n - -\end{verbatim} -\normalsize - -\item [use] - \index[console]{use} - Cette commande vous perment de pr\'eciser le catalogue que vous voulez utiliser. - En principe, vous n'utiliserez qu'un seul catalogue, aussi vous n'aurez pas - besoin de faire ce choix. Sinon, utilisez cette commande pour passer de l'un - de vos catalogues \`a l'autre. - -use \lt{}database-name\gt{} - -\item [var] - \label{var} - \index[console]{var name} - Cette commande prend une cha\^ine \'eventuellement encadr\'ee de guillemets et effectue - l'expansion des variables comme elle serait effectu\'ee au niveau de la - directive {\bf LabelFormat}. Ainsi, vous pouvez tester vos cha\^ines - de format d'\'etiquetage. La diff\'erence entre la commande {\bf var} et le - processus effectif est que pour la premi\`ere, aucun job n'est en cours, - aussi des valeurs factices sont utilis\'ees au lieu des variables sp\'ecifiques - aux jobs. Cela vous permet cependant de vous faire une bonne id\'ee de ce qui - se passerait dans le cas r\'eel. - -\item [version] - \index[console]{version} - Cette commande affiche la version du Director. - -\item [quit] - \index[console]{quit} - Cette commande stoppe le programme Console. Celui-ci envoie la requ\^ete - {\bf quit} au Director et attend son accus\'e de r\'eception. Si le Director - est occup\'e, cela peut prendre un certain temps. Vous pouvez quitter - imm\'ediatement en utilisant la variante {\bf .quit} ({\bf quit} pr\'ec\'ed\'ee - d'un point). - -\item [query] - \index[console]{query} - Cette commande lit une requ\^ete SQL pr\'ed\'efinie dans le fichier de requ\^etes - (le nom et l'emplacement de ce fichier sont d\'efinis par la directive - QueryFile du fichier de configuration du Director). Il vous est alors - demand\'e de s\'electionner une requ\^ete du fichier, et \'eventuellement de - saisir un ou plusieurs param\`etres. La requ\^ete est alors soumise au - moteur de base de donn\'ees. - -Les requ\^etes suivantes sont actuellement (version 1.24) disponibles : - -\footnotesize -\begin{verbatim} -Available queries: - 1: List Job totals: - 2: List where a file is saved: - 3: List where the most recent copies of a file are saved: - 4: List total files/bytes by Job: - 5: List total files/bytes by Volume: - 6: List last 20 Full Backups for a Client: - 7: List Volumes used by selected JobId: - 8: List Volumes to Restore All Files: - 9: List where a File is saved: -Choose a query (1-9): - -\end{verbatim} -\normalsize - -\item [exit] - \index[console]{exit} - Cette commande termine le programme Console. - -\item [wait] - \index[console]{wait} - Cette commande place le Director en pause jusqu'\`a ce qu'il n'y ait plus - aucun job en ex\'ecution. Cette commande est utile dans des situation - d'utilisation automatis\'ee par scripts telles que les tests de r\'egression - o\`u vous voulez d\'emarrer un job, et attendre qu'il se termine avant de - poursuivre. Cette commande admet les options suivantes : - -\footnotesize -\begin{verbatim} - wait [jobid=nn] [jobuid=unique id] [job=job name] -\end{verbatim} -\normalsize - -\end{description} - -\label{dotcommands} - -\subsection*{Commandes sp\'eciales, pr\'ec\'ed\'ees d'un point} -\index[general]{Commands!sp\'eciales, pr\'ec\'ed\'ees d'un point} -\index[general]{Commandes sp\'eciales, pr\'ec\'ed\'ees d'un point} -\addcontentsline{toc}{subsection}{Commandes sp\'eciales, pr\'ec\'ed\'ees d'un point} - -Voici une liste de commandes pr\'efix\'ees d'un point (.). Elles ont pour vocation -d'\^etre utilis\'ees soit dans des programmes {\it batch}, soit par des interfaces -graphiques. Elles ne sont, en principe, pas utilis\'ees en mode interactif. -Une fois que le d\'eveloppement d'interfaces graphiques aura d\'emarr\'e, cette liste -s'accro\^itra consid\'erablement. - -\footnotesize -\begin{verbatim} -.backups job=xxx list backups for specified job -.defaults client=xxx fileset=yyy list defaults for specified client -.die cause the Director to segment fault (for debugging) -.dir when in tree mode prints the equivalent to the dir command, - but with fields separated by commas rather than spaces. -.jobs list all job names -.levels list all levels -.filesets list all fileset names -.clients list all client names -.pools list all pool names -.types list job types -.msgs return any queued messages -.messages get quick messages -.help help command output -.quit quit -.status get status output -.exit quit -\end{verbatim} -\normalsize - -\label{atcommands} - -\subsection*{Commandes sp\'eciales, pr\'ec\'ed\'ees d'un arobase (@)} -\index[general]{Commandes!sp\'eciales arobase @} -\index[general]{Commandes sp\'eciales, pr\'ec\'ed\'ees d'un arobase (@)} -\addcontentsline{toc}{subsection}{Commandes sp\'eciales, pr\'ec\'ed\'ees d'un arobase (@)} - -Normalement, toutes les commandes saisies dans la Console sont imm\'ediatement -transmises au Director, qui peut r\'esider sur une autre machine, afin d'y \^etre -ex\'ecut\'ees. Il existe cependant quelques commandes, toutes pr\'ec\'ed\'ees du -caract\`ere arobase (@), qui ne sont pas envoy\'ees au Director, mais -directement interpr\'et\'ees par la Console. Notez que seule la Console -tty impl\'emente ces commandes, et non la Console GNOME. En voici la liste : - -\begin{description} - -\item [@input \lt{}nom-de-fichier\gt{}] - \index[console]{@input \lt{}nom-de-fichier\gt{}} - Lit et ex\'ecute les commandes consign\'ees dans le fichier sp\'ecifi\'e. - -\item [@output \lt{}nom-de-fichier\gt{} w/a] - \index[console]{@output \lt{}nom-de-fichier\gt{} w/a} - Envoit l'ensemble des retours de la Console vers le fichier sp\'ecifi\'e, - avec \'ecrasement si l'option {\bf w} est sp\'ecifi\'ee, ou ajout \`a la suite si l'option - {\bf a} est sp\'ecifi\'ee. Pour rediriger la sortie vers le terminal, entrez - simplement {\bf output} sans sp\'ecifier de nom de fichier. - ATTENTION : prenez garde de ne pas \'ecraser un fichier valide. - Voici un exemple typique lors d'un test de r\'egression : - -\footnotesize -\begin{verbatim} - @output /dev/null - commands ... - @output - -\end{verbatim} -\normalsize - -\item [@tee \lt{}nom-de-fichier\gt{} w/a] - \index[console]{@tee \lt{}nom-de-fichier\gt{} w/a} - Comme la commande pr\'ec\'edente avec envoi simultan\'e vers le terminal. Pour - sortir de ce mode, vous pouvez utiliser {\bf @tee} ou {\bf @output} sans - sp\'ecifier de nom de fichier. - -\item [@sleep \lt{}seconds\gt{}] - \index[console]{@sleep \lt{}seconds\gt{}} - Met en sommeil pour une dur\'ee du nombre de secondes sp\'ecifi\'e. - -\item [@time] - \index[console]{@time} - Affiche la date et l'heure courantes. - -\item [@version] - \index[console]{@version} - Affiche la version de la Console. - -\item [@quit] - \index[console]{@quit} - Quitte. - -\item [@exit] - \index[console]{@exit} - Quitte. - -\item [@\# n-importe-quoi] - \index[console]{n-importe-quoi} - Commentaire. -\end{description} - -\label{scripting} - -\subsection*{Ex\'ecuter la Console depuis un script shell} -\index[general]{Script!Ex\'ecuter la Console depuis un script shell} -\index[general]{Ex\'ecuter la Console depuis un script shell} -\addcontentsline{toc}{subsection}{Ex\'ecuter la Console depuis un script shell} -Vous pouvez automatiser de nombreuses t\^aches effectu\'ees \`a la Console, en les -ex\'ecutant dans un script shell. Par exemple, si vous avez cr\'e\'e un fichier -contenant ceci : - -\footnotesize -\begin{verbatim} - ./bconsole -c ./bconsole.conf < calling -SD: 3000 OK Hello -DR: JobId=nnn Allow=(append, read) Session=(*, SessionId) - (Session not implemented yet) -SD: 3000 OK Job Authorization= -DR: use device= media_type= - pool_name= pool_type= -SD: 3000 OK use device -\end{verbatim} -\normalsize - -For the Director to be authorized, the \lt{}Director-name\gt{} and the -\lt{}password\gt{} must match the values in one of the Storage daemon's -Director resources (there may be several Directors that can access a single -Storage daemon). - -\subsection*{The Protocol Used Between the Director and the File Daemon} -\index{Daemon!Protocol Used Between the Director and the File } -\index{Protocol Used Between the Director and the File Daemon } -\addcontentsline{toc}{subsection}{Protocol Used Between the Director and the -File Daemon} - -A typical conversation might look like the following: - -\footnotesize -\begin{verbatim} -FD: listens -DR: makes connection -DR: Hello calling -FD: 2000 OK Hello -DR: JobId=nnn Authorization= -FD: 2000 OK Job -DR: storage address = port = - name = mediatype = -FD: 2000 OK storage -DR: include -DR: -DR: - ... -DR: Null packet -FD: 2000 OK include -DR: exclude -DR: -DR: - ... -DR: Null packet -FD: 2000 OK exclude -DR: full -FD: 2000 OK full -DR: save -FD: 2000 OK save -FD: Attribute record for each file as sent to the - Storage daemon (described above). -FD: Null packet -FD: - e.g. - 3000 OK Volumes = - 3001 Volume = - - 3002 Volume data = - - ... additional Volume / Volume data pairs for volumes 2 .. n -FD: Null packet -FD: close socket -\end{verbatim} -\normalsize - -\subsection*{The Save Protocol Between the File Daemon and the Storage Daemon} -\index{Save Protocol Between the File Daemon and the Storage Daemon } -\index{Daemon!Save Protocol Between the File Daemon and the Storage } -\addcontentsline{toc}{subsection}{Save Protocol Between the File Daemon and -the Storage Daemon} - -Once the Director has send a {\bf save} command to the File daemon, the File -daemon will contact the Storage daemon to begin the save. - -In what follows: FD: refers to information set via the network from the File -daemon to the Storage daemon, and SD: refers to information set from the -Storage daemon to the File daemon. - -\subsubsection*{Command and Control Information} -\index{Information!Command and Control } -\index{Command and Control Information } -\addcontentsline{toc}{subsubsection}{Command and Control Information} - -Command and control information is exchanged in human readable ASCII commands. - - -\footnotesize -\begin{verbatim} -FD: listens -SD: makes connection -FD: append open session = [] -SD: 3000 OK ticket = -FD: append data -SD: 3000 OK data address = port = -\end{verbatim} -\normalsize - -\subsubsection*{Data Information} -\index{Information!Data } -\index{Data Information } -\addcontentsline{toc}{subsubsection}{Data Information} - -The Data information consists of the file attributes and data to the Storage -daemon. For the most part, the data information is sent one way: from the File -daemon to the Storage daemon. This allows the File daemon to transfer -information as fast as possible without a lot of handshaking and network -overhead. - -However, from time to time, the File daemon needs to do a sort of checkpoint -of the situation to ensure that everything is going well with the Storage -daemon. To do so, the File daemon sends a packet with a negative length -indicating that he wishes the Storage daemon to respond by sending a packet of -information to the File daemon. The File daemon then waits to receive a packet -from the Storage daemon before continuing. - -All data sent are in binary format except for the header packet, which is in -ASCII. There are two packet types used data transfer mode: a header packet, -the contents of which are known to the Storage daemon, and a data packet, the -contents of which are never examined by the Storage daemon. - -The first data packet to the Storage daemon will be an ASCII header packet -consisting of the following data. - -\lt{}File-Index\gt{} \lt{}Stream-Id\gt{} \lt{}Info\gt{} where {\bf -\lt{}File-Index\gt{}} is a sequential number beginning from one that -increments with each file (or directory) sent. - -where {\bf \lt{}Stream-Id\gt{}} will be 1 for the Attributes record and 2 for -uncompressed File data. 3 is reserved for the MD5 signature for the file. - -where {\bf \lt{}Info\gt{}} transmit information about the Stream to the -Storage Daemon. It is a character string field where each character has a -meaning. The only character currently defined is 0 (zero), which is simply a -place holder (a no op). In the future, there may be codes indicating -compressed data, encrypted data, etc. - -Immediately following the header packet, the Storage daemon will expect any -number of data packets. The series of data packets is terminated by a zero -length packet, which indicates to the Storage daemon that the next packet will -be another header packet. As previously mentioned, a negative length packet is -a request for the Storage daemon to temporarily enter command mode and send a -reply to the File daemon. Thus an actual conversation might contain the -following exchanges: - -\footnotesize -\begin{verbatim} -FD: <1 1 0> (header packet) -FD: -FD: Null packet -FD: <1 2 0> -FD: -FD: Packet length = -1 -SD: 3000 OK -FD: <2 1 0> -FD: -FD: Null packet -FD: <2 2 0> -FD: -FD: Null packet -FD: Null packet -FD: append end session -SD: 3000 OK end -FD: append close session -SD: 3000 OK Volumes = -SD: 3001 Volume = - -SD: 3002 Volume data = - -SD: ... additional Volume / Volume data pairs for - volumes 2 .. n -FD: close socket -\end{verbatim} -\normalsize - -The information returned to the File daemon by the Storage daemon in response -to the {\bf append close session} is transmit in turn to the Director. diff --git a/docs/manual-fr/developers.tex b/docs/manual-fr/developers.tex deleted file mode 100644 index 48d0eda1..00000000 --- a/docs/manual-fr/developers.tex +++ /dev/null @@ -1,72 +0,0 @@ -%% -%% - -\documentclass[11pt,a4paper]{report} -\usepackage{html} -\usepackage{float} -\usepackage{graphicx} -\usepackage{bacula} -\usepackage{longtable} -\usepackage{makeidx} -\usepackage{index} -\usepackage{setspace} -\usepackage{hyperref} -\usepackage{french} - - -\makeindex - -\sloppy - -\begin{document} -\sloppy - -\newfont{\bighead}{cmr17 at 36pt} -%% \topmargin -0.5in -%% \textheight 9in -\parskip 10pt -\parindent 0pt -%% \oddsidemargin -0.0in -%% \evensidemargin -0.25in -%% \textwidth 7in - -\title{\includegraphics{./bacula-logo.eps} \\ \bigskip - \Large{Il surgit de la nuit et absorbe l'essence vitale - de vos ordinateurs.} } -\author{Kern Sibbald \\ - Traduit de l'anglais par Ludovic Strappazon } -\date{\vspace{2.0in}\today \\ - Ce mode d'emploi document la version 1.37.3 de Bacula} - -\maketitle - -\clearpage -\tableofcontents -\clearpage -\listoffigures -\clearpage -\listoftables -\clearpage - -\include{generaldevel} -\include{daemonprotocol} -\include{director} -\include{file} -\include{storage} -\include{mediaformat} -\include{porting} -\include{regression} -\include{md5} -\include{mempool} -\include{netprotocol} -\include{smartall} - - -% The following line tells link_resolver.pl to not include these files: -% nolinks developersi baculai-dir baculai-fd baculai-sd baculai-console baculai-main - -% pull in the index -\clearpage -\printindex - -\end{document} diff --git a/docs/manual-fr/developersi.tex b/docs/manual-fr/developersi.tex deleted file mode 100644 index 35910beb..00000000 --- a/docs/manual-fr/developersi.tex +++ /dev/null @@ -1,340 +0,0 @@ -\begin{theindex} - - \item [, \hyperpage{27--32}, \hyperpage{34, 35}, \hyperpage{43}, - \hyperpage{57}, \hyperpage{61} - - \indexspace - - \item Download smartall.zip (Zipped archive) , \hyperpage{80} - - \indexspace - - \item ACKNOWLEDGEMENTS , \hyperpage{63} - \item Adding a New Test , \hyperpage{58} - \item Additional Error information , \hyperpage{69} - \item Alloc() Function , \hyperpage{78} - \item ALSO - \subitem SEE , \hyperpage{62} - \item Archive - \subitem Download smartall.zip Zipped , \hyperpage{80} - \subitem Download md5.zip Zipped , \hyperpage{62} - \item Assignment - \subitem Copyright , \hyperpage{5} - \item Attributes - \subitem Unix File , \hyperpage{43} - \item Avoid if Possible , \hyperpage{10} - - \indexspace - - \item Backup - \subitem Commands Received from the Director for a , \hyperpage{25} - \item Bacula - \subitem Building the Test , \hyperpage{55} - \subitem Developing , \hyperpage{6} - \item Bacula Developer Notes , \hyperpage{4} - \item Bacula Memory Management , \hyperpage{64} - \item Bacula Porting Notes , \hyperpage{50} - \item Bacula Regression Testing , \hyperpage{54} - \item Bacula Source File Structure , \hyperpage{8} - \item Becoming a Server , \hyperpage{71} - \item Block Header , \hyperpage{34} - \item Bnet and Threads , \hyperpage{68} - \item Bnet\_close , \hyperpage{70} - \item Bnet\_fsend , \hyperpage{69} - \item Bnet\_open , \hyperpage{68} - \item Bnet\_recv , \hyperpage{69} - \item Bnet\_send , \hyperpage{69} - \item Bnet\_sig , \hyperpage{70} - \item Bnet\_strerror , \hyperpage{70} - \item BUGS , \hyperpage{62} - \item Building the Test Bacula , \hyperpage{55} - - \indexspace - - \item Classes - \subitem Message , \hyperpage{14} - \item Code - \subitem When Implementing Incomplete , \hyperpage{8} - \item Command and Control Information , \hyperpage{20} - \item Command Line Message Digest Utility , \hyperpage{60} - \item Commands Received from the Director for a Backup , - \hyperpage{25} - \item Commands Received from the Director for a Restore , - \hyperpage{25} - \item Contributions , \hyperpage{4} - \item Conventions - \subitem Higher Level , \hyperpage{71} - \item COPYING , \hyperpage{63} - \item Copying , \hyperpage{80} - \item Copyright Assignment , \hyperpage{5} - \item Copyrights , \hyperpage{4} - \item Corporate Assignment Statement , \hyperpage{5} - - \indexspace - - \item Daemon - \subitem Director Services , \hyperpage{23} - \subitem File Services , \hyperpage{24} - \subitem Protocol Used Between the Director and the File , - \hyperpage{19} - \subitem Protocol Used Between the Director and the Storage , - \hyperpage{18} - \subitem Save Protocol Between the File Daemon and the Storage , - \hyperpage{20} - \item Daemon Protocol , \hyperpage{17} - \item Data Information , \hyperpage{20} - \item Debug Messages , \hyperpage{14} - \item Debugger - \subitem Using a , \hyperpage{7} - \item Debugging , \hyperpage{7} - \item Definitions , \hyperpage{30} - \item DESCRIPTION , \hyperpage{60} - \item Design - \subitem Storage Daemon , \hyperpage{26} - \item Details - \subitem SMARTALLOC , \hyperpage{76} - \item Detection - \subitem Smart Memory Allocation With Orphaned Buffer , - \hyperpage{72} - \item Developing Bacula , \hyperpage{6} - \item Director Services Daemon , \hyperpage{23} - \item Directory Structure , \hyperpage{58} - \item Disabled - \subitem When SMARTALLOC is , \hyperpage{77} - \item Do Not Use , \hyperpage{10} - \item Do Use Whenever Possible , \hyperpage{10} - \item Don'ts , \hyperpage{13} - \item Download md5.zip (Zipped archive) , \hyperpage{62} - \item Dynamically Allocated Memory , \hyperpage{64} - - \indexspace - - \item Error Messages , \hyperpage{15} - \item EXIT STATUS , \hyperpage{62} - - \indexspace - - \item Fails - \subitem If a Test , \hyperpage{57} - \item File Services Daemon , \hyperpage{24} - \item Files - \subitem Header , \hyperpage{9} - \subitem Special , \hyperpage{8} - \item FILES , \hyperpage{62} - \item Format - \subitem Old Depreciated Tape , \hyperpage{44} - \subitem Overall , \hyperpage{33} - \subitem Overall Storage , \hyperpage{38} - \subitem Storage Daemon File Output , \hyperpage{32} - \subitem Storage Media Output , \hyperpage{30} - \subitem Volume Label , \hyperpage{37} - \item Function - \subitem alloc , \hyperpage{78} - - \indexspace - - \item General , \hyperpage{4}, \hyperpage{17}, \hyperpage{30}, - \hyperpage{54}, \hyperpage{64}, \hyperpage{68} - \item General Daemon Protocol , \hyperpage{17} - - \indexspace - - \item Hack - \subitem Invitation to the , \hyperpage{79} - \item Hand - \subitem Running the Tests by , \hyperpage{58} - \item Header - \subitem Block , \hyperpage{34} - \subitem Record , \hyperpage{34} - \subitem Version 2 Record , \hyperpage{36} - \subitem Version BB02 Block , \hyperpage{36} - \item Header Files , \hyperpage{9} - \item Higher Level Conventions , \hyperpage{71} - - \indexspace - - \item If a Test Fails , \hyperpage{57} - \item Indenting Standards , \hyperpage{11} - \item Information - \subitem Additional Error , \hyperpage{69} - \subitem Command and Control , \hyperpage{20} - \subitem Data , \hyperpage{20} - \item Installing SMARTALLOC , \hyperpage{73} - \item Introduction - \subitem SD Design , \hyperpage{26} - \item Invitation to the Hack , \hyperpage{79} - - \indexspace - - \item Job Messages , \hyperpage{15} - - \indexspace - - \item Label - \subitem Session , \hyperpage{37} - \item Leaks - \subitem Memory , \hyperpage{7} - \item Libraries - \subitem Living with , \hyperpage{74} - \item Living with Libraries , \hyperpage{74} - \item Low Level Network Protocol , \hyperpage{17} - - \indexspace - - \item Management - \subitem Bacula Memory , \hyperpage{64} - \item Memory - \subitem Dynamically Allocated , \hyperpage{64} - \subitem Pooled and Non-pooled , \hyperpage{65} - \subitem Statically Allocated , \hyperpage{64} - \item Memory Leaks , \hyperpage{7} - \item Memory Messages , \hyperpage{16} - \item Message Classes , \hyperpage{14} - \item Messages - \subitem Debug , \hyperpage{14} - \subitem Error , \hyperpage{15} - \subitem Job , \hyperpage{15} - \subitem Memory , \hyperpage{16} - - \indexspace - - \item NAME , \hyperpage{60} - \item Notes - \subitem Bacula Developer , \hyperpage{4} - \subitem Bacula Porting , \hyperpage{50} - - \indexspace - - \item Old Depreciated Tape Format , \hyperpage{44} - \item OPTIONS , \hyperpage{61} - \item Other Tests , \hyperpage{57} - \item Outline - \subitem SD Development , \hyperpage{26} - \item Overall Format , \hyperpage{33} - \item Overall Storage Format , \hyperpage{38} - \item Overlays and Underhandedness , \hyperpage{78} - - \indexspace - - \item Parameters - \subitem Setting the Configuration , \hyperpage{54} - \item Patches , \hyperpage{4} - \item Pooled and Non-pooled Memory , \hyperpage{65} - \item Porting - \subitem Steps to Take for , \hyperpage{51} - \item Porting Requirements , \hyperpage{50} - \item Possible - \subitem Avoid if , \hyperpage{10} - \subitem Do Use Whenever , \hyperpage{10} - \item Program - \subitem Test and Demonstration , \hyperpage{79} - \item Programming Standards , \hyperpage{10} - \item Protocol - \subitem Daemon , \hyperpage{17} - \subitem General Daemon , \hyperpage{17} - \subitem Low Level Network , \hyperpage{17} - \subitem TCP/IP Network , \hyperpage{68} - \item Protocol Used Between the Director and the File Daemon , - \hyperpage{19} - \item Protocol Used Between the Director and the Storage Daemon , - \hyperpage{18} - - \indexspace - - \item Record Header , \hyperpage{34} - \item Regression - \subitem Running the Disk Only , \hyperpage{55} - \item Requests - \subitem SD Append , \hyperpage{27} - \subitem SD Read , \hyperpage{28} - \item Requirements - \subitem Porting , \hyperpage{50} - \item Restore - \subitem Commands Received from the Director for a , \hyperpage{25} - \item Running the Disk Only Regression , \hyperpage{55} - \item Running the Regression Script , \hyperpage{54} - \item Running the Tests by Hand , \hyperpage{58} - - \indexspace - - \item Save Protocol Between the File Daemon and the Storage Daemon , - \hyperpage{20} - \item Script - \subitem Running the Regression , \hyperpage{54} - \item SD Append Requests , \hyperpage{27} - \item SD Connections and Sessions , \hyperpage{27} - \item SD Design Introduction , \hyperpage{26} - \item SD Development Outline , \hyperpage{26} - \item SD Read Requests , \hyperpage{28} - \item SEE ALSO , \hyperpage{62} - \item Serialization , \hyperpage{33} - \item Server - \subitem Becoming a , \hyperpage{71} - \item Session Label , \hyperpage{37} - \item Sessions - \subitem SD Connections and , \hyperpage{27} - \item Setting the Configuration Parameters , \hyperpage{54} - \item Smart Memory Allocation With Orphaned Buffer Detection , - \hyperpage{72} - \item SMARTALLOC - \subitem Installing , \hyperpage{73} - \subitem Squelching a , \hyperpage{74} - \item SMARTALLOC Details , \hyperpage{76} - \item Special Files , \hyperpage{8} - \item Squelching a SMARTALLOC , \hyperpage{74} - \item Standards - \subitem Indenting , \hyperpage{11} - \subitem Programming , \hyperpage{10} - \item Statement - \subitem Corporate Assignment , \hyperpage{5} - \item Statically Allocated Memory , \hyperpage{64} - \item STATUS - \subitem EXIT , \hyperpage{62} - \item Steps to Take for Porting , \hyperpage{51} - \item Storage Daemon Design , \hyperpage{26} - \item Storage Daemon File Output Format , \hyperpage{32} - \item Storage Media Output Format , \hyperpage{30} - \item Structure - \subitem Bacula Source File , \hyperpage{8} - \subitem Directory , \hyperpage{58} - \item SYNOPSIS , \hyperpage{60} - - \indexspace - - \item Tabbing , \hyperpage{13} - \item TCP/IP Network Protocol , \hyperpage{68} - \item Test - \subitem Adding a New , \hyperpage{58} - \subitem Writing a Regression , \hyperpage{58} - \item Test and Demonstration Program , \hyperpage{79} - \item Testing - \subitem Bacula Regression , \hyperpage{54} - \item Tests - \subitem Other , \hyperpage{57} - \item Threads - \subitem bnet and , \hyperpage{68} - - \indexspace - - \item Underhandedness - \subitem Overlays and , \hyperpage{78} - \item Unix File Attributes , \hyperpage{43} - \item Use - \subitem Do Not , \hyperpage{10} - \item Using a Debugger , \hyperpage{7} - \item Utility - \subitem Command Line Message Digest , \hyperpage{60} - - \indexspace - - \item Version 2 Record Header , \hyperpage{36} - \item Version BB02 Block Header , \hyperpage{36} - \item Volume Label Format , \hyperpage{37} - - \indexspace - - \item When Implementing Incomplete Code , \hyperpage{8} - \item When SMARTALLOC is Disabled , \hyperpage{77} - \item Writing a Regression Test , \hyperpage{58} - -\end{theindex} diff --git a/docs/manual-fr/dirdconf.tex b/docs/manual-fr/dirdconf.tex deleted file mode 100644 index ac2272a5..00000000 --- a/docs/manual-fr/dirdconf.tex +++ /dev/null @@ -1,3903 +0,0 @@ -%% -%% - -\section*{Configurer le Director} -\label{_ChapterStart40} -\index[general]{Director!Configurer le} -\index[general]{Configurer le Director} -\addcontentsline{toc}{section}{Configurer le Director} - -Parmi tous les fichiers de configuration requis pour ex\'ecuter {\bf Bacula}, -celui du Director est le plus compliqu\'e, et c'est celui que vous modifierez -le plus souvent, en ajoutant des clients ou en modifiant les FileSets. - -Pour une discussion g\'en\'erale concernant les fichiers et ressources ainsi -que les types de donn\'ees reconnus par {\bf Bacula}, veuillez consulter le -chapitre -\ilink{Configuration}{_ChapterStart16} de ce manuel. - -\subsection*{Les types de ressources du Director} -\index[general]{Les types de ressources du Director} -\index[general]{Director!Les types de ressources du} -\addcontentsline{toc}{subsection}{Les types de ressources du Director} - -Les types de ressources du Director sont : - -Job, JobDefs, Client, Storage, Catalog, Schedule, FileSet, Pool, Director, et -Messages. Nous les pr\'esentons ici dans l'ordre le plus logique (relativement -au fichier de configuration du Director) : - -\begin{itemize} -\item - \ilink{Director}{DirectorResource4} -- Pour d\'efinir le nom du - Director et son mot de passe pour l'authentification du programme Console. Il - ne doit y avoir qu'une seule d\'efinition de ressource Director dans le - fichier de configuration. Si vous avez soit {\bf /dev/random} soit {\bf bc} - sur votre machine, Bacula g\'en\`erera un mot de passe al\'eatoire lors du - processus de configuration, sinon, il sera laiss\'e blanc. -\item - \ilink{Job}{JobResource} -- Pour d\'efinir les Jobs de types - sauvegarde et restauration, et pour lier les ressources Client, FileSet et -Schedules \`a utiliser conjointement pour chaque Job. -\item - \ilink{JobDefs}{JobDefsResource} -- Ressource optionnelle destin\'ee \`a - fournir des valeurs par d\'efaut pour les ressources Job. -\item - \ilink{Schedule}{ScheduleResource} -- Pour d\'efinir le moment - o\`u un Job doit \^etre lanc\'e automatiquement par le {\it scheduler} -interne de Bacula. -\item - \ilink{FileSet}{FileSetResource} -- Pour d\'efinir l'ensemble des - fichiers \`a sauvegarder pour chaque client. -\item - \ilink{Client}{ClientResource2} -- Pour d\'efinir quel Client est - \`a sauvegarder. -\item - \ilink{Storage}{StorageResource2} -- Pour d\'efinir sur quel - p\'eriph\'erique physique les volumes seront mont\'es. -\item - \ilink{Pool}{PoolResource} -- Pour d\'efinir quel le pool de volumes - qui peut \^etre utilis\'e pour un Job donn\'e -\item - \ilink{Catalog}{CatalogResource} -- Pour d\'efinir la base de - donn\'ees o\`u conserver les listes des fichiers sauvegard\'es et des volumes -o\`u ils ont \'et\'e sauvegard\'es. -\item - \ilink{Messages}{_ChapterStart15} -- Pour d\'efinir les - destinataires (ou les fichiers de logs) des messages d'erreur et -d'information. -\end{itemize} - -\subsection*{La ressource Director} -\label{DirectorResource4} -\index[general]{Director!La ressource} -\index[general]{La ressource Director} -\addcontentsline{toc}{subsection}{La ressource Director} - -La ressource Director d\'efinit les attributs du Director ex\'ecut\'e sur le -r\'eseau. Dans l'impl\'ementation actuelle, il n'y a qu'une ressource -Director, mais la r\'ealisation finale contiendra plusieurs Directors pour -maintenir la redondance de la base des indexes et m\'edia. - -\begin{description} - -\item [Director] - \index[dir]{Director} - D\'ebut de la ressource Director. Une ressource Director et une seule doit -\^etre d\'efinie. - -\item [Name = \lt{}nom\gt{}] - \index[dir]{Name} - \index[dir]{Directive!Name} - Le nom du Director utilis\'e par l'administrateur syst\`eme. Cette directive -est requise - -\item [Description = \lt{ }texte\gt{}] - \index[dir]{Description} - \index[dir]{Directive!Description} - Le champ texte contient une description du Director qui sera affich\'ee dans -l'interface graphique. Cette directive est optionnelle. - -\item [Password = \lt{}UA-password\gt{}] - \index[dir]{Password} - \index[dir]{Directive!Password} - Sp\'ecifie le mot de passe qui doit \^etre fourni par la Console Bacula par -d\'efaut pour \^etre autoris\'ee. Le m\^eme mot de passe doit appara{\^\i}tre -dans la ressource {\bf Director} du fichier de configuration de la console. -Pour plus de s\'ecurit\'e, le mot de passe ne transite jamais sur le r\'eseau, -l'authentification se fait via un \'echange de type {\it challenge-response} -d'un {\it hash code} cr\'e\'e avec le mot de passe. Cette directive est -requise. Si vous disposez de {\bf /dev/random} ou {\bf bc} sur votre machine, -Bacula g\'en\`erera un mot de passe al\'eatoire lors du processus -d'installation, sinon il sera laiss\'e blanc et vous devrez en d\'efinir un -manuellement. - -\item [Messages = \lt{}Nom-de-ressource-Messages\gt{}] - \index[dir]{Messages} - \index[dir]{Directive!Messages} - La ressource {\bf messages} sp\'ecifie o\`u doivent \^etre d\'elivr\'es les messages du Director - qui ne sont pas associ\'es \`a un job sp\'ecifique. La plupart des messages sont relatifs - \`a un job et seront dirig\'es vers la ressource {\bf messages} sp\'ecifi\'ee par le job. - Cependant, quelques messages peuvent \^etre g\'en\'er\'es lorsque aucun job n'est actif. - Cette directive est requise. - -\item [Working Directory = \lt{}R\'epertoire\gt{}] - \index[dir]{Working Directory} - \index[dir]{Directive!Working Directory} - Cette directive sp\'ecifie un r\'epertoire o\`u le Director peut d\'eposer ses fichiers - d'\'etats. Ce r\'epertoire ne devrait \^etre utilis\'e que par Bacula, mais il peut \^etre - partag\'e par d'autres {\it daemons} Bacula. Notez cependant que si ce r\'epertoire est - partag\'e avec d'autres daemons Bacula, vous devez vous assurer que le nom {\bf Name} - donn\'e \`a chaque daemon est unique afin d'\'eviter des collisions entre les fichiers - temporaires utilis\'es. Par d\'efaut, le processus de configuration de Bacula cr\'e\'e des noms - de daemons uniques en les postfixant avec -dir, -fd et -sd. - Les substitutions shell standard sont effectu\'ees \`a la lecture du fichier de - configuration, de sorte que des valeurs telles que {\bf \$HOME} seront correctement - substitu\'ees. Cette directive est requise. - - Si vous avez sp\'ecifi\'e un utilisateur et/ou un groupe pour le Director lors de la - configuration avec les options {\bf {-}{-}with-dir-user} et/ou {\bf {-}{-}with-dir-group} de - la commande ./configure, le r\'epertoire de travail Working Directory doit appartenir - doit appartenir \`a ce groupe et \`a cet utilisateur. - -\item [Pid Directory = \lt{}R\'epertoire\gt{}] - \index[dir]{Pid Directory} - \index[dir]{Directive!Pid Directory} - Cette directive sp\'ecifie un r\'epertoire o\`u le Director peut d\'eposer son fichier -d'Id de processus. Ce fichier est utilis\'e pour stopper Bacula et pr\'evenir l'ex\'ecution -simultan\'ee de plusieurs copies de Bacula. Les substitutions shell standard sont -effectu\'ees \`a la lecture du fichier de configuration, de sorte que des valeurs -telles que {\bf \$HOME} seront correctement substitu\'ees. - -Typiquement, sur les syst\`emes Linux, vous utiliserez ici {\bf /var/run}. Si vous -n'installez pas Bacula dans les r\'epertoires syst\`eme, vous pouvez utiliser le -r\'epertoire de travail {\bf Working Directory} d\'efini plus haut. -Cette directive est requise. - -\item [Scripts Directory = \lt{}Directory\gt{}] - \index[dir]{Scripts Directory} - \index[dir]{Directive!Scripts Directory} - Cette directive sp\'ecifie le r\'epertoire dans lequel le Director devra rechercher - le script Python de d\'emarrage {\bf DirStartup.py}. Ce r\'epertoire peut \^etre - partag\'e par d'autres daemons Bacula.Les substitutions shell standard sont effectu\'ees - \`a la lecture du fichier de configuration, de sorte que des valeurs telles que - {\bf \$HOME} seront correctement substitu\'ees. Cette directive est optionnelle. - -\item [QueryFile = \lt{}Path\gt{}] - \index[dir]{QueryFile} - \index[dir]{Directive!QueryFile} - Cette directive sp\'ecifie un r\'epertoire et un fichier dans lequel le -Director peut trouver les requ\^etes SQL pr\'e\'etablies pour la commande -{\bf Query} de la Console. Les substitutions shell standard sont -effectu\'ees \`a la lecture du fichier de configuration, de sorte que des valeurs -telles que {\bf \$HOME} seront correctement substitu\'ees. -Cette directive est requise. - -\label{DirMaxConJobs} - -\item [Maximum Concurrent Jobs = \lt{}nombre\gt{}] - \index[dir]{Maximum Concurrent Jobs} - \index[dir]{Directive!Maximum Concurrent Jobs} - \index[general]{Jobs Simultan\'es} - \index[general]{Jobs Concurrents} - - O\`u \lt{}nombre\gt{} est le nombre maximal de jobs qui peuvent \^etre ex\'ecut\'es -simultan\'ement par le Director. La valeur par d\'efaut est 1, mais vous pouvez utiliser -une valeur plus grande. -Notez que le format des volumes devient beaucoup plus compliqu\'e avec plusieurs jobs -ex\'ecut\'es simultan\'ement. De ce fait, les restaurations peuvent prendre beaucoup plus -de temps si Bacula doit faire le tri parmi les segments entrem\'el\'es de ces jobs. Ceci -peut \^etre \'evit\'e en s'arrangeant pour que chacun des jobs ex\'ecut\'es simultan\'ement -\'ecrive sur un volume distinct. Une autre possibilit\'e consiste \`a utiliser le -{\it data spooling} : les donn\'ees seront d'abord "spool\'ees" sur disque -simultan\'ement, ensuite les fichiers "spool" seront \'ecrits s\'equentiellement -sur le volume. - -Dans certains cas, des directives telles que {\bf Maximum Volume Jobs} ne sont pas -correctement synchronis\'ees avec le nombre de jobs simultan\'es, et des probl\`emes -de synchronisation subtils peuvent survenir, aussi des tests minutieux sont recommand\'es. - -Actuellement, il n'y a aucun param\`etre de configuration pour r\'egler ou limiter -le nombre de connections par console. Un maximum de cinq connection simultan\'ees -est autoris\'e. - -Pour plus de d\'etails concernant l'ex\'ecution simultan\'ee de plusieurs jobs, consultez la -partie \ilink{Ex\'ecution simultan\'ee de plusieurs jobs}{ConcurrentJobs} du chapitre Astuces de ce manuel. - - -\item [FD Connect Timeout = \lt{}dur\'ee\gt{}] - \index[dir]{FD Connect Timeout} - \index[dir]{Directive!FD Connect Timeout} - O\`u {\bf dur\'ee} est le d\'elai durant lequel le Director tente de contacter - le File Daemon pour d\'emarrer un job. Une fois ce d\'elai \'ecoul\'e, le Director supprimera le job. - La valeur par d\'efaut est 30 minutes. - -\item [SD Connect Timeout = \lt{}dur\'ee\gt{}] - \index[dir]{SD Connect Timeout} - \index[dir]{Directive!SD Connect Timeout} - O\`u {\bf dur\'ee} est le d\'elai durant lequel le Director tente de contacter - le Storage Daemon pour d\'emarrer un job. Une fois ce d\'elai \'ecoul\'e, le Director supprimera le job. - La valeur par d\'efaut est 30 minutes. - -\item [DirAddresses = \lt{}Sp\'ecification-adresses-IP\gt{}] - \index[dir]{DirAddresses} - \index[dir]{Adresse} - \index[general]{Adresse} - \index[dir]{Directive!DirAddresses} - Sp\'ecifie les ports et adresses sur lesquels le Director se met en attente de - connections de Consoles Bacula. La meilleure explication est sans doute un exemple : - -\footnotesize -\begin{verbatim} - DirAddresses = { - ip = { addr = 1.2.3.4; port = 1205;} - ipv4 = { - addr = 1.2.3.4; port = http;} - ipv6 = { - addr = 1.2.3.4; - port = 1205; - } - ip = { - addr = 1.2.3.4 - port = 1205 - } - ip = { addr = 1.2.3.4 } - ip = { addr = 201:220:222::2 } - ip = { - addr = bluedot.thun.net - } - } -\end{verbatim} -\normalsize - -o\`u "ip", "ip4", "ip6", "addr", et "port sont les mots clef. Notez que -les adresses peuvent \^etre sp\'ecifi\'ees sous forme de quadruplets point\'es, ou -suivant la notation \`a doubles points IPv6, ou encore sous forme de nom symbolique -(seulement pour la sp\'ecification ip). D'autre part, le port peut \^etre sp\'ecifi\'e -par un nombre, ou par une valeur mn\'emonique du fichier /etc/services. Si un port -n'est pas pr\'ecis\'e, celui par d\'efaut sera utilis\'e. Si une section ip est sp\'ecifi\'ee, -la r\'esolution peut \^etre faite soit par IPv4, soit par IPv6. Si ip4 est sp\'ecifi\'e, -seules les r\'esolutions IPv4 seront permises. Il en va de m\^eme avec ip6. - -Notez que si vous utilisez la directive DirAddresses, vous ne devez utiliser ni la directive -DirPort, ni la directive DirAddress dans la m\^eme ressource. - -\item [DIRport = \lt{}num\'ero-de-port\gt{}] - \index[dir]{DIRport} - \index[dir]{Directive!DIRport} - Sp\'ecifie le port (un entier positif) sur lequel le Director est \`a l'\'ecoute -de connections de Consoles Bacula. Ce m\^eme num\'ero de port doit \^etre sp\'ecifi\'e -dans la ressource Director du fichier de configuration de la console. La -valeur par d\'efaut est 9101, aussi, il n'est en principe pas n\'ecessaire -de renseigner cette directive. Elle n'est pas requise si vous sp\'ecifiez des -DirAdresses. - -\item [DirAddress = \lt{}Adresse-IP\gt{}] - \index[dir]{DirAddress} - \index[dir]{Directive!DirAddress} - Cette directive est optionnelle. Lorsqu'elle est sp\'ecifi\'ee, le Director n'accepte -de connections Console que de l'adresse sp\'ecifi\'ee {\bf Adresse-IP}, qui peut \^etre -soit un nom de domaine, soit une adresse IP au format quadruplet point\'e ou cha\^ine quot\'ee. -Si cette directive n'est pas sp\'ecifi\'ee, le Director acceptera des connections de Console -de toute adresse valide. Notez que contrairement \`a la sp\'ecification DirAdresses d\'ecrite -plus haut, cette directive ne permet de sp\'ecifier qu'une seule adresse. Cette directive -n'est pas requise si vous utilisez la directive DirAdresses. - -\end{description} - -Voici un exemple d'une ressource Director valide : - -\footnotesize -\begin{verbatim} -Director { - Name = HeadMan - WorkingDirectory = "$HOME/bacula/bin/working" - Password = UA_password - PidDirectory = "$HOME/bacula/bin/working" - QueryFile = "$HOME/bacula/bin/query.sql" - Messages = Standard -} -\end{verbatim} -\normalsize - -\subsection*{La ressource Job} -\label{JobResource} -\index[general]{Resource!Job } -\index[general]{Job Resource } -\addcontentsline{toc}{subsection}{Job Resource} - -La ressource Job d\'efinit un Job (sauvegarde, restauration,...) que Bacula doit -ex\'ecuter. Chaque d\'efinition de ressource Job contient le nom d'un client, la -liste des \'el\'ements \`a sauvegarder (FileSet), la planification (Schedule) pour -ce Job, le lieu o\`u sauvegarder ces donn\'ees (Storage Device) et quel groupe de -media utiliser (Pool). En effet, chaque ressource Job doit r\'epondre aux questions : -"Quoi ?", "O\`u ?", "Quand ?" et "Comment ?" soit, respectivement Fileset, Storage, -Schedule, Type et Niveau (Sauvegarde/Restauration - Full/Differentielle/Incr\'ementale). -Notez que le FileSet doit \^etre sp\'ecifi\'e lors des restaurations pour des raisons -historiques, mais il n'est plus utilis\'e. - -Un seul type ({\bf Backup}, {\bf Restore}, ...) peut \^etre sp\'ecifi\'e pour un Job donn\'e. -Si vous voulez sauvegarder plusieurs FileSets sur le m\^eme client, vous devez d\'efinir un -Job pour chacun d'entre eux. - -\begin{description} - -\item [Job] - \index[dir]{Job} - \index[dir]{Directive!Job} - D\'ebut de la ressource Job. Il faut d\'efinir au moins une ressource Job. - -\item [Name = \lt{}name\gt{}] - \index[dir]{Name} - \index[dir]{Directive!Name} - Le nom du Job. Ce nom peut \^etre utilis\'e avec la commande {\bf Run} du - programme Console pour lancer un Job. Si le nom contient des espaces, - il doit \^etre plac\'e entre quotes. C'est g\'en\'eralement une bonne id\'ee de - nommer vos Jobs du nom du Client qu'ils sauvegardent, afin de les - identifier ais\'ement. - - Lors de l'ex\'ecution d'un Job, son nom unique est compos\'e du nom que vous avez - sp\'ecifi\'e ici suffix\'e avec la date et l'heure de sa planification. - Cette directive est requise. - -\item [Enabled = \lt{}yes|no\gt{}] - \index[dir]{Enable} - \index[dir]{Directive!Enable} - Cette directive permet d'activer ou d\'esactiver l'ex\'ecution automatique d'un job - par le planificateur. - -\item [Type = \lt{}job-type\gt{}] - \index[dir]{Type} - \index[dir]{Directive!Type} - La directive {\bf Type} sp\'ecifie le type de Job, qui peut \^etre l'un des - suivants : {\bf Backup}, {\bf Restore}, {\bf Verify}, ou {\bf Admin}. - Cette directive est requise. Pour chaque type de Job, il existe diff\'erents - niveaux, qui seront d\'ecrits dans les prochains paragraphes. - -\begin{description} - -\item [Backup] - \index[dir]{Backup} - D\'efinit une sauvegarde. En principe, vous aurez au moins un job de type Backup - par client sauvegard\'e. A moins que vous ne d\'esactiviez le catalogue, la - plupart des donn\'ees et statistiques concernant les fichiers sauvegard\'ees - seront \'ecrites dans le catalogue. - -\item [Restore] - \index[dir]{Restore} - D\'efinit une restauration. En principe, vous ne cr\'eerez qu'un seul job de ce - type, que vous utiliserez comme un prototype que vous modifierez \`a l'aide - de la console lorsque vous devrez restaurer. Bien que certaines informations - basiques soient conserv\'ees dans le catalogue lors de restaurations, leur - quantit\'e est infime en regard des informations stock\'ees pour une sauvegarde -- - par exemple, aucune entr\'ee de nom de fichier n'est g\'en\'er\'ee, puisqu'aucun fichier - n'est sauvegard\'e. - -\item [Verify] - \index[dir]{Verify} - D\'efinit un Job de type Verify. Le Jobs de type {\bf verify} permettent de - comparer le catalogue au syst\`eme de fichiers ou \`a ce qui a \'et\'e sauvegard\'e. - Vous pouvez l'utiliser pour vous assurer qu'une cartouche de donn\'ees est - lisible, mais aussi comme un syst\`eme de d\'etection d'intrusion \`a la fa\c {c}on de - Tripwire. - -\item [Admin] - \index[dir]{Admin} - D\'efinit un Job de type Admin. Un {\bf Admin} peut s'utiliser pour "\'elaguer" - p\'eriodiquement le catalogue, si vous ne souhaitez pas que ceci soit fait \`a la fin - de chaque sauvegarde. Bien que les Jobs de type admin soient enregistr\'es dans le - catalogue, la quantit\'e de donn\'ees g\'en\'er\'ee est infime. - -\end{description} - -\label{Level} - -\item [Level = \lt{}job-level\gt{}] - \index[dir]{Directive!Level} - \index[dir]{Level} - La directive Level sp\'ecifie le niveau d'ex\'ecutiondu job par d\'efaut. - Chaque type de job a son propre jeu de niveaux qui peuvent \^etre sp\'ecifi\'es. - Le niveau d'ex\'ecution est en g\'en\'eral surcharg\'e par une valeur diff\'erente - sp\'ecifi\'ee dans la ressource {\bf Schedule}. Cette directive n'est pas - requise mais doit \^etre sp\'ecifi\'ee soit ici, soit en tant que surcharge - dans la ressource {\bf Schedule}. - -Pour un job de type {\bf Backup} le niveau doit \^etre l'un des suivants : - -\begin{description} - -\item [Full] - \index[dir]{Full} - Tous les fichiers du FileSet, qu'ils aient \'et\'e modifi\'es ou non. - -\item [Incremental] - \index[dir]{Incremental} - Tous les fichiers modifi\'es depuis la derni\`ere sauvegarde valide du FileSet - sp\'ecifi\'e pour le m\^eme job. Si le Director ne peut trouver une sauvegarde Full ant\'erieure, - le niveau du job sera \'elev\'e en une sauvegarde Full. Lorsque le Director - recherche une Full valide dans le catalogue, il recherche un job avec - les caract\'eristiques suivantes : - -\begin{itemize} -\item le m\^eme nom de job ; -\item le m\^eme nom de client ; -\item le m\^eme FileSet (toute modification de la d\'efinition du FileSet telle - que l'ajout ou la suppression de fichiers dans les sections Include ou - Exclude constitue un changement de FileSet). -\item le niveau requis (Full, Differential ou Incremental) -\item le job s'est termin\'e normalement, c'est \`a dire un qu'il ne s'est pas termin\'e - en \'echec, et n'a pas \'et\'e effac\'e. -\end{itemize} - -Si toutes les conditions ci-dessus ne sont pas r\'ealis\'ees, le Director -augmentera la sauvegarde incr\'ementale en une sauvegarde Full. Dans le cas -contraire, la sauvegarde incr\'ementale sera effectu\'ee normalement. - -Le File Daemon (Client) d\'etermine les fichiers \`a sauvegarder pour une -incr\'ementale par comparaison de l'heure de d\'emarrage du Job pr\'ec\'edent -(Full, Diff\'erentiel ou Incr\'emental) avec les dates de derni\`ere modification -de chaque fichier (st\_mtime) et de ses attributs (st\_ctime). Si le fichier -ou ses attributs ont chang\'es depuis cette date de d\'emarrage, alors le fichier -sera sauvegard\'e. - -Veuillez noter que certains logiciels anti-virus peuvent modifier la date -st\_time lors de leurs op\'erations de scan. Ainsi, si l'antivirus modifie -la date d'acc\`es (st\_atime), qui n'est pas utilis\'ee par Bacula, il -provoquera une modification du st\_ctime et conduira Bacula \`a sauvegarder -les fichiers concern\'es lors des incr\'ementales et diff\'erentielles. Dans le -cas de l'antivirus Sophos, vous pouvez \'eviter cet inconv\'enient en utilisant -l'option {\bf \verb{--{no-reset-atime}. Pour les autres logiciels, voyez -leurs manuels. - -Lorsque Bacula effectue une sauvegarde incr\'ementale, tous les fichiers modifi\'es -pr\'esents sur le syst\`eme sont sauvegard\'es. Cependant, tout fichier supprim\'e depuis -la derni\`ere Full demeure dans le catalogue, ce qui signifie que si vous effectuez -une restauration \`a partir de sauvegardes incr\'ementales (et de la Full associ\'ee), -les fichiers supprim\'es depuis la derni\`ere Full seront aussi restaur\'es. Ces fichiers -n'appara\^itront plus dans le catalogue apr\`es avoir fait une nouvelle sauvegarde -Full. Le processus pour supprimer ces fichiers du catalogue lors d'une -incr\'ementale ralentirait fortement les sauvegardes incr\'ementales. Il n'est -actuellement pas impl\'ement\'e dans Bacula. - -De plus, si vous d\'eplacez un r\'epertoire plut\^ot que de le copier, les fichiers qu'il -contient voient leurs dates de derni\`ere modification (st\_mtime) et de dernier acc\`es -(st\_ctime) inchang\'es. Par cons\'equent, ces fichiers ne seront probablement -sauvegard\'es par aucune incr\'ementale ou diff\'erentielle, puisque ces derni\`eres -ne se r\'ef\`erent qu'\`a ces indicateurs. Aussi, il est pr\'ef\'erable de copier un dossier -avant de supprimer l'original plut\^ot que de le d\'eplacer, si vous voulez qu'il soit -correctement sauvegard\'e. - -\item [Differential] - \index[dir]{Differential} - Tous les fichiers modifi\'es depuis la derni\`ere sauvegarde Full valide du FileSet - sp\'ecifi\'e pour le m\^eme job. Si le Director ne peut trouver une sauvegarde Full - ant\'erieure, le niveau du job sera \'elev\'e en une sauvegarde Full. Lorsque le - Director recherche une Full valide dans le catalogue, il recherche un job avec - les caract\'eristiques suivantes : - -\begin{itemize} -\item le m\^eme nom de job ; -\item le m\^eme nom de client ; -\item le m\^eme FileSet (toute modification de la d\'efinition du FileSet telle - que l'ajout ou la suppression de fichiers dans les sections Include ou - Exclude constitue un changement de FileSet). -\item le Job \'etait une sauvegarde FULL -\item le Job s'est termin\'e normalement, c'est \`a dire qu'il ne s'est pas termin\'e - en \'echec, et n'a pas \'et\'e effac\'e. -\end{itemize} - -Si toutes les conditions ci-dessus ne sont pas r\'ealis\'ees, le Director -augmentera la sauvegarde diff\'erentielle en une sauvegarde Full. Dans le cas -contraire, la sauvegarde diff\'erentielle sera effectu\'ee normalement. - -Le File Daemon (Client) d\'etermine les fichiers \`a sauvegarder pour une -diff\'erentielle par comparaison de l'heure de d\'emarrage de la derni\`ere -sauvegarde Full avec les dates de derni\`ere modification -de chaque fichier (st\_mtime) et de ses attributs (st\_ctime). Si le fichier -ou ses attributs ont chang\'es depuis cette date de d\'emarrage, alors le fichier -sera sauvegard\'e. La date de d\'emarrage utilis\'ee est affich\'e apr\`es le {\bf Since} -du rapport de Job. Dans de rares cas, certains fichiers sont sauvegard\'es deux fois -\`a cause de l'utilisation de la date de d\'emarrage de la sauvegarde pr\'ec\'edente, -mais ceci assure qu'aucun changement n'est perdu. Comme pour les incr\'ementales, -vous devriez vous assurer que les horloges de votre serveur Bacula et de vos clients -sont synchronis\'ees, ou aussi proches que possible, pour \'eviter le risque d'omission -d'un fichier. Notez qu'\`a partir de la version 1.33, Bacula effectue automatiquement -ces ajustements de sorte que les horloges utilis\'ees par Bacula soient synchrones. - -Veuillez noter que certains logiciels anti-virus peuvent modifier la date -st\_time lors de leurs op\'erations de scan. Ainsi, si l'antivirus modifie -la date d'acc\`es (st\_atime), qui n'est pas utilis\'ee par Bacula, il -provoquera une modification du st\_ctime et conduira Bacula \`a sauvegarder -les fichiers concern\'es lors des incr\'ementales et diff\'erentielles. Dans le -cas de l'antivirus Sophos, vous pouvez \'eviter cet inconv\'enient en utilisant -l'option {\bf \verb{--{no-reset-atime}. Pour les autres logiciels, voyez -leurs manuels. - -Lorsque Bacula effectue une sauvegarde diff\'erentielle, tous les fichiers modifi\'es -pr\'esents sur le syst\`eme sont sauvegard\'es. Cependant, tout fichier supprim\'e depuis -la derni\`ere Full demeure dans le catalogue, ce qui signifie que si vous effectuez -une restauration \`a partir de sauvegardes diff\'erentielles (et de la Full associ\'ee), -les fichiers supprim\'es depuis la derni\`ere Full seront aussi restaur\'es. Ces fichiers -n'appara\^itront plus dans le catalogue apr\`es avoir fait une nouvelle sauvegarde -Full. Le processus pour supprimer ces fichiers du catalogue lors d'une -incr\'ementale ralentirait fortement les sauvegardes diff\'erentielles. Il n'est -actuellement pas impl\'ement\'e dans Bacula, mais plannifi\'e pour une future version -de Bacula. - -Comme not\'e ci-dessus, si vous d\'eplacez un r\'epertoire plut\^ot que de le copier, les fichiers -qu'il contient voient leurs dates de derni\`ere modification (st\_mtime) et de dernier acc\`es -(st\_ctime) inchang\'es. Par cons\'equent, ces fichiers ne seront probablement -sauvegard\'es par aucune incr\'ementale ou diff\'erentielle, puisque ces derni\`eres -ne se r\'ef\`erent qu'\`a ces indicateurs. Aussi, il est pr\'ef\'erable de copier un dossier -avant de supprimer l'original plut\^ot que de le d\'eplacer, si vous voulez qu'il soit -correctement sauvegard\'e. - -R\'eguli\`erement, quelqu'un demande \`a quoi servent les sauvegardes diff\'erentielles -du moment que les incr\'ementales r\'ecup\`erent tous les fichiers modifi\'es. Il existe -plusieurs r\'eponses \`a cette question, mais la plus importante \`a mes yeux est de -combiner toutes les incr\'ementales et diff\'erentielles depuis la derni\`ere full en -une seule diff\'erentielle. Ceci a deux effets : 1. La redondance. 2. Plus important, -la r\'eduction du nombre de volumes requis pour faire une restauration en -\'eliminant la n\'ecessit\'e de lire tous les volumes des pr\'ec\'edentes incr\'ementales -depuis la derni\`ere full. - -\end{description} - -Pour un Job de type {\bf Restore}, aucun niveau ne doit \^etre sp\'ecifi\'e. - -Pour un Job de type {\bf Verify}, le niveau peut \^etre l'un des suivants : - -\begin{description} - -\item [InitCatalog] - \index[dir]{InitCatalog} - Examine le {\bf FileSet} sp\'ecifi\'e et stocke les attributs de fichiers dans le - catalogue. Vous pouvez vous interroger sur l'int\'er\^et d'un Job qui ne - sauvegarde aucun fichier. La r\'eponse est de pouvoir utiliser Bacula comme - vous utiliseriez Tripwire, en d'autres termes, ce type de Jobs vous permet - de sauvegarder l'\'etat d'un ensemble de fichiers d\'efini par un {\bf FileSet} - afin de pouvoir ult\'erieurement contr\^oler si rien n'a \'et\'e modifi\'e, supprim\'e ou - ajout\'e. Ceci peut \^etre utilis\'e pour d\'etecter une intrusion. Typiquement, - vous sp\'ecifiez un {\bf FileSet} qui contient l'ensemble des fichiers qui ne - devraient pas changer (par exemple /sbin, /boot, /lib, /bin, ...). Ensuite, - vous ex\'ecutez le Job verify de niveau {\bf InitCatalog} apr\`es l'installation - de votre syst\`eme, puis apr\`es chaque modification (mise \`a jour). Ensuite, - lorsque vous souhaitez contr\^oler l'\'etat de votre syst\`eme de fichiers, - vous utilisez un Job {\bf Verify}, {\bf level = Catalog} afin de comparer - le r\'esultat de votre {\bf InitCatalog} avec l'\'etat actuel de votre syst\`eme - de fichiers. - -\item [Catalog] - \index[dir]{Catalog} - Compare l'\'etat actuel des fichiers et l'\'etat pr\'ec\'edemment sauvegard\'e - lors d'un {\bf InitCatalog}. Toutes les anomalies sont rapport\'ees. - Les objets du rapport sont d\'etermin\'es par les options {\bf verify} - sp\'ecifi\'ees dans la directive {\bf Include} du {\bf FileSet} sp\'ecifi\'e - (voyez la ressource {\bf FileSet} ci-dessous pour plus de d\'etails). - Typiquement, cette commande sera ex\'ecut\'ee quotidiennement pour - contr\^oler toute modification de votre syst\`eme de fichier. - -Attention ! Si vous ex\'ecutez deux jobs Verify Catalog simultan\'ement sur le m\^eme client, -les r\'esultats seront probablement erronn\'es. En effet, Verify Catalog modifie -le catalogue lors de son ex\'ecution afin de d\'etecter les nouveaux fichiers. - -\item [VolumeToCatalog] - \index[dir]{VolumeToCatalog} - Ce niveau permet de lire les attributs de fichiers \'ecrits sur le Volume - lors du dernier Job. Les attributs de fichiers sont compar\'es aux valeurs - sauvegard\'ees dans le catalogue et toute diff\'erence est rapport\'ee. Ceci - est similaire au niveau {\bf Catalog}, sauf que ce sont les - attributs des fichiers du volume plut\^ot que ceux des fichiers du disque - qui sont compar\'es aux attributs sauvegard\'es dans le catalogue. Bien que - les attributs et signatures (MD5 ou SHA1) soient compar\'es, les donn\'ees - r\'eelles ne le sont pas (elles ne figurent pas dans le catalogue). - -Attention ! Si vous ex\'ecutez deux jobs Verify VolumeToCatalog simultan\'ement sur le m\^eme client, -les r\'esultats seront probablement erronn\'es. En effet, Verify VolumeToCatalog modifie -le catalogue lors de son ex\'ecution afin de d\'etecter les nouveaux fichiers. - -\item [DiskToCatalog] - \index[dir]{DiskToCatalog} - Ce niveau permet de lire les fichiers tels qu'ils sont actuellement sur le - disque et de comparer leurs attributs actuels avec ceux stock\'es dans le - catalogue lors de la derni\`ere sauvegarde pour le Job sp\'ecifi\'e par la - directive {\bf VerifyJob}. Ce niveau diff\`ere du niveau {\bf Catalog} - d\'ecrit plus haut en ce qu'il ne se r\'ef\`ere pas \`a un Job Verify ant\'erieur, - mais \`a la derni\`ere sauvegarde. Lorsque vous utilisez ce niveau , vous devez - renseigner les option Verify de la section Include. Ces options d\'eterminent - quels attributs seront compar\'es. - -Cette commande peut se r\'ev\'eler tr\`es utile si vous avez des probl\`emes de disque -car elle comparera l'\'etat actuel de votre disque avec la derni\`ere sauvegarde -valide, qui peut remonter \`a plusieurs jobs. - -Notez que l'impl\'ementation actuelle (1.32c) n'identifie pas les fichiers qui -ont \'et\'e supprim\'es. -\end{description} - -\item [Verify Job = \lt{}Job-Resource-Name\gt{}] - \index[dir]{Verify Job} - \index[dir]{Directive!Verify Job} - Si vous ex\'ecutez un job verify sans cette directive, le dernier job - ex\'ecut\'e sera compar\'e avec le catalogue, ce qui signifie que votre commande - verify doit succ\'eder imm\'ediatement \`a une sauvegarde. Si vous sp\'ecifiez - un {\bf Verify Job}, Bacula trouvera le dernier job ex\'ecut\'e avec ce nom. - Ceci vous permet d'ex\'ecuter toutes vos sauvegardes, puis d'ex\'ecuter les jobs - Verify sur les sauvegardes de votre choix (le plus souvent, un {\bf VolumeToCatalog} - de sorte que la cartouche qui vient juste d'\^etre \'ecrite est relue). - -\item [JobDefs = \lt{}JobDefs-Resource-Name\gt{}] - \index[dir]{JobDefs} - \index[dir]{Directive!JobDefs} - Si un nom de JobDef est sp\'ecifi\'e dans la d\'efinition d'un Job, toutes les valeurs - d\'efinies dans la ressource JobDef concern\'ee seront utilis\'ees en tant que valeurs - par d\'efaut pour le Job. Toute valeur explicitement sp\'ecifi\'ee dans la - d\'efinition du Job outrepasse la valeur par d\'efaut d\'efinie par le JobDef. - L'utilisation de cette directive permet d'\'ecrire des ressources Job plus - compactes, o\`u la majeure partie des directives sont d\'efinies dans un ou - plusieurs JobDefs. C'est particuli\`erement pratique si vous avez de nombreux - Jobs similaires avec des variations mineures telles que diff\'erents clients. - Un exemple basique de l'utilisation d'un Jobdef est fourni dans le fichier - bacula-dir.conf par d\'efaut. - -\item [Bootstrap = \lt{}bootstrap-file\gt{}] - \index[dir]{Bootstrap} - \index[dir]{Directive!Bootstrap} - La directive Bootstrap sp\'ecifie un fichier bootstrap qui, s'il est fourni, - sera utilis\'e lors des restaurations et ignor\'e par tout les autres Jobs. - Le fichier {\bf bootstrap} contient la liste des cartouches n\'ecessaires - pour la restauration ainsi que les index des fichiers \`a restaurer - (localisation sur la cartouche). Cette directive - est optionnelle, et n'est utilis\'ee que pour les restaurations. De plus, - elle peut \^etre modifi\'ee lorsqu'une restauration est lanc\'ee depuis la console. - -Si vous utilisez la commande {\bf Restore} dans la console pour lancer une -restauration, le fichier {\bf bootstrap} sera cr\'e\'e automatiquement \`a partir des -fichiers que vous avez s\'electionn\'es pour la restauration. - -Pour plus de d\'etails concernant les fichiers {\bf bootstrap}, veuillez -consulter le chapitre \ilink{Restaurer des fichiers avec le fichier Bootstrap}{_ChapterStart43} -de ce manuel. - -\label{writebootstrap} -\item [Write Bootstrap = \lt{}bootstrap-file-specification\gt{}] - \index[dir]{Write Bootstrap} - \index[dir]{Directive!Write Bootstrap} - La directive {\bf writebootstrap} sp\'ecifie le de fichier Bootstrap o\`u Bacula - \'ecrira lors de chaque sauvegarde. Ainsi, cette directive s'applique - exclusivement aux jobs de type sauvegarde. Si la sauvegarde est une Full, - Bacula \'ecrase le contenu du fichier sp\'ecifi\'e. Sinon, Bacula ajoute les - nouveaux enregistrements Bootstrap \`a la fin du fichier. - -En utilisant cette fonction, vous aurez constamment un fichier bootstrap -capable de recouvrer l'\'etat le plus r\'ecent de votre syst\`eme. Le fichier -bootstrap devrait \^etre \'ecrit sur un disque mont\'e sur une autre machine, de -sorte que vous puissiez en disposer imm\'ediatement en cas de d\'efaillance -de votre disque dur. Une alternative consiste \`a copier le fichier sur une autre -machine apr\`es chaque mise \`a jour. - -Si la {\bf sp\'ecification de fichier bootstrap} d\'ebute par une barre verticale (|), -Bacula consid\`ere la sp\'ecification comme un nom de programme vers lequel les -les enregistrement bootstrap seront redirig\'es. Ce peut \^etre, par exemple, un -script qui vous envoie par e-mail les enregistrements bootstrap. - -A partir de la version 1.40, Bacula effectue des -\ilink{character substitution}{substitution de caracteres} comme dans une directive -RunScript. Pour g\'erer automatiquement vos fichiers bootstrap, vous pouvez utiliser -ceci dans vos {\bf JobDefs} : - -\begin{verbatim} -JobDefs { - Write Bootstrap = "%c_%n.bsr" - ... -} -\end{verbatim} - -Pour plus de d\'etails sur l'utilisation de fichiers bootstrap, veuillez -consulter le chapitre intitul\'e \ilink{Le Fichier Bootstrap}{_ChapterStart43} -de ce manuel. - - -\item [ Client = \lt{}client-resource-name\gt{}] - \index[dir]{Client} - \index[dir]{Directive!Client} - La directive Client sp\'ecifie le Client (File Daemon) \`a utiliser dans le Job. - Le client est ex\'ecut\'e sur la machine \`a sauvegarder. Il exp\'edie les fichiers requis - au Storage Daemon lors des sauvegardes, et re\c {c}oit les fichiers du Storage Daemon - lors des restaurations. Pour plus de d\'etails, consultez la section - \ilink{Ressource Client}{ClientResource2} de ce chapitre. Cette deirective est requise. - - -\item [ FileSet = \lt{}FileSet-resource-name\gt{}] - \index[dir]{FileSet} - \index[dir]{FileSet} - La directive FileSet sp\'ecifie le FileSet \`a utiliser dans le Job concern\'e. Le - FileSet d\'efinit les r\'epertoires et fichiers \`a sauvegarder, ainsi que les options - \`a utiliser pour les sauvegarder (par exemple la compression,...). Un Job ne peut - contenir qu'un seul FileSet. Pour plus de d\'etails, consultez la section - \ilink{Ressource FileSet}{FileSetResource} de ce chapitre. - Cette directive est requise. - -\item [ Messages = \lt{}messages-resource-name\gt{}] - \index[dir]{Messages} - \index[dir]{Directive!Messages} - La directive Messages d\'efinit la ressource Message qui doit \^etre utilis\'ee - pour le job concern\'e. Ainsi, elle d\'etermine le comment et o\`u seront - d\'elivr\'es les diff\'erents messages de Bacula. Par exemple, vous pouvez diriger - certains messages vers un fichier de logs, tandis que d'autres seront - envoy\'es par e-mail. Pour plus de d\'etails, consultez le chapitre - \ilink{Ressource Messages}{_ChapterStart15} de ce manuel. Cette directive - est requise. - -\item [ Pool = \lt{}pool-resource-name\gt{}] - \index[dir]{Pool} - \index[dir]{Directive!Pool} - La directive Pool sp\'ecifie le jeu de volumes qui doit \^etre utilis\'e pour - sauvegarder vos donn\'ees. De nombreuses installations de Bacula - n'utiliseront que le pool d\'efini par d\'efaut {\bf Default}. Toutefois, - si vous voulez sp\'ecifier diff\'erents jeux de volumes pou diff\'erents clients - ou diff\'erents jobs, vous voudrez probablement utiliser les Pools. - Pour plus de d\'etails, consultez la section \ilink{Ressource Pool}{PoolResource} - de ce chapitre. Cette directive est requise - -\item [ Full Backup Pool = \lt{}pool-resource-name\gt{}] - \index[dir]{Full Backup Pool} - \index[dir]{Directive!Full Backup Pool} - La directive {\it Full Backup Pool} sp\'ecifie un Pool \`a utiliser pour les - sauvegardes Full. Cette directive outrepasse toute autre sp\'ecification - de Pool lors d'une sauvegarde Full. Cette directive est optionnelle. - -\item [ Differential Backup Pool = \lt{}pool-resource-name\gt{}] - \index[dir]{Differential Backup Pool} - \index[dir]{Directive!Differential Backup Pool} - La directive {\it Differential Backup Pool} sp\'ecifie un Pool \`a utiliser pour les - sauvegardes Diff\'erentielles. Cette directive outrepasse toute autre sp\'ecification - de Pool lors d'une sauvegarde Diff\'erentielle. Cette directive est optionnelle. - -\item [ Incremental Backup Pool = \lt{}pool-resource-name\gt{}] - \index[dir]{Incremental Backup Pool} - \index[dir]{Directive!Differential Backup Pool} - La directive {\it Incremental Backup Pool} sp\'ecifie un Pool \`a utiliser pour les - sauvegardes Incr\'ementales. Cette directive outrepasse toute autre sp\'ecification - de Pool lors d'une sauvegarde Incr\'ementale. Cette directive est optionnelle. - -\item [ Schedule = \lt{}schedule-name\gt{}] - \index[dir]{Schedule} - \index[dir]{Directive!Schedule} - La directive Schedule d\'efinit la planification du job. Le {\it schedule} d\'etermine - la date et l'instant o\`u le job doit \^etre lanc\'e automatiquement, et le niveau - (Full, Diff\'erentiel, Incr\'emental...) du job en question. Cette directive est - optionnelle. Si elle est omise, le job ne pourra \^etre ex\'ecut\'e que manuellement via - la Console. Bien que vous puissiez vous contenter d'une ressource Schedule simple - pour tout job, vous pouvez aussi d\'efinir des ressources Schedule avec plusieurs - directives {\bf Run}, afin de lancer le job \`a diff\'erentes heures. Chacune de ces - directives {\bf Run} permet d'outrepasser les valeurs par d\'efaut de Level, Pool, - Storage et Messages ressources. Ceci autorise une grande souplesse d'utilisation - d'un simple job. - Pour plus de d\'etails, consultez le chapitre. - \ilink{Ressource Schedule}{ScheduleResource} de ce manuel. - -\item [ Storage = \lt{}storage-resource-name\gt{}] - \index[dir]{Storage} - \index[dir]{Directive!Storage} - La directive Storage d\'efinit le nom du service storage que vous souhaitez - utiliser pour sauvegarder les donn\'ees du FileSet. Pour plus de d\'etails, consultez le - chapitre \ilink{Ressource Storage}{StorageResource2} de ce manuel. - Cette directive est requise. - -\item [ Max Start Delay = \lt{}time\gt{}] - \index[sd]{Max Start Delay} - \index[dir]{Directive!Max Start Delay} - La directive Max Start Delay sp\'ecifie le d\'elai maximal entre l'horaire - planifi\'e (dans le schedule) et l'horaire effectif de d\'emarrage du job. - Par exemple, un job peut \^etre programm\'e pour d\'emarrer \`a 1h, mais \^etre - mis en attente \`a cause d'autres jobs en cours d'ex\'ecution. Si le - Max Start Delay a \'et\'e r\'egl\'e \`a 3600, le job sera supprimm\'e s'il n'a pas - d\'emarr\'e \`a 2h. Ceci peut se r\'ev\'eler utile pour, par exemple, \'eviter qu'un job - s'ex\'ecute duant les heures ouvrables. La valeur par d\'efaut est 0 (pas de limite). - -\item [ Max Run Time = \lt{}time\gt{}] - \index[sd]{Max Run Time} - \index[dir]{Directive!Max Run Time} - La directive Max Run Time sp\'ecifie le d\'elai allou\'e pour l'ex\'ecution - compl\`ete d'un job depuis son lancement (pas n\'ecessairement \`a l'heure - de sa programmation) jusqu'\`a sa fin. Cette directive est impl\'ement\'ee - depuis la version 1.33. - -\item [ Max Wait Time = \lt{}time\gt{}] - \index[sd]{Max Wait Time} - \index[dir]{Directive!Max Wait Time} - La directive Max Wait Time sp\'ecifie le d\'elai maximum durant lequel un - job peut rester bloqu\'e en attente d'une ressource (par exemple, en attente du - montage d'une cartouche ou encore en attente des Storage ou File Daemon occup\'es - \`a d'autres tâches) depuis son lancement (pas n\'ecessairement \`a l'heure - de sa programmation) jusqu'\`a sa fin. Cette directive est impl\'ement\'ee - depuis la version 1.33. - -\item [Incremental Max Wait Time = \lt{}time\gt{}] - \index[dir]{Incremental Max Wait Time} - \index[dir]{Directive!Incremental Max Wait Time} - Cette directive sp\'ecifie le temps maximum durant lequel une sauvegarde - incr\'ementale peut rester bloqu\'ee en attente d'une ressource (par exemple, en - attente d'une cartouche ou des File ou Storage daemons), compt\'e \`a partir - du d\'emarrage du job, ({\bf pas n\'ecessairement} l'heure \`a laquelle le job - a \'et\'e programm\'e). Notez que si un {\bf Max Wait Time} a \'et\'e sp\'ecifi\'e, - il peut aussi s'appliquer au job. - -\item [Differential Max Wait Time = \lt{}time\gt{}] - \index[dir]{Differential Max Wait Time} - \index[dir]{Directive!Differential Max Wait Time} - Cette directive sp\'ecifie le temps maximum durant lequel une sauvegarde - diff\'erentielle peut rester bloqu\'ee en attente d'une ressource (par exemple, en - attente d'une cartouche ou des File ou Storage daemons), compt\'e \`a partir - du d\'emarrage du job, ({\bf pas n\'ecessairement} l'heure \`a laquelle le job - a \'et\'e programm\'e). Notez que si un {\bf Max Wait Time} a \'et\'e sp\'ecifi\'e, - il peut aussi s'appliquer au job. - -\item [Prefer Mounted Volumes = \lt{}yes|no\gt{}] - \index[dir]{Prefer Mounted Volumes} - \index[dir]{Directive!Differential Max Wait Time} - Si cette directive est activ\'ee (c'est le cas par d\'efaut), le Director - ordonne au Storage daemon de s\'electionner de pr\'ef\'erence soit une - librairie, soit un lecteur avec un volume valide d\'ej\`a mont\'e, plut\^ot qu'un - lecteur pas pr\`et. Si aucun lecteur n'est pr\`et, c'est le premier lecteur - pr\`et qui sera s\'electionn\'e. - - Si cette directive est d\'esactiv\'ee, le Storage daemon privil\'egiera - les lecteurs inutilis\'es. Ce mode de fonctionnement peut \^etre tr\`es utile - pour ces sites avec de nombreux lecteurs qui o\`u il peut \^etre pr\'ef\'erable - de maximiser le flux des sauvegardes au prix d'une utilisation d'un plus - grand nombre de lecteurs et de cartouches. Afin d'optimiser l'utilisation - de plusieurs lecteurs, vous voudrez probablement lancer chacun de vos - jobs l'un apr\`es l'autre avec un intervalle de 5 secondes environ. Ceci - aidera \`a assurer que chaque nuit, le m\^eme lecteur (volume) est - s\'electionn\'e pour le m\^eme job. Autrement, lors d'une restauration, vous - pourriez trouver vos fichiers dispers\'es sur beaucoup plus de volumes que - n\'ecessaire. - -\item [ Prune Jobs = \lt{}yes|no\gt{}] - \index[dir]{Prune Jobs} - \index[dir]{Directive!Prune Jobs} - En principe, l'\'elagage des jobs du catalogue est sp\'ecifi\'e pour chaque client - dans sa propre ressource Client par la directive {\bf AutoPrune}. Si cette - directive est sp\'ecifi\'ee (normalement, non) et si la valeur est {\bf yes}, - elle outrepasse la valeur sp\'ecifi\'ee dans la ressource Client. La valeur - par d\'efaut est {\bf no}. - -\item [ Prune Files = \lt{}yes|no\gt{}] - \index[dir]{Prune Files} - \index[dir]{Directive!Prune Jobs} - En principe, l'\'elagage des fichiers du catalogue est sp\'ecifi\'e pour chaque client - dans sa propre ressource Client par la directive {\bf AutoPrune}. Si cette - directive est sp\'ecifi\'ee (normalement, non) et si la valeur est {\bf yes}, - elle outrepasse la valeur sp\'ecifi\'ee dans la ressource Client. La valeur - par d\'efaut est {\bf no}. - -\item [ Prune Volumes = \lt{}yes|no\gt{}] - \index[dir]{Prune Volumes} - \index[dir]{Directive!Prune Jobs} - En principe, l'\'elagage des volumes du catalogue est sp\'ecifi\'e pour chaque client - dans sa propre ressource Client par la directive {\bf AutoPrune}. Si cette - directive est sp\'ecifi\'ee (normalement, non) et si la valeur est {\bf yes}, - elle outrepasse la valeur sp\'ecifi\'ee dans la ressource Client. La valeur - par d\'efaut est {\bf no}. - -\item [RunScript \{...\}] - \index[dir]{RunScript} - \index[dir]{Directive!Run Script} - - La commande sp\'ecifi\'ee est ex\'ecut\'ee en tant que programme externe avant le - lancement du job. Cette directive est optionnelle. - Vous disposez des options suivantes : \\ - -\begin{tabular}{|c|c|c|l} -Options & Valeur & Defaut & Informations \\ -\hline -\hline -Runs On Success & Yes/No & {\it Yes} & La commande est ex\'ecut\'ee si le job s'est termin\'e avec succ\`es\\ -\hline -Runs On Failure & Yes/No & {\it No} & La commande est ex\'ecut\'ee si le job a \'echou\'e\\ -\hline -Runs On Client & Yes/No & {\it Yes} & La commande est ex\'ecut\'ee sur le client\\ -\hline -Runs When & Before|After|Always & {\it Never} & Le moment o\`u la commande doit \^etre ex\'ecut\'ee\\ -\hline -Abort Job On Error & Yes/No & {\it Yes} & Abandonne le job si le script retourne - un r\'esultat non nul\\ -\hline -Command & & & Le chemin vers votre script\\ -\hline -\end{tabular} - Tout retour de la commande sur la sortie standard est - incluse dans le rapport de job de Bacula. La cha\^ine {bf command} doit \^etre - un nom de programme valide ou un script shell - - D'autre part, - la cha\^ine {bf command} est parcourue puis envoy\'ee vers la fonction execvp(), ce qui - signifie que le chemin de la commande est recherch\'e pour son ex\'ecution, mais - qu'il n'y a aucune interpr\'etation shell. Par cons\'equent, si vous voulez utiliser - des commandes complexes ou toute fonctionnalit\'e du shell telle que la - redirection, vous devez appeler un script shell o\`u vous mettrez vos commandes. - - Avant de soumettre la commande sp\'ecifi\'ee au syst\`eme d'exploitation, Bacula - effectue les substitutions suivantes : - -\label{character substitution} - -\footnotesize -\begin{verbatim} - %% = % - %c = Nom du client - %d = Nom du Director - %e = Statut de sortie du job - %i = JobId - %j = Nom unique du job - %l = Niveau du job - %n = Nom du job - %s = Temps Depuis (NDT : Since Time) - %t = Type de job (Backup,...) - %v = Nom de volume -\end{verbatim} -\normalsize - -Le code de statut de fin de job peut prendre les valeurs suivantes : - -\index[dir]{Exit Status} -\begin{itemize} -\item OK -\item Error -\item Fatal Error -\item Canceled -\item Differences -\item Unknown term code -\end{itemize} - - Aussi, si vous l'utilisez dans une ligne de commande, il vous faudra l'encadrer - de quotes. - -Vous disposez des raccourcis suivants :\\ -\begin{tabular}{|c|c|c|c|c|c} -Mot clef & RunsOnSuccess & RunsOnFailure & AbortJobOnError & Runs On Client & RunsWhen \\ -\hline -Run Before Job & & & Yes & No & Before \\ -\hline -Run After Job & Yes & No & & No & After \\ -\hline -Run After Failed Job & No & Yes & & No & After \\ -\hline -Client Run Before Job & & & Yes & Yes & Before \\ -\hline -Client Run After Job & Yes & No & & Yes & After \\ -\hline -Client Run After Failed Job & No & Yes & & Yes & After \\ -\end{tabular} - -Exemple : -\begin{verbatim} -RunScript { - RunsWhen = Before - AbortJobOnError = No - Command = "/etc/init.d/apache stop" -} - -RunScript { - RunsWhen = After - RunsOnFailure = yes - Command = "/etc/init.d/apache start" -} -\end{verbatim} - -{\bf Consid\'erations particuli\`eres \`a Windows} - D'autre part, pour les clients Windows \`a partir de la version 1.33, notez bien - que vous devez fournir un chemin correct pour votre script, et que le script - peut avoir l'extension .com, .exe, ou .bat. Si vous sp\'ecifiez un chemin, - vous devez aussi sp\'ecifier l'extension compl\`ete. Les commandes \`a la fa\c{c}on - d'Unix ne fonctionneront pas, \`a moins que vous n'ayez install\'e et - correctement configur\'e Cygwin en plus (et s\'epar\'ement) de Bacula. - -La commande peut \^etre n'importe quel programme reconnu par cmd.exe ou command.com -comme un fichier ex\'ecutable. Sp\'ecifier une extension de fichier ex\'ecutable -est optionnel, \`a moins qu'il y ait une ambigu\"it\'e (par exemple ls.bat, ls.exe). - -Bacula cherche la commande dans le r\'epertoire "System \%Path\%" (Dans la -bo\^ite de dialogue des variables d'environnement vous avez les variables -"syst\`eme" et "utilisateurs". Si bacula-fd fonctionne en tant que -service, seules les variables d'environnement syst\`emes sont accessibles.) - -Les variables d'environnement syst\`eme peuvent \^etre invoqu\'ees avec la -syntaxe \%var\% et utilis\'ees comme portion du nom de la commande ou des -arguments. - -Lorsque la sp\'ecification du chemin absolu d'un ex\'ecutable ou le nom de -l'ex\'ecutable contient des espaces ou des caract\`eres sp\'eciaux, ils doivent -\^etre quot\'es. Il en va de m\^eme pour les arguments. - -\footnotesize -\begin{verbatim} -ClientRunBeforeJob = "\"C:/Program Files/Software - Vendor/Executable\" /arg1 /arg2 \"foo bar\"" -\end{verbatim} -\normalsize - -Les caract\`eres sp\'eciaux \&()[]\{\}\^{}=;!'+,`\^u devront \^etre quot\'es s'ils font -partie d'un nom de fichier ou d'un argument. - - -If someone is logged in a blank ``command'' window running the commands will -be present during the execution of the command. - -Quelques suggestions de Phil Stracchino pour l'ex\'ecution sur les machines -Win32 avec le File Daemon Win32 natif : - -\begin{enumerate} -\item Vous pourriez utiliser la directive ClientRunBeforeJob pour sp\'ecifier - un fichier .bat qui ex\'ecute les commandes cot\'e client plut\^ot que - d'essayer d'ex\'ecuter (par exemple) regedit /e directement. -\item Le fichier batch devrait retourner explicitement 0 lors des ex\'ecutions correctes. -\item Le chemin vers le fichier batch devrait \^etre sp\'ecifi\'e au format Unix : - - ClientRunBeforeJob = ``c:/bacula/bin/systemstate.bat'' - -plut\^ot qu'au format DOS/Windows : - -ClientRunBeforeJob = -``c:\textbackslash{}bacula\textbackslash{}bin\textbackslash{}systemstate.bat'' -INCORRECT -\end{enumerate} - -L'exemple suivant d'utilisation de la directive Client Run Before Job a \'et\'e soumis -par un utilisateur :\\ -Vous pourriez \'ecrire un script shell pour sauvegarder une base DB2 dans un FIFO. Voici -le script en question : - -\footnotesize -\begin{verbatim} - #!/bin/sh - # ===== backupdb.sh - DIR=/u01/mercuryd - - mkfifo $DIR/dbpipe - db2 BACKUP DATABASE mercuryd TO $DIR/dbpipe WITHOUT PROMPTING & - sleep 1 -\end{verbatim} -\normalsize - -La ligne suivante dans la ressource Job du fichier bacula-dir.conf : -\footnotesize -\begin{verbatim} - Client Run Before Job = "su - mercuryd -c \"/u01/mercuryd/backupdb.sh '%t' -'%l'\"" -\end{verbatim} -\normalsize - -Lorsque le job est ex\'ecut\'e, vous obtiendrez un message de sortie du script -annon\c{c}ant que la sauvegarde a d\'emarr\'e. M\^eme si la commande est ex\'ecut\'ee en -arri\`ere plan avec \&, le job bloquera jusqu'\`a la commande "db2 BACKUP DATABASE", et -la sauvegarde se fige. - -Pour rem\'edier \`a cette situation, la ligne "db2 BACKUP DATABASE" -devrait \^etre modifi\'ee en : - -\footnotesize -\begin{verbatim} - db2 BACKUP DATABASE mercuryd TO $DIR/dbpipe WITHOUT PROMPTING > $DIR/backup.log -2>&1 < /dev/null & -\end{verbatim} -\normalsize - -Il est important de rediriger l'entr\'ee et la sortie d'une commande en arri\`ere plan -vers /dev/null pour \'eviter le bloquage du script. - -\item [ Run Before Job = \lt{}command\gt{}] - \index[dir]{Run Before Job} - \index[dir]{Directive!Run Before Job} - La commande sp\'ecifi\'ee est ex\'ecut\'ee en tant que programme externe avant le - lancement du job. Cette directive n'est pas requise,mais si elle est d\'efinie, - et si le code retour d'ex\'ecution du programme est diff\'erent de z\'ero, le job qui - a lanc\'e le programme est effac\'e. - -\begin{verbatim} -Run Before Job = "echo test" -\end{verbatim} - est \'equivalent \'a : -\begin{verbatim} -RunScript { - Command = "echo test" - RunsOnClient = No - RunsWhen = Before -} -\end{verbatim} - -Lutz Kittler a fait remarquer que ceci peut \^etre un moyen ais\'e pour modifier -vos schedules pour les vacances. Par exemple, supposons que vous fassiez -habituellement des sauvegardes Full le vendredi, mais que jeudi et vendredi -soient f\'eri\'es. Pour \'eviter d'avoir \`a changer les cartouches entre jeudi et vendredi -alors que personne n'est au bureau, vous pouvez cr\'eer un RunBeforeJob qui retourne -un statut non nul jeudi et z\'ero les autres jours. Ainsi, le job de jeudi ne sera pas -ex\'ecut\'e, et la cartouche que vous avez ins\'er\'e mercredi sera disponible pour la Full -de vendredi. - -\item [ Run After Job = \lt{}command\gt{}] - \index[dir]{Run After Job} - \index[dir]{Directive!Run After Job} - La commande sp\'ecifi\'ee est ex\'ecut\'ee en tant que programme externe apr\`es la fin - du job. La cha\^ine {bf command} doit \^etre un nom de programme valide ou un - script shell. Cette directive n'est pas requise. Si le code de sortie du - programme est non nul, Bacula affiche un message d'avertissement (warning). - Avant de soumettre - la commande sp\'ecifi\'ee au syst\`eme d'exploitation, Bacula effectue les - substitutions de caract\`eres d\'ecrites au paragraphe {\bf RunScript} - -Un exemple d'utilisation de cette directive est donn\'e au chapitre -\ilink{Astuces}{JobNotification} de ce manuel. -Lisez le paragraphe {\bf Run After Failed Job} si vous voulez ex\'ecuter -une commande lorqu'un job se termine avec un statut anormal. - -\item [Run After Failed Job = \lt{}command\gt{}] - \index[dir]{Run After Job} - \index[dir]{Directive!Run After Job} - La commande sp\'ecifi\'ee est ex\'ecut\'ee en tant que programme externe apr\`es la fin - du job lorqu'il se termine avec un statut d'erreur. Cette directive est optionnelle. - La cha\^ine {\bf command} doit \^etre le nom d'un programme ou d'un script shell. - Si le code de sortie du programme est non nul, Bacula affiche un mesage d'avertissement - (warning). Avant de soumettre - la commande sp\'ecifi\'ee au syst\`eme d'exploitation, Bacula effectue les - substitutions de caract\`eres d\'ecrites au paragraphe {\bf RunScript}. Notez que - vous pouvez, si vous souhaitez que - votre programme soit ex\'ecut\'e quel que soit l'issue du job, utiliser une d\'efinition - telle que : - -RunScript { - Command = "echo test" - RunsWhen = After - RunsOnFailure = yes - RunsOnClient = no - RunsOnSuccess = yes \# default, you can drop this line -} - - Le chapitre \ilink{Trucs et astuces}{JobNotification} de ce manuel propose un - exemple d'utilisation de cette directive. - -\item [ Client Run Before Job = \lt{}command\gt{}] - \index[dir]{Client Run Before Job} - \index[dir]{Directive!Client Run Before Job} - Cette directive est similaire \`a {\bf Run Before Job} except\'e que la - commande est ex\'ecut\'ee sur la machine cliente. Les m\^emes restrictions - s'appliquent aux syt\`emes Unix que celles signal\'ees pour {\bf Run Before Job}. - -\item [ Client Run After Job = \lt{}command\gt{}] - \index[dir]{Client Run After Job} - \index[dir]{Directive!Client Run After Job} - Cette directive est similaire \`a {\bf Run After Job} sauf qu'elle est ex\'ecut\'ee - sur la machine cliente. Veuillez consulter les notes concernant les clients - Windows dans le paragraphe {\bf RunScript} ci-dessus. - -\item [ Rerun Failed Levels = \lt{}yes|no\gt{}] - \index[dir]{Rerun Failed Levels} - \index[dir]{Directive!Rerun Failed Levels} - Si la valeur de cette directive est {\bf yes} ({\bf no} par d\'efaut), et si - Bacula d\'etecte qu'un job ant\'erieur d'un niveau plus \'elev\'e (Full ou - diff\'erentiel), alors le job est \'elev\'e au niveau le plus haut. Ceci est - particuli\`erement utile pour sauvegarder les pc portables qui peuvent - \^etre fr\'equemment inaccessibles. En effet, apr\`es l'\'echec d'une Full, vous - souhaiterez probablement que la prochaine sauvegarde soit de niveau Full - plut\^ot qu'Incremental ou Diff\'erentiel. - -\item [ Spool Data = \lt{}yes|no\gt{}] - \index[dir]{Spool Data} - \index[dir]{Directive!Spool Data} - Si la valeur de cette directive est {\bf yes} ({\bf no} par d\'efaut), le - Storage Daemon aura pour consigne de stocker les donn\'ees dans un - fichier spoule sur disque plut\^ot que de les \'ecrire directement sur bande. - Lorsque toutes les donn\'ees sont dans le spoule ou lorsque la taille - maximale fix\'ee pour le fichier spoule est atteinte, les donn\'ees sont - d\'echarg\'ees du spoule vers les bandes. Lorsque la valeur de cette directive - est {\bf yes}, la directive Spool Attributes est aussi automatiquement - mise \`a la valeur {\bf yes}. L'utilisation de cette fonctionnalit\'e - pr\'evient les arr\^ets et red\'emarrage incessants lors des incr\'ementales. - Elle ne doit pas \^etre utilis\'ee si vous sauvegardez sur disque. - - -\item [ Spool Attributes = \lt{}yes|no\gt{}] - \index[dir]{Spool Attributes} - \index[dir]{Directive!Spool Attributes} - \index[dir]{lenteur} - \index[general]{lent} - \index[dir]{Sauvegardes!lent} - \index[general]{Sauvegardes!lent} - La valeur par d\'efaut est {\bf no}, ce qui signifie que le Storage Daemon - envoie les attributs de fichiers au Director au moment o\`u ils (les fichiers) - sont ecrits sur la bande. Cependant, si vous souhaitez \'eviter le risque - de ralentissement d\^u aux mises \`a jour du catalogue, vous pouvez r\'egler - cette directive \`a {\bf yes}, dans ce cas, le Storage Daemon stockera les - attributs de fichiers dans un fichier tampon du Working Directory pour ne les - transmettre au Director qu'\`a la fin de l'\'ecriture sur bande des donn\'ees du job. - -\item [ Where = \lt{}directory\gt{}] - \index[dir]{Where} - \index[dir]{Directive!Where} - Cette directive ne concerne que les jobs de type Restauration. Elle permet - de sp\'ecifier un pr\'efixe au nom du r\'epertoire o\`u tous les fichiers sont - restaur\'es. Ceci permet de restaurer les fichiers en un emplacement - diff\'erent de celui o\`u ils ont \'et\'e sauvegard\'es. Si {\bf Where} n'est pas - renseign\'e, ou si sa valeur est backslash ({\bf /}), les fichiers sont - restaur\'es \`a leur emplacement d'origine. Par d\'efaut, nous avons donn\'e \`a - {\bf Where} la valeur {\bf /tmp/bacula-restores} dans les fichiers de - configuration fournis en exemple, ceci afin d'\'eviter l'\'ecrasement - accidentel de vos fichiers. - -\item [ Replace = \lt{}replace-option\gt{}] - \index[dir]{Replace} - \index[dir]{Directive!Replace} - Cette directive ne concerne que les jobs de type Restauration. Elle pr\'ecise - la conduite \`a adopter dans l'\'eventualit\'e o\`u Bacula serait conduit \`a restaurer - un fichier ou un r\'epertoire qui existe d\'ej\`a. Les options suivantes sont - disponibles : - -\begin{description} - -\item [always] - \index[dir]{always } - Lorsque le fichier \`a restaurer existe d\'ej\`a, il est supprim\'e et remplac\'e par la - copie sauvegard\'ee. - -\item [ifnewer] - \index[dir]{ifnewer } - Si le fichier sauvegard\'e (sur bande) est plus r\'ecent que le fichier existant, - le fichier existant est supprim\'e et remplac\'e par la copie sauvegard\'ee. - -\item [ifolder] - \index[dir]{ifolder } - Si le fichier sauvegard\'e (sur bande) est plus ancien que le fichier existant, - le fichier existant est supprim\'e et remplac\'e par la copie sauvegard\'ee. - -\item [never] - \index[dir]{never } - Si le fichier sauvegard\'e existe d\'ej\`a, Bacula renonce \`a restaurer ce fichier. -\end{description} - -\item [ Prefix Links=\lt{}yes|no\gt{}] - \index[dir]{Prefix Links} - \index[dir]{Directive!Prefix Links} - Si la valeur de cette directive est {\bf Yes} et si un pr\'efixe de chemin - {\bf Where} est sp\'ecifi\'e, alors ce dernier s'applique aussi aux liens - absolus. La valeur par d\'efaut est {\bf No}. Lorsque cette directive est \`a - {\bf Yes}, tous les liens absolus seront aussi modifi\'es pour - pointer vers le nouveau r\'epertoire. En principe, c'est ce qui est souhait\'e : - l'ensemble du r\'epertoire restaur\'e conserve sa coh\'erence interne. Cependant, - si vous voulez replacer les fichiers ult\'erieurement \`a leurs emplacements - d'origine, tous les liens absolus seront bris\'es. - -\item [ Maximum Concurrent Jobs = \lt{}number\gt{}] - \index[dir]{Maximum Concurrent Jobs} - \index[dir]{Directive!Maximum Concurrent Jobs} - O\`u \lt{}number\gt{} est le nombre maximum de jobs de la ressource Job courrante - qui peuvent \^etre ex\'ecut\'es simultan\'ement. Notez que cette directive ne limite - que les jobs avec le m\^eme nom que la ressource dans laquelle elle - figure. Toute autre restriction du nombre maximum de jobs simultan\'es, que ce soit au - niveau du Director, du Client ou de la ressource Storage, s'applique en plus de - de la limite stipul\'ee ici. La valeur par d\'efaut est 1, mais vous pouvez utiliser - une valeur plus grande. Nous vous recommandons fortement de lire - attentivement le paragraphe WARNING sous \ilink{ Maximum Concurrent Jobs}{DirMaxConJobs} - dans la section concernant la ressource Director. - -\item [ Reschedule On Error = \lt{}yes|no\gt{}] - \index[dir]{Reschedule On Error} - \index[dir]{Directive!Reschedule On Error} - Si cette directive est activ\'ee, alors si le job se termine en erreur, il sera - reprogramm\'e en accord avec les directives {\bf Reschedule Interval} et - {\bf Reschedule Times}. Si vous supprimez le job, il ne sera pas reprogramm\'e. - La valeur par d\'efaut est {\bf no}. - -Cette sp\'ecification peut se r\'ev\'eler utile pour les pc portables ainsi que pour toutes -les machines qui ne sont pas connect\'ees au r\'eseau en permanence. - -\item [ Reschedule Interval = \lt{}time-specification\gt{}] - \index[dir]{Reschedule Interval} - \index[dir]{Directive!Reschedule Interval} - Si cette directive est activ\'ee, alors si le job se termine en erreur, il sera - reprogramm\'e apr\`es l'intervalle de temps stipul\'e par {\bf time-specification}. - Consultez la section \ilink{ the time specification formats}{Time} du chapitre - Configurer Bacula pour plus de d\'etails sur les sp\'ecifications de temps. Si - aucun intervalle n'est sp\'ecifi\'e, le job ne sera pas reprogramm\'e en cas d'erreur. - -\item [ Reschedule Times = \lt{}count\gt{}] - \index[dir]{Reschedule Times} - \index[dir]{Directive!Reschedule Times} - Cette directive pr\'ecise le nombre maximal de tentatives d'ex\'ecution du job. - S'il est fix\'e \`a z\'ero (valeur par d\'efaut), le job sera reprogramm\'e - ind\'efiniment. - -\item [Run = \lt{}job-name\gt{}] - \index[dir]{Run} - \index[dir]{Directive!Run} - \index[dir]{Cloner un Job} - La directive Run (\`a ne pas confondre avec l'option Run dans un - Schedule) vous permet de d\'emarrer ou de cloner des jobs. En utilisant les - mots-clef de clonage (voir ci dessous), vous pouvez sauvegarder les m\^emes - donn\'ees (ou presque les m\^emes) vers deux (ou plus) lecteurs en m\^eme temps. - Le nom de job {\bf job-name} est en principe le m\^eme que celui de la - ressource job courante (cr\'eant ainsi un clone). Cependant, ce peut \^etre - n'importe quel nom de job, de sorte qu'un job peut d\'emarrer d'autre jobs li\'es. - La partie apr\`es le signe \'egale doit \^etre encadr\'ee de double quotes, et peut - contenir toute cha\^ine ou jeu d'options (surcharges) qui pourraient \^etre - sp\'ecifi\'ees \`a l'utilisation de la commande Run dans la Console. Par exemple, - {\bf storage=DDS-4 ...}. De plus, deux mots-clef sp\'eciaux vous permettent de - cloner le job courant : {\bf level=\%l} et {\bf since=\%s}. le \%l du mot clef - level permet d'entrer le niveau r\'eel du job courant et le \%s du mot clef since - permet d'imposer la m\^eme date pour la comparaison que celle utilis\'ee par le job courant.a - Notez que dans le cas du mot-clef since, le \%s doit \^etre encadr\'e de double quotes, - qui doivent \^etre elles m\^emes pr\'ec\'ed\'ees de barres obliques arri\`eres puisque elles sont - d\'ej\`a entre double quotes. Par exemple : - - \begin{verbatim} - run = "Nightly-backup level=%s since=\"%s\" storage=DDS-4" - \end{verbatim} - Un job clon\'e ne d\'emarrera pas de nouveaux clones, aussi il n'est pas possible de les cascader. - -\label{Priority} -\item [ Priority = \lt{}number\gt{}] - \index[dir]{Priority} - \index[dir]{Directive!Priority} - Cette directive vous permet de contr\^oler l'ordre d'ex\'ecution des jobs en - sp\'ecifiant un entier positif non nul. Plus grand est ce nombre, plus basse - est la priorit\'e du job. En supposant que vous n'ex\'ecutiez pas de jobs - simultan\'es, tous les jobs en file d'attente avec la priorit\'e 1 seront - ex\'ecut\'es avant ceux avec la priorit\'e 2, et ainsi de suite, sans prise en - compte de l'ordre original de planification. - - La priorit\'e affecte seulement les jobs en file d'attente, et non les jobs d\'eja - en cours d'ex\'ecution. Si un ou plusieurs jobs de priorit\'e 2 sont d\'ej\`a en cours - d'ex\'ecution, et si un nouveau job est programm\'e avec la priorit\'e 1, les jobs - en cours d'ex\'ecution doivent se terminer pour que le job de priorit\'e 1 puisse - d\'emarrer. - - La priorit\'e par d\'efaut est 10. - -Si vous voulez ex\'ecutez plusieurs jobs simultan\'es, -vous devriez garder les points suivants \`a l'esprit : - -\begin{itemize} -\item Pour ex\'ecuter plusieurs jobs simultan\'es, vous devez ajuster la directive - {\bf Maximum Concurrent Jobs} (utiliser une valeur sup\'erieure \'a 1) - en cinq ou six endroits diff\'erents : dans le - fichier bacula-dir.conf, les ressources {\bf Job}, {\bf Client}, {\bf Storage}; - dans le fichier bacula-fd, la ressource {\bf FileDaemon}; et dans le fichier - bacula-sd.conf, la ressource {\bf Storage}. Si vous omettez l'un d'entre eux, - les jobs seront ex\'ecut\'es un par un. -\item Bacula n'ex\'ecute pas simultan\'ement les jobs de priorit\'es distinctes. -\item Si Bacula ex\'ecute un job de priorit\'e 2 et si un nouveau job de priorit\'e - 1 est programm\'e, il attendra la fin du job de priorit\'e 1, m\^eme si les - param\`etres {\bf Maximum Concurrent Jobs} pourraient permettre l'ex\'ecution - simultan\'ee de deux jobs. -\item Supposons que Bacula soit en train d'ex\'ecuter un job de priorit\'e 2 et qu'un - job de priorit\'e 1 soit programm\'e et mis en queue en attente de la fin du - job de priorit\'e 2. Si vous d\'emarrez alors un second job de priorit\'e 2, le job - en attente de priorit\'e 1 emp\`echera le nouveau job de priorit\'e 2 de s'ex\'ecuter - en parall\`ele au premier. Ainsi : tant qu'il reste un job de priorit\'e sup\'erieure - \`a ex\'ecuter, aucun nouveau job de priorit\'e inf\'erieure ne pourra d\'emarrer, m\^eme si - les param\`etres {\bf Maximum Concurrent Jobs} devraient le permettre. Ceci permet - d'assurer que les jobs de priorit\'e sup\'erieure seront ex\'ecut\'es d\`es que possible. -\end{itemize} - -Si vous avez plusieurs jobs de priorit\'es diff\'erentes, il est pr\'ef\'erable de ne pas les -d\'emarrer exactement \`a la m\^eme heure, car Bacula doit les examiner un \`a la fois. Si, -par hazard, Bacula commence par traiter un job de priorit\'e inf\'erieure, il sera -ex\'ecut\'e avant votre job de priorit\'e \'elev\'e. Pour \'eviter cette situation, -d\'emarrez l'un quelconque des jobs de priorit\'e \'elev\'ee quelques secondes avant -ceux de basse priorit\'e. Ainsi, vous serez assur\'e que Bacula examine les jobs -dans l'ordre voulu et que votre sch\'ema de priorit\'es sera respect\'e. - -\label{WritePartAfterJob} - -\item [ Write Part After Job = \lt{}yes|no\gt{}] - \index[sd]{Write Part After Job} - \index[dir]{Directive!Write Part After Job} -Cette directive est impl\'ement\'ee depuis la version 1.37. -Si la valeur de cette directive est {\bf yes} ({\bf no} par d\'efaut), un nouveau -"fichier partition" (ndt : part file) sera cr\'e\'e apr\`es la fin du job. - -Cette directive devrait \^etre activ\'ee lors de l'\'ecriture sur des p\'eriph\'erique -qui requi\`erent un montage (par exemple, les DVDs), afin de vous assurer que -le fichier partition courant, celui qui contient les donn\'ees de ce job, est -envoy\'e vers le p\'eriph\'erique, et qu'aucune donn\'ee n'est laiss\'ee dans le fichier -temporaire sur le disque dur. Quoi qu'il en soit, avec certains supports tels -que les DVD+R et DVD-R, beaucoup d'espace (environ 10 Mb) est perdu \`a chaque fois -qu'un fichier partition est \'ecrit. Aussi, si vous ex\'ecutez plusieurs jobs \`a la -suite, vous devriez r\'egler cette directive \`a {\bf no} pour tous ces jobs sauf -le dernier, pour \'eviter un gaspillage important d'espace, tout en ayant la certitude -que les donn\'ees sont bien \'ecrites sur le m\'edium lorsque tous les jobs sont -achev\'es. - -Cette directive est ignor\'ee avec les bandes et les p\'eriph\'eriques FIFO. -\end{description} - -Voici un exemple de d\'efinition de ressource Job valide. - -\footnotesize -\begin{verbatim} -Job { - Name = "Minou" - Type = Backup - Level = Incremental # default - Client = Minou - FileSet="Minou Full Set" - Storage = DLTDrive - Pool = Default - Schedule = "MinouWeeklyCycle" - Messages = Standard -} -\end{verbatim} -\normalsize - -\subsection*{La ressource JobDefs} -\label{JobDefsResource} -\index[general]{JobDefs Resource } -\index[general]{Resource!JobDefs } -\addcontentsline{toc}{subsection}{JobDefs Resource} - -La ressource Jobdefs admet toutes les directives qui peuvent appara\^itre dans -une ressource Job. Une ressource Jobdefs ne cr\'e\'e en aucun cas un Job, son r\^ole -est de pouvoir \^etre d\'esign\'ee dans une ressource Job comme un ensemble de -param\`etres par d\'efaut. Ceci permet de d\'efinir plusieurs jobs similaires avec -concision, en ne mentionnant, pour chaque job, que les diff\'erences avec les -valeurs par d\'efaut sp\'ecifi\'ees dans la ressource Jobdefs. - -\subsection*{La ressource Schedule} -\label{ScheduleResource} -\index[general]{Resource!Schedule } -\index[general]{Schedule Resource } -\addcontentsline{toc}{subsection}{Schedule Resource} - -La ressource Schedule offre un moyen pour planifier automatiquement un Job, -mais aussi la possibilit\'e de surcharger les param\`etres par d\'efaut de Level, -Pool, Storage, et Messages ressources. Si une ressource Schedule n'est pas -sp\'ecifi\'ee dans un job, ce job ne peut \^etre ex\'ecut\'e que manuellement. -En g\'en\'eral, vous sp\'ecifierez une action et le moment de son lancement. - -\begin{description} - -\item [Schedule] - \index[dir]{Schedule} - \index[dir]{Directive!Schedule} - D\'ebut des directives Schedule. La ressource {\bf Schedule} n'est pas requise, - mais il vous en faudra au moins une si vous souhaitez que vos jobs soient - ex\'ecut\'es automatiquement. - -\item [Name = \lt{}name\gt{}] - \index[dir]{Name} - \index[dir]{Directive!Name} - Le nom du Schedule d\'efini. Cette directive est requise. - -\item [Run = \lt{}Job-overrides\gt{} \lt{}Date-time-specification\gt{} ] - \index[dir]{Run} - \index[dir]{Directive!Run} - La directive Run d\'efinit quand un job doit \^etre ex\'ecut\'e, et les \'eventuelles - surcharges \`a appliquer. Il est possible de sp\'ecifier plusieurs directives - {\bf run} au sein d'une ressource {\bf Schedule}, elles seront toutes - appliqu\'ees. Si vous avez deux directives {\bf Run} qui d\'emarrent au m\^eme - moment, deux jobs seront lanc\'es simultan\'ement (en fait, avec une seconde d'\'ecart). - - -La directive {\bf Job-overrides} permet d'outrepasser les sp\'ecifications de -Level, Storage, Messages et Pool \'ecrites dans la ressource Job. De plus, -les sp\'ecifications FullPool, DifferentialPool et IncrementalPool permettent -de passer outre les sp\'ecification de Pool, en accord avec le niveau (level) -effectif d'ex\'ecution du job. - -L'utilisation de surcharges permet de peaufiner le param\'etrage d'un job -particulier. Par exemple, vous pourriez surcharger une sp\'ecification -Messages qui enverrait vos logs de backups vers un fichier, de fa\c {c}on \`a ce qu'ils -vous soient envoy\'es par mails pour les Fulls hebdomadaires ou mensuelles. - -Les directives {\bf Job-overrides} sont sp\'ecifi\'ees en tant que {\bf mot-clef=valeur} -o\`u le mot-clef est l'un des suivants : Level, Storage, Messages, Pool, FullPool, -DifferentialPool ou IncrementalPool, et la {\bf valeur} est d\'efinie selon le format -adapt\'e \`a la directive. Vous pouvez sp\'ecifier plusieurs surcharges {\bf Job-overrides} -en une seule directive {\bf Run} en les s\'eparant par des espaces ou des -trailing comas (traduction ?). Par exemple : - -\begin{description} - -\item [Level=Full] - \index[dir]{Level} - \index[dir]{Directive!Level} - Tous les fichiers du FileSet qu'ils aient ou non chang\'e. - -\item [Level=Incremental] - \index[dir]{Level} - \index[dir]{Directive!Level} - Tous les fichiers qui ont chang\'e depuis la derni\`ere sauvegarde. - -\item [Pool=Weekly] - \index[dir]{Pool} - \index[dir]{Directive!Pool} - Sp\'ecifie l'utilisation du Pool nomm\'e {\bf Weekly}. - -\item [Storage=DLT\_Drive] - \index[dir]{Storage } - \index[dir]{Directive!Storage} - Sp\'ecifie l'utilisation du lecteur {\bf DLT\_Drive} pour p\'eriph\'erique de stockage. - -\item [Messages=Verbose] - \index[dir]{Messages } - \index[dir]{Directive!Messages} - Sp\'ecifie l'utilisation de la ressource messages {\bf Verbose} pour le job. - -\item [FullPool=Full] - \index[dir]{FullPool} - \index[dir]{Directive!FullPool} - - Sp\'ecifie l'utilisation du Pool nomm\'e {\bf Full} si le job est une sauvegarde Full, - ou s'il a \'et\'e \'elev\'e en Full bien qu'ayant \'et\'e lanc\'e en tant que diff\'erentiel ou - incr\'emental. - -\item [DifferentialPool=Differential] - \index[dir]{DifferentialPool } - \index[dir]{Directive!DifferentialPool} - Sp\'ecifie l'utilisation du Pool nomm\'e {\bf Differential} si le job est une - sauvegarde diff\'erentielle. - -\item [IncrementalPool=Incremental] - \index[dir]{IncrementalPool} - \index[dir]{Directive!IncrementalPool} - Sp\'ecifie l'utilisation du Pool nomm\'e {\bf Incremental} si le job est une - sauvegarde incr\'ementale. - -\item [SpoolData=yes|no] - \index[dir]{SpoolData} - \index[dir]{Directive!SpoolData} - Indique \`a Bacula d'ordonner au Storage Daemon de placer les donn\'ees sur un - spool disque avant de les envoyer vers les cartouches. - -\item [WritePartAfterJob=yes|no] - \index[dir]{WritePartAfterJob} - \index[dir]{Directive!WritePartAfterJob} - Indique \`a Bacula d'ordonner au Storage Daemon d'\'ecrire le fichier partition - courant vers le p\'eriph\'erique lorsque le job s'ach\`eve (voir -\ilink{la directive Write Part After Job dans la ressource Job}{WritePartAfterJob}). -\end{description} - -{\bf Date-time-specification} D\'etermine la planification d'ex\'ecution du job. -La sp\'ecification est une r\'ep\'etition, et, par d\'efaut, Bacula est param\'etr\'e -pour ex\'ecuter un job au d\'ebut de chaque heure de chaque jour de chaque semaine -de chaque mois de chaque ann\'ee. Ce n'est probablement pas ce que vous souhaitez, -aussi vous devez pr\'eciser ou limiter les moments o\`u vous souhaitez voir vos jobs -ex\'ecut\'es. Toute sp\'ecification est suppos\'ee cyclique et servira \`a limiter le -cycle par d\'efaut. Ceci se fait en sp\'ecifiant des masques ou des horaires, -jours de la semaine, jours du mois, semaines du mois, semaines de l'ann\'ee et -mois de l'ann\'ee o\`u vous voulez ex\'ecuter le job. En combinant ces possibilit\'es, -vous pouvez d\'efinir une planification qui se r\'ep\`ete \`a presque n'importe quelle -fr\'equence. - -Concr\`etement, vous devez d\'efinir les {\bf mois}, {\bf jour}, {\bf heure} et -{\bf minute} o\`u le job est \`a ex\'ecuter. Parmis ces quatre objets, le {\bf jour} -est particulier en ce qu'il peut sp\'ecifier un jour du mois (1,2,...31) ou de la -semaine (Monday, Tuesday,...Sunday). Enfin, vous pouvez aussi sp\'ecifier un -jour de la semaine pour restreindre la planification \`a la premi\`ere, deuxi\`eme, -troisi\`eme, quatri\`eme ou cinqui\`eme semaine du mois. - -Par exemple, si vous sp\'ecifiez seulement un jour de la semaine, disons {\bf Mardi}, -le job sera ex\'ecut\'e toutes les heures de chaque mardi de chaque mois. La raison -en est que les param\`etres {\bf Mois} et {\bf Heure} sont rest\'es \`a leurs valeurs -par d\'efaut : chaque mois et chaque heure. - -Notez que, par d\'efaut, sans autre sp\'ecification, votre job s'ex\'ecutera au -d\'ebut de chaque heure. Si vous souhaitez que votre job s'ex\'ecute plus souvent -qu'une fois par heure, il vous faudra d\'efinir plusieurs sp\'ecifications {\bf run} -avec pour chacune une minut diff\'erente. - -Les dates et horaires d'ex\'ecutions des jobs peuvent \^etre sp\'ecifi\'es comme suit, -en pseudo-BNF : - -\footnotesize -\begin{verbatim} - = on - = at - = 1st | 2nd | 3rd | 4th | 5th | first | - second | third | forth | fifth - = sun | mon | tue | wed | thu | fri | sat | - sunday | monday | tuesday | wednesday | - thursday | friday | saturday - = w00 | w01 | ... w52 | w53 - = jan | feb | mar | apr | may | jun | jul | - aug | sep | oct | nov | dec | january | - february | ... | december - = daily - = weekly - = monthly - = hourly - = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 - = | -<12hour> = 0 | 1 | 2 | ... 12 - = 0 | 1 | 2 | ... 23 - = 0 | 1 | 2 | ... 59 - = 1 | 2 | ... 31 -