From: Kern Sibbald Date: Thu, 13 Dec 2007 15:09:15 +0000 (+0000) Subject: Remove old German manual X-Git-Tag: Release-3.0.0~2149 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=e8256363fafb5509a3843b7d57186f35c413333a;p=bacula%2Fdocs Remove old German manual --- diff --git a/docs/manual-de/Makefile.in b/docs/manual-de/Makefile.in deleted file mode 100644 index 6648329a..00000000 --- a/docs/manual-de/Makefile.in +++ /dev/null @@ -1,149 +0,0 @@ -# -# -# Makefile for LaTeX -# -# To build everything do -# make tex -# make web -# make html -# make dvipdf -# -# or simply -# -# make -# -# for rapid development do: -# make tex -# make show -# -# -# If you are having problems getting "make" to work, debugging it is -# easier if can see the output from latex, which is normally redirected -# to /dev/null. To see it, do the following: -# -# cd docs/manual -# make tex -# latex bacula.tex -# -# typically the latex command will stop indicating the error (e.g. a -# missing \ in front of a _ or a missing { or ] ... -# -# The following characters must be preceded by a backslash -# to be entered as printable characters: -# -# # $ % & ~ _ ^ \ { } -# - -IMAGES=../images - -first_rule: bacula - -bacula: tex web dvipdf mini-clean - -.SUFFIXES: .tex .html -.PHONY: -.DONTCARE: - - -tex: - @./update_version - @echo "Making version `cat version.tex`" - @cp -fp ${IMAGES}/hires/*.eps . - @touch baculai-dir.tex baculai-fd.tex baculai-sd.tex \ - baculai-console.tex baculai-general.tex - latex -interaction=batchmode bacula.tex - makeindex bacula.idx -o bacula.ind 2>/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 3 -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-de/ansi-labels.tex b/docs/manual-de/ansi-labels.tex deleted file mode 100644 index 7769d448..00000000 --- a/docs/manual-de/ansi-labels.tex +++ /dev/null @@ -1,60 +0,0 @@ - -\chapter{ANSI und IBM Tape Labels} -\label{AnsiLabelsChapter} -\index[general]{ANSI und IBM Tape Labels} -\index[general]{Labels!Tape} - -Wenn Bacula entsprechend konfiguriert wird, unterst\"{u}tzt es ANSI und IBM Tape Labels. -Mit der richtigen Konfiguration, kann man Bacula sogar zwingen, -nur noch ANSI oder IBM Labels zu verwenden. - -Bacula kann ein ANSI oder IBM Tape Label erstellen, aber wenn Check Labels -konfiguriert ist (siehe unten), wird Bacula versuchen ein existierendes Tape Label zu finden, -und dieses dann verwenden. -Sie k\"{o}nnen die Tape Labels also mit anderen Programmen erstellen -und Bacula wird diese Labels erkennen und damit arbeiten. - -Obwohl Bacula ANSI und IBM Tape Labels erkennen und auch schreiben kann, -wird es immer auch ein eigenes Tape Label erzeugen. - -Wenn ANSI oder IBM Tape Labels verwenden werden, -d\"{u}rfen die Volume Namen nicht mehr als 6 Zeichen beinhalten. - -Wenn Sie Ihre Volumes nicht mit Bacula gelabelt haben, dann wird -das ANSI oder IBM Tape Label nur von Bacula erkannt, wenn Sie das -HDR1 Label mit {\bf BACULA.DATA} im Dateinamen (beginnend mit -dem 5. Zeichen) erzeugt haben. Wenn Bacula das Tape Label schreibt, -werden diese Informationen genutzt um das Tape als Bacula Tape zu erkennen. -Dieses erm\"{o}glicht Tapes mit ANSI oder IBM Labels mit unterschiedlichen Backupprogrammen zu benutzen. - - -\section{Director Pool Konfiguration} - -\begin{description} -\item [ Label Type = ANSI | IBM | Bacula] - Diese Direktive ist in der Director Pool und in der SD Device Konfiguration g\"{u}ltig. - Wenn sie in der SD Device Konfiguration angegeben wird, hat sie Vorrang vor dem, - was der Director dem SD \"{u}bergibt. - Der Standardwert ist Label Type = Bacula. -\end{description} - -\section{Storage Daemon Device Konfiguration} - -\begin{description} -\item [ Label Type = ANSI | IBM | Bacula] - Diese Direktive ist in der Director Pool und in der SD Device Konfiguration g\"{u}ltig. - Wenn sie in der SD Device Konfiguration angegeben wird, hat sie Vorrang vor dem, - was der Director dem SD \"{u}bergibt. - Der Standardwert ist Label Type = Bacula. - -\item [Check Labels = yes | no] - Diese Direktive ist in der SD Device Konfiguration g\"{u}ltig. - Wenn Sie beabsichtigen, ANSI oder IBM Tape Labels zu lesen, *muss* - sie auf yes gesetzt sein. Auch wenn das Volume kein ANSI oder IBM Label hat, - kann diese Direktive auf yes gesetzt werden, - Bacula wird dann den Typ des Tape Labels automatisch \"{u}berpr\"{u}fen. - Wird sie nicht auf yes gesetzt, wird Bacula annehmen, dass das Volume - mit einem Bacula Tape Label versehen ist, - eine Überpr\"{u}fung auf ANSI oder IBM Tape Labels finden dann nicht statt. - Der Standardwert ist Check Labels = no. - \end{description} diff --git a/docs/manual-de/autochangerres.tex b/docs/manual-de/autochangerres.tex deleted file mode 100644 index 4a322d4e..00000000 --- a/docs/manual-de/autochangerres.tex +++ /dev/null @@ -1,110 +0,0 @@ -\subsection*{Autochanger-Konfiguration} -\label{AutochangerRes} -\index[sd]{Autochanger-Konfiguration } -\index[sd]{Konfiguration!Autochanger } -\addcontentsline{toc}{subsection}{Autochanger-Konfiguration} - -In der Autochanger-Konfiguration k\"{o}nnen Autochanger mit einzelnen oder mehreren Laufwerken angelegt werden, -indem eine oder mehrere Ger\"{a}tekonfigurationen zu einer Einheit, die Bacula Autochanger nennt, -gruppiert werden. (Autochangerherrsteller nennen so etwas auch "Tape Library") - -Damit Ihr Autochanger korrekt funktioniert, -{\bf m\"{u}ssen} Sie eine Autochanger-Konfiguration in der Konfigurationsdatei -des Storage-Dienstes erstellen und in der Konfiguration des Director-Dienstes -{\bf muss} ein entsprechender Storage-Eintrag auf den Autochanger-Namen -in der Storage-Dienst-Konfiguration verweisen. -In fr\"{u}heren Bacula-Versionen verwies die Autochanger-Konfiguration des -Director-Dienstes direkt auf Ger\"{a}te-Konfigurationen des Storage-Dienstes. -Seit Version 1.38.0 ist es nicht mehr m\"{o}glich, aus einer Autochanger-Konfiguration des Director-Dienstes, -direkt auf die Autochanger-Ger\"{a}te zu verweisen. - -\begin{description} -\item [Name = \lt{}Autochanger-Name\gt{}] - \index[sd]{Name} - die Angabe des Autochanger-Namens. Dieser Name wird in der Director-Storage-Definition benutzt um auf den - Autochanger zu verweisen. - Die Konfiguration des Namens ist zwingend erforderlich. - -\item [Device = \lt{}Device-name1, device-name2, ...\gt{}] - die Angabe eines oder mehrerer Ger\"{a}te-Namen, die den Device-Eintr\"{a}gen der Laufwerke - des Autochangers entsprechen. - Wenn Ihr Autochanger mehrere Laufwerke hat, m\"{u}ssen Sie auch mehrere Ger\"{a}te-Namen angeben, - jeweils einen f\"{u}r jede Ger\"{a}te-Konfiguration, die einem Laufwerk des Autochangers entspricht. - Sie k\"{o}nnen mehrere Ger\"{a}te-Namen durch Kommas getrennt in einer Zeile, - oder mehrere Device-Eintr\"{a}ge angeben. - Die Konfiguration der Ger\"{a}te-Namen ist zwingend erforderlich. - -\item [Changer Device = {\it Bezeichner}] - \index[sd]{Changer Device} - der angegebene {\bf Bezeichner} entspricht dem Ger\"{a}te-Namen des Autochangers (nicht der Laufwerke) - der durch das Betriebssystem vergeben wird. - Wenn der Ger\"{a}te-Name hier konfiguriert wird, braucht er nicht mehr in den Device-Eintr\"{a}gen der Laufwerke - angegeben werden. - Wenn der Ger\"{a}te-Name auch in den Device-Eintr\"{a}gen angegeben wird, - hat der dortige Eintrag Vorrang vor der Angabe in der Autochanger-Konfiguration. - -\item [Changer Command = {\it Bezeichner}] - \index[sd]{Changer Command } - der angegebene {\bf Bezeichner} gibt das zu verwendende externe Programm an, - dass Bacula aufruft, um automatisch Volumes zu wechseln. Meistens wird hier - das mit Bacula zur Verf\"{u}gung gestellte {\bf mtx-changer} angegeben. - Wenn der Kommando-Name hier konfiguriert wird, braucht er nicht mehr in den Device-Eintr\"{a}gen der Laufwerke - angegeben werden. - Wenn der Kommando-Name auch in den Device-Eintr\"{a}gen angegeben wird, - hat der dortige Eintrag Vorrang vor der Angabe in der Autochanger-Konfiguration. -\end{description} - -Das Folgende ist ein Beispiel einer g\"{u}ltigen Autochanger-Konfiguration: - -\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 - -Bitte beachten Sie dass es wichtig ist, dass {\bf Autochanger = yes} in allen Device-Eintr\"{a}gen -angegeben wird die zum Autochanger geh\"{o}ren. -Ein Device-Eintrag darf nie zu mehr als einem Autochanger geh\"{o}ren. -Au{\ss}erdem darf die Storage-Konfiguration des Director-Dienstes nur auf die Autochanger-Konfiguration -zeigen und nicht auf die Device-Eintr\"{a}ge. - -Wenn Sie ein Laufwerk des Autochangers nicht automatisch durch Bacula benutzen lassen wollen, -z.B. um immer ein freies Laufwerk f\"{u}r R\"{u}cksicherungen zu haben, -k\"{o}nnen Sie folgendes dem entsprechenden Device-Eintrag hinzuf\"{u}gen: - -\footnotesize -\begin{verbatim} -Autoselect = no -\end{verbatim} -\normalsize - -In diesem Fall wird Bacula das Laufwerk nicht mehr automatisch ausw\"{a}hlen, wenn es auf den Autochanger zugreift. -Sie k\"{o}nnen das Laufwerk weiterhin benutzen, indem Sie direkt den Device-Namen ansprechen, -anstatt des Autochangers. -Ein Beispiel einer solchen Konfiguration sehen Sie oben bei dem Device-Eintrag DDS-4-3. -Diese Laufwerk wird nicht benutzt werden, wenn der Autochanger-Name DDS-4-changer als Storage-Definition -genutzt wird, es l\"{a}sst sich aber direkt, mit entsprechenden Storage-Konfigurations-Eintrag im Director-Dienst, -als Storage DDS-4-3 ansprechen. diff --git a/docs/manual-de/autochangers.tex b/docs/manual-de/autochangers.tex deleted file mode 100644 index d9d1b789..00000000 --- a/docs/manual-de/autochangers.tex +++ /dev/null @@ -1,916 +0,0 @@ -%% -%% - -\chapter{Autochanger Unterst\"{u}tzung} -\label{AutochangersChapter} -\index[general]{Unterst\"{u}tzung!Autochanger } -\index[general]{Autochanger Unterst\"{u}tzung } - -Bacula unterst\"{u}tzt Autochanger zum Lesen und Schreiben von Tapes. -Damit Bacula mit einem Autochanger arbeiten kann, m\"{u}ssen einige Voraussetzungen erf\"{u}llt sein, -die Details werden im folgenden gekl\"{a}rt. - -\begin{itemize} -\item Ein Script das den Autochanger, gem\"{a}{\ss} den von Bacula gesendeten Kommandos, steuert. - Bacula stellt solch ein Script in der {\bf depkgs} Distribution zur Verf\"{u}gung. - -\item Jedes Volume (Tape) das benutzt wird, muss sowohl im Katalog definiert sein, - als auch eine Slotnummer zugeteilt sein, nur so kann Bacula wissen, welches Volume - aktuell im Autochanger verf\"{u}gbar ist. - Normalerweise wird das mittels des {\bf label} Kommandos erreicht, - weiter unten wird genauer darauf eingegangen. - Volumes m\"{u}ssen manuell gelabelt werden, bevor sie benutzt werden k\"{o}nnen. - -\item Die Konfigurationsdateien des Storage-Dienstes m\"{u}ssen angepasst werden, - damit Device-Eintr\"{a}ge Autochangern zugeordnet werden k\"{o}nnen, - sowie einige Parameter mehr. - -\item Sie sollten auch die Storage-Definitionen in der Director-Dienst-Konfiguration anpassen, - so dass automatisch nachgefragt wird, welcher Slot genutzt werden soll, wenn ein Volume gelabelt wird. - -\item Sie m\"{u}ssen sicherstellen, dass der Storage-Dienst (wenn er nicht als root ausgef\"{u}hrt wird) - Zugriffsrechte auf die Laufwerks- und auf das Autochanger-Kontroll-Device hat. - -\item Sie m\"{u}ssen {\bf Autochanger = yes} in der Storage-Definitionen des Director-Dienstes setzen, - damit nach dem Slot gefragt wird wenn Sie Volumes labeln. -\end{itemize} - -In Version 1.37 und sp\"{a}ter, gibt es eine neue \ilink{Autochanger-Konfiguration}{AutochangerRes} -die erlaubt, bestimmte Device-Eintr\"{a}ge zu gruppieren um einen Autochanger mit mehreren Laufwerken -zu konfigurieren. Diese Konfiguration m\"{u}ssen Sie benutzen, wenn Sie einen Autochanger verwenden wollen. - -Bacula benutzt sein eigenes {\bf mtx-changer} Script als Interface zu dem Programm, -dass die Steuerung des Autochangers \"{u}bernimmt. {\bf mtx-changer} kann im Prinzip so angepasst werden, -dass es mit jedem Steuerungsprogramm f\"{u}r beliebige Autochanger funktioniert. -Die derzeitige Version von {\bf mtx-changer} arbeitet mit {\bf mtx}. -FreeBSD-Benutzer haben ein Script zur Verf\"{u}gung gestellt (im Verzeichnis {\bf examples/autochangers}), -dass Bacula {\bf chio} benutzen l\"{a}sst. - -Bacula unterst\"{u}tzt Autochanger mir Barcode-Lesern, -dieses beinhaltet zwei Consolen-Kommandos: {\bf label barcodes} und {\bf update slots}. -Im Abschnitt "Barcode Unterst\"{u}tzung" (siehe unten) erfolgt eine detaillierte Beschreibung dieser Kommandos. - -Momentan beinhaltet die Autochanger-Unterst\"{u}tzung keine Stacker und Silos, -und auch keine Laufwerks-Reinigung (Cleaning). Stacker und Silos werden nicht unterst\"{u}tzt, -da sie keinen wahlfreien Zugriff auf ihre Slots erlauben. -Unter Umst\"{a}nden schaffen Sie es vielleicht, einen Stacker (GravityFeed o. \"{a}.) -mit Bacula zum laufen zu bringen, indem Sie Ihre Konfiguration soweit anpassen, dass auf -den Autochanger nur sequentiell zugegriffen wird. -Die Unterst\"{u}tzung f\"{u}r Autochanger mit mehreren Laufwerken erfordert eine -Konfiguration wie in \ilink{Autochanger resource}{AutochangerRes} beschrieben. -Diese Konfiguration ist aber auch f\"{u}r Autochanger mit nur einem Laufwerk zu benutzen. - -Wenn {\bf mtx} korrekt mit Ihrem Autochanger zusammenarbeitet, -dann ist es nur eine Frage der Anpassung des {\bf mtx-changer} Scripts (falls n\"{o}tig) -um den Autochanger mit Bacula zu benutzen. -Eine Liste mit von {\bf mtx} unterst\"{u}zten Autochangern, finden Sie unter folgendem Link: -\elink{http://mtx.opensource-sw.net/compatibility.php}{http://mtx.opensource-sw.net/compatibility.php}. -Die Homepage des {\bf mtx} Projekts ist: -\elink{http://mtx.opensource-sw.net/}{http://mtx.opensource-sw.net/}. - -Anmerkung: wir haben R\"{u}ckmeldungen von einigen Benutzern erhalten, -die \"{u}ber gewisse Inkompatibilit\"{a}ten zwischen dem Linux-Kernel und mtx berichten. -Zum Beispiel zwischen Kernel 2.6.18-8.1.8.el5 von CentOS und RedHat und Version 1.3.10 -und 1.3.11 von mtx. Ein Umstieg auf Kernel-Version 2.6.22 hat diese Probleme behoben. - -Zus\"{a}tzlich scheinen einige Versionen von mtx, z.B. 1.3.11, die maximale Anzahl der Slots auf 64 -zu begrenzen, Abhilfe schafft die Benutzung von mtx-Version 1.3.10. - -Wenn Sie Probleme haben, benutzen Sie bitte das {\bf auto} Kommando im {\bf btape} Programm, -um die Funktionalit\"{a}t des Autochangers mit Bacula zu testen. -Bitte bedenken Sie, dass bei vielen Distributionen (z.B. FreeBSD, Debian, ...) der Storage-Dienst -nicht als Benutzer und Gruppe {\bf root} l\"{a}ft, sonder als Benutzer {\bf bacula} und Gruppe {\bf tape}. -In diesem Fall m\"{u}ssen Sie sicherstellen, das der Benutzer oder die Gruppe entsprechende Rechte hat, -um auf den Autochanger und die Laufwerke zuzugreifen. - -Manche Benutzer berichten, dass der Storage-Dienst unter Umst\"{a}nden -beim laden eines Tapes in das Laufwerk blockiert, falls schon ein Tape im Laufwerk ist. -Soweit wir das ermitteln konnten, ist es einfache eine Frage der Wartezeit: -Das Laufwerk hat vorher ein Tape beschrieben und wird f\"{u}r eine ganze Zeit -(bis zu 7 Minuten bei langsamen Laufwerken) im Status BLOCKED verbleiben, -w\"{a}hrend das Tape zur\"{u}ckgespult und entladen wird, erst danach kann ein anderes -Tape in das Laufwerk geladen werden. - -\label{SCSI devices} -\section{Zuordnung der SCSI Ger\"{a}te} -\index[general]{Zuordnung der SCSI Ger\"{a}te} -\index[general]{SCSI Ger\"{a}te} -\index[general]{Ger\"{a}te!SCSI} - -Unter Linux k\"{o}nnen Sie: -\footnotesize -\begin{verbatim} -cat /proc/scsi/scsi -\end{verbatim} -\normalsize - -ausf\"{u}hren, um zu sehen welche SCSI-Ger\"{a}te Sie haben. -Zudem k\"{o}nnen Sie: -\footnotesize -\begin{verbatim} -cat /proc/scsi/sg/device_hdr /proc/scsi/sg/devices -\end{verbatim} -\normalsize - -benutzen, um herauszufinden, welches das Autochanger-Kontroll-Device ist, -({\bf /dev/sg0} f\"{u}r die erste Zeile, {\bf /dev/sg1} f\"{u}r die zweite, ...) -das Sie in der Konfiguration unter {\bf Changer Device = } angeben m\"{u}ssen. - -F\"{u}r weiterf\"{u}hrende Information \"{u}ber SCSI-Ger\"{a}te, schauen Sie bitte in den Abschnitt -\ilink{Linux SCSI Tricks}{SCSITricks} aus dem Tape-Testing-Kapitel des Handbuchs. - -Unter FreeBSD k\"{o}nnen Sie: - -\footnotesize -\begin{verbatim} -camcontrol devlist -\end{verbatim} -\normalsize - -benutzen, um SCSI-Ger\"{a}te und die Kontroll-Devices {\bf /dev/passn} des Autochangers anzuzeigen, -die Sie in der Konfiguration unter {\bf Changer Device = } angeben m\"{u}ssen. - -Bitte stellen Sie sicher, dass der Storage-Dienst auf diese Ger\"{a}te zugreifen darf. - -Der folgende Tipp f\"{u}r FreeBSD-Benutzer kommt von Danny Butroyd: -beim Neustart des Computers hat Bacula keine Berechtigung auf das Autochanger-Kontroll-Device -(z.B. /dev/pass0) zuzugreifen, -Um dies zu umgehen, editieren Sie die Datei /etc/devfs.conf und f\"{u}gen unten diese Zeilen hinzu: - -\footnotesize -\begin{verbatim} -own pass0 root:bacula -perm pass0 0666 -own nsa0.0 root:bacula -perm nsa0.0 0666 -\end{verbatim} -\normalsize - -Das gibt der Gruppe bacula, nur um sicher zu gehen, auch die Schreib-Berechtigung f\"{u}r das Ger\"{a}t nsa0.0. -Damit die neue Konfiguration wirksam wird, m\"{u}ssen Sie: - -/etc/rc.d/devfs restart - -ausf\"{u}hren. -Danach brauchen Sie nie wieder die Berechtigungen von Hand zu setzen, wenn der Computer neu gestartet wurde. - -\label{scripts} -\section{Beispiel Scripte} -\index[general]{Scripte!Beispiel } -\index[general]{Beispiel Scripte } - -Lesen Sie bitte den nachfolgenden Abschnitt, damit Sie verstehen wie Bacula mit Autochangern arbeitet. -Auch wenn Bacula ein standard {\bf mtx-changer} Script installiert, ben\"{o}tigen Sie f\"{u}r Ihren Autochanger -eventuell einige Anpassungen. Falls Sie Beispiele sehen wollen, schauen Sie bitte in das Verzeichnis -{\bf\lt{}bacula-src\gt{}/examples/devices}, wo Sie eine {\bf HP-autoloader.conf} Bacula-Ger\"{a}te-Konfiguration, -sowie mehrere {\bf mtx-changer} Scripte finden werden, die schon f\"{u}r unterschiedliche Autochanger angepasst sind. - -\label{Slots} - -\section{Slots} -\index[general]{Slots } - -Um den Autochanger richtig ansteuern zu k\"{o}nnen, muss Bacula wissen -welches Volume in welchem Slot des Autochangers ist. In den Slots werden die Tapes aufbewahrt, -die nicht in einem Laufwerk geladen sind. Bacula nummeriert diese Slots von eins bis zur Anzahl der -vorhandenen Tapes im Autochanger. - -Bacula benutzt niemals ein Volume im Autochanger, dass nicht gelabelt ist, dem keine Slotnummer im Katalog -zugewiesen ist oder wenn das Volume nicht als InChanger im Katalog markiert ist. Bacula muss wissen wo das -Volume/Tape ist, sonst kann es nicht geladen werden. -Jedem Volume im Autochanger muss \"{u}ber das Console-Programm eine Slot-Nummer zugewiesen werden. -Diese Information wird im Katalog, zusammen mit anderen Informationen \"{u}ber das Volume, gespeichert. -Wenn kein Slot angegeben, oder der Slot auf Null gesetzt ist, wird Bacula das Volume nicht benutzen, -auch wenn alle anderen ben\"{o}tigten Konfigurationsparameter richtig gesetzt sind. -Wenn Sie das {\bf mount} Console-Kommando ausf\"{u}hren, m\"{u}ssen Sie angeben welches Tape aus welchem Slot -in das Laufwerk geladen werden soll. Falls schon ein Tape im Laufwerk ist, wird es entladen und danach das -beim {bf\ mount} angegeben Tape geladen. Normalerweise wird kein anderes Tape im Laufwerk sein, da Bacula beim -{\bf unmount} Console-Kommando das Laufwerk leert. - -Sie k\"{o}nnen die Slot-Nummer und die InChanger-Markierung \"{u}berpr\"{u}fen, indem Sie: -\begin{verbatim} -list Volumes -\end{verbatim} -im Consolen-Programm ausf\"{u}hren. - -\label{mult} -\section{mehrere Laufwerke} -\index[general]{Laufwerke!mehrere } -\index[general]{mehrere Laufwerke } - -Einige Autochanger haben mehr als ein Laufwerk. Die in Version 1.37 vorgestellte \ilink{Autochanger-Konfiguration}{AutochangerRes}, erlaubt Ihnen mehrere Ger\"{a}te-Konfigurationen, -die jeweils einem Laufwerk entsprechen, zu einem Autochanger zu gruppieren. Der Director-Dienst k\"{o}nnte trotzdem -die Laufwerke direkt ansprechen, aber dies zu erlauben, w\"{u}rde die einwandfreie Zusammenarbeit der Laufwerke -einschr\"{a}nken. Anstelle dessen sollte dem Director-Dienst, in der Director-Storage-Konfiguration, eine Autochanger-Konfiguration zugewiesen werden. Dieses erlaubt dem Storage-Dienst sicherzustellen, dass nur auf -ein Laufwerk zur Zeit vom {\bf mtx-changer} Script zugegriffen wird und nicht beide Laufwerke auf dasselbe Volume verweisen. - -Mehrere Laufwerke erfordern das Setzen des {\bf Drive Index} in den Ger\"{a}te-Eintr\"{a}gen der -Storage-Dienst-Konfiguration. -Laufwerks-Nummern bzw. der {\bf Drive Index} beginnen standardm\"{a}{\ss}ig bei Null. -Um mit dem zweiten Laufwerk im Autochanger arbeiten zu k\"{o}nnen, muss ein weiterer Ger\"{a}te-Eintrag -erstellt werden, wobei der {\bf Drive Index} dann Eins ist. -Normalerweise wird das zweite Laufwerk dasselbe {\bf Changer Device} verwenden, -aber ein anderes {\bf Archive Device}. - -Bacula Jobs werden bevorzugt auf das Volume geschrieben, dass schon in einem Laufwerk geladen ist. -Wenn Sie mehrere Laufwerke haben und Bacula auf mehreren Laufwerke gleichzeitig Jobs, -die denselben Pool verwenden, schreiben soll, muss der Parameter \ilink{Prefer Mounted Volumes} {PreferMountedVolumes} -in der Director-Dienst-Konfiguration in den entsprechenden Job-Eintr\"{a}gen auf "no" gesetzt werden. -Der Storage-Dienst wird daraufhin so viele Volumes wie m\"{o}glich in die Laufwerke laden. - -\label{ConfigRecords} -\section{Ger\"{a}te-Konfigurations-Parameter} -\index[general]{Parameter!Ger\"{a}te-Konfiguration } -\index[general]{Ger\"{a}te-Konfigurations-Parameter } - -Bacula's Autochanger-Konfiguration wird in den Ger\"{a}te-Eintr\"{a}gen des Storage-Dienstes festgelegt. -Vier Parameter: {\bf Autochanger}, {\bf Changer Device},{\bf Changer Command}, und {\bf Maximum Changer Wait} -steuern wie Bacula den Autochanger benutzt. - -Diese vier Parameter der {\bf Device}-Konfiguration, sind unten detailliert beschrieben. -{\bf Changer Device} und {\bf Changer Command} werden in der Gr\"{a}te-Konfiguration nicht ben\"{o}tigt, -wenn sie in der {\bf Autochanger}-Konfiguration stehen. - -\begin{description} - -\item [Autochanger = {\it Yes|No} ] - \index[sd]{Autochanger } - Der {\bf Autochanger}-Parameter gibt an, ob der Ger\"{a}te-Eintrag einen Autochanger beschreibt oder nicht. - Der Standardwert ist Autochanger = No. - -\item [Changer Device = \lt{}device-name\gt{}] - \index[sd]{Changer Device } - Zus\"{a}tzlich zu dem Archive Device Eintrag, muss das {\bf Changer Device} angegeben werden. -Das ist notwendig, weil die meisten Autochanger \"{u}ber ein anderes Ger\"{a}t gesteuert werden, -als f\"{u}r das Schreiben und Lesen der Volumes verwendet wird. -Ein Beispiel: unter Linux wird normalerweise das generische SCSI-Interface zum Steuern des Autochangers verwendet, -w\"{a}rend das standard SCSI-Interface f\"{u}r Lese- und Schreibvorg\"{a}ge genutzt wird. -F\"{u}r das {\bf Archive Device = /dev/nst0} hat man dann typischerweise das {\bf Changer Device = /dev/sg0}. -Gr\"{o}{\ss}ere Autochanger, mit mehreren Laufwerken und vielen Slots, k\"{o}nnen das Kontroll-Device -auch auf z.B. {\bf Changer Device = /dev/sg2} haben. - -Unter FreeBSD liegt das Kontroll-Device zwischen {\bf /dev/pass0} und {\bf /dev/passn}. - -Unter Solaris finden Sie das Kontroll-Device im Verzeichnis {\bf /dev/rdsk}. - -Stellen Sie bitte sicher, dass der Storage-Dienst die notwendigen Rechte besitzt, -um auf die entsprechenden Ger\"{a}te zugreifen zu d\"{u}rfen. - -\item [Changer Command = \lt{}command\gt{}] - \index[sd]{Changer Command } - Dieser Parameter gibt an, welches externe Kommando und mit welchen Argumenten, -aufgerufen wird, um den Autochanger zu steuern. -Es wird vorausgesetzt, dass dieses Kommando ein normales Programm oder Shell-Script ist, -das vom Betriebssystem ausgef\"{u}hrt werden kann. -Dieses Kommando wird jedes mal aufgerufen, wenn Bacula das Autochanger-Kontroll-Device ansprechen m\"{o}chte. -Die folgenden Ersetzungen werden durchgef\"{u}hrt, bevor das {\bf command} dem Betriebssystem zur -Ausf\"{u}hrung \"{u}bergeben wird: - -\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 - -Hier ist ein Beispiel f\"[{u}r die Benutzung von {\bf mtx} mit dem {\bf mtx-changer} Script, -dass in der Bacula-Distribution enthalten ist: - -\footnotesize -\begin{verbatim} -Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d" -\end{verbatim} -\normalsize - -Falls das {\bf mtx-changer} Script nicht in {\bf /etc/bacula} liegt, -m\"{u}ssen Sie den Pfad entsprechend anpassen, -Einzelheiten zu den drei von Bacula benutzten Kommandos (loaded, load, unload), -sowie zu den von Bacula erwarteten Ausgaben des {\bf mtx-changer} Scripts, -werden weiter unten im Abschnitt {\bf Bacula Autochanger Schnittstelle} beschrieben.. - -\item [Maximum Changer Wait = \lt{}time\gt{}] - \index[sd]{Maximum Changer Wait } - Dieser Parameter gibt an, wie lange Bacula maximal warten soll, -bis der Autochanger auf ein Kommando (z.B. load) reagiert. -Der Standardwert betr\"{a}gt 120 Sekunden. Wenn Sie einen langsamen Autochanger haben, -m\"{u}ssen Sie hier eventuell eine l\"{ä}ngere Zeit konfigurieren. - -Wenn der Autochanger nicht innerhalb der {\bf Maximum Changer Wait} Zeit antwortet, -wird das Kommando abgebrochen und Bacula wird das Eingreifen des Bedieners verlangen. - -\item [Drive Index = \lt{}number\gt{}] - \index[sd]{Drive Index } - Dieser Parameter gibt die Nummer des Laufwerks innerhalb des Autochangers an. -Da die Nummerierung bei Null beginnt, wird das zweite Laufwerk mit folgendem Eintrag angegeben: - -\footnotesize -\begin{verbatim} -Device Index = 1 - -\end{verbatim} -\normalsize - -Um das zweite Laufwerk nutzen zu k\"{o}nnen, muss ein zweiter Device-Eintrag in der Konfigurationsdatei des -Storage-Dienstes erstellt werden. Einzelheiten dazu stehen, weiter oben in diesem Kapitel, in dem Abschnitt -{\bf mehrere Laufwerke} -\end{description} - -Damit der Autochanger zuverl\"{a}{\ss}ig funktioniert, muss zus\"{a}tzlich ein Autochanger-Eintrag erstellt werden. -\input{autochangerres} - -\label{example} -\section{eine Beispiel-Konfigurationsdatei} -\index[general]{Beispiel-Konfigurationsdatei} -\index[general]{Datei!Beispiel Konfiguration } - -Die folgenden beiden Konfigurations-Eintr\"{a}ge realisieren einen Autochanger: - -\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 - -Wobei Sie {\bf Archive Device}, {\bf Changer Device} und den Pfad zum -{\bf Changer Command} Ihrem System entsprechend anpassen m\"{u}ssen. - -\section{eine Beispiel-Konfigurationsdatei f\"{u}r mehrere Laufwerke} -\index[general]{Beispiel-Konfigurationsdatei f\"{u}r mehrere Laufwerke} - -Die folgenden Konfigurations-Eintr\"{a}ge realisieren einen Autochanger mit mehreren Laufwerken: - -\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 - -Wobei Sie {\bf Archive Device}, {\bf Changer Device} und den Pfad zum -{\bf Changer Command} Ihrem System entsprechend anpassen m\"{u}ssen. - -\label{SpecifyingSlots} -\section{Festlegen der Slots beim Labeln} -\index[general]{Festlegen der Slots beim Labeln } -\index[general]{Labeln!Festlegen der Slots } - -Wenn Sie einen {\bf Autochanger = yes} Eintrag in Ihrer Storage-Konfiguration des -Director-Dienstes hinzugef\"{u}gt haben, wird die Bacula Console Sie bei diesen beiden Kommandos -{\bf add} und {\bf label} automatisch nach einem Slot f\"{u}r die jeweilige Aktion fragen. -Beim {\bf label} Kommando wird Bacula automatisch das richtige Volume in ein Laufwerk laden. - -Au{\ss}erdem muss, wie oben beschrieben, der Parameter {\bf Autochanger = yes} in der Ger\"{a}te-Konfiguration -des Storage-Dienstes vorhanden sein, damit der Autochanger benutzt werden kann. -N\"{a}here Informationen zu diesen Parametern finden Sie in der \ilink{Storage Konfiguration}{Autochanger1} -des Director-Kapitels und in \ilink{Device Konfiguration}{Autochanger} des Storage-Kapitels. - -Somit k\"{o}nnen alle Aktionen mit dem Autochanger komplett automatisiert werden. -Zudem ist es m\"{o}glich mit dem Men\"{u}punkt {\bf Volume Parameters} des Consolen-Kommandos {\bf update} den Slot -zu setzen und zu \"{a}ndern. - -Selbst wenn alle oben genannten Konfigurationen und Parameter richtig angegeben sind, -wird Bacula nur dann korrekt mit den Volumes im Autochanger arbeiten, wenn -den Volume-Eintr\"{a}ge im Katalog, die den Tapes im Autochanger entsprechenden, -auch eine {\bf slot}-Nummer zugewiesen ist. - -Wenn Ihr Autochanger Barcodes unterst\"{u}tzt, k\"{o}nnen Sie alle Volumes im Autochanger, -eins nach dem anderen, labeln indem Sie das Console-Kommando {\bf label barcodes} verwenden. -Jedes Tape mit Barcode, wird von Bacula in ein Laufwerk geladen und dann mit dem selben Namen gelabelt, -der auch auf dem Barcode steht. Gleichzeitig wird ein Katalog-Eintrag f\"{u}r das Volume angelegt. -Wenn der Barcode mit der Zeichenkette beginnt, die als {\bf CleaningPrefix= } konfiguriert ist, -wird Bacula das Tape f\"{u}r ein Reinigungsband halten und es wird nicht versucht das Tape zu labeln. -Ein Beispiel: - -\footnotesize -\begin{verbatim} -Pool { - Name ... - Cleaning Prefix = "CLN" -} -\end{verbatim} -\normalsize - -Jedes Volume mit einem Barcode wie CLNxxxxx wird als Reinigungsband behandelt und nicht gelabelt. - -Bitte bedenken Sie, dass jedes Volume, dass der Autochanger automatisch benutzen soll, bereits vor-gelabelt sein muss. -Wenn Sie keinen Barcode-Leser haben, muss das von Hand geschehen (oder durch ein Script). - -\section{Tape-Wechsel} -\index[general]{Tapewechsel } -Wenn Sie Tapes dem Autochanger entnehmen oder hinzuf\"{u}gen wollen, -oder das {\bf mtx} Kommando von Hand aufrufen wollen, -m\"{u}ssen Sie Bacula den Autochanger freigeben lassen, -indem Sie folgendes Console-Kommando ausf\"{u}hren: - -\footnotesize -\begin{verbatim} -unmount -(wechseln der Tapes und/oder mtx ausf\"{u}hren -mount -\end{verbatim} -\normalsize - -Wenn Sie den Autochanger nicht freigeben, wei{\ss} Bacula -nach dem Tapewechsel nicht mehr, welches Volume in welchen Slot des Autochanger ist -und wird nicht mehr korrekt mit dem Autochanger arbeiten k\"{o}nnen. -Bacula geht immer davon aus, dass es exklusiven Zugriff auf den Autochanger hat, -solange ein Laufwerk gemountet ist. - - -\label{Magazines} -\section{Arbeiten mit mehreren Magazinen} -\index[general]{Arbeiten mit mehreren Magazinen } -\index[general]{Magazine!Arbeiten mit mehreren } - -Wenn Sie mehrere Magazine haben, oder wenn Sie Tapes in den Magazinen tauschen, -m\"{u}ssen Sie Bacula dar\"{u}ber informieren. Bacula wird immer die Tapes im Autochanger -bevorzugt vor anderen Tapes benutzen, somit werden Bedienereingriffe minimiert. - -Wenn Ihr Autochanger mit Barcodes (maschinenlesbare Tape Labels) arbeitet, -ist der Schritt, Bacula \"{u}ber die im Autochanger verf\" {u}gbaren Tapes zu informieren, sehr einfach. -Jedes mal wenn Sie ein Magazin wechseln, oder Tapes aus dem Magazine entfernen bzw. hinzuf\"{u}gen, -f\"{u}hren Sie einfach: - -\footnotesize -\begin{verbatim} -unmount -(Magazin/Tapes wechseln) -update slots -mount -\end{verbatim} -\normalsize - -im Console-Programm aus. Daraufhin wird Bacula den Autochanger nach einer aktuellen Liste -der in den Magazinen verf\"{u}gbaren Tapes fragen. Bei diesem Vorgang werden keine Tapes gelesen, -diese Informationen werden vom Autochanger w\"{a}hrend des Inventory ermittelt. -Bacula aktualisiert die Volume-Eintr\"{a}ge im Katalog, so dass bei allen in den Magazinen vorhandenen Tapes -das {\bf InChanger} Flag und auch die Slot-Nummern richtig gesetzt werden. - -Falls Sie keinen Barcode-Leser im Autochanger haben, gibt es mehrere andere M\"{o}glichkeiten. - -\begin{enumerate} -\item Sie k\"{o}nnen den Slot und das {\bf InChanger} Flag manuell setzen, indem Sie das {\bf update volume} -Consolen-Kommando verwenden (sehr umst\"{a}ndlich). - -\item Sie k\"{o}nnen das - -\footnotesize -\begin{verbatim} -update slots scan -\end{verbatim} -\normalsize - - Consolen-Kommando ausf\"{u}hren. Daraufhin wird Bacula jedes Tape nacheinander in ein Laufwerk laden, - das Tape Label lesen und den Katalog (Slot, InChanger-Flag) aktualisieren. - Dieses Vorgehen ist zwar wirkungsvoll, aber auch sehr langsam. - -\item Sie k\"{o}nnen das {\bf mtx-changer} Script anpassen, damit es die Barcodes im Autochanger simuliert (siehe unten). -\end{enumerate} - -\label{simulating} -\section{Simulieren von Barcodes im Autochanger} -\index[general]{Autochanger!Simulieren von Barcodes im } -\index[general]{Simulieren von Barcodes im Autochanger } - -Sie k\"{o}nnen die Barcodes im Autochanger simulieren, indem Sie das {\bf mtx-changer} Script so anpassen, -dass es die selben Informationen zur\"{u}ckgibt, die ein Autochanger mit Barcodes liefert. -Dazu wird die folgende Zeile im {\bf mtx-changer} Script: - -\footnotesize -\begin{verbatim} - ${MTX} -f $ctl status | - grep " *Storage Element [0-9]*:.*Full" | - awk "{print \$3 \$4}" | sed "s/Full *\(:VolumeTag=\)*//" -\end{verbatim} -\normalsize -(Der Zeilenumbruch dient hier nur der Darstellung, im {\bf mtx-changer} Script ist es eine Zeile) - -durch ein \# auskommentiert oder einfach gel\"{o}scht (Zeilennummer ist ungef\"{a}hr 99). -An ihrer Stelle wird eine neue Zeile erstellt, die den Inhalt einer Datei ausgibt. -Zum Beispiel: - -\footnotesize -\begin{verbatim} -cat /etc/bacula/changer.volumes -\end{verbatim} -\normalsize - -Stellen Sie sicher, dass Sie den kompletten Pfad zur Datei angeben, Ort und Name der Datei sind egal. -Die Inhalt der Datei muss folgenden Beispiel entsprechen: - -\footnotesize -\begin{verbatim} -1:Volume1 -2:Volume2 -3:Volume3 -... -\end{verbatim} -\normalsize - -Wobei die 1, 2 und 3 die Slot-Nummern und Volume1, Volume2 und Volume3 die Namen (bzw. Barcodes) sind. -Sie k\"{o}]nnen mehrere Datei erstellen, die den Tapes in verschiedenen Magazinen entsprechen und beim Wechsel -der Magazine einfach die f\"{u}r das Magazine g\"{u}ltige Datei in die {\bf /etc/bacula/changer.volumes} kopieren. -Sie brauchen Bacula nicht neu zu starten, wenn Sie Magazine wechseln, nur die Datei muss den richtigen Inhalt haben. -Wenn Sie dann das Console-Kommando {\bf update slots} ausf\"{u}hren, wird Ihr Autochanger f\"{u}r Bacula so erscheinen, -als ob er Barcodes unterst\"{u}tzen w\"{u}rde. - - -\label{updateslots} -\section{Alle Parameter des Update Slots Kommandos} -\index[general]{Alle Parameter des Update Slots Kommandos } -\index[general]{Kommandos!alle Parameter des Update Slots } - -Wenn Sie ncht alle Slots \"{u}berpr\"{u}fen lassen wollen, nur weil Sie ein Tape im Magazin getauscht haben, -k\"{o}nnen Sie das Consolen-Kommando {\bf update slots}, genauso wie das Kommando {\bf update slots scan}, -mit zus\"{a}tzlichen Parametern aufrufen: - -\footnotesize -\begin{verbatim} -update slots=n1,n2,n3-n4, ... -\end{verbatim} -\normalsize - -wobei der Parameter {\bf scan} optional ist. Die Parameter n1, n2, n3-n7... geben die Slots an, -wobei n1, n2 f\"{u}r einzelne Slots und n3-n7 f\"{u}r einen Bereich von Slots steht (n3 bis n7). - -Diese Parameter sind n\"{u}tzlich, wenn Sie {\bf update slots scan} (sehr langsam) ausf\"{u}hren und dabei -die Slots auf die mit gewechselten Tapes begrenzen k\"{o}nnen. - -Als Beispiel, das Console-Kommando : - -\footnotesize -\begin{verbatim} -update slots=1,6 scan -\end{verbatim} -\normalsize - -veranlasst Bacula, das Tape im ersten Slot des Autochangers in ein Laufwerk zu laden, das Label zu lesen und den -Katalog entsprechend zu aktualisieren. -Danach passiert dasselbe mit dem Tape im sechsten Slot. -Das Console-Kommando: - -\footnotesize -\begin{verbatim} -update slots=1-3,6 -\end{verbatim} -\normalsize - -liest die Barcodes der Tapes in den Slots 1, 2, 3 und 6 und aktualisiert den Katalog. -Wenn Ihr Autochanger keinen Barcode-Leser hat und Sie das {\bf mtx changer} Script nicht, wie oben beschrieben, -angepasst haben, wird dieses Console-Kommando keine Tapes finden und folglich nichts tun. - -\label{FreeBSD} -\section{FreeBSD Belange} -\index[general]{Belange!FreeBSD } -\index[general]{FreeBSD Belange } - -Falls unter FreeBSD Probleme auftreten, wenn Bacula versucht auf ein Laufwerk zuzugreifen -und folgende Fehlermeldung erscheint: {\bf Device not configured}, -passiert dass weil FreeBSD den Ger\"{a}te-Eintrag {\bf /dev/nsa1} entfernt, wenn kein Tape im Laufwerk ist. -Das hat zur Folge, dass Bacula das Ger\"{a}t nicht \"{o}ffnen kann. Die L\"{o}sung f\"{u}r dieses Problem ist es, -sicherzustellen, dass immer ein Tape im Laufwerk ist, wenn Bacula gestartet wird. -Diese Problem ist in den Bacula-Versionen 1.32f-5 und sp\"{a}ter behoben. - -Beachten Sie bitte das Kapitel \ilink{Laufwerk-Tests}{FreeBSDTapes} bevor Sie den Autochanger testen, -dort finden Sie weitere {\bf wichtige} Informationen die Laufwerke betreffend. - -\label{AutochangerTesting} -\section{Autochanger-Test und Anpassung des mtx-changer Scripts} -\index[general]{Autochanger-Test } -\index[general]{Anpassung des mtx-changer Scripts} - - -Bevor Sie den Autochanger gleich mit Bacula ausprobieren, ist es vorzuziehen, zuerst von Hand -zu testen ob er richtig funktioniert. -Um das zu tun, empfehlen wir, dass Sie die folgenden Kommandos ausf\"{u}hren (wobei angenommen wird, -dass das {\bf mtx-changer} Script unter {\bf /etc/bacula/mtx-changer} liegt): - -\begin{description} - -\item [Stellen Sie sicher, dass Bacula nicht l\"{a}uft.] - -\item [/etc/bacula/mtx-changer \ /dev/sg0 \ list \ 0 \ /dev/nst0 \ 0] -\index[sd]{mtx-changer list} - -Das Kommando sollte diese Ausgabe erzeugen: - -\footnotesize -\begin{verbatim} - 1: - 2: - 3: - ... - -\end{verbatim} -\normalsize - -eine oder mehrere Zeilen f\"{u}r jeden belegten Slot im Autochanger, -wobei hinter jeder Zahl ein Doppelpunkt ({\bf :}) stehen muss. -Wenn Ihr Autochanger Barcodes unterst\"{u}tzt, steht hinter dem Doppelpunkt der Barcode. -Falls ein Fehler auftritt, muss die Ursache gefunden werden -(versuchen Sie z.B. ein anderes Kontroll-Device zu verwenden, falls {\bf /dev/sg0} falsch ist). -Unter FreeBSD z.B. liegt das Kontroll-Device gew\"{o}hnlich auf {\bf /dev/pass2}. - -\item [/etc/bacula/mtx-changer \ /dev/sg0 \ slots ] -\index[sd]{mtx-changer slots} - -Das Kommando sollte die Anzahl der Slots im Autochanger anzeigen. - -\item [/etc/bacula/mtx-changer \ /dev/sg0 \ unload \ 1 \ /dev/nst0 \ 0 ] -\index[sd]{mtx-changer unload} - - Falls das Tape aus Slot 1 in einem Laufwerk geladen ist, sollte es jetzt entladen werden. - -\item [/etc/bacula/mtx-changer \ /dev/sg0 \ load \ 3 \ /dev/nst0 \ 0 ] -\index[sd]{mtx-changer load} - -Angenommen in Slot 3 ist ein Tape, dann wird es jetzt in das erste Laufwerk geladen (\bf Drive Index = 0) - -\item [/etc/bacula/mtx-changer \ /dev/sg0 \ loaded \ 0 \ /dev/nst0 \ 0] -\index[sd]{mtx-changer loaded} - -Dieses Kommando sollte jetzt 3 ausgeben (Die Slot-Nummer des in Laufwerk 0 geladenen Tapes.). -Beachten Sie, dass wir im Kommando eine ung\"{u}ltige Slotnummer 0 verwendet haben. -In diesem Fall, wird sie einfach ignoriert, weil sie nicht ben\"{o}tigt wird. -Allerdings musste eine Slot-Nummer angegeben werden, weil der Laufwerksparameter -am Ende des Kommandos erforderlich war, um das richtige Laufwerk zu w\"{a}hlen. - -\item [/etc/bacula/mtx-changer \ /dev/sg0 \ unload \ 3 /dev/nst0 \ 0] - -wird das Laufwerk mit {\bf Drive Index = 0} in Slot 3 entladen. - -\end{description} - -Nachdem alle oben genannten Kommandos funktionieren und in der -Storage-Dienst-Konfiguration auch das richtige {\bf Changer Command} angegeben ist, -sollte Bacula jetzt mit Ihrem Autochanger arbeiten k\"{o}nnen. -Das letzte verbleibende Problem ist, dass der Autochanger einige Zeit ben\"{o}tigt, -das Tape zu laden, nachdem das entsprechende Kommando abgesetzt wurde. -Wenn sich das {\bf mtx-changer} Script nach dem load-Kommando beendet, -wird Bacula sofort versuchen das Tape zur\"{u}ckzuspulen und zu lesen. -Wenn Bacula Ein-/Ausgabe-Fehler nach dem Laden des Tapes meldet, werden Sie eventuell eine -Verz\"{o}gerungszeit (z.B. {\bf sleep 20}) im {\bf mtx changer} Script nach dem {\bf mtx} Kommando -einf\"{u}gen m\"{u}ssen. Bitte bedenken Sie, dass egal was Sie dem {\bf mtx changer} Script an Kommandos -hinzuf\"{u}gen, sich das Script immer mit {\bf exit 0} beendet. -Bacula \"{u}berpr\"{u}ft den R\"{u}ckgabewert des Script nach jedem Aufruf und er muss immer 0 sein, -wenn alles geklappt hat. - -Ob Sie eine {\bf sleep}-Zeit im Script angeben m\"{u}ssen, k\"{o}nnen Sie mit folgenden -Kommandos \"{u}berpr\"{u}fen, indem Sie sie in ein Script schreiben und ausf\"{u}hren. - -\footnotesize -\begin{verbatim} -#!/bin/sh -/etc/bacula/mtx-changer /dev/sg0 unload 1 /dev/nst0 0 -/etc/bacula/mtx-changer /dev/sg0 load 3 /dev/nst0 0 -mt -f /dev/st0 rewind -mt -f /dev/st0 weof -\end{verbatim} -\normalsize - -Wenn das Script funktioniert, haben Sie wahrscheinlich keine zeitlichen Probleme. -Wenn es nicht funktioniert, tragen Sie, direkt hinter dem mtx-changer load Kommando, -{\bf sleep 30} oder auch {\bf sleep 60} ein. Wenn es damit funktioniert, -\"{u}bernehmen Sie den passenden {\bf sleep}-Eintrag in das {\bf mtx-changer} Script, -so wird diese Verz\"{o}gerungszeit jedes mal angewendet, wenn Bacula das Script aufruft. - -Ein zweites Problem, dass einige Autochanger betrifft, ist dass die Laufwerke diese Autochanger das Tape -auswerfen m\"{u}ssen, bevor es aus dem Laufwerk entfernt werden kann. Falls das zutrifft, wird das Kommando -{\bf load 3} niemals erfolgreich beendet werden, egal wie lange Sie warten. -In diesem Fall, k\"{o}nnen Sie ein Auswurf-Kommando direkt hinter das {\bf unload} setzen, -so dass das Script dann so aussieht: - -\footnotesize -\begin{verbatim} -#!/bin/sh -/etc/bacula/mtx-changer /dev/sg0 unload 1 /dev/nst0 0 -mt -f /dev/st0 offline -/etc/bacula/mtx-changer /dev/sg0 load 3 /dev/nst0 0 -mt -f /dev/st0 rewind -mt -f /dev/st0 weof -\end{verbatim} -\normalsize - -Nat\"{u}rlich m\"{u}ssen Sie das {\bf offline} Kommando in das {\bf mtx changer} Script \"{u}bernehmen, -falls es das Problem behebt. Da Bacula den R\"{u}ckgabewert des {\bf mtx changer} Scripts \"{u}berpr\"{u}ft, -stellen sie wiederum sicher, dass er immer 0 ist, bzw. das der R\"{u}ckgabewert des {\bf mtx} Kommandos an -Bacula \"{u}bergeben wird. - -Wie vorher schon angemerkt, sind im Verzeichnis {\bf \lt{}bacula-source\gt{}/examples/devices} mehrere -Scripte, die die oben genannten Kommandos bereits enthalten. Sie k\"{o}nnen eine Hilfe sein, um Ihr Script -zum laufen zu bringen. - -Wenn Bacula den Fehler {\bf Rewind error on /dev/nst0. ERR=Input/output error.} ausgibt, -werden Sie in den meisten F\"{a}llen eine l\"{a}ngere {\bf sleep}-Zeit in Ihrem {\bf mtx-changer} Script -hinzuf\"{u}gen m\"{u}ssen, bevor es nach dem {\bf load} Kommando beendet wird. - -\label{using} -\section{Arbeiten mit dem Autochanger} -\index[general]{Arbeiten mit dem Autochanger } -\index[general]{Autochanger!Arbeiten mit dem } - -Angenommen, Sie haben alle notwendigen Storage-Dienst-Device-Eintr\"{a}ge richtig konfiguriert -und Sie haben einen {\bf Autochanger = yes} Eintrag zu der Storage-Konfiguration im Director-Dienst -hinzuge\"{u}gt. - -Jetzt f\"{u}llen Sie Ihren Autochanger mit, zum Beispiel, 6 leeren Tapes. - -Was muss passieren, damit Bacula auf diese Tapes zugreifen kann? - -Eine M\"{o}glichkeit ist, dass jedes Tape vorgelabelt wird. Starten Sie Bacula und -f\"{u}hren Sie das Console-Programm aus, innerhalb des Console-Programms verwenden Sie das Kommando {\bf label}: - -\footnotesize -\begin{verbatim} -./bconsole -Connecting to Director rufus:8101 -1000 OK: rufus-dir Version: 1.26 (4 October 2002) -*label -\end{verbatim} -\normalsize - -wird etwas \"{a}hnliches wie hier ausgeben: - -\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 - -W\"{a}hlen Sie den Autochanger und es erscheint: - -\footnotesize -\begin{verbatim} -Enter new Volume name: TestVolume1 -Enter slot (0 for none): 1 -\end{verbatim} -\normalsize - -geben Sie {\bf Testvolume1} f\"{u}r den Tape-Namen ein und {\bf 1} f\"{u}r den Slot. -Bacula fragt: - -\footnotesize -\begin{verbatim} -Defined Pools: - 1: Default - 2: File -Select the Pool (1-2): 1 -\end{verbatim} -\normalsize - -W\"{a}hlen Sie den Default Pool. Das wird automatisch gemacht, wenn Sie nur einen Pool haben. -Nun wird Bacula damit beginnen, das ben\"{o}tigte Laufwerk zu entladen und -das Tape aus Slot 1 in das Laufwerk zu laden und als Testvolume1 zu labeln. -In diesem Beispiel war kein Tape im Laufwerk, die Ausgabe sieht dann so aus: - -\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 - -Sie k\"{o}nnen dann damit fortfahren, die andern Tapes zu labeln. -Die Ausgaben werden etwas anders aussehen, weil Bacula dann erst das -vorherige, gerade gelabelte Tape, aus dem Laufwerk entladen muss, -bevor das neue Tape geladen werden kann. - -Wenn Sie alle Tapes gelabelt haben, wird Bacula sie automatisch verwenden, wenn sie ben\"{o}tigt werden. - -Um nachzusehen, wie die Tapes gelabelt sind, geben Sie einfach das Console-Kommando {\bf list volumes} ein, -das wird eine Liste, wie die folgende ausgeben: - -\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{Barcode Unterst\"{u}tzung} -\index[general]{Unterst\"{u}tzung!Barcode } -\index[general]{Barcode Unterst\"{u}tzung } - -Bacula unterst\"{u}tzt Barcodes mit zwei Console-Kommandos: -{\bf label barcodes} und {\bf update slots}. - -Das Kommando {\bf label barcodes} bewirkt, dass Bacula mittels des {\bf mtx-changer} {\bf list} -Kommandos die Barcodes der Tapes in allen Slots einliest. Danach wird jedes Tape, eins nach dem anderen, -mit dem Namen gelabelt, den der Barcode enth\"{a}lt. - -Das {\bf update slots} Kommando holt, \"{u}ber das {\bf mtx-changer} Script, zuerst eine Liste aller Tapes und deren Barcodes. Dann versucht es im Katalog die entsprechenden Tapes zu finden und aktualisiert -den {\bf Slot} und das {\bf InChanger} Flag. Falls das Tape nicht im Katalog gelistet ist, passiert nichts. -Diese Kommando wird ben\"{o}tigt, um die Volume-Eintr\"{a}ge im Katalog mit den tats\"{a}chlich im Autochanger -zur Verf\"{u}gung stehenden Tapes abzugleichen, nachdem Tapes gewechselt oder in andere Slots verschoben wurden. - -Die Angabe des {\bf Cleaning Prefix} kann in der Pool-Konfiguration benutzt werden, um anzugeben welche -Tapes (Barcodes) im Katalog mit dem {\bf VolStatus} {\bf Cleaning} gekennzeichnet werden sollen. -Das verhindert, dass Bacula versucht auf dem Tape zu schreiben. - -\label{interface} -\section{Bacula Autochanger Schnittstelle} -\index[general]{Schnittstelle!Bacula Autochanger } -\index[general]{Bacula Autochanger Schnittstelle } - -Bacula ruft das Autochanger-Script auf, dass Sie als {\bf Changer Command} angegeben haben. -Normalerweise ist es das von Bacula mitgelieferte {\bf mtx-changer} Script, -aber tats\"{a}chlich kann es auch jedes andere Programm sein. -Die einzige Anforderung ist, dass es die Kommandos die Bacula benutzt, -{\bf loaded}, {\bf load}, {\bf unload}, {\bf list} und {\bf slots}, unterst\"{u}tzt. -Ausserdem muss jedes dieser Kommandos genau diese R\"{u}ckgabewerte liefern: - -\footnotesize -\begin{verbatim} -- Die momentan benutzten Autochanger-Kommandos sind: - loaded -- gibt, ab 1 beginnend, die Nummer des im Laufwerk geladenen Slot zur\"{u}ck, - bzw. 0 wenn das Laufwerk leer ist. - load -- l\"{a}dt das Tape aus dem angegebenen Slot in das Laufwerk (einige Autochanger - ben\"{o}tigen eine 30-sek\"{u}ndige Pause nach diesem Kommando) - unload -- entl\"{a}dt das Tape aus dem Laufwerk zur\"{u}ck in den Slot - list -- gibt eine Zeile pro Tape im Autochanger aus. - Das Format ist: :. Wobei - der {\bf Slot} eine Zahl (nicht null) ist, die der Slot-Nummer entspricht, - und {\bf Barcode} ist, falls vorhanden, der Barcode des Tapes, - ansonsten ist {\bf Barcode} leer. - slots -- gibt die absolute Anzahl der Slots im Autochanger zur\"{u}ck. -\end{verbatim} -\normalsize - -Bacula \"{u}berpr\"{u}ft den R\"{u}ckgabewert des aufgerufenen Programms, -wenn er Null ist, werden die gelieferten Daten akzeptiert. -Wenn der R\"{u}ckgabewert nicht Null ist, wird eine entsprechende Fehlermeldung ausgegeben und -Bacula wird ein manuelles laden des Tapes in das Laufwerk erwarten. diff --git a/docs/manual-de/bimagemgr-chapter.tex b/docs/manual-de/bimagemgr-chapter.tex deleted file mode 100644 index 6b6239d0..00000000 --- a/docs/manual-de/bimagemgr-chapter.tex +++ /dev/null @@ -1,149 +0,0 @@ -%% -%% -%% The following characters must be preceded by a backslash -%% to be entered as printable characters: -%% -%% # $ % & ~ _ ^ \ { } -%% - -\section{bimagemgr} -\label{bimagemgr} -\index[general]{Bimagemgr } - -{\bf bimagemgr} ist ein Hilfsmittel f\"{u}r diejenigen, die Ihre Backups auf -Festplatten-Volumes speichern und diese Volumes auf CDR brennen wollen. -Es hat eine Web-basierte Bedienoberfl\"{a}che und ist in Perl programmiert. -Es wird benutzt, um zu kontrollieren, wann die Notwendigkeit besteht, eine -Volume-Datei auf eine CD zu brennen. -Es ben\"{o}tigt: - -\begin{itemize} -\item Einen Web-Server der auf derselben Maschine wie Bacula l\"{a}uft -\item Einen auf dem Bacula-Server installierten und konfigurierten CD-Rekorder -\item Das cdr-tools-Paket muss installiert sein -\item perl, perl-DBI Modul, und entweder das DBD-MySQL, DBD-SQLite oder DBD-PostgreSQL Modul -\end{itemize} - -DVD-Brenner werden von bimagemgr zur Zeit nicht unterst\"{u}tzt, das ist aber f\"{u}r -zuk\"{u}nftige Versionen geplant. - -\subsection{bimagemgr Installation} -\index[general]{bimagemgr!Installation } -\index[general]{bimagemgr Installation } - -Installation aus dem tar.gz: -% TODO: use itemized list for this? -1. Pr\"{u}fen und anpassen des Makefile, um es auf Ihre Computer-Konfiguration abzustimmen. -2. Editieren der Datei config.pm ,um sie auf Ihre Konfiguration abzustimmen. -3. F\"{u}hren Sie 'make install' als root aus. -4. Passen Sie in Ihrer httpd.conf das Timeout an. Der Web-Server darf die Verbindung nicht schliessen, -solange der Brennvorgang nicht abgeschlossen ist. Der ben\"{o}tigte Wert, den Sie als Timeout -konfigurieren m\"{u}ssen, h\"{a}ngt von der Geschwindigkeit Ihres CD-Brenners ab, oder ob Sie \"{u}ber das Netzwerk brennen. In den meisten F\"{a}llen reichen 1000 Sekunden als Timeout. Den httpd neu starten. -5. Stellen Sie sicher, dass das Kommando cdrecord als "setuid root" installiert ist. -% TODO: I am pretty sure cdrecord can be used without setuid root -% TODO: as long as devices are setup correctly - -Installation eines rpm-Paketes: -% TODO: use itemized list for this? -1. Installieren Sie das rpm-Paket f\"{u}r Ihre Plattform. -2. Editieren Sie die Datei /cgi-bin/config.pm, um sie an Ihre Konfiguration abzupassen. -3. Passen Sie in Ihrer httpd.conf das Timeout an. Der Web-Server darf die Verbindung nicht schliessen, -solange der Brennvorgang nicht abgeschlossen ist. Der ben\"{o}tigte Wert, den Sie als Timeout -konfigurieren m\"{u}ssen, h\"{a}ngt von der Geschwindigkeit Ihres CD-Brenners ab, oder ob Sie \"{u}ber das Netzwerk brennen. In den meisten F\"{a}llen reichen 1000 Sekunden als Timeout. Den httpd neu starten. -4. Stellen Sie sicher, dass das Kommando cdrecord als "setuid root" installiert ist. - -Zugriff auf die Volume-Dateien: -Die Volume-Dateien haben standardm\"{a}{\ss}ig die Zugriffsrechte 640 gesetzt -und k\"{o}nnen nur von Benutzer root gelesen werden. -Die empfohlene Methode ist die folgende (das funktioniert nur, wenn bacula und bimagemgr -auf demselben Computer laufen wie der Web-Server): - -F\"{u}r Bacula-Versionen 1.34 oder 1.36 installiert aus dem tar.gz - -% TODO: use itemized list for this? -1. Erstellen Sie eine neu Gruppe namens bacula und f\"{u}gen Sie den Benutzer apache dieser Gruppe -hinzu (bei RedHat und Mandrake, bei SuSE ist es der Benutzer wwwrun, bei debian www-data) -2. \"{A}ndern Sie den Eigent\"{u}mer aller Volume-Dateien auf root.bacula. -3. Passen Sie das Script /etc/init.d/bacula an und setzen Sie SD\_USER=root und SD\_GROUP=bacula. -Starten Sie Bacula neu. - -Anmerkung: Schritt Nr. 3 sollte auch in /etc/init.d/bacula-sd gemacht werden, -aber die Dateien aus Bacula-Versionen vor 1.36 unterst\"{u}tzen dies nicht. -In diesem Fall kann es n\"{o}tig sein den Computer neu zu starten, -um '/etc/bacula/bacula restart' auszuf\"{u}hren. - -F\"{u}r Bacula-Versionen 1.38 installiert aus dem tar.gz -% TODO: use itemized list for this? -1. Ihr configure-Aufruf sollte dies beinhalten: -% TODO: fix formatting here - --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. F\"{u}gen Sie den Benutzer apache der Gruppe bacula hinzu -(bei RedHat und Mandrake, bei SuSE ist es der Benutzer wwwrun, bei debian www-data) -3. Kontrollieren/\"{A}ndern Sie den Eigent\"{u}mer aller Volume-Dateien auf root.bacula - -F\"{u}r Bacul-Versionen 1.36 oder 1.38 mit rpm installiert - -% TODO: use itemized list for this? -1. F\"{u}gen Sie den Benutzer apache der Gruppe bacula hinzu -(bei RedHat und Mandrake, bei SuSE ist es der Benutzer wwwrun, bei debian www-data) -2. Kontrollieren/\"{A}ndern Sie den Eigent\"{u}mer aller Volume-Dateien auf root.bacula - -Wenn bimagemgr mit einem rpm-Paket Version gr\"{o}{\ss}er 1.38.9 installiert wird, -wird der Web-Server-Benutzer automatisch der Gruppe bacula hinzugef\"{u}gt. -Stellen Sie sicher, dass Sie die Datei config.pm nach der Installation anpassen. - -bimagemgr kann jetzt alle Volume-Dateien lesen, aber sie sind nicht durch alle Benutzer lesbar. - -Wenn Sie bimagemgr auf einen anderen Computer installieren (nicht empfohlen), -m\"{u}ssen Sie die Zugriffsrechte aller Volume-Dateien auf 644 \"{a}ndern, -damit Sie \"{u}ber nfs oder andere Mittel darauf zugreifen k\"{o}nnen. -Beachten Sie, dass bei diesem Vorgehen die Volume-Dateien f\"{u}r alle Benutzer lesbar sind -und Sie den Schutz der Dateien anders sicherstellen. - -\subsection{bimagemgr Benutzung} -\index[general]{bimagemgr!Benutzung } -\index[general]{bimagemgr Benutzung } - -Rufen Sie das Programm mit Ihrem Web-Browser auf, z.B. {\tt http://localhost/cgi-bin/bimagemgr.pl}, -dann sollten Sie eine Darstellung \"{a}hnlich der unten im Bild 1 abgebildeten sehen. -% TODO: use tex to say figure number -Das Programm wird die Bacula-Datenbank abfragen und alle Volume-Dateien mit dem Datum -des letzten Schreibvorgangs und dem Zeitpunkt darstellen, wo das Volume zum letzten -Mal auf CD gebrannt wurde. Wenn ein Volume auf CD gebrannt werden muss (letzter Schreibvorgang -ist neuer als der letzte Brennvorgang), wird ein "Brennen"-Knopf in der rechten Spalte angezeigt. - -\addcontentsline{lof}{figure}{Bacula CD Image Manager} -\includegraphics{./bimagemgr1.eps} \\Figure 1 -% TODO: use tex to say figure number - -Legen Sie eine leere CD in Ihren CD-Brenner und klicken Sie auf den "Brennen"-Knopf. -Dann \"{o}ffnet sich ein PopUp-Fenster, wie im Bild 2, das den Brennvorgang anzeigt. -% TODO: use tex to say figure number - -\addcontentsline{lof}{figure}{Bacula CD Image Brennfortschritt-Fenster} -\includegraphics{./bimagemgr2.eps} \\Figure 2 -% TODO: use tex to say figure number - -Wenn der Brennvorgang abgeschlo{\ss}en ist, zeigt das PopUp-Fenster die Ausgaben von cdrecord -an (siehe Bild 3). -% TODO: use tex to say figure number -Schlie{\ss}en Sie das PopUp-Fenster und laden Sie die Hauptseite neu. -Das Datum des letzten Brennvorgangs wird aktualisiert und der "Brennen"-Knopf verschwindet. -Sollte das Brennen fehlgeschlagen sein, k\"{o}nnen Sie das Datum des letzten Brennvorgangs -zur\"{u}cksetzen, indem Sie auf den Link "Reset" des Volumes klicken. - -\addcontentsline{lof}{figure}{Bacula CD Image Brennergebnis} -\includegraphics{./bimagemgr3.eps} \\Figure 3 -% TODO: use tex to say figure number - -In der untersten Zeile des Hauptfensters sind zwei weitere Kn\"{o}pfe, -mit "Burn Catalog" und "Blank CDRW" beschriftet. -"Burn Catalog" schreibt eine Kopie Ihrer Katalog-Datenbank auf eine CD. -Falls Sie CDRW-Medien benutzen, k\"{o}nnen Sie mit "Blank CDRW" ein Medium l\"{o}schen -bevor Sie es wiederverwenden. -Regelm\"{a}ssiges speichern Ihrer Volume-Dateien und Ihrer Katalog-Datenbank mit bimagemgr auf CD's -stellt sicher, dass Sie jederzeit im Falle eines Datenverlustes auf Ihrem Bacula-Server -diesen einfach wiederherstellen k\"{o}nnen. diff --git a/docs/manual-de/bimagemgr.tex b/docs/manual-de/bimagemgr.tex deleted file mode 100644 index 48ca14ed..00000000 --- a/docs/manual-de/bimagemgr.tex +++ /dev/null @@ -1,60 +0,0 @@ -%% -%% -%% The following characters must be preceded by a backslash -%% to be entered as printable characters: -%% -%% # $ % & ~ _ ^ \ { } -%% - -\documentclass[11pt,a4paper]{book} -\usepackage{html} -\usepackage{float} -\usepackage{graphicx} -\usepackage{bacula} -\usepackage{longtable} -\usepackage{makeidx} -\usepackage{index} -\usepackage{setspace} -\usepackage{hyperref} - -\makeindex -\newindex{general}{bix}{bid}{General Index} - -\sloppy - -\begin{document} -\sloppy - -\newfont{\bighead}{cmr17 at 36pt} -\parskip 10pt -\parindent 0pt - - -\title{\includegraphics{./bacula-logo.eps} \\ \bigskip - \begin{center} - \large{It comes in the night and sucks - the essence from your computers. } - \end{center} -} -\author{Kern Sibbald} -\date{\vspace{1.0in}\today \\ - This manual documents Bacula version \input{version} \\ - ~\vspace{0.2in}\\ - Copyright \copyright 1999-2007, Free Software Foundation Europe e.V. - \\ - ~\vspace{0.2in}\\ - Permission is granted to copy, distribute and/or modify this document under the terms of the \\ - GNU Free Documentation License, Version 1.2 published by the Free Software Foundation; \\ - with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. \\ - A copy of the license is included in the section entitled "GNU Free Documentation License". -} - -\maketitle - -\clearpage - -\markboth{Bacula Manual}{} -\include{bimagemgr-chapter} -\include{fdl} - -\end{document} diff --git a/docs/manual-de/bootstrap.tex b/docs/manual-de/bootstrap.tex deleted file mode 100644 index 633c8942..00000000 --- a/docs/manual-de/bootstrap.tex +++ /dev/null @@ -1,415 +0,0 @@ -%% -%% - -\chapter{Die Bootstrap-Datei} -\label{BootstrapChapter} -\index[general]{Datei!Bootstrap } -\index[general]{Bootstrap-Datei } - -Die Informationen in diesem Kapitel sollen Ihnen helfen, entweder eigene Bootstrap-Dateien -zu erstellen, oder die von Bacula erzeugten zu editieren. Da die Bootstrap-Datei automatisch beim ausf\"{u}hren des -\ilink{restore}{_ConsoleChapter} Console-Kommandos, oder wenn Sie \ilink{ Write Bootstrap}{writebootstrap} -in den Job-Eintr\"{a}gen der Director-Dienst-Konfiguration angeben, erzeugt wird, -brauchen Sie das genaue Format eigentlich nicht wissen. - -Die Bootstrap-Datei enth\"{a}lt Informationen im ASCII-Format, -die pr\"{a}zise angeben, welche Dateien wiederhergestellt werden sollen, auf welchem Volume sie liegen -und wo auf dem Volume. Es ist ein relativ kompaktes Format diese Informationen anzugeben, aber es ist -lesbar f\"{u}r Menschen und kann mit einem Texteditor ge\"{a}ndert werden. - -\section{Bootstrap-Datei Format} -\index[general]{Format!Bootstrap} -\index[general]{Bootstrap-Datei Format } - -Das generelle Format der Bootstrap-Datei ist: - -{\bf \lt{}Schl\"{u}sselwort\gt{} = \lt{}Wert\gt{}} - -Wobei jedes Schl\"{u}sselwort und sein Wert angeben, welche Dateien wiederhergestellt werden. -Genauer gesagt, das Schl\"{u}sselwort und sein Wert dienen dazu, zu limitieren welche -Dateien wiederhergestellt werden, sie verhalten sich wie ein Filter. -Das Fehlen eines Schl\"{u}sselwort bedeutet, dass alle Dateien angenommen werden. - -In der Bootstrap-Datei werden Leerzeilen und Zeilen beginnent mit {\#} ignoriert. - -Es existieren Schl\"{u}sselw\"{o}rter, die die Filterung nach Volume, Client, Job, Fileindex, Session ID, -Session Time usw. erlauben. - -Je mehr Schl\"{u}sselw\"{o}rter Sie angeben, desto genauer ist die Auswahl der Dateien, die wiederhergestellt werden. -Alle Schl\"{u}sselw\"{o}rter werden \"{u}ber {\bf UND} verkn\"{u}pft. - -Ein Beispiel: - -\footnotesize -\begin{verbatim} -Volume = Test-001 -VolSessionId = 1 -VolSessionTime = 108927638 -\end{verbatim} -\normalsize - -veranlasst den Storage-Dienst (oder das {\bf bextract} Programm), nur die Dateien wiederherzustellen, die -auf dem Volume Test-001 vorhanden sind {\bf UND} eine VolumeSessionID mit 1 haben {\bf UND} deren VolumeSessionTime -gleich 108927638 ist. - -Hier ist eine Liste aller erlaubten Schl\"{u}sselw\"{o}rter in der Reihenfolge in der sie auf -die auf dem Volume befindlichen Daten angewendet werden: - -\begin{description} - -\item [Volume] - \index[general]{Volume } - Dieser Wert gibt an, auf welches Volume die folgenden Schl\"{u}sselw\"{o}rter angewendet werden sollen. - Falls in der Bootstrap-Datei ein zweites Volume angegeben wird, beziehen sich die darauf folgenden - Schl\"{u}sselw\"{o}rter auf dieses Volume. - Wenn der Name des Volumes Leerzeichen enth\"{a}lt, muss er in Anf\"{u}hrungszeichen gesetzt werden. - Mindestens ein Volume muss angegeben werden. - -\item [Count] - \index[general]{Count} - Dieser Wert ist die Gesamtanzahl der Dateien, die von dem Volume gelesen werden sollen. - Daran erkennt der Storage-Dienst, wann er das Lesen beenden soll. - Dieser Wert ist optional. - -\item [VolFile] - \index[general]{VolFile} - Dieser Wert gibt eine Dateinummer oder eine Liste bzw. einen Bereich von Dateinummern an, - die auf dem aktuellen Volume gefunden werden soll. Die Dateinummer stellt die physikalische - Datei auf dem Volume da, wo die Daten gespeichert sind. Bei einem Tape wird dieser Wert benutzt, - um das Band richtig zu positionieren und wenn das Laufwerk die letzte angegebene Datei gelesen hat, - wird der Lesevorgang gestoppt. - -\item [VolBlock] - \index[general]{VolBlock} - Dieser Wert gibt eine Blocknummer oder eine Liste bzw. einen Bereich von Blocknummern an, - die auf dem aktuellen Volume gefunden werden soll. Die Blocknummer stellt die physikalischen - Bl\"{o}cke auf dem Volume da, wo die Daten gespeichert sind. - -\item [VolSessionTime] - \index[general]{VolSessionTime } - Dieser Wert gibt die Volume-Session-Zeit an, die auf dem aktuellen Volume gefunden werden soll. - -\item [VolSessionId] - \index[general]{VolSessionId } - Dieser Wert gibt eine Volume-Session-ID oder eine Liste bzw. einen Bereich von Volume-Sesion-IDs an, - die auf dem aktuellen Volume gefunden werden soll. Jedes Paar aus Volume-Session-ID und Volume-Session-Zeit, - stimmt mit einem einzelnen Job \"{u}berein, der auf dem Volume gespeichert ist. - -\item [JobId] - \index[general]{JobId } - Dieser Wert gibt eine Job-ID oder eine Liste bzw. einen Bereich von Job-Ids an, - die auf dem aktuellen Volume gefunden werden soll. Beachten Sie bitte, dass die Job-ID - eventuell nicht eindeutig ist, falls Sie mehrere Director-Dienste haben, oder falls Sie - Ihre Datenbank neu initialisiert haben sollten. Der Job-ID-Filter funktioniert nicht, wenn - Sie mehrere Jobs gleichzeitig haben laufen lassen. - Dieser Wert ist optional und wird von Bacula nicht zum zur\"{u}cksichern ben\"{o}tigt. - -\item [Job] - \index[general]{Job } - Dieser Wert gibt einen Job-Namen oder eine Liste von Job-Namen an, die auf dem aktuellen - Volume gefunden werden sollen. Der Job-Name stimmt mit einem einzigartigen Paar aus Volume-Session-Zeit - und VolumeSessionID \"{u}berein, allerdings ist er f\"{u}r Menschen ein bischen leichter zu lesen. - Gew\"{o}hnliche regul\"{a}re Ausdr\"{u}cke k\"{o}nnen benutzt werden, um einen entsprechenden Job-Namen zu finden. - Der Job-Name-Filter funktioniert nicht, wenn Sie mehrere Jobs gleichzeitig haben laufen lassen. - Dieser Wert ist optional und wird von Bacula nicht zum zur\"{u}cksichern ben\"{o}tigt. - -\item [Client] - \index[general]{Client } - Dieser Wert gibt einen Client-Namen oder eine Liste von Client-Namen an, dia auf dem aktuellen - Volume gefunden werden soll. Gew\"{o}hnliche regul\"{a}re Ausdr\"{u}cke k\"{o}nnen benutzt werden, - um einen entsprechenden Job-Namen zu finden. Der Client-Filter funktioniert nicht, - wenn Sie mehrere Jobs gleichzeitig haben laufen lassen. - Dieser Wert ist optional und wird von Bacula nicht zum zur\"{u}cksichern ben\"{o}tigt. - -\item [FileIndex] - \index[general]{FileIndex } - Dieser Wert gibt einen File-Index oder eine Liste bzw. einen Bereich von File-Indexen an, - die auf dem aktuellen Volume gefunden werden soll. Jedes File (Datei) das auf einem Volume gespeichert ist, - hat f\"{u}r seine Session einen einzigartigen File-Index. Bei jeder Session wird f\"{u}r das erste - gespeicherte File der File-Index auf eins gesetzt und dann mit jedem weiteren File um eins erh\"{o}ht. - - F\"{u}r ein beliebiges Volume bedeutet das, dass die drei Werte von Volume-Session-ID, Volume-Session-Time - und File-Index zusammen eine einzelne einzigartige Datei auf einem Volume angeben. Diese Datei ist eventuell - mehrfach auf dem Volume vorhanden, aber f\"{u}r jedes Vorkommen gibt es eine einzigartige Kombination - dieser drei Werte. Diese drei Werte sind f\"{u}r jede Datei in der Katalog-Datenbank gespeichert. - - Um eine Datei wiederherzustellen, ist die Angabe eines Wertes (oder einer Liste von File-Indexen) - erforderlich. - -\item [Slot] - \index[general]{Slot } - Dieser Wert gibt den Autochanger-Slot an. F\"{u}r jedes Volume darf nur ein Slot angegeben werden. - -\item [Stream] - \index[general]{Stream } - Dieser Wert gibt einen Stream (Strom) oder eine Liste bzw. einen Bereich von Streams an. - Solange Sie nicht wirklich wissen, was Sie tun, (wenn Sie das interne Arbeiten von Bacula kennen), - sollten Sie auf diese Angabe verzichten. - Dieser Wert ist optional und wird von Bacula nicht zum zur\"{u}cksichern ben\"{o}tigt. - -\item [*JobType] - \index[general]{*JobType } - Noch nicht implementiert. - -\item [*JobLevel] - \index[general]{*JobLevel } - Noch nicht implementiert. -\end{description} - -Bei der Angabe des Volume ist zu bedenken, dass dies der erste Parameter sein muss. -Alle anderen Parameter k\"{o}nnen in beliebiger Reihenfolge und Anzahl hinter einem -Volume-Eintrag angegeben werden. - -Mehrere Volume-Eintr\"{a}ge k\"{o}nnen in der selben Bootstrap-Datei vorkommen, -aber mit jedem Vorkommen beginnt ein neuer Satz an Filter, g\"{u}ltig f\"{u}r -das abgegebene Volume. - -Beim verarbeiten der Bootstrap-Datei werden alle Schl\"{u}sselw\"{o}rter -unterhalb eines Volume-Eintrags mit {\bf UND} verkn\"{u}pft. -Also wird: - -\footnotesize -\begin{verbatim} -Volume = Test-01 -Client = "My machine" -FileIndex = 1 -\end{verbatim} -\normalsize - -auf alle Dateien auf dem Volume Test-01 {\bf UND} von Client My machine -{\bf UND} mit dem Fileindex 1 passen. - -Mehrfach angegebene Schl\"{u}sselw\"{o}rter werden mit {\bf ODER} verkn\"{u}pft. -Also wird: - -\footnotesize -\begin{verbatim} -Volume = Test-01 -Client = "My machine" -Client = "Backup machine" -FileIndex = 1 -\end{verbatim} -\normalsize - -auf alle Dateien auf dem Volume Test-01 {\bf UND} von Client My machine -{\bf ODER} vom Client Backup machine {\bf UND} mit dem Fileindex 1 passen. - -F\"{u}r Zahlenwerte k\"{o}nnen Sie einen Bereich oder eine Liste angeben, -f\"{u}r alle anderen Parameter, bis auf Volumes, nur eine Liste. -Eine Liste ist gleichbedeutend mit mehrfachen Angaben eines Parameters. -Ein Beispiel - -\footnotesize -\begin{verbatim} -Volume = Test-01 -Client = "My machine", "Backup machine" -FileIndex = 1-20, 35 -\end{verbatim} -\normalsize - -passt auf alle Dateien auf dem Volume Test-01 {\bf UND} von Client My machine -{\bf ODER} vom Client Backup machine {\bf UND} mit dem Fileindex 1 {\bf ODER} -2 {\bf ODER} 3 ... {\bf ODER} 20 {\bf ODER} 35. - -Wie oben erw\"{a}hnt, k\"{o}nnen mehrere Volume-Eintr\"{a}ge in der selben -Bootstrap-Datei stehen. Jedes Vorkommen eines Volume-Eintrags beginnt einen neuen -Satz an Filterregeln der auf dem angegebenen Volume angewendet wird und mit weiteren -Volume-Eintr\"{a}gen \"{u}ber {\bf ODER} verkn\"{u}pft wird. - -Als ein Beispiel nehmen wir an, dass wir, mit dem Console-Kommando {\bf query} , -nach dem Satz Volumes fragen, die ben\"{o}tigt werden, um alle Dateien des Clients Rufus -wiederherstellen zu k\"{o}nnen: - -\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 - -Die Ausgabe zeigt uns, dass wir vier Jobs wiederherstellen m\"{u}ssen. -Der erste ist eine vollst\"{a}ndige Sicherung, und die drei folgenden sind inkrementelle Sicherungen. - -Die folgende Bootstrap-Datei wird ben\"{o}tigt um alle Dateien wiederherzustellen: - -\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 - -Als letztes Beispiel nehmen wir an, dass die erste vollst\"{a}ndige Sicherung sich -\"{u}ber zwei verschiedene Volumes erstreckt. Die Ausgabe des Console-Kommandos -{\bf query} sieht eventuell so aus: - -\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 - -und die folgende Bootstrap-Datei wird ben\"{o}tigt, um diese Dateien wiederherzustellen: - -\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 - -\section{automatische Erzeugung der Bootstrap-Datei} -\index[general]{Datei!automatische Erzeugung der Bootstrap-} -\index[general]{automatische Erzeugung der Bootstrap-Datei } - - -Eine Sache ist vermutlich wissenswert: die Bootstrap-Dateien die automatisch -am Ende eines jeden Jobs erzeugt werden, sind nicht so optimiert wie die, die -durch das Console-Kommando {\bf restore} erzeugt werden. -Das ist so, weil die Bootstrap-Dateien, die am Ende des Jobs erstellt werden, -alle Dateien enthalten, die f\"{u}r diesen Job auf das Volume geschrieben wurden. -Die Konsequenz ist, dass alle Dateien die w\"{a}rend eines inkrementellen oder differenziellen -Jobs geschrieben wurden, beim Wiederherstellen zun\"{a}chst von der vollst\"{a}ndigen Sicherung -wiederhergestellt werden und dann von der inkrementellen oder differenziellen Sicherung. - -Wenn die Bootstrap-Datei f\"{u}r die Wiederherstellung erstellt wird, -wird immer nur eine Version der Datei (die aktuellste) zur Wiederherstellung aufgelistet. - -Falls Ihr Rechner noch ein bischen Zeit \"{u}brig hat, k\"{o}nnen Sie Ihre -Bootstrap-Dateien optimieren, indem Sie das folgende tun: - -\footnotesize -\begin{verbatim} - ./bconsole - restore client=xxx select all - done - no - quit - Backup bootstrap file. -\end{verbatim} -\normalsize - -Das wird allerdings nicht funktionieren, wenn Ihr Client mehrere Filesets hat, -denn dann wird noch eine weitere Eingabe erforderlich. -Das Console-Kommando {\bf restore client=xxx select all} erstellt den Restore-Dateibaum -und w\"{a}hlt alle Dateien aus, {\bf done} beendet den Auswahlmodus, dann wird die Bootstrap-Datei f\"{u}r diesen -Wiederherstellungs-Job geschrieben. -Das {\bf no} beantwortet die Frage {\bf Do you want to run this (yes/mod/no)}. -{\bf quit} beendet das Console-Programm, danach kann die neu erstellte Bootstrap-Datei gesichert werden. - -\label{bscanBootstrap} -\section{Bootstrap-Datei f\"{u}r bscan} -\index[general]{bscan} -\index[general]{bscan!Bootstrap-Datei} -\index[general]{bscan Bootstrap-Datei} -Wenn Sie mit dem bscan-Programm sehr viele Volumes abfragen m\"{u}ssen, -wird Ihr Kommando eventuell das Limit der Kommandozeilel\"{a}nge \"{u}berschreiten (511 Zeichen). -In dem Fall, k\"{o}nnen Sie eine einfache Bootstrap-Datei erzeugen, die nur Volume-Namen enth\"{a}lt. -Ein Beispiel: - -\footnotesize -\begin{verbatim} -Volume="Vol001" -Volume="Vol002" -Volume="Vol003" -Volume="Vol004" -Volume="Vol005" -\end{verbatim} -\normalsize - - -\section{ein weiteres Beispiel der Bootstrap-Datei} -\index[general]{Beispiel ein weiteres!Bootstrap-Datei } -\index[general]{ein weiteres Beispiel der Bootstrap-Datei } - -Wenn Sie nur einen einzigen Job vom Volume lesen wollen, k\"{o}nnen Sie das -durch ausw\"{a}hlen der Job-Id tun (Funktion nicht getestet), oder besser noch, -Sie geben die VolumeSessionTime und VolumeSessionID an, falls Sie sie wissen. -(Die beiden Werte werden auf dem Job-Report ausgegeben und sind in der Katalog-Datenbank -zu finden.) -Die VolumeSessionTime und VolumeSessionID anzugeben ist auch die Art, -wie Bacula Wiederherstellungen durchf\"{u}hrt. -Eine Bootstrap-Datei kann dann wie folgt aussehen: - -\footnotesize -\begin{verbatim} -Volume="Vol001" -VolSessionId=10 -VolSessionTime=1080847820 -\end{verbatim} -\normalsize - -Wenn Sie wissen, wie viele Dateien gesichert wurden (siehe den Job-Report), -k\"{o}nnen Sie die Auswahl enorm beschleunigen, indem Sie der Bootstrap-Datei -folgendes hinzuf\"{u}gen (angenommen es waren 157 Dateien): - -\footnotesize -\begin{verbatim} -FileIndex=1-157 -Count=157 -\end{verbatim} -\normalsize - -Letztendlich, wenn Sie auch die File-Nummer wissen, wo auf dem Volume die -ausgew\"{a}hlten Dateien liegen, k\"{o}nnen Sie das bcopy-Programm veranlassen, -zum richtigen File auf dem Volumen zu springen, ohne jeden Eintrag lesen zu m\"{u}ssen: - -\footnotesize -\begin{verbatim} -VolFile=20 -\end{verbatim} -\normalsize - -Bootstrap-Dateien sind weder magisch noch kompliziert. Sie zu lesen und Bacula sinnvoll mit ihnen -arbeiten zu lassen *ist* magisch, aber darum brauchen Sie sich nicht k\"{u}mmern. - -Wenn Sie eine *echte* Bootstrap-Datei sehen wollen, starten sie das Console-Programm und geben Sie -{\bf restore} ein, w\"{a}hlen ein paar Dateien aus und antworten mit {\bf no}, -wenn Sie gefragt werden, ob Sie die Wiederherstellung starten wollen. Dann finden Sie die Bootstrap-Datei -im Arbeitsverzeichnis des Director-Dienstes (z.B. unter /var/lib/bacula/backup-dir.restore.2.bsr). diff --git a/docs/manual-de/bugs.tex b/docs/manual-de/bugs.tex deleted file mode 100644 index 6f4b9b6a..00000000 --- a/docs/manual-de/bugs.tex +++ /dev/null @@ -1,19 +0,0 @@ -%% -%% - -\section{Bacula Bugs} -\label{BugsChapter} -\index[general]{Bacula Bugs } -\index[general]{Bugs!Bacula } - -Zum Gl\"{u}ck gibt es in Bacula nicht sehr viele Programmfehler (Bugs), -aber dank Dan Langille haben wir eine \elink{Bug-Datenbank}{http://bugs.bacula.org}, -wo Fehler gemeldet werden k\"{o}nnen. Wenn ein Fehler behoben ist, wird normalerweise ein -Programmst\"{u}ck das den Fehler korrigiert (Patch), auf der Seite des Fehlerberichts -ver\"{o}ffentlicht. - -Das Verzeichnis {\bf patches} im aktuellen SVN enth\"{a}lt eine Liste aller Programmkorrekturen -die f\"{u}r \"{a}ltere Bacula-Versionen ver\"{o}ffentlicht wurden. - -Eine "grobe" \"{U}bersicht der momentanen Arbeit und bekannter Probleme befindet sich -auch in der Datei {\bf kernstodo} im Hauptverzeichnis der Bacula-Programmquellen. diff --git a/docs/manual-de/catmaintenance.tex b/docs/manual-de/catmaintenance.tex deleted file mode 100644 index c5c175ea..00000000 --- a/docs/manual-de/catmaintenance.tex +++ /dev/null @@ -1,730 +0,0 @@ -%% -%% - -\chapter{Katalog Verwaltung} -\label{CatMaintenanceChapter} -\index[general]{Verwaltung!Katalog } -\index[general]{Katalog Verwaltung} - -Ohne eine ordnungsgem\"{a}{\ss}e Einrichtung und Verwaltung kann es sein, -dass Ihr Katalog immer gr\"{o}{\ss}er wird wenn Jobs laufen und Daten gesichert werden. -Zudem kann der Katalog ineffizient und langsam werden. Wie schnell der Katalog w\"{a}chst, -h\"{a}ngt von der Anzahl der Jobs und der Menge der dabei gesicherten Dateien ab. -Durch das L\"{o}schen von Eintr\"{a}gen im Katalog kann Platz geschaffen werden f\"{u}r -neue Eintr\"{a}ge der folgenden Jobs. Durch regelm\"{a}{\ss}iges l\"{o}schen alter abgelaufener -Daten (\"{a}lter als durch die Aufbewahrungszeitr\"{a}ume (Retention Periods) angegeben), -wird daf\"{u}r gesorgt, dass die Katalog-Datenbank eine konstante Gr\"{o}{\ss}e beibeh\"{a}lt. - -Sie k\"{o}nnen mit der vorgegebenen Konfiguration beginnen, sie enth\"{a}lt bereits -sinnvolle Vorgaben f\"{u}r eine kleine Anzahl von Clients (kleiner 5), in diesem Fall -wird die Katalogwartung, wenn Sie einige hundert Megabyte freien Plattenplatz haben, -nicht dringlich sein. Was aber auch immer der Fall ist, einiges Wissen \"{u}ber -die Retention Periods/Aufbewahrungszeitr\"{a}ume der Daten im Katalog und auf den Volumes ist hilfreich. - -\section{Einstellung der Aufbewahrungszeitr\"{a}ume} -\label{Retention} -\index[general]{Einstellung der Aufbewahrungszeitr\"{a}ume } -\index[general]{Zeitr\"{a}ume!Einstellung der Aufbewahrungs- } - -Bacula benutzt drei verschiedene Aufbewahrungszeitr\"{a}ume: -die {\bf File Retention}: der Aufbewahrungszeitraum f\"{u}r Dateien, -die {\bf Job Retention}: der Aufbewahrungszeitraum f\"{u}r Jobs und -die {\bf Volume Retention}: der Aufbewahrungszeitraum f\"{u}r Volumes. -Von diesen drei ist der Aufbewahrungszeitraum f\"{u}r Dateien der entscheidende, -wenn es darum geht, wie gro{\ss} die Datenbank werden wird. - -Die {\bf File Retention} und die {\bf Job Retention} werden in der Client-Konfiguration, -wie unten gezeigt, angegeben. Die {\bf Volume Retention} wird in der Pool-Konfiguration -angegeben, genauere Informationen dazu finden Sie im n\"{a}chsten Kapitel dieses Handbuchs. - -\begin{description} - -\item [File Retention = \lt{}time-period-specification\gt{}] - \index[dir]{File Retention } - Der Aufbewahrungszeitraum f\"{u}r Dateien gibt die Zeitspanne an, die die -Datei-Eintr\"{a}ge in der Katalog-Datenbank aufbewahrt werden. -Wenn {\bf AutoPrune} in der Client-Konfiguration auf {\bf yes} gesetzt ist, -wird Bacula die Katalog-Eintr\"{a}ge der Dateien l\"{o}schen, die \"{a}lter als -dieser Zeitraum sind. Das L\"{o}schen erfolgt nach Beendigung eines Jobs des entsprechenden Clients. -Bitte beachten Sie, dass die Client-Datenbank-Eintr\"{a}ge eine Kopie der Aufbewahrungszeitr\"{a}ume -f\"{u}r Dateien und Jobs enthalten, Bacula aber die Zeitr\"{a}ume aus der aktuellen Client-Konfiguration -des Director-Dienstes benutzt um alte Katalog-Eintr\"{a}ge zu l\"{o}schen. - -Da die Datei-Eintr\"{a}ge ca. 80 Prozent der Katalog-Datenbankgr\"{o}{\ss}e ausmachen, -sollten Sie sorgf\"{a}lltig ermitteln \"{u}ber welchen Zeitraum Sie die Eintr\"{a}ge aufbewahren wollen. -Nachdem die Datei-Eintr\"{a}ge gel\"{o}scht wurden, ist es nicht mehr m\"{o}glich einzelne dieser Dateien -mit einem R\"{u}cksicherungs-Job wiederherzustellen, aber die Bacula-Versionen 1.37 und sp\"{a}ter -sind in der Lage, aufgrund des Job-Eintrags im Katalog, alle Dateien des Jobs zur\"{u}ckzusichern -solange der Job-Eintrag im Katalog vorhanden ist. - -Aufbewahrungszeitr\"{a}ume werden in Sekunden angegeben, aber der Einfachheit halber sind auch -eine Reihe von Hilfsangaben m\"{o}glich, so dass man Minuten, Stunden, Tage, Wochen, -Monate, Quartale und Jahre konfigurieren kann. Lesen Sie bitte das \ilink{Konfigurations-Kapitel}{Time} -dieses Handbuchs um mehr \"{u}ber diese Hilfsangaben zu erfahren. - -Der Standardwert der Aufbewahrungszeit f\"{u}r Dateien ist 60 Tage. - -\item [Job Retention = \lt{}time-period-specification\gt{}] - \index[dir]{Job Retention } - Der Aufbewahrungszeitraum f\"{u}r Jobs gibt die Zeitspanne an, die die -Job-Eintr\"{a}ge in der Katalog-Datenbank aufbewahrt werden. -Wenn {\bf AutoPrune} in der Client-Konfiguration auf {\bf yes} gesetzt ist, -wird Bacula die Katalog-Eintr\"{a}ge der Jobs l\"{o}schen, die \"{a}lter als -dieser Zeitraum sind. Beachten Sie, dass wenn ein Job-Eintrag gel\"{o}scht wird, -auch alle zu diesem Job geh\"{o}renden Datei- und JobMedia-Eintr\"{a}ge aus dem -Katalog gel\"{o}scht werden. Dies passiert unabh\"{a}ngig von der Aufbewahrungszeit f\"{u}r Dateien, -infolge dessen wird die Aufbewahrungszeit f\"{u}r Dateien normalerweise k\"{u}rzer sein als f\"{u}r Jobs. - -Wie oben erw\"{a}hnt, sind Sie nicht mehr in der Lage einzelne Dateien eines Jobs zur\"{u}ckzusichern, -wenn die Datei-Eintr\"{a}ge aus der Katalog-Datenbank entfernt wurden. Jedoch, solange der Job-Eintrag -im Katalog vorhanden ist, k\"{o}nnen Sie immer noch den kompletten Job mit allen Dateien wiederherstellen -(ab Bacula-Version 1.37 und gr\"{o}{\ss}er). Daher ist es eine gute Idee, die Job-Eintr\"{a}ge im Katalog -l\"{a}nger als die Datei-Eintr\"{a}ge aufzubewahren. - -Aufbewahrungszeitr\"{a}ume werden in Sekunden angegeben, aber der Einfachheit halber sind auch -eine Reihe von Hilfsangaben m\"{o}glich, so dass man Minuten, Stunden, Tage, Wochen, -Monate, Quartale und Jahre konfigurieren kann. Lesen Sie bitte das \ilink{Konfigurations-Kapitel}{Time} -dieses Handbuchs um mehr \"{u}ber diese Hilfsangaben zu erfahren. - -Der Standardwert der Aufbewahrungszeit f\"{u}r Jobs ist 180 Tage. - -\item [AutoPrune = \lt{}yes/no\gt{}] - \index[dir]{AutoPrune } - Wenn AutoPrune auf {\bf yes} (Standard) gesetzt ist, wird Bacula nach jedem Job -automatisch \"{u}berpr\"{u}fen, ob die Aufbewahrungszeit f\"{u}r bestimmte Dateien und/oder Jobs -des gerade gesicherten Clients abgelaufen ist und diese aus dem Katalog entfernen. -Falls Sie AutoPrune durch das Setzen auf {\bf no} ausschalten, wird Ihre Katalog-Datenbank mit jedem -gelaufenen Job immer gr\"{o}{\ss}er werden. -\end{description} - -\label{CompactingMySQL} -\section{Komprimieren Ihrer MySQL Datenbank} -\index[general]{Datenbank!Komprimieren Ihrer MySQL } -\index[general]{Komprimieren Ihrer MySQL Datenbank } - -Mit der Zeit, wie oben schon angemerkt, wird Ihre Datenbank dazu neigen zu wachsen. -Auch wenn Bacula regelm\"{a}{\ss}ig Datei-Eintr\"{a}ge l\"{o}scht, wird die {\bf MySQL}-Datenbank -st\"{a}ndig gr\"{o}{\ss}er werden. Um dies zu vermeiden, muss die Datenbank komprimiert werden. -Normalerweise kennen gro{\ss}e kommerzielle Datenbanken, wie Oracle, bestimmte Kommandos -um den verschwendeten Festplattenplatz wieder freizugeben. MySQL hat das {\bf OPTIMIZE TABLE} -Kommando und bei SQLite (Version 2.8.4 und gr\"{o}{\ss}er) k\"{o}nnen Sie das {\bf VACUUM} -Kommando zu diesem Zweck benutzen. Wir \"{u}berlassen es Ihnen, die N\"{u}tzlichkeit von -{\bf OPTIMIZE TABLE} oder {\bf VACUUM} zu ermitteln. - -Alle Datenbanken haben Hilfsmittel, um die enthaltenen Daten im ASCII-Format in eine Datei zu schreiben -und diese Datei dann auch wieder einzulesen. Wenn man das tut, wird die Datenbank erneut erzeugt, was ein -sehr kompaktes Datenbank-Format als Ergebnis hat. Weiter unten zeigen wir Ihnen, wie Sie das bei -MySQL, SQLite und PostgreSQL durchf\"{u}hren k\"{o}nnen. - -Bei einer {\bf MySQL} Datenbank k\"{o}nnen Sie den Inhalt der Katalog-Datenbank mit den folgenden Kommandos -in eine ASCII-Datei (bacula.sql) schreiben und neu in die Datenbank importieren: - -\footnotesize -\begin{verbatim} -mysqldump -f --opt bacula > bacula.sql -mysql bacula < bacula.sql -rm -f bacula.sql -\end{verbatim} -\normalsize - -Abh\"{a}ngig von der Gr\"{o}{\ss}e Ihrer Datenbank, wird dies mehr oder weniger Zeit und auch Festplattenplatz -ben\"{o}tigen. Zum Beispiel, wenn ich in das Verzeichnis wechsle, wo meine MySQL-Datenbank liegt (typischerweise -/var/lib/mysql) und dieses Kommando ausf\"{u}hre: - -\footnotesize -\begin{verbatim} -du bacula -\end{verbatim} -\normalsize - -bekomme ich die Ausgabe {\bf 620,644}, was bedeutet dass das Verzeichnis bacula 620.644 Bl\"{o}cke -von 1024 Bytes auf der Festplatte belegt, meine Datenbank enth\"{a}lt also ca. 635 MB an Daten. -Nachdem ich das {\bf mysqldump} ausgef\"{u}hrt habe, ist die dabei entstandene Datei bacula.sql -{\bf 174.356} Bl\"{o}cke gro{\ss}, wenn diese Datei mit dem Kommando {\bf mysql bacula < bacula.sql} -wieder in die Datenbank importiert wird, ergibt sich eine Datenbankgr\"{o}{\ss}e von nur noch {\bf 210.464} -Bl\"{o}cken. Mit anderen Worten, die komprimierte Version meiner Datenbank, die seit ca. 1 Jahr -in Benutzung ist, ist ungef\"{a}hr nur noch ein Drittel so gro{\ss} wie vorher. - -Als Konsequenz wird empfohlen, auf die Gr\"{o}{\ss}e der Datenbank zu achten und sie von Zeit zu Zeit -(alle sechs Monate oder j\"{a}hrlich) zu komprimieren. - -\label{DatabaseRepair} -\label{RepairingMySQL} -\section{Reparatur Ihrer MySQL Datenbank} -\index[general]{Datenbank!Reparatur Ihrer MySQL } -\index[general]{Reparatur Ihrer MySQL Datenbank } - -Wenn Sie bemerken, dass das Schreiben der MySQL-Datenbank zu Fehlern f\"{u}hrt, -oder das der Director-Dienst h\"{a}ngt, wenn er auf die Datenbank zugreift, -sollten Sie sich die MySQL Datenbank\"{u}berpr\"{u}fungs- und Reparaturprogramme ansehen. -Welches Programm Sie laufen lassen sollten, h\"{a}ngt mit der von Ihnen benutzten Datenbank- -Indizierung zusammen. Wenn Sie das Standardverfahren nutzen, werden Sie vermutlich {\bf myisamchk} -laufen lassen. F\"{a}r n\"{a}here Information lesen Sie bitte auch: -\elink{http://dev.mysql.com/doc/refman/5.1/de/client-utility-programs.html} -{http://dev.mysql.com/doc/refman/5.1/de/client-utility-programs.html}. - -Falls die auftretenden Fehler einfache SQL-Warnungen sind, sollten Sie zuerst das von Bacula mitgelieferte -dbcheck-Programm ausf\"{u}hren, bevor Sie die MySQL-Datenbank-Reparaturprogramme nutzen. -Dieses Programm kann verwaiste Datenbankeintr\"{a}ge finden und andere Inkonsistenzen in der -Katalog-Datenbank beheben. - -Eine typische Ursache von Datenbankproblemen ist das Volllaufen einer Partition. -In solch einem Fall muss entweder zus\"{a}tzlicher Platz geschaffen werden, oder -belegter Platz freigegeben werden, bevor die Datenbank mit {\bf myisamchk} repariert werden kann. - -Hier ist ein Beispiel, wie man eine korrupte Datenbank reparieren k\"{o}nnte, falls nach dem Vollaufen -einer Partition die Datenbankprobleme mit {\bf myisamchk -r} nicht behoben werden k\"{o}nnen: - -kopieren Sie folgende Zeilen in ein Shell-Script names {\bf repair}: -\footnotesize -\begin{verbatim} -#!/bin/sh -for i in *.MYD ; do - mv $i x${i} - t=`echo $i | cut -f 1 -d '.' -` - mysql bacula <bacula.db -select * from sqlite_master where type='index' and tbl_name='File'; -\end{verbatim} -\normalsize - -Falls ein Index fehlt, im besonderen der {\bf JobId}-Index, k\"{o}nnen Sie ihn mit den folgenden Befehlen erstellen: - -\footnotesize -\begin{verbatim} -mysql bacula -CREATE INDEX file_jobid_idx on File (JobId); -CREATE INDEX file_jfp_idx on File (Job, FilenameId, PathId); -\end{verbatim} -\normalsize - - - -\label{CompactingPostgres} -\section{Komprimieren Ihrer PostgreSQL Datenbank} -\index[general]{Datenbank!Komprimieren Ihrer PostgreSQL } -\index[general]{Komprimieren Ihrer PostgreSQL Datenbank } - -\"{U}ber die Zeit, wie schon oben angemerkt, wird Ihre Datenbank wachsen. -Auch wenn Bacula regelm\"{a}{\ss}ig alte Daten l\"{o}scht, wird das PostgreSQL Kommando {\bf VACUUM} -Ihnen helfen die Datenbank zu komprimieren. Alternativ wollen Sie eventuell das {\bf vacuumdb}-Kommando nutzen, -das vom cron-Dienst gestartet werden kann. - -Alle Datenbanken haben Hilfsmittel, um die Daten in eine ASCII-Datei zu schreiben um sie dann erneut einzulesen. -Wenn Sie das tun, wird die Datenbank komplett neu aufgebaut und so eine kompaktere Version entstehen. -Wie Sie so etwas tun k\"{o}nnen, zeigt Ihnen das folgende PostgreSQL Beispiel. - -Bei einer PostgreSQL-Datenbank lassen Sie die Daten in eine ASCII-Datei schreiben und neu einlesen, -wenn Sie diese Kommandos ausf\"{u}hren: - -\footnotesize -\begin{verbatim} -pg_dump -c bacula > bacula.sql -cat bacula.sql | psql bacula -rm -f bacula.sql -\end{verbatim} -\normalsize - -Abh\"{a}gig von Ihrer Datenabnkgr\"{o}{\ss}e wird dieser Vorgang mehr oder -weniger Zeit und Festplattenplatz in Anspruch nehmen. Sie sollten vorher -in das Arbeitsverzeichnis Ihrer Datenbank wechseln (typischerweise -/var/lib/postgres/data) und die Gr\"{o}{\ss}e \"{u}berpr\"{u}fen. - -Bestimmte PostgreSQL-Nutzer empfehlen nicht die oben genannte Prozedur, sie sind der Meinung: -bei PostgreSQL ist es nicht notwendig, die Daten zu exportieren um sie dann wieder einzulesen. -Das normale Ausf\"{u}hren des {\bf VACUUM}-Kommandos reicht, um die Datenbank performant zu halten. -Wenn Sie es ganz genau machen wollen, benutzen Sie speziellen Kommandos {\bf VACUUM FULL, REINDEX} und {\bf CLUSTER} -um sich den Umweg \"{u}ber das exportieren und wiedereinlesen der Daten zu ersparen. - -Zum Schlu{\ss} wollen Sie vielleicht noch einen Blick auf die zugeh\"{o}rige PostgreSQL-Dokumentation werfen, -Sie finden sie (auf englisch) unter: -\elink{http://www.postgresql.org/docs/8.2/interactive/maintenance.html} -{http://www.postgresql.org/docs/8.2/interactive/maintenance.html}. - -\section{Komprimieren Ihrer SQLite Datenbank} -\index[general]{Komprimieren Ihrer SQLite Datenbank} -\index[general]{Datenbank!Komprimieren Ihrer SQLite } - -Lesen Sie bitte zuerst die vorherigen Abschnitte die erkl\"{a}ren, warum es erforderlich ist, eine Datenbank zu komprimieren. -SQLite-Versionen gr\"{o}{\ss}er 2.8.4 haben das {\bf Vacuum}-Kommando um die Datenbank zu komprimieren: - -\footnotesize -\begin{verbatim} -cd {\bf working-directory} -echo 'vacuum;' | sqlite bacula.db -\end{verbatim} -\normalsize - -Als Alternative k\"{o}nnen Sie auch die folgenden Kommandos (auf Ihr System angepasst) benutzen: - -\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 - -Wobei {\bf working-directory} das Verzeichnis ist, dass Sie in Ihrer Director-Dienst-Konfiguration angegeben haben. -Beachten Sie bitte, dass es im Fall von SQLite erforderlich ist, die alte Datenbank komplett zu l\"{o}schen, -bevor die komprimierte Version angelegt werden kann. - -\section{Migration von SQLite zu MySQL} -\index[general]{MySQL!Migration von SQLite zu } -\index[general]{Migration von SQLite zu MySQL } - -Wenn Sie Bacula anfangs mit SQLite zusammen benutzt haben, gibt es sp\"{a}ter -eine Reihe von Gr\"{u}nden, weshalb Sie eventuell auf MySQL umsteigen wollen: -SQLite belegt mehr Festplattenplatz f\"{u}r dieselbe Datenmenge als MySQL; -falls die Datenbank besch\"{a}digt wird, ist es mit SQLite problematischer als -bei MySQL oder PostgreSQL, sie wiederherzustellen. Viele Benutzer sind erfolgreich -von SQLite auf MySQL umgestiegen, indem sie zuerst die Daten exportiert haben und sie dann -mit einem z.B. Perl-Script in ein passendes Format konvertiert haben, um sie in die -MySQL-Datenbank zu importieren. Dies ist aber kein sehr einfacher Vorgang. - -\label{BackingUpBacula} -\section{Sichern Ihrer Bacula Datenbank} -\index[general]{Sichern Ihrer Bacula Datenbank} -\index[general]{Datenbank!Sichern Ihrer Bacula } - -Falls jemals der Rechner auf dem Ihre Bacula-Installation l\"{a}uft abst\"{u}rzt, -und Sie diesen wiederherstellen m\"{u}ssen, wird es einer der ersten Schritte sein, -die Datenbank zur\"{u}ckzusichern. Obwohl Bacula fr\"{o}hlich die Datenbank sichert, -wenn sie im FileSet angegeben ist, ist das kein sehr guter Weg, da Bacula die Datenbank -\"{a}ndert, w\"{a}hrend sie gesichert wird. Dadurch ist die gesicherte Datenbank wahrscheinlich -in einem inkonsistenten Zustand. Noch schlimmer ist, dass die Datenbank gesichert wird, -bevor Bacula alle Aktualisierungen durchf\"{u}hren kann. - -Um diese Problem zu umgehen, m\"{u}ssen Sie die Datenbank sichern nachdem alle Backup-Jobs -gelaufen sind. Zus\"{a}tzlich werden Sie wohl eine Kopie der Datenbank erstellen wollen, -w\"{a}hrend Bacula keine Aktualisierungen vornimmt. Um das zu erreichen, k\"{o}nnen Sie -die beiden Scripte {\bf make\_catalog\_backup} und {\bf delete\_catalog\_backup} benutzen, -die Ihrer Bacula-Version beiliegen. Diese Dateien werden, zusammen mit den anderen Bacula-Scripts, -automatisch erzeugt. Das erste Script erzeugt eine ASCII-Kopie Ihrer Datenbank namens {\bf bacula.sql} -in dem Arbeitsverzeichnis, dass Sie in der Konfiguration angegeben haben. Das zweite Script -l\"{o}scht die Datei {\bf bacula.sql} wieder. - -Die grundlegenden Arbeitsschritte damit alles korrekt funktioniert, sind folgende: - -\begin{itemize} -\item alle Backup-Jobs laufen lassen -\item wenn alle Jobs beendet sind, wird ein Catalog Backup-Job gestartet -\item Der Catalog Backup-Job muss nach den anderen Backup-Jobs laufen - -\item Benutzen Sie {\bf RunBeforeJob} um die ASCII-Sicherungsdatei zu erstellen und - {\bf RunAfterJob} um sie wieder zu l\"{o}schen -\end{itemize} - -Angenommen Sie starten alle Ihre Backup-Jobs nachts um 01:05, k\"{o}nnen Sie das Catalog-Backup -mit der folgenden zus\"{a}tzlichen Director-Dienst-Konfiguration ausf\"{u}hren lassen: - -\footnotesize -\begin{verbatim} -# Catalog-Datenbank-Backup (nach der n\"{a}chtlichen Sicherung) -Job { - Name = "BackupCatalog" - Type = Backup - Client=rufus-fd - FileSet="Catalog" - Schedule = "WeeklyCycleAfterBackup" - Storage = DLTDrive - Messages = Standard - Pool = Default - # Achtung!!! Das Passwort auf der Kommandozeile zu \"{u}bergeben ist nicht sicher. - # Lesen Sie bitte die Kommentare in der Datei make_catalog_backup. - RunBeforeJob = "/home/kern/bacula/bin/make_catalog_backup" - RunAfterJob = "/home/kern/bacula/bin/delete_catalog_backup" - Write Bootstrap = "/home/kern/bacula/working/BackupCatalog.bsr" -} -# Diese Schedule starten das Catalog-Backup nach den anderen Sicherungen -Schedule { - Name = "WeeklyCycleAfterBackup - Run = Level=Full sun-sat at 1:10 -} -# Das FileSet f\"{u}r die ASCII-Kopie der Datenbank -FileSet { - Name = "Catalog" - Include { - Options { - signature=MD5 - } - File = \lt{}working_directory\gt{}/bacula.sql - } -} -\end{verbatim} -\normalsize - -Stellen Sie sicher, dass, wie in dem Beispiel, eine Bootstrap-Datei geschrieben wird. -Bevorzugterweise wird eine Kopie dieser Bootstrap-Datei auf einem andern Computer gespeichert. -Dies erlaubt eine schnelle Wiederherstellung der Datenbank, falls erforderlich. Wenn Sie -keine Bootstrap-Datei haben, ist es trotzdem m\"{o}glich, erfordert aber mehr Arbeit und dauert l\"{a}nger. - - -\label{BackingUpBaculaSecurityConsiderations} -\section{Sicherheitsaspekte} -\index[general]{Sicherung der Bacula Datenbank - Sicherheitsaspekte } -\index[general]{Datenbank!Sicherung der Bacula Datenbank - Sicherheitsaspekte } - -Das Script make\_catalog\_backup wird als Beispiel bereitgestellt, wie Sie Ihre -Bacula Datenbank sichern k\"{o}nnen. Wir erwarten das Sie, entsprechend Ihrer Situation, -Vorsichtsma{\ss}nahmen treffen. -make\_catalog\_backup ist so ausgelegt, dass das Passwort auf der Kommandozeile \"{u}bergeben wird. -Das ist in Ordnung, solange sich nur vertrauensw\"{u}rdige Benutzer am System anmelden k\"{o}nnen, -ansonsten ist es inakzeptabel. Die meisten Datenbanksysteme bieten eine alternative Methode an, -um das Passwort nicht auf der Kommandozeile \"{u}bergeben zu m\"{u}ssen. - -Das Script make\_catalog\_backup enth\"{a}lt einige Warnungen dies betreffend. Bitte lesen Sie -die Kommentare im Script. - -Bei PostgreSQL k\"{o}nnen Sie z.B. eine Passwort-Datei verwenden, siehe -\elink{.pgpass}{http://www.postgresql.org/docs/8.2/static/libpq-pgpass.html}, -und MySQL hat die \elink{ .my.cnf}{http://dev.mysql.com/doc/refman/5.1/de/password-security.html}. - -Wir hoffen, dass wir Ihnen damit etwas helfen konnten, -aber nur Sie k\"{o}nenn beurteilen, was in Ihrer Situation erforderlich ist. - - -\label{BackingUPOtherDBs} -\section{Sicherung anderer Datenbanken} -\index[general]{Sicherung anderer Datenbanken } -\index[general]{Datenbanken!Sicherung anderer } - -Wie oben schon erw\"{a}hnt wurde, f\"{u}hrt das Sichern von Datenbank-Dateien im laufenden Betrieb -dazu, dass die gesicherten Dateien sich wahrscheinlich in einem inkonsistenten Zustand befinden. - -Die beste L\"{o}sung daf\"{u}r ist, die Datenbank vor der Sicherung zu stoppen, -oder datenbankspezifische Hilfsprogramme zu verwenden, um eine g\"{u}ltige Sicherungsdatei zu erstellen, -die Bacula dann auf die Volumes schreiben kann. Wenn Sie unsicher sind, wie Sie das am besten mit der -von Ihnen benutzten Datenbank erreichen k\"{o}nnen, hilft Ihnen eventuell die Webseite von Backup Central -weiter. Auf \elink{ Free Backup and Recovery Software}{http://www.backupcentral.com/toc-free-backup-software.html} -finden Sie Links zu Scripts die zeigen, wie man die meisten gr\"{o}{\ss}eren Datenbanken sichern kann. - -\label{Size} - -\section{Datenbank Gr\"{o}{\ss}e} -\index[general]{Gr\"{o}{\ss}e!Datenbank } -\index[general]{Datenbank Gr\"{o}{\ss}e } - -Wenn Sie nicht automatisch alte Datens\"{a}tze aus Ihrer Katalog-Datenbank l\"{o}schen lassen, -wird Ihre Datenbank mit jedem gelaufenen Backup-Job wachsen (siehe auch weiter oben). -Normalerweise sollten Sie sich entscheiden, wie lange Sie die Datei-Eintr\"{a}ge im Katalog -aufbewaren wollen und die {\bf File Retention} entsprechend konfigurieren. Dann k\"{o}nnen Sie -entweder abwarten wie gro{\ss} Ihre Katalog-Datenbank werden wird, oder es aber auch unge\"{a}hr -berechnen. Dazu m\"{u}ssen Sie wissen, dass f\"{u}r jede gesicherte Datei in etwa 154 Bytes in der -Katalog-Datenbank belegt werden und wieviele Dateien Sie auf wievielen Computern sichern werden. - -Ein Beispiel: angenommen Sie sichern zwei Computer, jeder mit 100.000 Dateien. -Weiterhin angenommen, Sie machen ein w\"{o}chentliches Full-Backup und ein -inkrementelles jeden Tag, wobei bei einem inkrementellen Backup typischerweise 4.000 Dateien -gesichert werden. Die ungef\"{a}hre Gr\"{o}{\ss}e Ihrer Datenbank nach einem Monat -kann dann so berechnet werden: - -\footnotesize -\begin{verbatim} - Gr\"{o}{\ss}e = 154 * Anzahl Computer * (100.000 * 4 + 10.000 * 26) -\end{verbatim} -\normalsize - -wenn ein Monat mit 4 Wochen angenommen wird, werden also 26 inkrementelle Backups im Monat laufen. -Das ergibt das folgende: -\footnotesize -\begin{verbatim} - Gr\"{o}{\ss}e = 154 * 2 * (100.000 * 4 + 10.000 * 26) -or - Gr\"{o}{\ss}e = 308 * (400.000 + 260.000) -or - Gr\"{o}{\ss}e = 203.280.000 Bytes -\end{verbatim} -\normalsize - -f\"{u}r die beiden oben angenommen Computer k\"{o}nnen wir also davon ausgehen, dass die Datenbank -in etwa 200 Megabytes gro{\ss} wird. Nat\"{u}rlich h\"{a}ngt dieser Wert davon ab, wieviele -Dateien wirklich gesichert werden. - -Unten sehen Sie ein paar Statistiken f\"{u}r eine MySQL-Datenbank die -Job-Eintr\"{a}ge f\"{u}r 5 Clients \"{u}ber 8.5 Monate und -Datei-Eintr\"{a}ge \"{u}ber 80 Tage enth\"{a}lt (\"{a}ltere -Datei-Eintr\"{a}ge wurden schon gel\"{o}scht). Bei diesen 5 Clients wurden -nur die Benutzer- und System-Dateien gesichert, die sich st\"{a}ndig -\"{a}ndern. Bei allen anderen Dateien wird angenommen, dass sie leicht aus -den Software-Paketen des Betriebssystems wiederherstellbar sind. - -In der Liste sind die Dateien (die den MySQL-Tabellen entsprechen) mit der Endung .MYD -die, die die eigentlichen Daten enthalten und die mit der Endung .MYI enthalten die Indexe. - -Sie werden bemerken, dass die meisten Eintr\"{a}ge in der Datei File.MYD -(die die Datei-Attribute enth\"{a}lt) enthalten sind und diese auch den -meisten Platz auf der Festplatte belegt. Die {\bf File Retention} (der Aufbewahrungszeitraum -f\"{u}r Dateien) ist also im wesentlichen daf\"{u}r verantwortlich, wie gro{\ss} die Datenbank wird. -Eine kurze Berechnung zeigt, dass die Datenbank mit jeder gesicherten Datei ungef\"{a}hr um -154 Bytes w\"{a}chst. - -\footnotesize -\begin{verbatim} -Gr\"{o}{\ss}e - in Bytes Eintr\"{a}ge Dateiname - ============ ========= =========== - 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 - -Die Datenbank hat eine Gr\"{o}{\ss}e von ca. 450 Megabytes.. - -H\"{a}tten wir SQLite genommen, w\"{a}re die Bestimmung der Datenbankgr\"{o}{\ss}e -viel einfacher gewesen, da SQLite alle Daten in einer einzigen Datei speichert, -dann aber h\"{a}tten wir nicht so einfach erkennen k\"{o}nnen, welche der Tabellen -den meisten Speicherplatz ben\"{o}tigt. - -SQLite Datenbanken k\"{o}nnen bis zu 50 \% gr\"{o}{\ss}er sein als MySQL-Datenbanken -(bei gleichem Datenbestand), weil bei SQLite alle Daten als ASCII-Zeichenketten gespeichert werden. -Sogar bin\"{a}re Daten werden als ASCII-Zeichenkette dargestellt, und das scheint den Speicherverbrauch -zu erh\"{o}hen. diff --git a/docs/manual-de/check_tex.pl b/docs/manual-de/check_tex.pl deleted file mode 100755 index e12d51be..00000000 --- a/docs/manual-de/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-de/configure.tex b/docs/manual-de/configure.tex deleted file mode 100644 index 6f7376a3..00000000 --- a/docs/manual-de/configure.tex +++ /dev/null @@ -1,383 +0,0 @@ -%% -%% - -\chapter{Anpassen der Konfigurations-Dateien} -\label{ConfigureChapter} -\index[general]{Dateien!Anpassen der Konfigurations } -\index[general]{Anpassen der Konfigurations-Dateien } - -Jedes einzelne der Bacula Programme liest beim Starten die angegebene Konfigurations-Datei ein, -falls keine angegeben wird benutzt Bacula jeweils die Standard-Konfigurations-Dateien {\bf bacula-dir.conf}, {\bf -bacula-fd.conf}, {\bf bacula-sd.conf}, oder {\bf console.conf} f\"{u}r den Director-Dienst, den Client-Dienst, -den Storage-Dienst und f\"{u}r das Console-Programm. - -Jeder Dienst (Director,Client, Storage und Console) hat seine eigene Konfigurations-Datei die eine Reihe von -Eintr\"{a}gen enth\"{a}lt. Die Eintr\"{a}ge sind sehr \"{a}hnlich, aber die angegebenen Parameter sind von -Dienst zu Dienst unterschiedlich. Zum Beispiel wird in der Director-Dienst-Konfiguration mit dem Eintrag -{\bf Director} der Name des Director-Dienstes, eine Reihe globaler Parameter, sowie das Director-Passwort festgelegt. -Der {\bf Director}-Eintrag im Client-Dienst gibt an, welcher Director-Dienst diesen Client kontaktieren darf. - -Bevor Sie Bacula zum ersten mal starten, m\"{u}ssen Sie die Konfigurations-Dateien f\"{u}r jeden Dienst anpassen. -Standard-Konfigurations-Dateien werden f\"{u}r jeden Dienst bei der Installation erzeugt, aber m\"{u}ssen Ihrem Computer -angepasst werden. Einen \"{U}berblick \"{u}ber die Konfigurations-Eintr\"{a}ge sehen Sie hier: - -\addcontentsline{lof}{figure}{Bacula Objects} -\includegraphics{./bacula-objects.eps} -\\ -(vielen Dank an Aristides Maniatis f\"{u}r diese Graphik) -\label{ResFormat} - -\section{Zeichens\"{a}tze} -\index[general]{Zeichens\"{a}tze} -Bacula wurde so entwickelt, dass es die meisten Zeichens\"{a}tze der Welt versteht, -US ASCII, deutsch, französich, chinesisch, ..... Allerdings tut es dies, indem es -alles in UTF-8 umwandelt und Bacula erwartet, dass alle Konfigurationsdateien -(auch die auf Win32-Computern) als UTF-8-Format vorliegen. Normalerweise ist UTF-8 -der Standard-Zeichensatz auf Linux-Computern, aber eventuell nicht auf anderen -Unix-Varianten oder auf Windows. Sie sollten also sicherstellen, dass die entsprechenden -Umgebungsvariablen richtig gesetzt sind, befor Sie Bacula starten. - -Damit Bacula auch Konfigurations-Dateien mit fremden Zeichen korrekt lesen kann, -muss die Umgebungsvariable {bf LANG} mit {\bf .UTF-8} enden, zum Beispiel {\bf en\_US.UTF-8}. -Die Schreibweise kann bei verschiedenen Betriebssystemen variieren und ebenso kann auch die -Umgebungsvariable anders hei{\ss}en. Auf neueren Win32-Computern k\"{o}nnen Sie beim speichern -der Konfigurations-Dateien z.B. mit dem {\bf notepad} angeben, dass die Datei als UTF-8 -gespeichert werden soll. - -Bacula nimmt an, dass alle Dateinamen auf Linux und Unix im UTF-8-Format sind. -Bei Windows sind sie Unicode (UTF-16) und werden automatisch in UTF-8 umgewandelt. - -\section{Konfigurations-Parameter-Format} -\index[general]{Konfigurations-Parameter-Format } -\index[general]{Format!Konfigurations-Parameter } - -Auch wenn Sie nicht jedes Detail \"{u}ber alle Paramter wissen m\"{u}ssen, -ist ein grundlegendes Wissen des Konfigurations-Parameter-Formats erforderlich. -Jeder Konfigurations-Eintrag in einer Ressource (innerhalb der geschweiften Klammern) -ist zusammengesetzt aus dem Schl\"{u}sselwort gefolgt von einem Gleichheitszeichen, -dem dann ein oder mehrere Werte folgen. Das Schl\"{u}sselwort muss einem der -Bacula bekannten Konfigurations-Parameter entsprechen, wobei es gro{\ss}e oder kleine -Buchstaben enthalten darf, sowie auch Leerzeichen. - -Jede Ressource muss einen Paramter {\bf Name} beinhalten und kann zus\"{a}tzlich -eine optionale {\bf Description} enthalten. Der Name wird ben\"{o}tigt um die Ressource -eindeutig zu bezeichnen. Die Description wird verwendet wenn die Ressource angezeigt wird, -um eine leichtere Erkennung zu erm\"{o}glichen. -Ein Beispiel: - -\footnotesize -\begin{verbatim} -Director { - Name = "MeinDir" - Description = "Bacula Director" - WorkingDirectory = "$HOME/bacula/bin/working" -} -\end{verbatim} -\normalsize - -Diese Ressource definiert einen Director mit dem Namen "MeinDir" und dem Arbeitsverzeichnis -\$HOME/bacula/bin/working. Falls Sie Leerzeichen in einem Parameter verwenden wollen -(rechts vom Gleichheitszeichen) m\"{u}ssen Sie den Eintrag in doppelte Anf\"{u}hrungszeichen setzen. -Andernfalls sind Anf\"{u}hrungszeichen nicht n\"{o}tig. - -\label{Comments} -\subsection{Kommentare} -\index[general]{Kommentare} - -Wenn Bacula die Konfigurations-Dateien liest, werden leere Zeilen und alles hinter einem -Rautezeichen (\#) bis zum Zeilenende ignoriert. Ein Semikolon (;) wird als logisches -Zeilenende interprtiert und alles hinter dem Semikolon wird als n\"{a}chster -Konfigurations-Eintrag betrachtet. Wenn ein Eintrag in einer eigenen Zeile steht, -wird kein abschlie{\ss}endes Semikolon ben\"{o}tigt, in den Beispielen in diesem -Handbuch werden Sie daher kaum Semikolons finden. - - -\label{Case1} - -\subsection{Gro{\ss}/Kleinschreibung und Leerzeichen} -\index[general]{Leerzeichen!Gro{\ss}/Kleinschreibung} -\index[general]{Gro{\ss}/Kleinschreibung und Leerzeichen} - -Gro{\ss}/Kleinschreibung und Leerzeichen werden beim lesen der Schl\"{u}sselw\"{o}rter -(dem Teil vor dem Gleichheitszeichen) komplett ignoriert. - -Das bedeutet, dass die Schl\"{u}sselw\"{o}rter {\bf name}, {\bf Name} und {\bf N a m e} -alle identisch sind. - -Leerzeichen hinter dem Gleichheitszeichen, vor dem ersten Zeichen des Wertes -werden auch ignoriert. - -Generell werden Leerzeichen innerhalb eines Wertes nicht ignoriert, -wenn Leerzeichen im Wert vorhanden sind, muss der Wert in doppelte Anf\"{u}hrungszeichen -gesetzt werden. Namen d\"{u}rfen bis zu 127 Zeichen enthalten. Ein Name darf aus allen -ASCII-Zeichen bestehen. Innerhalb eine Zeichenkette die in doppelten Anf\"{u}hrungszeichen steht -kann man mit dem Backslash (umgekehrter Schr\"{a}gstrich \textbackslash{}) ein Zeichen maskieren, -damit es als es selbst dargestellt wird (praktisch um Anf\"{u}hrungszeichen und geschweifte Klammern -einzuf\"{u}gen). - -Bitte beachten Sie, dass Bacula Ressource-Namen, sowie bestimmte andere Namen (z.B. Volume-Namen), -nur aus Buchstaben, Zahlen und ein paar Sonderzeichen (Leerzeichen, Unterstrich,..) bestehen d\"{u}rfen. -Alle anderen Zeichen sind nicht erlaubt. - -\label{Includes} -\subsection{Einbinden anderer Konfigurations-Dateien} -\index[general]{Einbinden anderer Konfigurations-Dateien } -\index[general]{Dateien!Einbinden anderer Konfigurations } -\index[general]{Benutzung von @ zum einbinden anderer Dateien} -\index[general]{@{\bf Dateiname}} - -Falls Sie Ihre Konfiguration auf mehrere kleine Dateien aufteilen m\"{o}chten, -k\"{o}nnen Sie das tun, indem Sie andere Konfigurations-Dateien mit @{\bf Dateiname} einbinden. -Dabei muss @{\bf Dateiname} den absoluten Pfad und Dateinamen enthalten. Die Angabe @Dateiname -darf an jeder Stelle stehen, wo auch eine Konfigurationsangabe stehen kann. - -\label{DataTypes} -\subsection{grundlegende Datentypen} -\index[general]{Datentypen!grundlegende } -\index[general]{grundlegende Datentypen } - -Beim einlesen der Konfigurations-Parameter klassifiziert Bacula die Daten -gem\"{a}{\ss} den unten aufgelisteten Datentypen. Wenn Sie dass das erstemal lesen, -wird es Ihnen eventuell etwas kompliziert vorkommen, aber in Wahrheit ist es ganz einfach und logisch. - -\begin{description} - -\item [name] - \index[fd]{name} - Ein Schl\"{u}sselwort oder Name besteht aus alphanumerischen Zeichen, -einschlie{\ss}lich Bindestrich, Unterstrich und Dollar-Zeichen. Das erste Zeichen eines {\bf Name} -muss ein Buchstabe sein. Ein Name hat eine maximale L\"{a}nge von 127 Zeichen. Typischerweise stehen -Schl\"{u}sselw\"{o}rter auf der linken Seite des Gleichheitszeichens (d.h. es sind -Bacula-Schl\"{u}sselw\"{o}rter z.B. Konfigurations-Eintrag-Namen oder Parameter-Namen). -Schl\"{u}sselw\"{o}rter d\"{u}rfen nicht in Anf\"{u}hrungszeichen stehen. - -\item [name-string] - \index[fd]{name-string} - Ein Name-String ist \"{a}hnlich einem Namen, au{\ss}er das er in Anf\"{u}hrungszeichen stehen darf -und daher auch Lerrzeichen beinhalten kann. Ein Name-String darf 127 Zeichen lang sein und steht -typischerweise auf der rechten Seite des Gleichheitszeichens (d.h. es sind Werte die zum einem -Schl\"{u}sselwort geh\"{o}hren). - -\item [string] - \index[fd]{string} - Ein String ist eine Zeichenkette die, in Anf\"{u}hrungszeichen gestellt, jedes beliebige Zeichen enthalten darf. -Ein String hat keine L\"{a}ngenbegrenzung. Strings sind typischerweise Werte die Dateinamen, Verzeichnisnamen oder -Betriebssystem-Befehlen entsprechen. Ein Backslash (umgekehrter Schr\"{a}gstrich \textbackslash{}) maskiert das folgende -Zeichen als sich selbst, dadurch kann man Anf\"{u}hrungszeichen innerhalb des Strings verwenden, oder auch den Backslash selbst. - -\item [directory] - \index[dir]{directory} - A directory is either a quoted or non-quoted string. A directory will be -passed to your standard shell for expansion when it is scanned. Thus -constructs such as {\bf \$HOME} are interpreted to be their correct values. - -\item [password] - \index[dir]{password} - Ist ein Bacula-Passwort und wird intern als MD5-Hash gespeichert. - -\item [integer] - \index[dir]{integer} - Eine 32-Bit Ganzzahl, positiv oder negativ. - -\item [positive integer] - \index[dir]{positive integer } - Eine positive 32Bit-Ganzzahl. - -\item [long integer] - \index[dir]{long integer} - Eine 64-Bit Ganzzahl. Typischerweise f\"{u}r Werte wie Bytes die \"{u}ber 4 Millionen -betragen k\"{o}nnen und daher 64-Bit erfordern. - -\item [yes|no] - \index[dir]{yes or no } - Entweder ein Ja: {\bf yes} oder ein Nein: {bf no}. - -\label{Size1} -\item [size] -\index[dir]{size} - Eine Gr\"{o}{\ss}e angegeben in Bytes. Typischerweise eine Flie{\ss}kommazahl in wissenschaftlicher Schreibweise, -gefolgt von einem Modifikator. Intern als 64-Bit Ganzzahl gespeichert. Wenn ein Modofikator angegeben wird, muss er -direkt und ohne Leerzeichen dem Wert folgen. -Die folgenden Modifikatoren sind erlaubt: - -\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} - -\label{Time} -\item [time] -\index[dir]{time} - Eine Zeit oder ein Zeitraum in Sekunden. Intern als 64-Bit Ganzzahl gespeichert, -allerdings in zwei Teilen: ein Nummern-Teil und ein Modifikator-Teil. Die Nummer kann eine -Ganz- oder Flie{\ss}kommazahl sein. Wenn sie als Flie{\ss}kommazahl angegeben wird, wird auf -den n\"{a}chsten Ganzzahl-Wert gerundet. Der Modifikator ist zwingend erforderlich und mu{\ss} dem Nummern-teil folgen -(entweder durch Leerzeichen getrennt oder nicht). Die folgenden Modifikatoren sind erlaubt: - -\begin{description} - -\item [seconds] - \index[dir]{seconds} - Sekunden - -\item [minutes] - \index[dir]{minutes} - Minuten (60 Sekunden) - -\item [hours] - \index[dir]{hours } - Stunden (3600 Sekunden) - -\item [days] - \index[dir]{days} - Tage (3600*24 Sekunden) - -\item [weeks] - \index[dir]{weeks} - Wochen (3600*24*7 Sekunden) - -\item [months] - \index[dir]{months } - Monate (3600*24*30 Sekunden) - -\item [quarters] - \index[dir]{quarters } - Quartale (3600*24*91 Sekunden) - -\item [years] - \index[dir]{years } - Jahre (3600*24*365 Sekunden) -\end{description} - -Jede Abk\"{u}rzung dieser Modifikatoren ist erlaubt (d.h. {\bf Sekunden} k\"{o}nnen als -{\bf sec} oder {\bf s} angegeben werden). Ein {\bf m} wird als Monat angenommen. - -Die Angabe einer Zeit kann so viele Modifikatoren und Nummern enthalten, wie gew\"{u}nscht. -Ein Beispiel: - -\footnotesize -\begin{verbatim} -1 week 2 days 3 hours 10 mins -1 month 2 days 30 sec - -\end{verbatim} -\normalsize - -sind g\"{u}ltige Zeitangaben. - -\end{description} - -\label{ResTypes} -\section{Ressource Typen} -\index[general]{Typen!Ressource } -\index[general]{Ressource Typen } - -Die folgende Tabelle listet alle momentan von Bacula verwendeten Konfigurations-Eintr\"{a}ge auf. -Sie zeigt, welche Eintr\"{a}ge bei welchem Dienst vorhanden sein m\"{u}{\ss}en. Die Standard-Konfigurations-Dateien -beinhalten bereits mindestens ein Beispiel jedes ben\"{o}tigten Eintrags. Sie brauchen sich also keine Sorgen zu machen, -dass Sie diese Eintr\"{a}ge alle von Hand erstellen m\"{u}{\ss}en. - -\addcontentsline{lot}{table}{Ressource Typen} -\begin{longtable}{|l|l|l|l|l|} - \hline -\multicolumn{1}{|c| }{\bf Ressource } & \multicolumn{1}{c| }{\bf Director } & -\multicolumn{1}{c| }{\bf Client } & \multicolumn{1}{c| }{\bf Storage } & -\multicolumn{1}{c| }{\bf Console } \\ - \hline -{Autochanger } & {Nein } & {Nein } & {Ja } & {Nein } \\ -\hline -{Catalog } & {Ja } & {Nein } & {Nein } & {Nein } \\ - \hline -{Client } & {Ja } & {Ja } & {Nein } & {Nein } \\ - \hline -{Console } & {Ja } & {Nein } & {Nein } & {Ja } \\ - \hline -{Device } & {Nein } & {Nein } & {Ja } & {Nein } \\ - \hline -{Director } & {Ja } & {Ja } & {Ja } & {Ja } \\ - \hline -{FileSet } & {Ja } & {Nein } & {Nein } & {Nein } \\ - \hline -{Job } & {Ja } & {Nein } & {Nein } & {Nein } \\ - \hline -{JobDefs } & {Ja } & {Nein } & {Nein } & {Nein } \\ - \hline -{Message } & {Ja } & {Ja } & {Ja } & {Nein } \\ - \hline -{Pool } & {Ja } & {Nein } & {Nein } & {Nein } \\ - \hline -{Schedule } & {Ja } & {Nein } & {Nein } & {Nein } \\ - \hline -{Storage } & {Ja } & {Nein } & {Ja } & {Nein } -\\ \hline - -\end{longtable} - -\section{Namen, Passw\"{o}rter und Autorisation} -\label{Names} -\index[general]{Autorisation!Namen Passw\"{o}rter und } -\index[general]{Namen, Passw\"{o}rter und Autorisation } -\index[general]{Passw\"{o}rter} - -Damit ein Dienst mir einem anderen Kontakt aufnehmen darf, muss er sich mit einem Passwort autorisieren. -In den meisten F\"{a}llen geh\"{o}hrt ein Passwort zu einem bestimmten Namen, es muss also der Name und das Passwort -korrekt sein, um erfolgreich autorisiert zu werden. Passw\"{o}rter sind einfacher und beliebiger Text. Sie werden -nicht durch einen speziellen Prozess generiert; benutzen Sie einfach zuf\"{a}lligen Text. - -Die Standard-Konfigurations-Dateien enthalten automatisch erzeugte Passw\"{o}rter, die eine erfolgreiche Autorisierung -aller Dienste untereinander erlauben. Wenn Sie diese Passw\"{o}rter ver\"{a}ndern, m\"{u}{\ss}en Sie das auch auf der -entsprechenden Gegenseite tun. - -Hier ist ein Bild, worauf Sie sehen k\"{o}nnen, welche Namen und Passw\"{o}rter in welchen Dateien und Konfigurations-Eintr\"{a}gen -\"{u}bereinstimmen m\"{u}{\ss}en: - -\includegraphics{./Conf-Diagram.eps} - -Auf der linken Seite sehen Sie die Director-, Storage- und Client-Eintr\"{a}ge mit ihren Namen und Passw\"{o}rtern, -dieses steht alles in der Konfiguration des Director-Dienstes in der Datei {\bf bacula-dir.conf}. Auf der rechten Seite -sehen Sie die entsprechenden Eintr\"{a}ge in den Konfigurations-Dateien des Storage- und Client-Dienstes (SD und FD). - -Bitte beachten Sie, dass die Adresse {\bf fw-sd}, die in der Konfiguration des Storage-Dienstes steht, dem Client-Dienst -symbolisch \"{u}bergeben wird. Der Client-Dienst muss diesen Namen dann in eine g\"{u}ltigen IP-Adresse aufl\"{o}sen k\"{o}nnen. -Aus diesem Grund muss hier etweder eine IP-Adresse oder ein voll qualifizierter Rechnername stehen. Ein Name wie {\bf localhost} -ist nicht g\"{u}ltig und wird auf dem Client auf den Namen des localhost des Clients aufge\"{o}st. Das Passwort des Client-Dienstes -um sich am Storage-Dienst anzumelden ist tempor\"{a}r und wird dynamisch f\"{u}r jeden einzelnen Job erzeugt. Es steht also in keiner -der .conf-Dateien. - -\section{detailierte Information f\"{u}r jeden Dienst} -\index[general]{detailierte Information f\"{u}r jeden Dienst } -\index[general]{Dienst!detailierte Information f\"{u}r jeden } - -Die Details f\"{u}r jeden Konfigurations-Eintrag und die darin g\"{u}ltigen Parameter sind in den folgenden Kapiteln beschrieben. - -Die folgenden Konfigurations-Dateien m\"{u}{\ss}en definiert werden: - -\begin{itemize} -\item - \ilink{bconsole.conf}{ConsoleConfChapter} -- um die Konfiguration f\"{u}r das Console-Programm zu definieren -(die Benutzerschnittstelle zum Director-Dienst). Hier wird angegeben welche Director-Dienste verf\"{u}gbar sind, um mit ihnen zu arbeiten. - \item - \ilink{bacula-dir.conf}{DirectorChapter} -- um die Konfiguration des Director-Dienstes zu definieren. In dieser Datei geben Sie alle Storage- und -Client-Dienste an. -\item - \ilink{bacula-fd.conf}{FiledConfChapter} -- um die Konfiguration des Clients zu definieren. Diese Datei wird auf jedem Backup-Client ben\"{o}tigt. -\item - \ilink{bacula-sd.conf}{StoredConfChapter} -- um die Konfiguration des Storage-Dienstes zu definieren. Normalerweise werden Sie einen Storage-Dienst -haben, der Ihr Bandlaufwerk steuert. Wenn Sie mehrere Rechner mit angeschlossenen Bandlaufwerken haben, ben\"{o}tigen Sie nat\"{u}rlich einen Storage-Dienst -pro Rechner. -\end{itemize} diff --git a/docs/manual-de/console.tex b/docs/manual-de/console.tex deleted file mode 100644 index 57b235ff..00000000 --- a/docs/manual-de/console.tex +++ /dev/null @@ -1,1615 +0,0 @@ -%% -%% - -\chapter{Bacula Console} -\label{_ConsoleChapter} -\index[general]{Console!Bacula} -\index[general]{Bacula Console} -\index[general]{Console!Bacula} -\index[general]{Bacula Console} - -Die {\bf Bacula Console} (manchmal auch das BenutzerInterface genannt) -ist ein Programm, dass es dem Anwender oder System Aministrator erlaub, -den Bacula-Director-Dienst im laufenden Betrieb zu kontrollieren. - -Momentan gibt es zwei Versionen des Console-Programms: eine Shell- (TTY) -und eine GNOME GUI-Version. Beide erlauben es dem Administrator oder -autorisierten Benutzern Bacula zu steuern. Sie k\"{o}nnen sich den Status -eines bestimmten Jobs bzw. den Inhalt des Katalogs anzeigen lassen, -oder bestimmte Aktionen mit Tapes und Autochangern durchf\"{u}hren. - -Zus\"{a}tzlich gibt es noch die bwx-Console, die auf wxWidgets aufbaut, -und eine M\"{o}glichkeit bietet, den Wiederherstellungsproze{\ss} graphisch zu steuern. -Die bwx-Console befindet sich in einem fr\"{u}hen Entwicklungsstadium und -wurde leider seit einiger Zeit nicht weiterentwickelt. (Trotzdem kann sie sehr hilfreich sein.) - -Da sich alle Bacula-Consolen \"{u}ber das Netzwerk mit dem Director-Dienst verbinden, -ist es nicht notwendig sie auf dem selben Computer laufen zu lassen. - -Ein gewisses, minimales Grundwissen \"{u}ber die Console ist schon dann notwendig, -wenn Bacula auf mehr als einem Tape schreiben soll. Bacula wird n\"{a}mlich nach einem -leeren Band fragen, falls keines mehr verf\"{u}gbar ist, und erst nach dem mounten -eines neuen Tapes mittels der Console, wird Bacula weiterarbeiten k\"{o}nnen. - -\section{Console Konfiguration} -\index[general]{Console Konfiguration} -\index[general]{Konfiguration!Console} -\index[general]{Console Konfiguration} -\index[general]{Konfiguration!Console} - -Wenn Sie die Bacula-Console starten, liest sie ihre Standard-Konfigurations-Datei -namens {\bf bconsole.conf}, bzw. {\bf bgnome-console.conf} f\"{u}r die GNOME-Console, ein. -Im einfachsten Fall enth\"{a}llt diese Datei nur den Namen und die Adresse des Director-Dienstes -sowie das Passwort, dass f\"{u}r die Verbindung zum Director-Dienst ben\"{o}tigt wird. -F\"{u}r weitere Informationen zu dieser Datei, lesen Sie bitte das Kapitel \"{u}ber die \ilink{Console-Konfiguration-Datei}{ConsoleConfChapter} in diesem Handbuch. - -\section{Benutzung des Console-Programms} -\index[general]{Benutzung des Console-Programms} -\index[general]{Programm!Benutzung des Console-} -\index[general]{Benutzung des Console-Programms} -\index[general]{Programm!Benutzungs des Console-} - -Das Console-Programm kann mit den folgenden Optionen gestartet werden: -\footnotesize -\begin{verbatim} -Usage: bconsole [-s] [-c Konfigurations-Datei] [-d Debug-Level] - -c gibt die zu verwendene Konfigurations-Datei an - -dnn setzt den Debug-Lavel auf nn - -n kein conio - -s keine Signale (*) - -t test - list die Konfigurations-Datei und beendet sich dann - -? gibt diese Hilfe aus. -\end{verbatim} -\normalsize - -(*) \elink{Signale}{http://de.wikipedia.org/wiki/Signal\_\%28Computer\%29} - -Nach dem Start des Console-Programms zeigt es durch sein Prompt (*) an, -dass es auf Benutzereingaben wartet. (in der GNOME-Console gibt es kein Prompt, -geben Sie die Befehle bitte einfach in der Textbox unten im Fenster ein.) -Sie k\"{o}nnen in jeder Console einfach nur das Kommando eingeben, wenn weitere Parameter -erforderlich sind, wird das Programm Sie danach fragen. Alternativ k\"{o}nnen Sie -nat\"{u}rlich auch das komplette Kommando mit allen ben\"{o}tigten Parametern eingeben -und ausf\"{u}hren. Das normale Befehlsformat ist dieses: - -\footnotesize -\begin{verbatim} - [=] [=] ... -\end{verbatim} -\normalsize - -wobei {\bf Kommando} einer der unten aufgef\"{u}hrten Console-Befehle -und {\bf Parameter} eines der unten aufgelisteten Schl\"{u}sselw\"{o}rter ist, -dem dann meistens ein {\bf Argument} folgt. Alle Befehle k\"{o}nnen in der -k\"{u}rzesten eindeutigen Form eingegeben werden. Falls zwei Befehle mit identischen -Buchstaben anfangen, wird der ausgef\"{u}hrt, der in der Ausgabe des {\bf help}-Kommandos -am weitesten oben steht. Wenn Sie das andere Kommando ausf\"{u}hren m\"{o}chten m\"{u}ssen Sie -dementsprechend mehr Buchstaben eingeben, um es eindeutig anzugeben. Keiner der -Parameter darf abgek\"{u}rzt werden. - -Ein Beispiel: - -\footnotesize -\begin{verbatim} -list files jobid=23 -\end{verbatim} -\normalsize - -zeigt alle gesicherten Dateien mit der JobID 23 an. - -\footnotesize -\begin{verbatim} -show pools -\end{verbatim} -\normalsize - -zeigt alle Pool-Konfigurations-Eintr\"{a}ge an. - -Die maximale L\"{a}nge der eingegebenen Befehle, mit Parametern, ist 511 Zeichen. -Falls Sie die Console \"{u}ber ein Script ansprechen, denken Sie bitte daran, -dass Sie dieses Limit nicht \"{u}berschreiten. - -\section{Beenden des Console-Programs} -\index[general]{Programm!Beenden des Console-} -\index[general]{Beenden des Console-Programms} -\index[general]{Programm!Beenden des Console-} -\index[general]{Beenden des Console-Programms} - -Normalerweise beenden Sie das Console-Programm durch die Eingabe von {\bf quit} oder {\bf exit}. -Allerdings wartet die Console bis der Director-Dienst das Kommando best\"{a}tigt. Wenn der -Director bereits ein l\"{a}nger laufendes Kommando ausf\"{u}hrt, kann es sein, dass das Beenden -der Console einen Moment dauert. Falls Sie die Console sofort verlassen wollen, k\"{o}nnen Sie -in dem Fall das Kommando {\bf .quit} verwenden. - -Momentan gibt es keinen Weg ein laufendes Kommando nach dem Starten abzubrechen (z.B. mit STRG+C). -Allerdings k\"{o}nnen Sie jederzeit, wenn die Console Sie nach einer weiteren Eingabe fragt, -das aktuelle Kommmando beenden, indem Sie einen Punkt {\bf .} eingeben. Nach der Eingabe des Punktes, -werden Sie automatisch zum Hauptprompt oder bei verschachtelten Abfragen zum passenden letzten Prompt -zur\"{u}ckgeleitet. Bei einigen Eingaben, wie zum Beispiel der Frage nach einem Volume-Namen, wird -der Punkt als Eingabe gewertet und Sie haben beim n\"{a}chsten Prompt die M\"{o}glichkeit, -das Kommando abzubrechen. - -\label{keywords} -\section{Alphabetische Liste der Console-Schl\"{u}sselw\"{o}rter} -\index[general]{Schl\"{u}sselw\"{o}rter!Alphabetische Liste der Console} -\index[general]{Alphabetische Liste der Console-Schl\"{u}sselw\"{o}rter} -\index[general]{Schl\"{u}sselw\"{o}rter!Alphabetische Liste der Console} -\index[general]{Alphabetische Liste der Console-Schl\"{u}sselw\"{o}rter} -Wenn es nicht anders angegeben ist, ben\"{o}tigt jedes der folgenden Schl\"{u}sselw\"{o}rter -(Parameter der Console-Befehle) ein Argument, welches dem Schl\"{u}sselwort, -getrennt durch ein Gleichheitszeichen, folgt. -Ein Beispiel: -\begin{verbatim} -jobid=536 -\end{verbatim} - -Bitte beachten Sie, dass diese Liste durch die st\"{a}ndig weitergehende -Entwicklung eventuell weder komplett, noch in der Richtigen alphabetischen -Reihenfolge sein kann. - -\begin{description} -\item [restart] - Parameter des python-Kommandos, - dadurch wird der python-Interpreter neu gestartet. Ben\"{o}tigt keine Argumente. -\item [all] - Parameter des status und show-Kommandos, - dadurch werden alle Komponenten oder Eintr\"{a}ge ausgew\"{a}hlt -\item [allfrompool] - Parameter des update-Kommandos, - gibt an das alle Volumes des (im Parameter pool angegebenen) Pools - aktualisiert werden sollen. -\item [allfrompools] - Parameter des update-Kommandos, - gibt an das alle Volumes aller Pools aktualisiert werden sollen. -\item [before] - Parameter des restore-Kommandos. -\item [bootstrap] - Parameter des restore-Kommandos. -\item [catalog] - im use-Kommando erlaubt, - um den zu benutzenden Katalog auszuw\"{a}hlen -\item [catalogs] - Parameter des show-Kommandos. - Ben\"{o}tigt keine Argumente. -\item [client | fd] -\item [clients] - Parameter des show, list und llist-Kommandos, - bezeichnet alle Clients. Ben\"{o}tigt keine Argumente. -\item [counters] - im show-Kommando erlaubt. - Ben\"{o}tigt keine Argumente. -\item [current] - Parameter des restore-Kommandos. - Ben\"{o}tigt keine Argumente. -\item [days] - definiert die Anzahl der Tage, die das "list nextvol"-Kommando - in Betracht ziehen soll. Der Parameter days kann auch im Kommando - "status director" verwendet werden, um die geplanten Jobs f\"{u}r die - angegebene Anzahl Tage zu zeigen. -\item [devices] - Parameter des show-Kommandos. - Ben\"{o}tigt keine Argumente. -\item [dir | director] -\item [directors] - Parameter des show-Kommandos. - Ben\"{o}tigt keine Argumente. -\item [directory] - Parameter des restore-Kommandos. - Das Argument gibt das wiederherzustellende Verzeichnis an. -\item [enabled] - Dieser Parameter kann bei den Kommandos "update volumes" und "update slots" - verwendet werden. Das Argument kann yes, true, no, false, archived, 0,1 oder 2 sein. - 0 ist identisch mit no oder false, 1 mit yes oder true und 2 mit archived. - Archived Volumes werden weder benutzt noch automatisch aus dem Katalog gel\"{o}scht. - Volumes die nicht enabled sind, werden nicht f\"{u}r das Backup oder die Wiederherstellung benutzt. -\item [done] - wird im restore-Kommando benutzt. - Ben\"{o}tigt keine Argumente. -\item [file] - Parameter des restore-Kommandos. -\item [files] - Parameter des list und llist-Kommandos. - Ben\"{o}tigt keine Argumente. -\item [fileset] -\item [filesets] - Parameter des show-Kommandos. - Ben\"{o}tigt keine Argumente. -\item [help] - Parameter des show-Kommandos. - Ben\"{o}tigt keine Argumente. -\item [jobs] - Parameter des show, list und llist-Kommandos. - Ben\"{o}tigt keine Argumente. -\item [jobmedia] - Parameter des list und llist-Kommandos. - Ben\"{o}tigt keine Argumente. -\item [jobtotals] - Parameter des list und llist-Kommandos. - Ben\"{o}tigt keine Argumente. -\item [jobid] - Parameter des list und llist-Kommandos. - Die jobid ist die numerische Jobid, die im Job-Report angezeigt wird. - Sie ist der Index f\"{u}r die Datenbankeintr\"{a}ge des entsprechenden Jobs. - Da sie f\"{u}r alle in der Datenbank existierenden Jobs einzigartig ist, - kann sie erst wiederverwendet werden, wenn der vorherige Job mit dieser Jobid - aus der Datenbank gel\"{o}scht wurde. -\item [job | jobname] - Parameter des list und llist-Kommandos. - Der Job oder JobName entspricht dem Namen den Sie im Job-Eintr\"{a}g - angegeben haben, somit bezieht er sich auf alle Jobs dieses Namens, - die jemals gelaufen sind und deren Eintr\"{a}ge noch im Katalog existieren. -\item [level] -\item [listing] - Parameter des estimate-Kommandos. - Ben\"{o}tigt keine Argumente. -\item [limit] -\item [messages] - Parameter des show-Kommandos. - Ben\"{o}tigt keine Argumente. -\item [media] - Parameter des list und llist-Kommandos. - Ben\"{o}tigt keine Argumente. -\item [nextvol | nextvolume] - Parameter des list und llist-Kommandos. - Ben\"{o}tigt keine Argumente. -\item [on] - Ben\"{o}tigt keine Argumente. -\item [off] - Ben\"{o}tigt keine Argumente. -\item [pool] -\item [pools] - Parameter des show, list und llist-Kommandos. - Ben\"{o}tigt keine Argumente. -\item [select] - Parameter des restore-Kommandos. - Ben\"{o}tigt keine Argumente. -\item [storages] - Parameter des show-Kommandos. - Ben\"{o}tigt keine Argumente. -\item [schedules] - Parameter des show-Kommandos. - Ben\"{o}tigt keine Argumente. -\item [sd | store | storage] -\item [ujobid] - Parameter des list-Kommandos. - Die ujobid ist eine M\"{o}glichkeit einen Job eindeutig zu identifizieren. - Momentan besteht die ujobid aus dem JobNamen und der Uhrzeit wann der Job gelaufen ist. -\item [volume] -\item [volumes] - Parameter des list und llist-Kommandos. - Ben\"{o}tigt keine Argumente. -\item [where] - Parameter des restore-Kommandos. -\item [yes] - Parameter des restore-Kommandos. - Ben\"{o}tigt keine Argumente. -\end{description} - -\label{list} -\section{Alphabetische Liste der Console-Kommandos} -\index[general]{Kommandos!Alphabetische Liste der Console-} -\index[general]{Alphabetische Liste der Console-Kommandos} -\index[general]{Kommandos!Alphabetische Liste der Console-} -\index[general]{Alphabetische Liste der Console-Kommandos} - -Die folgenden Kommandos sind derzeit verf\"{u}gbar: - -\begin{description} -\item [{add [pool=\lt{}pool-name\gt{} storage=\lt{}storage\gt{} - jobid=\lt{}JobId\gt{}]} ] - \index[general]{add} - Das add-Kommando wird benutzt um Volumes zu einem bestehenden Pool - hinzuzuf\"{u}gen. Dazu wird der Volume-Eintrag in der Datenbank erzeugt - und das Volume dem Pool zugeordnet. Dabei erfolgt kein physikalischer Zugriff - auf das Volume. Nach dem hinzuf\"{u}gen zu einem Pool, geht Bacula davon - aus, dass das Volume wirklich existiert und auch bereits gelabelt ist. - Dises Kommando wird normalerweise nicht benutzt, da Bacula die Volumes - automatisch beim labeln einem Pool hinzuf\"{u}gt. Allerdings ist es hilfreich, - falls Sie ein Volume aus dem Katalog gel\"{o}scht haben und es sp\"{a}ter wieder - hinzuf\"{u}gen wollen. - - Typischerweise wird das label-Kommando anstelle des add-Kommandos benutzt, da - es au{\ss}er dem labeln des physikalischen Volumes, die identischen Schritte - wie das add-Kommando ausf\"{u}hrt. Das add-Kommando \"{a}ndert nur die Katalog-Eintr\"{a}ge - und nicht die physikalischen Volumes. Die physikalischen Volumes m\"{u}ssen - vorhanden und gelabelt sein (normalerweise mit dem label-Kommando). Trotzdem - kann das add-Kommando sinnvoll sein, wenn Sie zum Beispiel eine bestimmte Anzahl - von Volumes einem Pool hinzuf\"{u}gen wollen, wobei die Volumes erst zu einem - sp\"{a}teren Zeitpunkt gelabelt werden. Auch um ein Volume eines anderen Bacula-Systems - (bzw. anderen Director-Dienstes) zu importieren, kann das add-Kommando benutzt werden. - Die erlaubten Zeichen f\"{u}r einen Volume-Namen finden Sie weiter unten - in der Beschreibung des label-Kommandos. - -\item [autodisplay on/off] - \index[general]{autodisplay on/off} - Das autodisplay-Kommando kennt zwei Parameter: {\bf on} und {\bf off}, - wodurch die automatische Anzeige von Nachrichten in der Console entsprechend - ein- oder ausgeschaltet wird. Der Standardwert ist {\bf off}, was bedeutet, dass - Sie \"{u}ber neue Meldungen benachrichtigt werden, sie aber nicht automatisch - angezeigt werden. In der GNOME-Console ist das automatische Anzeigen dagegen - standardm\"{a}{\ss}ig aktiviert, d.h. neue Meldungen werden automatisch - ausgegeben, wenn sie vom Director-Dienst empfangen wurden (typischerweise innerhalb von - ca. 5 Sekunden nachdem sie generiert wurden). - - Wenn autodisplay auf off steht, m\"{u}ssen Sie neu Nachrichten mit dem - {\bf messages}-Kommando abrufen, um sie sich anzeigen zu lassen. - Wenn autodiplay auf on steht, werden die Nachrichten angezeigt, sobald die Console sie - empfangen hat. - -\item [automount on/off] - \index[general]{automount on/off} - Das automount-Kommando kennt zwei Parameter: {\bf on} und {\bf off}, - die entsprechend das automatische mounten nach dem labeln ({\bf label}-Kommando) - an- oder ausschalten. Der Standardwert ist on. Wenn automount ausgeschaltet ist, - m\"{u}ssen Sie nach dem labeln eines Volumes dieses explizit mounten ({\bf mount}-Kommando), - um es benutzen zu k\"{o}nnen. - -\item [{cancel [jobid=\lt{}number\gt{} job=\lt{}job-name\gt{} ujobid=\lt{}unique-jobid\gt{}]}] - \index[general]{cancel jobid} - Das cancel-Kommande wird benutzt um einen Job abzubrechen und kennt die - Parameter {\bf jobid=nnn} or {\bf job=xxx}, wober jobid die numerische JobID ist - und job der Job-Name. Wenn Sie weder job noch jobid angeben, listet die Console - alle in Frage kommenden Jobs auf und erlaubt Ihnen aus dieser Liste den abzubrechenden - Job auszuw\"{a}hlen. - - Wenn ein Job als abzubrechen gekennzeichnet wurde, kann es einige Zeit dauern, - bis er tats\"{a}chlich beendet wird (normalerweise innerhalb einer Minute). - Dise Zeit ist aber abh\"{a}ngig davon, was der Job gerade tut. - -\item [{create [pool=\lt{}pool-name\gt{}]}] - \index[general]{create pool} - Das create-Kommando wird normalerweise nicht benutzt, da die Pool-Eintr\"{a}ge - im Katalog automatisch angelegt werden, wenn der Director-Dienst startet und - er seine Pool-Konfiguration aus den Konfigurations-Dateien einliest. Falls ben\"{o}tigt, - kann mit diesem Kommando ein Pool-Eintrag in der Katalog-Datenbank erstellt werden, - der auf einem Pool-Konfigurations-Eintrag basiert, der in der Director-Dienst-Konfiguration - enthalten ist. Einfach gesagt \"{u}bernimmt dieses Kommando nur den Pool-Eintrag aus der - Konfiguration in die Datenbank. Normalerweise wird diese Kommando automatisch ausgef\"{u}hrt, - wenn der Pool zum ersten mal in einem Job-Eintrag benutzt wird. Wenn Sie dieses Kommando - auf einem bestehenden Pool ausf\"{u}hren, wird der Katalog sofort aktualisiert und enth\"{a}lt - dann die identische Pool-Konfiguration, wie die Konfigurations-Dateien. Nach dem Erstellen - eines Pool in den Konfigurations-Dateien werden Sie allerdings h\"{o}chstwahrscheinlich - das {\bf label}-Kommando benutzen, um ein oder mehrere Volumes dem neuen Pool hinzuzuf\"{u}gen - und die entsprechenden Eintr\"{a}ge im Katalog zu erzeugen, anstatt des create-Kommandos. - - Wenn ein Job gestartet wird und Bacula bemerkt, dass keine passender Pool-Eintrag im Katalog ist - aber in den Konfigurations-Dateien, dann wird der Pool im Katalog automatisch angelegt. - Wenn Sie m\"{o}chten, dass der Pool-Eintrag sofort (ohne das ein Job mit diesem Pool gestartet wurde) - im Katalog erscheint, k\"{o}nnen Sie einfach diese Kommando ausf\"{u}hren, um diesen Vorgang - zu erzwingen. - -\item [{delete [volume=\lt{}vol-name\gt{} pool=\lt{}pool-name\gt{} job - jobid=\lt{}id\gt{}]}] - \index[general]{delete} - Das delete-Kommando wird benutzt um ein Volume, einen Pool oder einen Job-Eintrag, - sowie jeweils alle dazugeh\"{o}rigen Datenbank-Eintr\"{a}ge, aus dem Katalog zu - entfernen. Das Kommando \"{a}ndert nur die Katalog-Datenbank, es hat keine - Auswirkungen auf die Konfigurations-Dateien oder die Daten auf den Volumes. - Wir empfehlen Ihnen dieses Kommando nur zu benutzen, wenn Sie wirklich wissen was Sie tun. - - Wenn der Parameter {\bf Volume} angegeben wird, wird das entsprechende Volume aus dem Katalog - gel\"{o}scht, wenn ein {\bf Pool} angeben wird, der entsprechende Pool und bei Angabe des Parameters - {\bf Job} der entsprechende Job, sowie alle zu diesem Job geh\"{o}hrenden JobMedia- und Datei-Eintr\"{a}ge. - Das delete-Kommando kann folgenderma{\ss}en aufgerufen werden: - -\begin{verbatim} -delete pool= oder -\end{verbatim} - -\begin{verbatim} -delete volume=>volume-name> pool=>pool-name> oder -\end{verbatim} - -\begin{verbatim} -delete JobId=>job-id> JobId=>job-id2> ... oder -\end{verbatim} - -\begin{verbatim} -delete Job JobId=n,m,o-r,t ... -\end{verbatim} - - Das erste Beispiel l\"{o}scht einen Pool-Eintrag aus der Katalog-Datenbank. - Das zweite l\"{o}scht einen Volume-Eintrag aus dem angegebenen Pool - und das dritte Beispiel l\"{o}scht die genannten JobID-Eintr\"{a}ge aus - dem Katalog. Es werden die JobIDs n, m, o, p, q, r und t gel\"{o}scht, - wobei die JobID's n, m, o ... nat\"{u}rlich Zahlen entsprechen m\"{u}ssen. - Wie Sie sehen kann das delete-Kommando Listen von JobIDs und auch Bereiche - (z.B. o-r) verarbeiten. - -\item [disable job\lt{}job-name\gt{}] - \index[general]{disable} - Das disable-Kommando erlaubt es Ihnen, zu verhindern das ein Job - automatisch durch den Director-Dienst ausgef\"{u}hrt wird. Wenn Sie den Director-Dienst - neu starten, wird der Status des Jobs wieder auf den Wert gesetzt, der - im Job-Eintrag der Director-Konfiguration eingetragen ist. - -\item [enable job\lt{}job-name\gt{}] - \index[general]{enable} - Das enable-Kommando erlaubt es Ihnen, einen Job der durch das - disable-Kommando aus der automatischen Job-Planung entfernt wurde, - wieder zu aktivieren. Wenn Sie den Director-Dienst neu starten, - wird der Status des Jobs wieder auf den Wert gesetzt, der im - Job-Eintrag der Director-Konfiguration eingetragen ist. - -\label{estimate} -\item [estimate] - \index[general]{estimate} - Mit dem estimate-Kommando k\"{o}nnen Sie sich anzeigen lassen, welche - Dateien durch einen bestimmten Job gesichert werden, ohne diesen Job - ausf\"{u}hren zu m\"{u}ssen. Standardm\"{a}{\ss}ig wird dabei ein Voll-Backup - angenommen. Sie k\"{o}nnen das aber durch den Parameter level entsprechend anpassen, - indem Sie zum Beispiel {\bf level=Incremental} oder {\bf level=Differential} an das - estimate-Kommando mit \"{u}bergeben. Wenn Sie im Aufruf des Kommandos keinen Job-Name - angegeben, wird die Console Ihnen ein Auswahlliste der m\"{o}glichen Jobs anzeigen. - Zus\"{a}tzlich k\"{o}nnen Sie noch die Parameter Client und FileSet angeben. Nach dem - Starten des Kommandos wird der Director-Dienst den Client kontaktieren der daraufhin - eine Liste der zu sichernden Dateien mit ihrer Gr\"{o}{\ss}e zur\"{u}ckgibt. Bitte beachten - Sie, dass das estimate-Kommando nur die Anzahl der von der Datei belegten Bl\"{o}cke zur - Bestimmung der Dateigr\"{o}{\ss}e einbezieht, so dass die Datenmenge die das estimate-Kommando - anzeigt immer etwas gr\"{o}{\ss}er sein wird, als das echte Backup. - - Wahlweise k\"{o}nnen Sie noch den Parameter {\bf listing} mit \"{u}bergeben, - dann wird eine Liste aller zu sichernden Dateien ausgegeben. Abh\"{a}ngig vom FileSet - kann diese Liste sehr lang sein und es daher einige Zeit dauern, alle Dateien anzuzeigen. - Das estimate-Kommando kann folgenderma{\ss}en aufgerufen werden: - - -\begin{verbatim} -estimate job= listing client= - fileset= level= -\end{verbatim} - - die Angabe des Jobs ist ausreichend, aber Sie k\"{o}nnen durch Angabe - des Clients, FileSets und/oder des Backup-Levels die entsprechenden Werte \"{u}berschreiben. - -Zum Beispiel k\"{o}nnen Sie folgendes eingeben: - -\footnotesize -\begin{verbatim} - @output /tmp/listing - estimate job=NightlySave listing level=Incremental - @output -\end{verbatim} -\normalsize - - durch das erste Kommando wird die Ausgabe der Console in die Datei - {\bf /tmp/listing} umgeleitet. Dann wird durch das estimate-Kommando - eine Liste aller Dateien erstellt, die beim n\"{a}chsten inkrementellen - Backup des Jobs {\bf NightlySave} gesichert werden. Die Console gibt dabei keine - Meldungen aus, da die Ausgabe ja auf die Datei /tmp/listing zeigt. Durch - das dritte Kommando @output wird die Umleitung der Ausgabe wieder aufgehoben. - Beachten Sie bitte, dass die angezeigten Bytes in der Ausgabe des estimate-Kommandos - \"{u}ber die Angabe der Dateigr\"{o}{\ss}e im Verzeichnis-Eintrag bestimmt wird. - Das kann zu gro{\ss}en Abweichungen bei der ermittelten Backup-Gr\"{o}{\ss}e f\"{u}hren, - falls im FileSet \elink{sparse}{http://de.wikipedia.org/wiki/Sparse-Datei}-Dateien - vorhanden sind. sparse-Dateien finden sich oft auf 64-Bit-Maschinen, wo sie f\"{u}r - bestimmte Systemdateien benutzt werden. Die angezeigten Bytes sind die Gesammtgr\"{o}{\ss}e - der gesicherten Dateien, wenn die FileSet-Option "sparse" nicht gesetzt ist. - Momentan gibt es keinen Weg, um mit dem estimate-Kommando die echte Backup-Gr\"{o}{\ss}e - f\"{u}r ein FileSet anzuzeigen, bei dem die sparse-Option gesetzt ist. - -\item [help] - \index[general]{help} - Das help-Kommando zeigt alle verf\"{u}gbaren Kommandos mit einer kurzen Beschreibung an. - -\item [label] - \index[general]{label} - \index[general]{relabel} - \index[general]{label} - \index[general]{relabel} - Das label-Kommando wird benutzt um physikalische Volumes zu labeln. - Das label-Kommando kann folgenderma{\ss}en aufgerufen werden: - -\begin{verbatim} -label storage=>storage-name> volume=>volume-name> slot=>slot> -\end{verbatim} - - Wenn Sie einen der Parameter storage, volume oder slot nicht angeben, - werden Sie von der Console danach gefragt. Der Media-Typ wird automatisch - anhand des Storage-Eintrags in der Director-Konfiguration gesetzt. - Wenn alle ben\"{o}tigten Informationen vorliegen, kontaktiert die - Console den angegebenen Storage-Dienst und sendet das label-Kommando. - Wenn das labeln erfolgreich war, wird ein entsprechender Volume-Eintrag - im passenden Pool erzeugt. - - Im Volume-Name d\"{u}rfen Buchstaben, Zahlen und folgende Sonderzeichen - verwendet werden: Binde- ({\bf -}) und Unterstrich ({\bf \_}), - Doppelpunkt ({\bf :}) und Punkt ({\bf .}). Alle anderen Zeichen, - einschlie{\ss}lich des Leerzeichens, sind nicht erlaubt. - Durch diese Einschr\"{a}nkung soll sichergestellt werden, dass - die Volume-Namen gut lesbar sind und es nicht zu Benutzerfehlern - aufgrund von Sonderzeichen im Namen kommt. - - Bitte beachten Sie, dass Bacula einen Ein-/Ausgabefehler meldet, - wenn ein neues bzw. komplett leeres Volume gelabelt wird. Bacula - versucht den ersten Block des Volumes zu lesen, um ein eventuell schon - vorhandenes label nicht zu \"{u}berschreiben, dieser Versuch erzeugt - den oben genannten Fehler. Um diesen Fehler zu vermeiden, k\"{o}nnen Sie - mit den folgenden Shell-Kommandos ein EOF am den Anfang des Volumes schreiben: - -\footnotesize -\begin{verbatim} - mt rewind - mt weof - -\end{verbatim} -\normalsize - -Das label-Kommando kann aufgrund verschiedener Gr\"{u}nde fehlschlagen: - -\begin{enumerate} -\item Der angegebene Volume-Name existiert schon in der Katalog-Datenbank - -\item Der Storage-Dienst hat schon ein Tape oder anderes Volume in dem - ben\"{o}tigten Ger\"{a}t gemountet. In diesem Fall m\"{u}ssen Sie - das Ger\"{a}t erst mit dem {\bf unmount}-Kommando freigeben und dann - ein leeres Volume zum labeln einlegen. - -\item Das Volume ist bereits gelabelt. Bacula wird niemals ein bestehendes label - \"{u}berschreiben, solange das Volume nicht abgelaufen ist und Sie das - {\bf relabel}-Kommando verwenden. - -\item Es ist kein Volume im Ger\"{a}t. -\end{enumerate} - -Es gibt zwei M\"{o}glichkeiten ein bestehendes Bacula-label zu \"{u}berschreiben. -Die brutale Methode ist es, einfach ein EOF an den Anfang des Volumes zu schreiben -(dabei wird das bestehende label durch das EOF \"{u}berschrieben). -Mit dem Programm {\bf mt} k\"{o}nnen Sie das zum Beispiel so tun: - -\footnotesize -\begin{verbatim} - [user@host]$ mt -f /dev/st0 rewind - [user@host]$ mt -f /dev/st0 weof -\end{verbatim} -\normalsize - -Ein Festplatten-Volume k\"{o}nnen Sie auch manuell l\"{o}schen. - -Danach benutzten Sie das label-Kommando, um ein neues label zu erzeugen. -Allerdings kann diese Vorgehensweise Spuren des alten Volumes in der -Katalog-Datenbank hinterlassen. - -Die bevorzugte Methode ein Volume neu zu labeln sollte es sein, -zuerst das Volume als bereinigt (purged) zu markieren. Das passiert entweder automatisch, -wenn die Aufbewahrungszeit (Volume-Retention) f\"{u}r das Volume abl\"{a}uft, -oder kann aber auch mit dem {\bf purge}-Kommando erzwungen werden. -Danach k\"{o}nnen Sie das {\bf relabel}-Kommando, wie weiter unten beschrieben, verwenden. - -Falls Ihr Autochanger Barcode-Labels unterst\"{u}tzt, k\"{o}nnen Sie -alle Volumes im Autochanger, eins nach dem anderen, mit dem Kommando -{\bf label barcodes} labeln. Dabei wird jedes Tape mit Barcode nacheinander -im Laufwerk gemountet und mit der auf dem Barcode enthaltenen Zeichenfolge -als Namen gelabelt. Ein entsprechender Katalog-Eintrag wird automatisch -mit erzeugt. Jedes Volume mit einem Barcode der mit den Zeichen beginnt, -die im Pool-Eintrag als CleaningPrefix konfiguriert sind, wird wie ein -Reinigungsband behandelt und nicht gelabelt. Allerdings wird dabei auch -ein Katalog-Eintrag f\"{u}r das Reinigungsband erstellt. - -Als Beispiel, mit dem Eintrag: -\footnotesize -\begin{verbatim} - Pool { - Name ... - Cleaning Prefix = "CLN" - } -\end{verbatim} -\normalsize - -wird jedes Tape, dessen Barcode mit CLN beginnt, als Reinigungsband betrachtet -und nicht automatisch gemountet. -Das label-Kommando kann folgenderma{\ss}en aufgerufen werden: - -\footnotesize -\begin{verbatim} -label storage=xxx pool=yyy slots=1-5,10 barcodes -\end{verbatim} -\normalsize - -\item [list] - \index[general]{list} - Das list-Kommando zeigt den angegebenen Inhalt der Katalog-Datenbank an. - Die verschiedenen Felder jedes Eintrags werden in einer Zeile ausgegeben. - Die verschiedenen M\"{o}glichkeiten sind: -\footnotesize -\begin{verbatim} - list jobs - - list jobid= (zeigt jobid an) - - list ujobid (zeigt den job mit dem Namen an) - - list job= (zeigt alle Jobs mit dem Namen an) - - list jobname= (identisch mit dem oberen) - - Im oberen Beispiel k\"{o}nnen Sie auch den Parameter limit=nn - hinzuf\"{u}gen, um die Ausgabe des Kommandos auf nn Jobs zu begrenzen - - 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 - - Die meisten der oben genannten Parameter sollten selbsterkl\"{a}rend sein. - \"{U}blicherweise werden Sie, falls Sie nicht gen\"{u}gend Parameter angeben, - von der Console nach den fehlenden Informationen gefragt. - - Das {\bf list nextvol}-Kommando gibt den Volume-Namen aus, der von dem angegebenen Job - beim n\"{a}chsten Backup benutzt werden wird. Allerdings sollten Sie beachten, dass - das tats\"{a}chlich benutzte Volume von einer Reihe von Faktoren, wie zum Beispiel - von den vorher laufenden Jobs oder der Zeit wann der Job l\"{a}uft, abh\"{a}ngen kann. - Eventuell wird ein Tape schon voll sein, das aber noch freien Platz hatte, als Sie - das Kommando ausf\"{u}hrten. Dieses Kommando gibt Ihnen also nur einen Hinweis darauf, - welches Tape benutzt werden k\"{o}nnte, aber es kann keine definitive Aussage dar\"{u}ber treffen. - Zus\"{a}tzlich kann dieses Kommando mehrere Seiteneffekte haben, da es den selben - Algorithmus durchl\"{a}uft, wie ein echter Backup-Job. Das bedeutet, dass es dazu f\"{u}hren kann, - dass aufgrund dieses Kommandos Volumes automatisch recycled oder gelöscht (purged) werden. - Standardm\"{a}{\ss}ig muss der angegebene Job innerhalb der n\"{a}chsten zwei Tage laufen, - ansonsten wird kein Volume f\"{u}r den Job gefunden. Allerdings k\"{o}nnen Sie durch Angabe des Parameters - {\bf days=nnn} bis zu 50 Tage in die Zukunft angeben, die das Kommando in die Berechnung - mit einbeziehen soll. Falls Sie, zum Beispiel, Freitags sehen wollen, welches Volume am Montag - vorrausssichtlich benutzt wird, k\"{o}nnen Sie folgendes Kommando benutzen: - {\bf list nextvol job=MyJob days=3}. - - Wenn Sie bestimmte, von Ihnen \"{o}fter ben\"{o}tigte, eigene Kommandos anlegen wollen - um sich bestimmte Inhalte der Katalog-Datenbank anzeigen zu lassen, - k\"{o}nnen Sie diese der Datei {\bf query.sql} hinzu\"{u}gen. Allerdings - erfordert das einiges an Wissen \"{u}ber SQL-Kommandos. Lesen Sie dazu bitte - den Abschnitt \"{u}ber das {\bf query}-Kommando in diesem Kapitel. - - Weiter unten finden Sie auch eine Beispiel-Ausgabe des {\bf llist}-Kommandos, - das Ihnen den kompletten Inhalt des Katalogs zu einem bestimmten Konfigurations-Eintrag - anzeigt. - - Als ein Beispiel, kann Ihnen der Aufruf des Kommandos {\bf list pools} die folgenden - Ausgaben anzeigen: - -\footnotesize -\begin{verbatim} -+------+---------+---------+---------+----------+-------------+ -| PoId | Name | NumVols | MaxVols | PoolType | LabelFormat | -+------+---------+---------+---------+----------+-------------+ -| 1 | Default | 0 | 0 | Backup | * | -| 2 | Recycle | 0 | 8 | Backup | File | -+------+---------+---------+---------+----------+-------------+ -\end{verbatim} -\normalsize - - As mentioned above, the {\bf list} command lists what is in the - database. Some things are put into the database immediately when Bacula - starts up, but in general, most things are put in only when they are - first used, which is the case for a Client as with Job records, etc. - - Bacula should create a client record in the database the first time you - run a job for that client. Doing a {\bf status} will not cause a - database record to be created. The client database record will be - created whether or not the job fails, but it must at least start. When - the Client is actually contacted, additional info from the client will - be added to the client record (a "uname -a" output). - - If you want to see what Client resources you have available in your conf - file, you use the Console command {\bf show clients}. - -\item [llist] - \index[general]{llist} - The llist or "long list" command takes all the same arguments that the - list command described above does. The difference is that the llist - command list the full contents of each database record selected. It - does so by listing the various fields of the record vertically, with one - field per line. It is possible to produce a very large number of output - lines with this command. - - If instead of the {\bf list pools} as in the example above, you enter - {\bf llist pools} you might get the following output: - -\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[general]{messages} - This command causes any pending console messages to be immediately displayed. - - -\item [mount] - \index[general]{mount} - The mount command is used to get Bacula to read a volume on a physical - device. It is a way to tell Bacula that you have mounted a tape and - that Bacula should examine the tape. This command is normally - used only after there was no Volume in a drive and Bacula requests you to mount a new - Volume or when you have specifically unmounted a Volume with the {\bf - unmount} console command, which causes Bacula to close the drive. If - you have an autoloader, the mount command will not cause Bacula to - operate the autoloader unless you specify a {\bf slot} and possibly a - {\bf drive}. The various forms of the mount command are: - -mount storage=\lt{}storage-name\gt{} [ slot=\lt{}num\gt{} ] [ - drive=\lt{}num\gt{} ] - -mount [ jobid=\lt{}id\gt{} | job=\lt{}job-name\gt{} ] - - If you have specified {\bf Automatic Mount = yes} in the Storage daemon's - Device resource, under most circumstances, Bacula will automatically access - the Volume unless you have explicitly {\bf unmount}ed it in the Console - program. - -\item[python] - \index[general]{python} - The python command takes a single argument {\bf restart}: - -python restart - - This causes the Python interpreter in the Director to be reinitialized. - This can be helpful for testing because once the Director starts and the - Python interpreter is initialized, there is no other way to make it - accept any changes to the startup script {\bf DirStartUp.py}. For more - details on Python scripting, please see the \ilink{Python - Scripting}{PythonChapter} chapter of this manual. - -\label{ManualPruning} -\item [prune] - \index[general]{prune} - The Prune command allows you to safely remove expired database records - from Jobs and Volumes. This command works only on the Catalog database - and does not affect data written to Volumes. In all cases, the Prune - command applies a retention period to the specified records. You can - Prune expired File entries from Job records; you can Prune expired Job - records from the database, and you can Prune both expired Job and File - records from specified Volumes. - -prune files|jobs|volume client=\lt{}client-name\gt{} -volume=\lt{}volume-name\gt{} - - For a Volume to be pruned, the {\bf VolStatus} must be Full, Used, or - Append, otherwise the pruning will not take place. - -\item [purge] - \index[general]{purge} - The Purge command will delete associated Catalog database records from - Jobs and Volumes without considering the retention period. {\bf Purge} - works only on the Catalog database and does not affect data written to - Volumes. This command can be dangerous because you can delete catalog - records associated with current backups of files, and we recommend that - you do not use it unless you know what you are doing. The permitted - forms of {\bf purge} are: - -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) - -For the {\bf purge} command to work on Volume Catalog database records the -{\bf VolStatus} must be Append, Full, Used, or Error. - -The actual data written to the Volume will be unaffected by this command. - -\item [relabel] - \index[general]{relabel} - \index[general]{relabel} - This command is used to label physical volumes. The full form of this - command is: - -relabel storage=\lt{}storage-name\gt{} oldvolume=\lt{}old-volume-name\gt{} - volume=\lt{}newvolume-name\gt{} - - If you leave out any part, you will be prompted for it. In order for - the Volume (old-volume-name) to be relabeled, it must be in the catalog, - and the volume status must be marked {\bf Purged} or {\bf Recycle}. - This happens automatically as a result of applying retention periods, or - you may explicitly purge the volume using the {\bf purge} command. - - Once the volume is physically relabeled, the old data previously written - on the Volume is lost and cannot be recovered. - -\item [release] - \index[general]{release} - This command is used to cause the Storage daemon to rewind (release) the - current tape in the drive, and to re-read the Volume label the next time - the tape is used. - -release storage=\lt{}storage-name\gt{} - - After a release command, the device is still kept open by Bacula (unless - Always Open is set to No in the Storage Daemon's configuration) so it - cannot be used by another program. However, with some tape drives, the - operator can remove the current tape and to insert a different one, and - when the next Job starts, Bacula will know to re-read the tape label to - find out what tape is mounted. If you want to be able to use the drive - with another program (e.g. {\bf mt}), you must use the {\bf unmount} - command to cause Bacula to completely release (close) the device. - -\item [reload] - \index[general]{reload} - The reload command causes the Director to re-read its configuration - file and apply the new values. The new values will take effect - immediately for all new jobs. However, if you change schedules, - be aware that the scheduler pre-schedules jobs up to two hours in - advance, so any changes that are to take place during the next two - hours may be delayed. Jobs that have already been scheduled to run - (i.e. surpassed their requested start time) will continue with the - old values. New jobs will use the new values. Each time you issue - a reload command while jobs are running, the prior config values - will queued until all jobs that were running before issuing - the reload terminate, at which time the old config values will - be released from memory. The Directory permits keeping up to - ten prior set of configurations before it will refuse a reload - command. Once at least one old set of config values has been - released it will again accept new reload commands. - - While it is possible to reload the Director's configuration on the fly, - even while jobs are executing, this is a complex operation and not - without side effects. Accordingly, if you have to reload the Director's - configuration while Bacula is running, it is advisable to restart the - Director at the next convenient opportunity. - -\label{restore_command} -\item [restore] - \index[general]{restore} - The restore command allows you to select one or more Jobs (JobIds) to be - restored using various methods. Once the JobIds are selected, the File - records for those Jobs are placed in an internal Bacula directory tree, - and the restore enters a file selection mode that allows you to - interactively walk up and down the file tree selecting individual files - to be restored. This mode is somewhat similar to the standard Unix {\bf - restore} program's interactive file selection mode. - -restore storage=\lt{}storage-name\gt{} client=\lt{}backup-client-name\gt{} - where=\lt{}path\gt{} pool=\lt{}pool-name\gt{} fileset=\lt{}fileset-name\gt{} - restoreclient=\lt{}restore-client-name\gt{} - select current all done - - Where {\bf current}, if specified, tells the restore command to - automatically select a restore to the most current backup. If not - specified, you will be prompted. The {\bf all} specification tells the - restore command to restore all files. If it is not specified, you will - be prompted for the files to restore. For details of the {\bf restore} - command, please see the \ilink{Restore Chapter}{RestoreChapter} of this - manual. - - The client keyword initially specifies the client from which the backup - was made and the client to which the restore will be make. However, - if the restoreclient keyword is specified, then the restore is written - to that client. - -\item [run] - \index[general]{run} - This command allows you to schedule jobs to be run immediately. The full form - of the command is: - -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 - - Any information that is needed but not specified will be listed for - selection, and before starting the job, you will be prompted to accept, - reject, or modify the parameters of the job to be run, unless you have - specified {\bf yes}, in which case the job will be immediately sent to - the scheduler. - - On my system, when I enter a run command, I get the following prompt: - -\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 - -If I then select number 5, I am prompted with: - -\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 - -If I now enter {\bf yes}, the Job will be run. If I enter {\bf mod}, I will -be presented with the following prompt. - -\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 - -If you wish to start a job at a later time, you can do so by setting the When -time. Use the {\bf mod} option and select {\bf When} (no. 6). Then enter the -desired start time in YYYY-MM-DD HH:MM:SS format. - -\item [setdebug] - \index[general]{setdebug} - \index[general]{setdebug} - \index[general]{debugging} - \index[general]{debugging Win32} - \index[general]{Windows!debugging} - This command is used to set the debug level in each daemon. The form of this - command is: - -setdebug level=nn [trace=0/1 client=\lt{}client-name\gt{} | dir | director | - storage=\lt{}storage-name\gt{} | all] - - If trace=1 is set, then tracing will be enabled, and the daemon will be - placed in trace mode, which means that all debug output as set by the - debug level will be directed to the file {\bf bacula.trace} in the - current directory of the daemon. Normally, tracing is needed only for - Win32 clients where the debug output cannot be written to a terminal or - redirected to a file. When tracing, each debug output message is - appended to the trace file. You must explicitly delete the file when - you are done. - -\item [show] - \index[general]{show} - \index[general]{show} - The show command will list the Director's resource records as defined in - the Director's configuration file (normally {\bf bacula-dir.conf}). - This command is used mainly for debugging purposes by developers. - The following keywords are accepted on the - show command line: catalogs, clients, counters, devices, directors, - filesets, jobs, messages, pools, schedules, storages, all, help. - Please don't confuse this command - with the {\bf list}, which displays the contents of the catalog. - -\item [sqlquery] - \index[general]{sqlquery} - The sqlquery command puts the Console program into SQL query mode where - each line you enter is concatenated to the previous line until a - semicolon (;) is seen. The semicolon terminates the command, which is - then passed directly to the SQL database engine. When the output from - the SQL engine is displayed, the formation of a new SQL command begins. - To terminate SQL query mode and return to the Console command prompt, - you enter a period (.) in column 1. - - Using this command, you can query the SQL catalog database directly. - Note you should really know what you are doing otherwise you could - damage the catalog database. See the {\bf query} command below for - simpler and safer way of entering SQL queries. - - Depending on what database engine you are using (MySQL, PostgreSQL or - SQLite), you will have somewhat different SQL commands available. For - more detailed information, please refer to the MySQL, PostgreSQL or - SQLite documentation. - -\item [status] - \index[general]{status} - This command will display the status of the next jobs that are scheduled - during the next 24 hours as well as the status of currently - running jobs. The full form of this command is: - -status [all | dir=\lt{}dir-name\gt{} | director | - client=\lt{}client-name\gt{} | storage=\lt{}storage-name\gt{} | - days=nnn] - - If you do a {\bf status dir}, the console will list any currently - running jobs, a summary of all jobs scheduled to be run in the next 24 - hours, and a listing of the last ten terminated jobs with their statuses. - The scheduled jobs summary will include the Volume name to be used. You - should be aware of two things: 1. to obtain the volume name, the code - goes through the same code that will be used when the job runs, but it - does not do pruning nor recycling of Volumes; 2. The Volume listed is - at best a guess. The Volume actually used may be different because of - the time difference (more durations may expire when the job runs) and - another job could completely fill the Volume requiring a new one. - - In the Running Jobs listing, you may find the following types of - information: - - -\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 - - Looking at the above listing from bottom to top, obviously JobId 5343 - (Rufus) is running. JobId 5348 (Minou) is waiting for JobId 5343 to - finish because it is using the Storage resource, hence the "waiting on - max Storage jobs". JobId 5349 has a lower priority than all the other - jobs so it is waiting for higher priority jobs to finish, and finally, - JobId 2508 (MatouVerify) is waiting because only one job can run at a - time, hence it is simply "waiting execution" - - If you do a {\bf status dir}, it will by default list the first - occurrence of all jobs that are scheduled today and tomorrow. If you - wish to see the jobs that are scheduled in the next three days (e.g. on - Friday you want to see the first occurrence of what tapes are scheduled - to be used on Friday, the weekend, and Monday), you can add the {\bf - days=3} option. Note, a {\bf days=0} shows the first occurrence of jobs - scheduled today only. If you have multiple run statements, the first - occurrence of each run statement for the job will be displayed for the - period specified. - - If your job seems to be blocked, you can get a general idea of the - problem by doing a {\bf status dir}, but you can most often get a - much more specific indication of the problem by doing a - {\bf status storage=xxx}. For example, on an idle test system, when - I do {\bf status storage=File}, I get: -\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 - -Now, what this tells me is that no jobs are running and that none of -the devices are in use. Now, if I {\bf unmount} the autochanger, which -will not be used in this example, and then start a Job that uses the -File device, the job will block. When I re-issue the status storage -command, I get for the Device status: - -\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 - -Now, here it should be clear that if a job were running that wanted -to use the Autochanger (with two devices), it would block because -the user unmounted the device. The real problem for the Job I started -using the "File" device is that the device is blocked waiting for -media -- that is Bacula needs you to label a Volume. - -\item [unmount] - \index[general]{unmount} - This command causes the indicated Bacula Storage daemon to unmount the - specified device. The forms of the command are the same as the mount command: -\footnotesize -\begin{verbatim} -unmount storage= [ drive= ] - -unmount [ jobid= | job= ] -\end{verbatim} -\normalsize - - Once you unmount a storage device, Bacula will no longer be able to use - it until you issue a mount command for that device. If Bacula needs to - access that device, it will block and issue mount requests periodically - to the operator. - - If the device you are unmounting is an autochanger, it will unload - the drive you have specified on the command line. If no drive is - specified, it will assume drive 1. - -\label{UpdateCommand} -\item [update] - \index[general]{update} - This command will update the catalog for either a specific Pool record, a Volume - record, or the Slots in an autochanger with barcode capability. In the case - of updating a Pool record, the new information will be automatically taken - from the corresponding Director's configuration resource record. It can be - used to increase the maximum number of volumes permitted or to set a maximum - number of volumes. The following main keywords may be specified: -\footnotesize -\begin{verbatim} - media, volume, pool, slots -\end{verbatim} -\normalsize - -In the case of updating a Volume, you will be prompted for which value you -wish to change. The following Volume parameters may be changed: - -\footnotesize -\begin{verbatim} - - Volume Status - Volume Retention Period - Volume Use Duration - Maximum Volume Jobs - Maximum Volume Files - Maximum Volume Bytes - Recycle Flag - Recycle Pool - Slot - InChanger Flag - Pool - Volume Files - Volume from Pool - All Volumes from Pool - All Volumes from all Pools - -\end{verbatim} -\normalsize - - For slots {\bf update slots}, Bacula will obtain a list of slots and - their barcodes from the Storage daemon, and for each barcode found, it - will automatically update the slot in the catalog Media record to - correspond to the new value. This is very useful if you have moved - cassettes in the magazine, or if you have removed the magazine and - inserted a different one. As the slot of each Volume is updated, the - InChanger flag for that Volume will also be set, and any other Volumes - in the Pool that were last mounted on the same Storage device - will have their InChanger flag turned off. This permits - Bacula to know what magazine (tape holder) is currently in the - autochanger. - - If you do not have barcodes, you can accomplish the same thing in - version 1.33 and later by using the {\bf update slots scan} command. - The {\bf scan} keyword tells Bacula to physically mount each tape and to - read its VolumeName. - - For Pool {\bf update pool}, Bacula will move the Volume record from its - existing pool to the pool specified. - - For {\bf Volume from Pool}, {\bf All Volumes from Pool} and {\bf All Volumes - from all Pools}, the following values are updated from the Pool record: - Recycle, RecyclePool, VolRetention, VolUseDuration, MaxVolJobs, MaxVolFiles, - and MaxVolBytes. (RecyclePool feature is available with bacula 2.1.4 or - higher.) - - The full form of the update command with all command line arguments is: - -\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 recyclepool=zzz - -\end{verbatim} -\normalsize - -\item [use] - \index[general]{use} - This command allows you to specify which Catalog database to use. Normally, -you will be using only one database so this will be done automatically. In -the case that you are using more than one database, you can use this command -to switch from one to another. - -use \lt{}database-name\gt{} - -\item [var] - \label{var} - \index[general]{var name} - This command takes a string or quoted string and does variable expansion on - it the same way variable expansion is done on the {\bf LabelFormat} string. - Thus, for the most part, you can test your LabelFormat strings. The - difference between the {\bf var} command and the actual LabelFormat process - is that during the var command, no job is running so "dummy" values are - used in place of Job specific variables. Generally, however, you will get a - good idea of what is going to happen in the real case. - -\item [version] - \index[general]{version} - The command prints the Director's version. - -\item [quit] - \index[general]{quit} - This command terminates the console program. The console program sends the - {\bf quit} request to the Director and waits for acknowledgment. If the - Director is busy doing a previous command for you that has not terminated, it - may take some time. You may quit immediately by issuing the {\bf .quit} - command (i.e. quit preceded by a period). - -\item [query] - \index[general]{query} - This command reads a predefined SQL query from the query file (the name and - location of the query file is defined with the QueryFile resource record in - the Director's configuration file). You are prompted to select a query from - the file, and possibly enter one or more parameters, then the command is - submitted to the Catalog database SQL engine. - -The following queries are currently available (version 1.24): - -\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[general]{exit} - This command terminates the console program. - -\item [wait] - \index[general]{wait} - The wait command causes the Director to pause until there are no jobs - running. This command is useful in a batch situation such as regression - testing where you wish to start a job and wait until that job completes - before continuing. This command now has the following options: -\footnotesize -\begin{verbatim} - wait [jobid=nn] [jobuid=unique id] [job=job name] -\end{verbatim} -\normalsize - If specified with a specific JobId, ... the wait command will wait - for that particular job to terminate before continuing. - -\end{description} - -\label{dotcommands} -\section{Special dot Commands} -\index[general]{Commands!Special dot} -\index[general]{Special dot Commands} - -There is a list of commands that are prefixed with a period (.). These -commands are intended to be used either by batch programs or graphical user -interface front-ends. They are not normally used by interactive users. Once -GUI development begins, this list will be considerably expanded. The following -is the list of dot commands: - -\footnotesize -\begin{verbatim} -.backups job=xxx list backups for specified job -.clients list all client names -.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. -.exit quit -.filesets list all fileset names -.help help command output -.jobs list all job names -.levels list all levels -.messages get quick messages -.msgs return any queued messages -.pools list all pool names -.quit quit -.status get status output -.storage return storage resource names -.types list job types -\end{verbatim} -\normalsize - -\label{atcommands} - -\section{Special At (@) Commands} -\index[general]{Commands!Special At @} -\index[general]{Special At (@) Commands} - -Normally, all commands entered to the Console program are immediately -forwarded to the Director, which may be on another machine, to be executed. -However, there is a small list of {\bf at} commands, all beginning with an at -character (@), that will not be sent to the Director, but rather interpreted -by the Console program directly. Note, these commands are implemented only in -the tty console program and not in the GNOME Console. These commands are: - -\begin{description} - -\item [@input \lt{}filename\gt{}] - \index[general]{@input \lt{}filename\gt{}} - Read and execute the commands contained in the file specified. - -\item [@output \lt{}filename\gt{} w/a] - \index[general]{@output \lt{}filename\gt{} w/a} - Send all following output to the filename specified either overwriting the -file (w) or appending to the file (a). To redirect the output to the -terminal, simply enter {\bf @output} without a filename specification. -WARNING: be careful not to overwrite a valid file. A typical example during a -regression test might be: - -\footnotesize -\begin{verbatim} - @output /dev/null - commands ... - @output - -\end{verbatim} -\normalsize - -\item [@tee \lt{}filename\gt{} w/a] - \index[general]{@tee \lt{}filename\gt{} w/a} - Send all subsequent output to both the specified file and the terminal. It is - turned off by specifying {\bf @tee} or {\bf @output} without a filename. - -\item [@sleep \lt{}seconds\gt{}] - \index[general]{@sleep \lt{}seconds\gt{}} - Sleep the specified number of seconds. - -\item [@time] - \index[general]{@time} - Print the current time and date. - -\item [@version] - \index[general]{@version} - Print the console's version. - -\item [@quit] - \index[general]{@quit} - quit - -\item [@exit] - \index[general]{@exit} - quit - -\item [@\# anything] - \index[general]{anything} - Comment -\end{description} - -\label{scripting} - -\section{Running the Console from a Shell Script} -\index[general]{Script!Running the Console Program from a Shell} -\index[general]{Running the Console Program from a Shell Script} - -You can automate many Console tasks by running the console program from a -shell script. For example, if you have created a file containing the following -commands: - -\footnotesize -\begin{verbatim} - ./bconsole -c ./bconsole.conf <master.keypair - -\item 2) Set the PKI Keypair statement in your bacula configuration file: - -\begin{verbatim} - PKI Keypair = master.keypair -\end{verbatim} - -\item Start the restore. The master keypair will be used to decrypt - the file data. - -\end{itemize} - - -\section{Generating Private/Public Encryption Keys} -\index[general]{Generating Private/Public Encryption Keypairs} - -Generate a Master Key Pair with: - -\footnotesize -\begin{verbatim} - openssl genrsa -out master.key 2048 - openssl req -new -key master.key -x509 -out master.cert -\end{verbatim} -\normalsize - -Generate a File Daemon Key Pair for each FD: - -\footnotesize -\begin{verbatim} - openssl genrsa -out fd-example.key 2048 - openssl req -new -key fd-example.key -x509 -out fd-example.cert - cat fd-example.key fd-example.cert >fd-example.pem -\end{verbatim} -\normalsize - -Note, there seems to be a lot of confusion around the file extensions given -to these keys. For example, a .pem file can contain all the following: -private keys (RSA and DSA), public keys (RSA and DSA) and (x509) certificates. -It is the default format for OpenSSL. It stores data Base64 encoded DER format, -surrounded by ASCII headers, so is suitable for text mode transfers between -systems. A .pem file may contain any number of keys either public or -private. We use it in cases where there is both a public and a private -key. - -Typically, above we have used the .cert extension to refer to X509 -certificate encoding that contains only a single public key. - - -\section{Example Data Encryption Configuration} -\index[general]{Example!File Daemon Configuration File} -\index[general]{Example!Data Encryption Configuration File} -\index[general]{Example Data Encryption Configuration} - -{\bf bacula-fd.conf} -\footnotesize -\begin{verbatim} -FileDaemon { - Name = example-fd - FDport = 9102 # where we listen for the director - WorkingDirectory = /var/bacula/working - Pid Directory = /var/run - Maximum Concurrent Jobs = 20 - - PKI Signatures = Yes # Enable Data Signing - PKI Encryption = Yes # Enable Data Encryption - PKI Keypair = "/etc/bacula/fd-example.pem" # Public and Private Keys - PKI Master Key = "/etc/bacula/master.cert" # ONLY the Public Key -} -\end{verbatim} -\normalsize diff --git a/docs/manual-de/dirdconf.tex b/docs/manual-de/dirdconf.tex deleted file mode 100644 index e3007140..00000000 --- a/docs/manual-de/dirdconf.tex +++ /dev/null @@ -1,2762 +0,0 @@ -%% -%% - -\section*{Configuring the Director} -\label{_ChapterStart40} -\index[general]{Director!Configuring the} -\index[general]{Configuring the Director} -\addcontentsline{toc}{section}{Configuring the Director} - -Of all the configuration files needed to run {\bf Bacula}, the Director's is -the most complicated, and the one that you will need to modify the most often -as you add clients or modify the FileSets. - -For a general discussion of configuration files and resources including the -data types recognized by {\bf Bacula}. Please see the -\ilink{Configuration}{_ChapterStart16} chapter of this manual. - -\subsection*{Director Resource Types} -\index[general]{Types!Director Resource} -\index[general]{Director Resource Types} -\addcontentsline{toc}{subsection}{Director Resource Types} - -Director resource type may be one of the following: - -Job, JobDefs, Client, Storage, Catalog, Schedule, FileSet, Pool, Director, or -Messages. We present them here in the most logical order for defining them: - -\begin{itemize} -\item - \ilink{Director}{DirectorResource4} -- to define the Director's - name and its access password used for authenticating the Console program. - Only a single Director resource definition may appear in the Director's - configuration file. If you have either {\bf /dev/random} or {\bf bc} on your - machine, Bacula will generate a random password during the configuration - process, otherwise it will be left blank. -\item - \ilink{Job}{JobResource} -- to define the backup/restore Jobs - and to tie together the Client, FileSet and Schedule resources to be used - for each Job. -\item - \ilink{JobDefs}{JobDefsResource} -- optional resource for - providing defaults for Job resources. -\item - \ilink{Schedule}{ScheduleResource} -- to define when a Job is to - be automatically run by {\bf Bacula's} internal scheduler. -\item - \ilink{FileSet}{FileSetResource} -- to define the set of files - to be backed up for each Client. -\item - \ilink{Client}{ClientResource2} -- to define what Client is to be - backed up. -\item - \ilink{Storage}{StorageResource2} -- to define on what physical - device the Volumes should be mounted. -\item - \ilink{Pool}{PoolResource} -- to define the pool of Volumes - that can be used for a particular Job. -\item - \ilink{Catalog}{CatalogResource} -- to define in what database to - keep the list of files and the Volume names where they are backed up. -\item - \ilink{Messages}{_ChapterStart15} -- to define where error and - information messages are to be sent or logged. -\end{itemize} - -\subsection*{The Director Resource} -\label{DirectorResource4} -\index[general]{Director Resource} -\index[general]{Resource!Director} -\addcontentsline{toc}{subsection}{Director Resource} - -The Director resource defines the attributes of the Directors running on the -network. In the current implementation, there is only a single Director -resource, but the final design will contain multiple Directors to maintain -index and media database redundancy. - -\begin{description} - -\item [Director] - \index[dir]{Director} - Start of the Director resource. One and only one director resource must be -supplied. - -\item [Name = \lt{}name\gt{}] - \index[dir]{Name } - The director name used by the system administrator. This directive is -required. - -\item [Description = \lt{}text\gt{}] - \index[dir]{Description } - The text field contains a description of the Director that will be displayed -in the graphical user interface. This directive is optional. - -\item [Password = \lt{}UA-password\gt{}] - \index[dir]{Password } - Specifies the password that must be supplied for the default Bacula Console - to be authorized. The same password must appear in the {\bf Director} - resource of the Console configuration file. For added security, the password - is never actually passed across the network but rather a challenge response - hash code created with the password. This directive is required. If you have - either {\bf /dev/random} or {\bf bc} on your machine, Bacula will generate a - random password during the configuration process, otherwise it will be left - blank and you must manually supply it. - -\item [Messages = \lt{}Messages-resource-name\gt{}] - \index[dir]{Messages } - The messages resource specifies where to deliver Director messages that are - not associated with a specific Job. Most messages are specific to a job and - will be directed to the Messages resource specified by the job. However, - there are a few messages that can occur when no job is running. This - directive is required. - -\item [Working Directory = \lt{}Directory\gt{}] - \index[dir]{Working Directory } - This directive is mandatory and specifies a directory in which the Director - may put its status files. This directory should be used only by Bacula but - may be shared by other Bacula daemons. However, please note, if this - directory is shared with other Bacula daemons (the File daemon and Storage - daemon), you must ensure that the {\bf Name} given to each daemon is - unique so that the temporary filenames used do not collide. By default - the Bacula configure process creates unique daemon names by postfixing them - with -dir, -fd, and -sd. Standard shell expansion of the {\bf - Directory} is done when the configuration file is read so that values such - as {\bf \$HOME} will be properly expanded. This directive is required. - -\item [Pid Directory = \lt{}Directory\gt{}] - \index[dir]{Pid Directory } - This directive is mandatory and specifies a directory in which the Director -may put its process Id file. The process Id file is used to shutdown -Bacula and to prevent multiple copies of Bacula from running simultaneously. -Standard shell expansion of the {\bf Directory} is done when the -configuration file is read so that values such as {\bf \$HOME} will be -properly expanded. - -Typically on Linux systems, you will set this to: {\bf /var/run}. If you are -not installing Bacula in the system directories, you can use the {\bf Working -Directory} as defined above. This directive is required. - -\item [Scripts Directory = \lt{}Directory\gt{}] - \index[dir]{Scripts Directory } - This directive is optional and, if defined, specifies a directory in - which the Director will look for the Python startup script {\bf - DirStartup.py}. This directory may be shared by other Bacula daemons. - Standard shell expansion of the directory is done when the configuration - file is read so that values such as {\bf \$HOME} will be properly - expanded. - -\item [QueryFile = \lt{}Path\gt{}] - \index[dir]{QueryFile } - This directive is mandatory and specifies a directory and file in which - the Director can find the canned SQL statements for the {\bf Query} - command of the Console. Standard shell expansion of the {\bf Path} is - done when the configuration file is read so that values such as {\bf - \$HOME} will be properly expanded. This directive is required. - -\label{DirMaxConJobs} -\item [Maximum Concurrent Jobs = \lt{}number\gt{}] -\index[dir]{Maximum Concurrent Jobs } -\index[general]{Simultaneous Jobs} -\index[general]{Concurrent Jobs} - where \lt{}number\gt{} is the maximum number of total Director Jobs that -should run concurrently. The default is set to 1, but you may set it to a -larger number. - -Please note that the Volume format becomes much more complicated with -multiple simultaneous jobs, consequently, restores can take much longer if -Bacula must sort through interleaved volume blocks from multiple simultaneous -jobs. This can be avoided by having each simultaneously running job write to -a different volume or by using data spooling, which will first spool the data -to disk simultaneously, then write each spool file to the volume in -sequence. - -There may also still be some cases where directives such as {\bf Maximum -Volume Jobs} are not properly synchronized with multiple simultaneous jobs -(subtle timing issues can arise), so careful testing is recommended. - -At the current time, there is no configuration parameter set to limit the -number of console connections. A maximum of five simultaneous console -connections are permitted. - -For more details on getting concurrent jobs to run, please see -\ilink{Running Concurrent Jobs}{ConcurrentJobs} in the Tips chapter -of this manual. - -\item [FD Connect Timeout = \lt{}time\gt{}] - \index[dir]{FD Connect Timeout } - where {\bf time} is the time that the Director should continue - attempting to contact the File daemon to start a job, and after which - the Director will cancel the job. The default is 30 minutes. - -\item [SD Connect Timeout = \lt{}time\gt{}] - \index[dir]{SD Connect Timeout } - where {\bf time} is the time that the Director should continue - attempting to contact the Storage daemon to start a job, and after which - the Director will cancel the job. The default is 30 minutes. - -\item [DirAddresses = \lt{}IP-address-specification\gt{}] - \index[dir]{DirAddresses } - Specify the ports and addresses on which the Director daemon will listen - for Bacula Console connections. Probably the simplest way to explain - this is to show an example: - -\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 - -where ip, ip4, ip6, addr, and port are all keywords. Note, that the address -can be specified as either a dotted quadruple, or IPv6 colon notation, or as -a symbolic name (only in the ip specification). Also, port can be specified -as a number or as the mnemonic value from the /etc/services file. If a port -is not specified, the default will be used. If an ip section is specified, -the resolution can be made either by IPv4 or IPv6. If ip4 is specified, then -only IPv4 resolutions will be permitted, and likewise with ip6. - -\item [DIRport = \lt{}port-number\gt{}] - \index[dir]{DIRport } - Specify the port (a positive integer) on which the Director daemon will -listen for Bacula Console connections. This same port number must be -specified in the Director resource of the Console configuration file. The -default is 9101, so normally this directive need not be specified. This -directive is not needed if you specify DirAddresses. - -\item [DirAddress = \lt{}IP-Address\gt{}] - \index[dir]{DirAddress } - This directive is optional, but if it is specified, it will cause the -Director server (for the Console program) to bind to the specified {\bf -IP-Address}, which is either a domain name or an IP address specified as a -dotted quadruple in string or quoted string format. If this directive is not -specified, the Director will bind to any available address (the default). -Note, unlike the DirAddresses specification noted above, this directive only -permits a single address to be specified. This directive is not needed if you -specify a DirAddresses (not plural). -\end{description} - -The following is an example of a valid Director resource definition: - -\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*{The Job Resource} -\label{JobResource} -\index[general]{Resource!Job} -\index[general]{Job Resource} -\addcontentsline{toc}{subsection}{Job Resource} - -The Job resource defines a Job (Backup, Restore, ...) that Bacula must -perform. Each Job resource definition contains the name of a Client and -a FileSet to backup, the Schedule for the Job, where the data -are to be stored, and what media Pool can be used. In effect, each Job -resource must specify What, Where, How, and When or FileSet, Storage, -Backup/Restore/Level, and Schedule respectively. Note, the FileSet must -be specified for a restore job for historical reasons, but it is no longer used. - -Only a single type ({\bf Backup}, {\bf Restore}, ...) can be specified for any -job. If you want to backup multiple FileSets on the same Client or multiple -Clients, you must define a Job for each one. - -\begin{description} - -\item [Job] - \index[dir]{Job} - Start of the Job resource. At least one Job resource is required. - -\item [Name = \lt{}name\gt{}] - \index[dir]{Name } - The Job name. This name can be specified on the {\bf Run} command in the - console program to start a job. If the name contains spaces, it must be - specified between quotes. It is generally a good idea to give your job the - same name as the Client that it will backup. This permits easy - identification of jobs. - - When the job actually runs, the unique Job Name will consist of the name you - specify here followed by the date and time the job was scheduled for - execution. This directive is required. - -\item [Type = \lt{}job-type\gt{}] - \index[dir]{Type } - The {\bf Type} directive specifies the Job type, which may be one of the - following: {\bf Backup}, {\bf Restore}, {\bf Verify}, or {\bf Admin}. This - directive is required. Within a particular Job Type, there are also Levels - as discussed in the next item. - -\begin{description} - -\item [Backup] - \index[dir]{Backup} - Run a backup Job. Normally you will have at least one Backup job for each -client you want to save. Normally, unless you turn off cataloging, most all -the important statistics and data concerning files backed up will be placed -in the catalog. - -\item [Restore] - \index[dir]{Restore} - Run a restore Job. Normally, you will specify only one Restore job which -acts -as a sort of prototype that you will modify using the console program in -order to perform restores. Although certain basic information from a Restore -job is saved in the catalog, it is very minimal compared to the information -stored for a Backup job -- for example, no File database entries are -generated since no Files are saved. - -\item [Verify] - \index[dir]{Verify} - Run a verify Job. In general, {\bf verify} jobs permit you to compare the -contents of the catalog to the file system, or to what was backed up. In -addition, to verifying that a tape that was written can be read, you can -also use {\bf verify} as a sort of tripwire intrusion detection. - -\item [Admin] - \index[dir]{Admin} - Run an admin Job. An {\bf Admin} job can be used to periodically run catalog -pruning, if you do not want to do it at the end of each {\bf Backup} Job. -Although an Admin job is recorded in the catalog, very little data is saved. -\end{description} - -\label{Level} - -\item [Level = \lt{}job-level\gt{}] - \index[dir]{Level } - The Level directive specifies the default Job level to be run. Each -different -Job Type (Backup, Restore, ...) has a different set of Levels that can be -specified. The Level is normally overridden by a different value that is -specified in the {\bf Schedule} resource. This directive is not required, but -must be specified either by a {\bf Level} directive or as an override -specified in the {\bf Schedule} resource. - -For a {\bf Backup} Job, the Level may be one of the following: - -\begin{description} - -\item [Full] - \index[dir]{Full} - is all files in the FileSet whether or not they have changed. - -\item [Incremental] - \index[dir]{Incremental} - is all files specified in the FileSet that have changed since the last successful backup of the - the same Job using the same FileSet and Client. - If the Director cannot find a previous valid Full backup then - the job will be upgraded into a Full backup. When the Director looks for a - valid backup record in the catalog database, it looks for a previous - Job with: - -\begin{itemize} -\item The same Job name. -\item The same Client name. -\item The same FileSet (any change to the definition of the FileSet such as - adding or deleting a file in the Include or Exclude sections constitutes a - different FileSet. -\item The Job was a Full, Differential, or Incremental backup. -\item The Job terminated normally (i.e. did not fail or was not canceled). - \end{itemize} - -If all the above conditions do not hold, the Director will upgrade the -Incremental to a Full save. Otherwise, the Incremental backup will be -performed as requested. - -The File daemon (Client) decides which files to backup for an Incremental -backup by comparing start time of the prior Job (Full, Differential, or -Incremental) against the time each file was last "modified" (st\_mtime) and -the time its attributes were last "changed"(st\_ctime). If the file was -modified or its attributes changed on or after this start time, it will then -be backed up. - -Please note that some virus scanning software may change st\_ctime while -doing the scan. For example, if the virus scanning program attempts to -reset the access time (st\_atime), which Bacula does not use, it will cause -st\_ctime to change and hence Bacula will backup the file during an -Incremental or Differential backup. In the case of Sophos virus scanning, you -can prevent it from resetting the access time (st\_atime) and hence changing -st\_ctime by using the {\bf \verb:--:no-reset-atime} option. For other -software, -please see their manual. - -When Bacula does an Incremental backup, all modified files that are still on -the system are backed up. However, any file that has been deleted since the -last Full backup remains in the Bacula catalog, which means that if between -a Full save and the time you do a restore, some files are deleted, those -deleted files will also be restored. The deleted files will no longer appear -in the catalog after doing another Full save. However, to remove deleted -files from the catalog during an Incremental backup is quite a time consuming -process and not currently implemented in Bacula. - -In addition, if you move a directory rather than copy it, the files in it do not -have their modification time (st\_mtime) or their attribute change time -(st\_ctime) -changed. As a consequence, those files will probably not be backed up by an -Incremental -or Differential backup which depend solely on these time stamps. If you move a -directory, -and wish it to be properly backed up, it is generally preferable to copy it, -then -delete the original. - -\item [Differential] - \index[dir]{Differential} - is all files specified in the FileSet that have changed since the last - successful Full backup of the same Job. If the Director cannot find a - valid previous Full backup for the same Job, FileSet, and Client, - backup, then the Differential job will be upgraded into a Full backup. - When the Director looks for a valid Full backup record in the catalog - database, it looks for a previous Job with: - -\begin{itemize} -\item The same Job name. -\item The same Client name. -\item The same FileSet (any change to the definition of the FileSet such as - adding or deleting a file in the Include or Exclude sections constitutes a - different FileSet. -\item The Job was a FULL backup. -\item The Job terminated normally (i.e. did not fail or was not canceled). -\end{itemize} - -If all the above conditions do not hold, the Director will upgrade the -Differential to a Full save. Otherwise, the Differential backup will be -performed as requested. - -The File daemon (Client) decides which files to backup for a differential -backup by comparing the start time of the prior Full backup Job against the -time each file was last "modified" (st\_mtime) and the time its attributes -were last "changed" (st\_ctime). If the file was modified or its attributes -were changed on or after this start time, it will then be backed up. The -start time used is displayed after the {\bf Since} on the Job report. In rare -cases, using the start time of the prior backup may cause some files to be -backed up twice, but it ensures that no change is missed. As with the -Incremental option, you should ensure that the clocks on your server and -client are synchronized or as close as possible to avoid the possibility of a -file being skipped. Note, on versions 1.33 or greater Bacula automatically -makes the necessary adjustments to the time between the server and the client -so that the times Bacula uses are synchronized. - -When Bacula does a Differential backup, all modified files that are still -on the system are backed up. However, any file that has been deleted since -the last Full backup remains in the Bacula catalog, which means that if -between a Full save and the time you do a restore, some files are deleted, -those deleted files will also be restored. The deleted files will no -longer appear in the catalog after doing another Full save. However, to -remove deleted files from the catalog during a Differential backup is quite -a time consuming process and not currently implemented in Bacula. It is, -however, a planned future feature. - - -As noted above, if you move a directory rather than copy it, the -files in it do not have their modification time (st\_mtime) or -their attribute change time (st\_ctime) changed. As a -consequence, those files will probably not be backed up by an -Incremental or Differential backup which depend solely on these -time stamps. If you move a directory, and wish it to be -properly backed up, it is generally preferable to copy it, then -delete the original. Alternatively, you can move the directory, then -use the {\bf touch} program to update the timestamps. - -Every once and a while, someone asks why we need Differential -backups as long as Incremental backups pickup all changed files. -There are possibly many answers to this question, but the one -that is the most important for me is that it effectively combines -all the Incremental and Differential backups since the last Full -backup into a single Differential backup. This has two effects: -1. It gives some redundancy. 2. More importantly, it reduces the -number of Volumes that are needed to do a restore effectively -eliminating the need to read all the volumes on which the -preceding Incremental and Differential backups since the last -Full are done. - - -\end{description} - -For a {\bf Restore} Job, no level needs to be specified. - -For a {\bf Verify} Job, the Level may be one of the following: - -\begin{description} - -\item [InitCatalog] - \index[dir]{InitCatalog} - does a scan of the specified {\bf FileSet} and stores the file - attributes in the Catalog database. Since no file data is saved, you - might ask why you would want to do this. It turns out to be a very - simple and easy way to have a {\bf Tripwire} like feature using {\bf - Bacula}. In other words, it allows you to save the state of a set of - files defined by the {\bf FileSet} and later check to see if those files - have been modified or deleted and if any new files have been added. - This can be used to detect system intrusion. Typically you would - specify a {\bf FileSet} that contains the set of system files that - should not change (e.g. /sbin, /boot, /lib, /bin, ...). Normally, you - run the {\bf InitCatalog} level verify one time when your system is - first setup, and then once again after each modification (upgrade) to - your system. Thereafter, when your want to check the state of your - system files, you use a {\bf Verify} {\bf level = Catalog}. This - compares the results of your {\bf InitCatalog} with the current state of - the files. - -\item [Catalog] - \index[dir]{Catalog} - Compares the current state of the files against the state previously - saved during an {\bf InitCatalog}. Any discrepancies are reported. The - items reported are determined by the {\bf verify} options specified on - the {\bf Include} directive in the specified {\bf FileSet} (see the {\bf - FileSet} resource below for more details). Typically this command will - be run once a day (or night) to check for any changes to your system - files. - - Please note! If you run two Verify Catalog jobs on the same client at - the same time, the results will certainly be incorrect. This is because - Verify Catalog modifies the Catalog database while running in order to - track new files. - -\item [VolumeToCatalog] - \index[dir]{VolumeToCatalog} - This level causes Bacula to read the file attribute data written to the -Volume from the last Job. The file attribute data are compared to the values -saved in the Catalog database and any differences are reported. This is -similar to the {\bf Catalog} level except that instead of comparing the disk -file attributes to the catalog database, the attribute data written to the -Volume is read and compared to the catalog database. Although the attribute -data including the signatures (MD5 or SHA1) are compared, the actual file data -is not compared (it is not in the catalog). - -Please note! If you run two Verify VolumeToCatalog jobs on the same client at -the same time, the results will certainly be incorrect. This is because the -Verify VolumeToCatalog modifies the Catalog database while running. - -\item [DiskToCatalog] - \index[dir]{DiskToCatalog} - This level causes Bacula to read the files as they currently are on disk, -and -to compare the current file attributes with the attributes saved in the -catalog from the last backup for the job specified on the {\bf VerifyJob} -directive. This level differs from the {\bf Catalog} level described above by -the fact that it doesn't compare against a previous Verify job but against a -previous backup. When you run this level, you must supply the verify options -on your Include statements. Those options determine what attribute fields are -compared. - -This command can be very useful if you have disk problems because it will -compare the current state of your disk against the last successful backup, -which may be several jobs. - -Note, the current implementation (1.32c) does not identify files that have -been deleted. -\end{description} - -\item [Verify Job = \lt{}Job-Resource-Name\gt{}] - \index[dir]{Verify Job } - If you run a verify job without this directive, the last job run will be -compared with the catalog, which means that you must immediately follow a -backup by a verify command. If you specify a {\bf Verify Job} Bacula will -find the last job with that name that ran. This permits you to run all your -backups, then run Verify jobs on those that you wish to be verified (most -often a {\bf VolumeToCatalog}) so that the tape just written is re-read. - -\item [JobDefs = \lt{}JobDefs-Resource-Name\gt{}] - \index[dir]{JobDefs } - If a JobDefs-Resource-Name is specified, all the values contained in the -named JobDefs resource will be used as the defaults for the current Job. Any -value that you explicitly define in the current Job resource, will override -any defaults specified in the JobDefs resource. The use of this directive -permits writing much more compact Job resources where the bulk of the -directives are defined in one or more JobDefs. This is particularly useful if -you have many similar Jobs but with minor variations such as different -Clients. A simple example of the use of JobDefs is provided in the default -bacula-dir.conf file. - -\item [Bootstrap = \lt{}bootstrap-file\gt{}] - \index[dir]{Bootstrap } - The Bootstrap directive specifies a bootstrap file that, if provided, will -be used during {\bf Restore} Jobs and is ignored in other Job types. The {\bf -bootstrap} file contains the list of tapes to be used in a restore Job as -well as which files are to be restored. Specification of this directive is -optional, and if specified, it is used only for a restore job. In addition, -when running a Restore job from the console, this value can be changed. - -If you use the {\bf Restore} command in the Console program, to start a -restore job, the {\bf bootstrap} file will be created automatically from the -files you select to be restored. - -For additional details of the {\bf bootstrap} file, please see -\ilink{Restoring Files with the Bootstrap File}{_ChapterStart43} -chapter of this manual. - -\label{writebootstrap} -\item [Write Bootstrap = \lt{}bootstrap-file-specification\gt{}] - \index[dir]{a name} - The {\bf writebootstrap} directive specifies a file name where Bacula will -write a {\bf bootstrap} file for each Backup job run. Thus this directive -applies only to Backup Jobs. If the Backup job is a Full save, Bacula will -erase any current contents of the specified file before writing the bootstrap -records. If the Job is an Incremental save, Bacula will append the current -bootstrap record to the end of the file. - -Using this feature, permits you to constantly have a bootstrap file that can -recover the current state of your system. Normally, the file specified should -be a mounted drive on another machine, so that if your hard disk is lost, -you will immediately have a bootstrap record available. Alternatively, you -should copy the bootstrap file to another machine after it is updated. - -If the {\bf bootstrap-file-specification} begins with a vertical bar (|), -Bacula will use the specification as the name of a program to which it will -pipe the bootstrap record. It could for example be a shell script that emails -you the bootstrap record. - -For more details on using this file, please see the chapter entitled -\ilink{The Bootstrap File}{_ChapterStart43} of this manual. - -\item [Client = \lt{}client-resource-name\gt{}] - \index[dir]{Client } - The Client directive specifies the Client (File daemon) that will be used in - the current Job. Only a single Client may be specified in any one Job. The - Client runs on the machine to be backed up, and sends the requested files to - the Storage daemon for backup, or receives them when restoring. For - additional details, see the - \ilink{Client Resource section}{ClientResource2} of this chapter. - This directive is required. - -\item [FileSet = \lt{}FileSet-resource-name\gt{}] - \index[dir]{FileSet } - The FileSet directive specifies the FileSet that will be used in the -current - Job. The FileSet specifies which directories (or files) are to be backed up, - and what options to use (e.g. compression, ...). Only a single FileSet - resource may be specified in any one Job. For additional details, see the - \ilink{FileSet Resource section}{FileSetResource} of this - chapter. This directive is required. - -\item [Messages = \lt{}messages-resource-name\gt{}] - \index[dir]{Messages } - The Messages directive defines what Messages resource should be used for -this - job, and thus how and where the various messages are to be delivered. For - example, you can direct some messages to a log file, and others can be sent - by email. For additional details, see the - \ilink{Messages Resource}{_ChapterStart15} Chapter of this - manual. This directive is required. - -\item [Pool = \lt{}pool-resource-name\gt{}] - \index[dir]{Pool } - The Pool directive defines the pool of Volumes where your data can be backed - up. Many Bacula installations will use only the {\bf Default} pool. However, - if you want to specify a different set of Volumes for different Clients or - different Jobs, you will probably want to use Pools. For additional details, - see the - \ilink{Pool Resource section}{PoolResource} of this chapter. This - directive is required. - -\item [Full Backup Pool = \lt{}pool-resource-name\gt{}] - \index[dir]{Full Backup Pool } - The {\it Full Backup Pool} specifies a Pool to be used for Full backups. It - will override any Pool specification during a Full backup. This directive is - optional. - -\item [Differential Backup Pool = \lt{}pool-resource-name\gt{}] - \index[dir]{Differential Backup Pool } - The {\it Differential Backup Pool} specifies a Pool to be used for - Differential backups. It will override any Pool specification during a - Differential backup. This directive is optional. - -\item [Incremental Backup Pool = \lt{}pool-resource-name\gt{}] - \index[dir]{Incremental Backup Pool } - The {\it Incremental Backup Pool} specifies a Pool to be used for -Incremental - backups. It will override any Pool specification during an Incremental -backup. - This directive is optional. - -\item [Schedule = \lt{}schedule-name\gt{}] - \index[dir]{Schedule } - The Schedule directive defines what schedule is to be used for the Job. - The schedule in turn determines when the Job will be automatically - started and what Job level (i.e. Full, Incremental, ...) is to be run. - This directive is optional, and if left out, the Job can only be started - manually using the Console program. Although you may specify only a - single Schedule resource for any one job, the Schedule resource may - contain multiple {\bf Run} directives, which allow you to run the Job at - many different times, and each {\bf run} directive permits overriding - the default Job Level Pool, Storage, and Messages resources. This gives - considerable flexibility in what can be done with a single Job. For - additional details, see the \ilink{Schedule Resource - Chapter}{ScheduleResource} of this manual. - - -\item [Storage = \lt{}storage-resource-name\gt{}] - \index[dir]{Storage } - The Storage directive defines the name of the storage services where you -want - to backup the FileSet data. For additional details, see the - \ilink{Storage Resource Chapter}{StorageResource2} of this manual. - This directive is required. - -\item [Max Start Delay = \lt{}time\gt{}] - \index[dir]{Max Start Delay } - The time specifies the maximum delay between the scheduled time and the - actual start time for the Job. For example, a job can be scheduled to - run at 1:00am, but because other jobs are running, it may wait to run. - If the delay is set to 3600 (one hour) and the job has not begun to run - by 2:00am, the job will be canceled. This can be useful, for example, - to prevent jobs from running during day time hours. The default is 0 - which indicates no limit. - -\item [Max Run Time = \lt{}time\gt{}] - \index[dir]{Max Run Time } - The time specifies the maximum allowed time that a job may run, counted - from when the job starts, ({\bf not} necessarily the same as when the - job was scheduled). This directive is implemented in version 1.33 and - later. - -\item [Max Wait Time = \lt{}time\gt{}] - \index[dir]{Max Wait Time } - The time specifies the maximum allowed time that a job may block waiting - for a resource (such as waiting for a tape to be mounted, or waiting for - the storage or file daemons to perform their duties), counted from the - when the job starts, ({\bf not} necessarily the same as when the job was - scheduled). This directive is implemented only in version 1.33 and - later. - - - -\item [Incremental Max Wait Time = \lt{}time\gt{}] - \index[dir]{Incremental Max Wait Time } - The time specifies the maximum allowed time that an Incremental backup - job may block waiting for a resource (such as waiting for a tape to be - mounted, or waiting for the storage or file daemons to perform their - duties), counted from the when the job starts, ({\bf not} necessarily - the same as when the job was scheduled). Please note that if there is a - {\bf Max Wait Time} it may also be applied to the job. - -\item [Differential Max Wait Time = \lt{}time\gt{}] - \index[dir]{Differential Max Wait Time } - The time specifies the maximum allowed time that a Differential backup - job may block waiting for a resource (such as waiting for a tape to be - mounted, or waiting for the storage or file daemons to perform their - duties), counted from the when the job starts, ({\bf not} necessarily - the same as when the job was scheduled). Please note that if there is a - {\bf Max Wait Time} it may also be applied to the job. - -\item [Prefer Mounted Volumes = \lt{}yes|no\gt{}] - \index[dir]{Prefer Mounted Volumes} - It the Prefer Mounted Volumes directive is set to {\bf yes} - (default yes), it is used to inform the Storage daemon - to select either an Autochanger or a drive with a valid - Volume already mounted in preference to a drive that is - not ready. If none is available, it will select the first - available drive. If the directive is set to {\bf no}, the - Storage daemon will prefer finding an unused drive. This - can potentially be useful for those sites that prefer to - maximum backup throughput at the expense of using additional - drives and Volumes. - - -\item [Prune Jobs = \lt{}yes|no\gt{}] - \index[dir]{Prune Jobs } - Normally, pruning of Jobs from the Catalog is specified on a Client by - Client basis in the Client resource with the {\bf AutoPrune} directive. - If this directive is specified (not normally) and the value is {\bf - yes}, it will override the value specified in the Client resource. The - default is {\bf no}. - - -\item [Prune Files = \lt{}yes|no\gt{}] - \index[dir]{Prune Files } - Normally, pruning of Files from the Catalog is specified on a Client by - Client basis in the Client resource with the {\bf AutoPrune} directive. - If this directive is specified (not normally) and the value is {\bf - yes}, it will override the value specified in the Client resource. The - default is {\bf no}. - -\item [Prune Volumes = \lt{}yes|no\gt{}] - \index[dir]{Prune Volumes } - Normally, pruning of Volumes from the Catalog is specified on a Client - by Client basis in the Client resource with the {\bf AutoPrune} - directive. If this directive is specified (not normally) and the value - is {\bf yes}, it will override the value specified in the Client - resource. The default is {\bf no}. - -\item [Run Before Job = \lt{}command\gt{}] - \index[dir]{Run Before Job } - The specified {\bf command} is run as an external program prior to - running the current Job. Any output sent by the command to standard output - will be included in the Bacula job report. The command string must be a - valid program name or name of a shell script. This directive is not - required, but if it is defined, and if the exit code of the program run - is non-zero, the current Bacula job will be canceled. In addition, the - command string is parsed then fed to the execvp() function, which means - that the path will be searched to execute your specified command, but - there is no shell interpretation, as a consequence, if you invoke - complicated commands or want any shell features such as redirection or - piping, you must call a shell script and do it inside that script. - - Before submitting the specified command to the operating system, Bacula - performs character substitution of the following characters: - -\footnotesize -\begin{verbatim} - %% = % - %c = Client's name - %d = Director's name - %i = JobId - %e = Job Exit Status - %j = Unique Job name - %l = Job Level - %n = Job name - %t = Job type - %v = Volume name - -\end{verbatim} -\normalsize - -The Job Exit Status code \%e edits the following values: - -\index[dir]{Exit Status} -\begin{itemize} -\item OK -\item Error -\item Fatal Error -\item Canceled -\item Differences -\item Unknown term code -\end{itemize} - - Thus if you edit it on a command line, you will need to enclose - it within some sort of quotes. - - Bacula checks the exit status of the RunBeforeJob program. If it is - non-zero, the job will be error terminated. Lutz Kittler has pointed - out that using the RunBeforJob directive can be a simple way to modify - your schedules during a holiday. For example, suppose that you normally - do Full backups on Fridays, but Thursday and Friday are holidays. To - avoid having to change tapes between Thursday and Friday when no one is - in the office, you can create a RunBeforeJob that returns a non-zero - status on Thursday and zero on all other days. That way, the Thursday - job will not run, and on Friday the tape you inserted on Wednesday - before leaving will be used. - -\item [Run After Job = \lt{}command\gt{}] - \index[dir]{Run After Job } - The specified {\bf command} is run as an external program after the - current job terminates. This directive is not required. The command - string must be a valid program name or name of a shell script. If the - exit code of the program run is non-zero, the current Bacula job will - terminate in error. Before submitting the specified command to the - operating system, Bacula performs character substitution as described - above for the {\bf Run Before Job} directive. - - An example of the use of this directive is given in the - \ilink{Tips Chapter}{JobNotification} of this manual. As of version - 1.30, Bacula checks the exit status of the RunAfter program. If it is - non-zero, the job will be terminated in error. - -\item [Client Run Before Job = \lt{}command\gt{}] - \index[dir]{Client Run Before Job } - This directive is the same as {\bf Run Before Job} except that the program is run on - the client machine. The same restrictions apply to Unix systems as noted - above for the {\bf Run Before Job}. In addition, for a Windows client on - version 1.33 and above, please take careful note that you must ensure a - correct path to your script. The script or program can be a .com, .exe or - a .bat file. However, if you specify a path, you must also specify the full - extension. Unix like commands will not work unless you have installed and - properly configured Cygwin in addition to and separately from Bacula. - - {\bf Special Windows Considerations} - The command can be anything that cmd.exe or command.com will recognize as an - executable file. Specifying the executable's extension is optional, unless - there is an ambiguity. (i.e. ls.bat, ls.exe) - - The System \%Path\% will be searched for the command. (under the environment - variable dialog you have have both System Environment and User Environment, - we believe that only the System environment will be available to bacula-fd, - if it is running as a service.) - - System environment variables can be referenced with \%var\% and - used as either part of the command name or arguments. - - When specifying a full path to an executable if the path or executable name - contains whitespace or special characters they will need to be quoted. - Arguments containing whitespace or special characters will also have to be - quoted. - -\footnotesize -\begin{verbatim} -ClientRunBeforeJob = "\"C:/Program Files/Software - Vendor/Executable\" /arg1 /arg2 \"foo bar\"" -\end{verbatim} -\normalsize - - The special characters \&()[]\{\}\^{}=;!'+,`\~{} will need to be quoted if - they are part of a filename or argument. - - If someone is logged in, a blank "command" window running the commands -will - be present during the execution of the command. - - Some Suggestions from Phil Stracchino for running on Win32 machines with the - native Win32 File daemon: - - \begin{enumerate} - \item You might want the ClientRunBeforeJob directive to specify a .bat file - which runs the actual client-side commands, rather than trying to run -(for - example) regedit /e directly. - \item The batch file should explicitly 'exit 0' on successful completion. - \item The path to the batch file should be specified in Unix form: - - ClientRunBeforeJob = "c:/bacula/bin/systemstate.bat" - - rather than DOS/Windows form: - - ClientRunBeforeJob = - -"c:\textbackslash{}bacula\textbackslash{}bin\textbackslash{}systemstate.bat" - INCORRECT - \end{enumerate} - -The following example of the use of the Client Run Before Job directive was -submitted by a user:\\ -You could write a shell script to back up a DB2 database to a FIFO. The shell -script is: - -\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 - -The following line in the Job resource in the bacula-dir.conf file: -\footnotesize -\begin{verbatim} - Client Run Before Job = "su - mercuryd -c \"/u01/mercuryd/backupdb.sh '%t' -'%l'\"" -\end{verbatim} -\normalsize - When the job is run, you will get messages from the output of the script -stating - that the backup has started. Even though the command being run is - backgrounded with \&, the job will block until the "db2 BACKUP DATABASE" -command, - thus the backup stalls. - - To remedy this situation, the "db2 BACKUP DATABASE" line should be changed to -the following: - -\footnotesize -\begin{verbatim} - db2 BACKUP DATABASE mercuryd TO $DIR/dbpipe WITHOUT PROMPTING > $DIR/backup.log -2>&1 < /dev/null & -\end{verbatim} -\normalsize - -It is important to redirect the input and outputs of a backgrounded command to -/dev/null to prevent the script from blocking. - - -\item [Client Run After Job = \lt{}command\gt{}] - \index[dir]{Client Run After Job } - This directive is the same as {\bf Run After Job} except that it is run on -the - client machine. Note, please see the notes above in {\bf Client Run Before - Job} concerning Windows clients. - -\item [Rerun Failed Levels = \lt{}yes|no\gt{}] - \index[dir]{Rerun Failed Levels } - If this directive is set to {\bf yes} (default no), and Bacula detects that -a - previous job at a higher level (i.e. Full or Differential) has failed, the - current job level will be upgraded to the higher level. This is particularly - useful for Laptops where they may often be unreachable, and if a prior Full - save has failed, you wish the very next backup to be a Full save rather -than - whatever level it is started as. - -\item [Spool Data = \lt{}yes|no\gt{}] - \index[dir]{Spool Data } - If this directive is set to {\bf yes} (default no), the Storage daemon will -be requested to spool the data for this Job to disk rather than write it -directly to tape. Once all the data arrives or the spool files' maximum sizes -are reached, the data will be despooled and written to tape. When this -directive is set to yes, the Spool Attributes is also automatically set to -yes. Spooling data prevents tape shoe-shine (start and stop) during -Incremental saves. This option should not be used if you are writing to a -disk file. - -\item [Spool Attributes = \lt{}yes|no\gt{}] - \index[dir]{Spool Attributes } - The default is set to {\bf no}, which means that the File attributes are -sent -by the Storage daemon to the Director as they are stored on tape. However, -if you want to avoid the possibility that database updates will slow down -writing to the tape, you may want to set the value to {\bf yes}, in which -case the Storage daemon will buffer the File attributes and Storage -coordinates to a temporary file in the Working Directory, then when writing -the Job data to the tape is completed, the attributes and storage coordinates -will be sent to the Director. - -\item [Where = \lt{}directory\gt{}] - \index[dir]{Where } - This directive applies only to a Restore job and specifies a prefix to the -directory name of all files being restored. This permits files to be restored -in a different location from which they were saved. If {\bf Where} is not -specified or is set to backslash ({\bf /}), the files will be restored to -their original location. By default, we have set {\bf Where} in the example -configuration files to be {\bf /tmp/bacula-restores}. This is to prevent -accidental overwriting of your files. - -\item [Replace = \lt{}replace-option\gt{}] - \index[dir]{Replace } - This directive applies only to a Restore job and specifies what happens when -Bacula wants to restore a file or directory that already exists. You have the - following options for {\bf replace-option}: - -\begin{description} - -\item [always] - \index[dir]{always} - when the file to be restored already exists, it is deleted and then replaced -by - the copy that was backed up. - -\item [ifnewer] - \index[dir]{ifnewer} - if the backed up file (on tape) is newer than the existing file, the existing - file is deleted and replaced by the back up. - -\item [ifolder] - \index[dir]{ifolder} - if the backed up file (on tape) is older than the existing file, the existing - file is deleted and replaced by the back up. - -\item [never] - \index[dir]{never} - if the backed up file already exists, Bacula skips restoring this file. -\end{description} - -\item [Prefix Links=\lt{}yes|no\gt{}] - \index[dir]{Prefix Links} - If a {\bf Where} path prefix is specified for a recovery job, apply it - to absolute links as well. The default is {\bf No}. When set to {\bf - Yes} then while restoring files to an alternate directory, any absolute - soft links will also be modified to point to the new alternate - directory. Normally this is what is desired -- i.e. everything is self - consistent. However, if you wish to later move the files to their - original locations, all files linked with absolute names will be broken. - -\item [Maximum Concurrent Jobs = \lt{}number\gt{}] - \index[dir]{Maximum Concurrent Jobs } - where \lt{}number\gt{} is the maximum number of Jobs from the current - Job resource that can run concurrently. Note, this directive limits - only Jobs with the same name as the resource in which it appears. Any - other restrictions on the maximum concurrent jobs such as in the - Director, Client, or Storage resources will also apply in addition to - the limit specified here. The default is set to 1, but you may set it - to a larger number. We strongly recommend that you read the WARNING - documented under \ilink{ Maximum Concurrent Jobs}{DirMaxConJobs} in the - Director's resource. - -\item [Reschedule On Error = \lt{}yes|no\gt{}] - \index[dir]{Reschedule On Error } - If this directive is enabled, and the job terminates in error, the job - will be rescheduled as determined by the {\bf Reschedule Interval} and - {\bf Reschedule Times} directives. If you cancel the job, it will not - be rescheduled. The default is {\bf no} (i.e. the job will not be - rescheduled). - - - This specification can be useful for portables, laptops, or other - machines that are not always connected to the network or switched on. - -\item [Reschedule Interval = \lt{}time-specification\gt{}] - \index[dir]{Reschedule Interval } - If you have specified {\bf Reschedule On Error = yes} and the job - terminates in error, it will be rescheduled after the interval of time - specified by {\bf time-specification}. See \ilink{the time - specification formats}{Time} in the Configure chapter for details of - time specifications. If no interval is specified, the job will not be - rescheduled on error. - -\item [Reschedule Times = \lt{}count\gt{}] - \index[dir]{Reschedule Times } - This directive specifies the maximum number of times to reschedule the - job. If it is set to zero (the default) the job will be rescheduled an - indefinite number of times. - -\item [Run = \lt{}job-name\gt{}] - \index[dir]{Run directive} - \index[dir]{Clone a Job} - The Run directive (not to be confused with the Run option in a - Schedule) allows you to start other jobs or to clone jobs. By using the - cloning keywords (see below), you can backup - the same data (or almost the same data) to two or more drives - at the same time. The {\bf job-name} is normally the same name - as the current Job resource (thus creating a clone). However, it - may be any Job name, so one job may start other related jobs. - - The part after the equal sign must be enclosed in double quotes, - and can contain any string or set of options (overrides) that you - can specify when entering the Run command from the console. For - example {\bf storage=DDS-4 ...}. In addition, there are two special - keywords that permit you to clone the current job. They are {\bf level=\%l} - and {\bf since=\%s}. The \%l in the level keyword permits - entering the actual level of the current job and the \%s in the since - keyword permits putting the same time for comparison as used on the - current job. Note, in the case of the since keyword, the \%s must be - enclosed in double quotes, and thus they must be preceded by a backslash - since they are already inside quotes. For example: - -\begin{verbatim} - run = "Nightly-backup level=%s since=\"%s\" storage=DDS-4" -\end{verbatim} - - - A cloned job will not start additional clones, so it is not - possible to recurse. - - - -\label{Priority} -\item [Priority = \lt{}number\gt{}] - \index[dir]{Priority } - This directive permits you to control the order in which your jobs run - by specifying a positive non-zero number. The higher the number, the - lower the job priority. Assuming you are not running concurrent jobs, - all queued jobs of priority 1 will run before queued jobs of priority 2 - and so on, regardless of the original scheduling order. - - The priority only affects waiting jobs that are queued to run, not jobs - that are already running. If one or more jobs of priority 2 are already - running, and a new job is scheduled with priority 1, the currently - running priority 2 jobs must complete before the priority 1 job is run. - - The default priority is 10. - - If you want to run concurrent jobs, which is not recommended, you should -keep - these points in mind: - -\begin{itemize} -\item To run concurrent jobs, you must set Maximum Concurrent Jobs = 2 in 5 - or 6 distinct places: in bacula-dir.conf in the Director, the Job, the - Client, the Storage resources; in bacula-fd in the FileDaemon (or Client) - resource, and in bacula-sd.conf in the Storage resource. If any one is - missing, it will throttle the jobs to one at a time. -\item Bacula concurrently runs jobs of only one priority at a time. It will - not simultaneously run a priority 1 and a priority 2 job. -\item If Bacula is running a priority 2 job and a new priority 1 job is - scheduled, it will wait until the running priority 2 job terminates even if - the Maximum Concurrent Jobs settings would otherwise allow two jobs to run - simultaneously. -\item Suppose that bacula is running a priority 2 job and a new priority 1 job - is scheduled and queued waiting for the running priority 2 job to terminate. - If you then start a second priority 2 job, the waiting priority 1 job will - prevent the new priority 2 job from running concurrently with the running - priority 2 job. That is: as long as there is a higher priority job waiting - to - run, no new lower priority jobs will start even if the Maximum Concurrent - Jobs settings would normally allow them to run. This ensures that higher - priority jobs will be run as soon as possible. -\end{itemize} - -If you have several jobs of different priority, it may not best to start -them at exactly the same time, because Bacula must examine them one at a -time. If by Bacula starts a lower priority job first, then it will run -before your high priority jobs. If you experience this problem, you may -avoid it by starting any higher priority jobs a few seconds before lower -priority ones. This insures that Bacula will examine the jobs in the -correct order, and that your priority scheme will be respected. - -\label{WritePartAfterJob} -\item [Write Part After Job = \lt{}yes|no\gt{}] - \index[dir]{Write Part After Job } - This directive is only implemented in version 1.37 and later. - If this directive is set to {\bf yes} (default {\bf no}), a new part file - will be created after the job is finished. - - It should be set to {\bf yes} when writing to devices that require mount - (for example DVD), so you are sure that the current part, containing - this job's data, is written to the device, and that no data is left in - the temporary file on the hard disk. However, on some media, like DVD+R - and DVD-R, a lot of space (about 10Mb) is lost everytime a part is - written. So, if you run several jobs each after another, you could set - this directive to {\bf no} for all jobs, except the last one, to avoid - wasting too much space, but to ensure that the data is written to the - medium when all jobs are finished. - - It is ignored with tape and FIFO devices. -\end{description} - -The following is an example of a valid Job resource definition: - -\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*{The JobDefs Resource} -\label{JobDefsResource} -\index[general]{JobDefs Resource} -\index[general]{Resource!JobDefs} -\addcontentsline{toc}{subsection}{JobDefs Resource} - -The JobDefs resource permits all the same directives that can appear in a Job -resource. However, a JobDefs resource does not create a Job, rather it can be -referenced within a Job to provide defaults for that Job. This permits you to -concisely define several nearly identical Jobs, each one referencing a JobDefs -resource which contains the defaults. Only the changes from the defaults need to -be mentioned in each Job. - -\subsection*{The Schedule Resource} -\label{ScheduleResource} -\index[general]{Resource!Schedule} -\index[general]{Schedule Resource} -\addcontentsline{toc}{subsection}{Schedule Resource} - -The Schedule resource provides a means of automatically scheduling a Job as -well as the ability to override the default Level, Pool, Storage and Messages -resources. If a Schedule resource is not referenced in a Job, the Job can only -be run manually. In general, you specify an action to be taken and when. - -\begin{description} - -\item [Schedule] - \index[dir]{Schedule} - Start of the Schedule directives. No {\bf Schedule} resource is required, -but -you will need at least one if you want Jobs to be automatically started. - -\item [Name = \lt{}name\gt{}] - \index[dir]{Name } - The name of the schedule being defined. The Name directive is required. - -\item [Run = \lt{}Job-overrides\gt{} \lt{}Date-time-specification\gt{}] - \index[dir]{Run } - The Run directive defines when a Job is to be run, and what overrides if any -to apply. You may specify multiple {\bf run} directives within a {\bf -Schedule} resource. If you do, they will all be applied (i.e. multiple -schedules). If you have two {\bf Run} directives that start at the same time, -two Jobs will start at the same time (well, within one second of each -other). - -The {\bf Job-overrides} permit overriding the Level, the Storage, the -Messages, and the Pool specifications provided in the Job resource. In -addition, the FullPool, the IncrementalPool, and the DifferentialPool -specifications permit overriding the Pool specification according to what -backup Job Level is in effect. - -By the use of overrides, you may customize a particular Job. For example, you -may specify a Messages override for your Incremental backups that outputs -messages to a log file, but for your weekly or monthly Full backups, you may -send the output by email by using a different Messages override. - -{\bf Job-overrides} are specified as: {\bf keyword=value} where the keyword -is Level, Storage, Messages, Pool, FullPool, DifferentialPool, or -IncrementalPool, and the {\bf value} is as defined on the respective -directive formats for the Job resource. You may specify multiple {\bf -Job-overrides} on one {\bf Run} directive by separating them with one or more -spaces or by separating them with a trailing comma. For example: - -\begin{description} - -\item [Level=Full] - \index[dir]{Level} - is all files in the FileSet whether or not they have changed. - -\item [Level=Incremental] - \index[dir]{Level} - is all files that have changed since the last backup. - -\item [Pool=Weekly] - \index[dir]{Pool} - specifies to use the Pool named {\bf Weekly}. - -\item [Storage=DLT\_Drive] - \index[dir]{Storage} - specifies to use {\bf DLT\_Drive} for the storage device. - -\item [Messages=Verbose] - \index[dir]{Messages} - specifies to use the {\bf Verbose} message resource for the Job. - -\item [FullPool=Full] - \index[dir]{FullPool} - specifies to use the Pool named {\bf Full} if the job is a full backup, or -is -upgraded from another type to a full backup. - -\item [DifferentialPool=Differential] - \index[dir]{DifferentialPool} - specifies to use the Pool named {\bf Differential} if the job is a -differential backup. - -\item [IncrementalPool=Incremental] - \index[dir]{IncrementalPool} - specifies to use the Pool named {\bf Incremental} if the job is an -incremental backup. - -\item [SpoolData=yes|no] - \index[dir]{SpoolData} - tells Bacula to request the Storage daemon to spool data to a disk file -before putting it on tape. - -\item [WritePartAfterJob=yes|no] - \index[dir]{WritePartAfterJob} - tells Bacula to request the Storage daemon to write the current part file to - the device when the job is finished (see - \ilink{Write Part After Job directive in the Job - resource}{WritePartAfterJob}). Please note, this directive is implemented - only in version 1.37 and later. - -\end{description} - -{\bf Date-time-specification} determines when the Job is to be run. The -specification is a repetition, and as a default Bacula is set to run a job at -the beginning of the hour of every hour of every day of every week of every -month of every year. This is not normally what you want, so you must specify -or limit when you want the job to run. Any specification given is assumed to -be repetitive in nature and will serve to override or limit the default -repetition. This is done by specifying masks or times for the hour, day of the -month, day of the week, week of the month, week of the year, and month when -you want the job to run. By specifying one or more of the above, you can -define a schedule to repeat at almost any frequency you want. - -Basically, you must supply a {\bf month}, {\bf day}, {\bf hour}, and {\bf -minute} the Job is to be run. Of these four items to be specified, {\bf day} -is special in that you may either specify a day of the month such as 1, 2, -... 31, or you may specify a day of the week such as Monday, Tuesday, ... -Sunday. Finally, you may also specify a week qualifier to restrict the -schedule to the first, second, third, fourth, or fifth week of the month. - -For example, if you specify only a day of the week, such as {\bf Tuesday} the -Job will be run every hour of every Tuesday of every Month. That is the {\bf -month} and {\bf hour} remain set to the defaults of every month and all -hours. - -Note, by default with no other specification, your job will run at the -beginning of every hour. If you wish your job to run more than once in any -given hour, you will need to specify multiple {\bf run} specifications each -with a different minute. - -The date/time to run the Job can be specified in the following way in -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 -