'Release-1.38.9'.
\clearpage
\include{generaldevel}
+\include{platformsupport}
\include{daemonprotocol}
\include{director}
\include{file}
Contributions from programmers are broken into two groups. The first are
contributions that are aids and not essential to Bacula. In general, these
will be scripts or will go into and examples or contributions directory.
+For these kinds of non-essential contributions there is no obligation to do
+a copyright assignment as described below. However, a copyright assignment
+would still be appreciated.
The second class of contributions are those which will be integrated with
Bacula and become an essential part. Within this class of contributions, there
Subject to the copyright assignment described below, your patches should be
sent in {\bf diff -u} format relative to the current contents of the Source
-Forge CVS, which is the easiest for me to understand. If you have checked
-out the source with CVS, you can get a diff using:
+Forge CVS, which is the easiest to understand and integrate.
+If you have checked out the source with CVS, you can get a diff using:
\begin{verbatim}
-cvs diff -u \lt{}change.patch
+cvs diff -u > change.patch
\end{verbatim}
-If you plan on doing
-significant development work over a period of time, after having your first
-patch reviewed and approved, you will be eligible for having developer CVS access so
-that you can commit your changes directly to the CVS repository. To do so, you
-will need a userid on Source Forge.
+If you plan on doing significant development work over a period of time,
+after having your first patch reviewed and approved, you will be eligible
+for having developer CVS access so that you can commit your changes
+directly to the CVS repository. To do so, you will need a userid on Source
+Forge.
\subsubsection*{Copyrights}
\index{Copyrights}
\addcontentsline{toc}{subsubsection}{Copyrights}
-To avoid future problems concerning changing licensing or copyrights, all code
-contributions more than a hand full of lines must be in the Public Domain or
-have the copyright assigned to Kern Sibbald as in the current code. Note,
-prior to November 2004, the code was copyrighted by Kern Sibbald and John
-Walker.
-
-Your name should be clearly indicated as the author of the code, and you must
-be extremely careful not to violate any copyrights or use other people's code
-without acknowledging it. The purpose of this requirement is to avoid future
-copyright, patent, or intellectual property problems. To understand on
-possible source of future problems, please examine the difficulties Mozilla is
-(was?) having finding previous contributors at
-\elink{
-http://www.mozilla.org/MPL/missing.html}
+To avoid future problems concerning changing licensing or copyrights, all
+code contributions more than a hand full of lines must be in the Public
+Domain or have the copyright assigned to Kern Sibbald as in the current
+code. Note, prior to November 2004, the code was copyrighted by Kern
+Sibbald and John Walker.
+
+Your name should be clearly indicated as the author of the code, and you
+must be extremely careful not to violate any copyrights or use other
+people's code without acknowledging it. The purpose of this requirement is
+to avoid future copyright, patent, or intellectual property problems. To
+understand on possible source of future problems, please examine the
+difficulties Mozilla is (was?) having finding previous contributors at
+\elink{ http://www.mozilla.org/MPL/missing.html}
{http://www.mozilla.org/MPL/missing.html}. The other important issue is to
avoid copyright, patent, or intellectual property violations as are currently
(May 2003) being claimed by SCO against IBM.
Although the copyright will be held by Kern, each developer is expected to
-indicate that he wrote and/or modified a particular module (or file) and any
-other sources. The copyright assignment may seem a bit unusual, but in
-reality, it is not. Most large projects require this. In fact, the paperwork
-associated with making contributions to the Free Software Foundation, was for
-me unsurmountable.
-
-If you have any doubts about this, please don't hesitate to ask. Our (John and
-my) track records with Autodesk are easily available; early
-programmers/founders/contributors and later employees had substantial shares
-of the company, and no one founder had a controlling part of the company. Even
-though Microsoft created many millionaires among early employees, the politics
-of Autodesk (during our time at the helm) is in stark contrast to Microsoft
-where the majority of the company is still tightly held among a few.
+indicate that he wrote and/or modified a particular module (or file) and
+any other sources. The copyright assignment may seem a bit unusual, but in
+reality, it is not. Most large projects require this. In fact, the
+paperwork associated with making contributions to the Free Software
+Foundation, was for me unsurmountable, so hopefully the rather
+simplified procedure we have will not create any difficulties for
+you.
+
+If you have any doubts about this, please don't hesitate to ask. The
+objective is to assure the long term servival of the Bacula project. There
+is no consideration of personal gain in this request. Our (John and my)
+track records with Autodesk are easily available; early
+programmers/founders/contributors and later employees had substantial
+shares of the company, and no one founder had a controlling part of the
+company. Even though Microsoft created many millionaires among early
+employees, the politics of Autodesk (during our time at the helm) is in
+stark contrast to Microsoft where the majority of the company is still
+tightly held among a few.
Items not needing a copyright assignment are: most small changes,
enhancements, or bug fixes of 5-10 lines of code, and documentation.
Since this is not a commercial enterprise, and I prefer to believe in
everyone's good faith, developers can assign the copyright by explicitly
-acknowledging that they do so in their first submission. This is sufficient if
-the developer is independent, or an employee of a not-for-profit organization
-or a university. Any developer that wants to contribute and is employed by a
-company must get a copyright assignment from his employer. This is to avoid
-misunderstandings between the employee, the company, and the Bacula project.
+acknowledging that they do so in their first submission. This is
+sufficient if the developer is independent, or an employee of a
+not-for-profit organization or a university. Any developer who wants to
+contribute and is employed by a company must get a copyright assignment
+from his employer. This is to avoid misunderstandings between the
+employee, the company, and the Bacula project. A good number of
+companies have already followed this procedure.
\subsubsection*{Corporate Assignment Statement}
\index{Statement!Corporate Assignment}
Kern Sibbald
Address-to-be-given
+If you wish to retain the full rights to use the software you
+have contributed in different projects, this is not a problem. Just
+request a perpetual non-exclusive license before sending in your
+copyright assignment.
+
\subsection*{Basic CVS Usage}
\index{Basic CVS Usage}
\index{CVS}
To get the source for a project, you must check it out ("checkout"), which
you do usually once.
+\subsubsection*{Public CVS Access}
+\index{Public CVS Access}
+\addcontentsline{toc}{subsubsection}{Public CVS Access}
+
The first time you checkout the code for each project, you will need to
-tell the cvs program where the CVS repository is. You do so by doing:
+tell the cvs program where the CVS repository is. The procedure for
+checking out code from the public CVS is:
+
+\begin{verbatim}
+cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/bacula login
+\end{verbatim}
+Then when it prompts for the password for {\bf anonymous}, simply
+press the Enter key. The above command is necessary only once
+the very first time you login. Then enter the following command:
+
+\begin{verbatim}
+cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/bacula co -P bacula
+\end{verbatim}
+
+The above will place the contents of the bacula module in a directory
+named {\bf bacula} in the current directory. This data will come
+from the public CVS, which typically runs 6 hours to a day behind the
+developer's CVS. Once you have created a copy of the CVS, you can use
+the commands listed below under the title CVS Usage.
+
+\subsubsection*{Developer CVS Access}
+\index{Developer CVS Access}
+\addcontentsline{toc}{subsubsection}{Developer CVS Access}
+
+If you are registered as a Bacula developer (contact Kern about this),
+you may access the developer's CVS using:
\begin{verbatim}
export CVS_RSH=ssh
where you replace \lt{}nnnn\gt{} by your Source Forge user name.
-Then do
+Then do:
\begin{verbatim}
cvs -z3 checkout -d <directory> bacula
to contain the Bacula source code. If you want the docs, replace the
word "bacula" on the above line by "docs" and be sure to put it in
a different directory. The -z3 just tells CVS to use compression during
-the transmission, which makes things go faster.
+the transmission, which makes things go faster. There is no need to
+do the anonymous login as is the case for non-developers.
The above command should generate output that looks a bit like the
following:
...
\end{verbatim}
+\subsubsection*{CVS Usage}
+\index{CVS Usage}
+\addcontentsline{toc}{subsubsection}{CVS Usage}
+
+The commands that follow with the exception of the {\bf commit}
+work the same whether you are accessing the public CVS or
+the developer's CVS.
Let's assume you used the name "bacula" for the directory, so your
command was:
number of new features will also be much the same providing that the
contributions continue to come -- and they show no signs of let up :-)
+\index{Feature Requests}
{\bf Feature Requests:} \\
In addition, I would like to "formalize" the feature requests a bit.
-img2.png\ 1./smartall.eps
img1.png\ 1./bacula-logo.eps
+img2.png\ 1./smartall.eps
--- /dev/null
+%%
+%%
+
+\section*{Platform Support}
+\label{_PlatformChapter}
+\index{Support!Platform}
+\index{Platform Support}
+\addcontentsline{toc}{section}{Platform Support}
+
+\subsection*{General}
+\index{General }
+\addcontentsline{toc}{subsection}{General}
+
+This chapter describes the requirements for having a
+supported platform (Operating System). In general, Bacula is
+quite portable. It supports 32 and 64 bit architectures as well
+as bigendian and littleendian machines. For full
+support, the platform (Operating System) must implement POSIX Unix
+system calls. However, for File daemon support only, a small
+compatibility library can be written to support almost any
+architecture.
+
+Currently Linux, FreeBSD, and Solaris are fully supported
+platforms, which means that the code has been tested on those
+machines and passes a full set of regression tests.
+
+In addition, the Windows File daemon is supported on most versions
+of Windows, and finally, there are a number of other platforms
+where the File daemon (client) is known to run: NetBSD, OpenBSD,
+Mac OSX, SGI, ...
+
+\subsection*{Requirements to become a Supported Platform}
+\index{Requirements!Platform}
+\index{Platform Requirements}
+\addcontentsline{toc}{subsection}{Platform Requirements}
+
+As mentioned above, in order to become a fully supported platform, it
+must support POSIX Unix system calls. In addition, the following
+requirements must be met:
+
+\begin{itemize}
+\item The principal developer (currently Kern) must have
+ non-root ssh access to a test machine running the platform.
+\item The ideal requirements and minimum requirements
+ for this machine are given below.
+\item There must be a defined platform champion who is normally
+ a system administrator for the machine that is available. This
+ person need not be a developer/programmer but must be familiar
+ with system administration of the platform.
+\item There must be at least one person designated who will
+ run regression tests prior to each release. Releases occur
+ approximately once every 6 months, but can be more frequent.
+ It takes at most a day's effort to setup the regression scripts
+ in the beginning, and after that, they can either be run daily
+ or on demand before a release. Running the regression scripts
+ involves only one or two command line commands and is fully
+ automated.
+\item Ideally there are one or more persons who will package
+ each Bacula release.
+\item Ideally there are one or more developers who can respond to
+ and fix platform specific bugs.
+\end{itemize}
+
+Ideal requirements for a test machine:
+\begin{itemize}
+\item The principal developer will have non-root ssh access to
+ the test machine at all times.
+\item The pricipal developer will have a root password.
+\item The test machine will provide approximately 200 MB of
+ disk space for continual use.
+\item The test machine will have approximately 500 MB of free
+ disk space for temporary use.
+\item The test machine will run the most common version of the OS.
+\item The test machine will have an autochanger of DDS-4 technology
+ or later having two or more tapes.
+\item The test machine will have MySQL and/or PostgreSQL database
+ access for account "bacula" available.
+\item The test machine will have sftp access.
+\item The test machine will provide an smtp server.
+\end{itemize}
+
+Minimum requirements for a test machine:
+\begin{itemize}
+\item The principal developer will have non-root ssh access to
+ the test machine when requested approximately once a month.
+\item The pricipal developer not have root access.
+\item The test machine will provide approximately 80 MB of
+ disk space for continual use.
+\item The test machine will have approximately 300 MB of free
+ disk space for temporary use.
+\item The test machine will run the the OS.
+\item The test machine will have a tape drive of DDS-4 technology
+ or later that can be scheduled for access.
+\item The test machine will not have MySQL and/or PostgreSQL database
+ access.
+\item The test machine will have no sftp access.
+\item The test machine will provide no email access.
+\end{itemize}
+
+Bare bones test machine requirements:
+\begin{itemize}
+\item The test machine is available only to a designated
+ test person (your own machine).
+\item The designated test person runs the regession
+ tests on demand.
+\item The test machine has a tape drive available.
+\end{itemize}
\begin{itemize}
\item {\bf Bacula} has been compiled and run on Linux RedHat, FreeBSD, and
Solaris systems.
-\item In addition, clients exist on Win32 (Cygwin), and Irix
+\item In addition, clients exist on Win32, and Irix
\item It requires GNU C++ to compile. You can try with other compilers, but
you are on your own. The Irix client is built with the Irix complier, but, in
general, you will need GNU.
distribution.
\item There are certain third party packages that Bacula needs. Except for
MySQL, they can all be found in the {\bf depkgs} and {\bf depkgs1} releases.
-\item If you want to build the Win32 binaries, you will need the full Cygwin
- 1.5.5 release. Although all components build (console has some warnings),
- only the File daemon has been tested. Please note that if you attempt to
-build Bacula on any other version of Cygwin, particularly previous versions,
-you will be on your own.
+\item To build the Win32 binaries, we use Microsoft VC++ standard
+ 2003. Please see the instructions in
+ bacula-source/src/win32/README.win32 for more details. If you
+ want to use VC++ Express, please see README.vc8. Our build is
+ done under the most recent version of Cygwin, but Cygwin is
+ not used in the Bacula binaries that are produced.
+ Unfortunately, we do not have the resources to help you build
+ your own version of the Win32 FD, so you are pretty much on
+ your own. You can ask the bacula-devel list for help, but
+ please don't expect much.
\item {\bf Bacula} requires a good implementation of pthreads to work.
\item The source code has been written with portability in mind and is mostly
POSIX compatible. Thus porting to any POSIX compatible operating system
-1.39.5 (20 February 2006)
+1.38.9 (02 May 2006)
-Kern;;;2006/01/06;;;12:30
-Bacula is now able to accept direct donations, and as of
-15 January 2006, we have received the following:
-
-Amounts received:
- Date Amount: Donor:
- 06 Oct 05 $ 50 Ludovic Strappazon
- 28 Oct 05 $100 Pontis Corporation, Pavlo Tabashov
- 30 Oct 05 $ 20 Jan Kesten
- 31 Oct 05 $100 Anonymous
- 02 Nov 05 $442 Graphical Data Capture Ltd
- 29 Nov 05 $ 65 Jim Barlow
- 07 Jan 06 $ 1.95 Bonus from PayPal (I don't know why)
-
-Payments made:
- Amount: To/for:
- 06 Jan 06 $100 OSDN (Source Forge) for hosting Bacula
-===
-
-Balance:
-Total $646.84 After payments and PayPal fees are deducted
-
-Many thanks to the above Bacula supporters.
+Kern;;;2006/04/04;;;12:30
+Bacula is now able to accept direct donations.
+Please follow the Make a Donation link for more
+information.
+Many thanks to the many Bacula supporters who
+have made donations.
;;;
-Kern;;;2005/12/06;;;16:30
-Results to date of donations to EFF for the Data Encryption project
-7 December 2005
- Donor: Amount:
- WingNET Internet $500
- Timo Neuvonen $250
- Ed Grether $25
- Charles Reinehr $100
- Michael Proto $25
- Phil Cordier $100
- Dan Langille $100
- Tom Plancon $65
- Felix Schwarz $60
- ClarkConnect $500
- Andrew Ford $25
- INetU, Inc $1000
- Jo at Winfix.it $70
- Goal: $3000 Total: $2,820
-
-Additional information is available from Landon at:
-
- http://landonf.bikemonkey.org/code/bacula
-
-The data encryption project is progressing nicely. Landon has now
-integrated his code into the main CVS development branch.
-
-;;;
</ul>
</div>
- <!-- Support -->
- <div class="menuHead"> Support </div>
- <div class="menuItem">
- <ul class="menuitem">
- <li class="menuItem"> <a href="<? echo $spath ?>/?page=support"> Getting Support </a> </li>
- <li class="menuItem"> <a href="<? echo $spath ?>/?page=maillists"> Email Lists </a> </li>
- <li class="menuItem"> <a href="<? echo $spath ?>/?page=bugs"> Bug Reports </a> </li>
- <li class="menuItem"> <a href="<? echo $spath ?>/?page=professional"> Professional </a></li>
- <li class="menuItem"> <a href="<? echo $spath ?>/?page=feature-request"> Feature Requests </a></li>
- </ul>
- </div>
-
<!-- Documentation -->
<!-- files need a version -->
<div class="menuHead"> Documentation </div>
</ul>
</div>
- <!-- Donations -->
- <div class="menuHead"> Donations </div>
+ <!-- Downloads -->
+ <div class="menuHead"> Downloads </div>
<div class="menuItem">
<ul class="menuitem">
- <li class="menuItem"> <a href="<? echo $spath ?>/?page=makedonation"> Make a Donation </a> </li>
- <li class="menuItem"> <a href="<? echo $spath ?>/?page=donations"> Donations Received </a> </li>
+ <li class="menuItem"> <a href="http://sourceforge.net/project/showfiles.php?group_id=50727"> Current Files </a> </li>
+ <li class="menuItem"> <a href="http://sourceforge.net/project/showfiles.php?group_id=50727#files"> All Files </a> </li>
+ <li class="menuItem"> <a href="http://sourceforge.net/cvs/?group_id=50727"> CVS Repository </a> </li>
</ul>
</div>
+ <!-- Support -->
+ <div class="menuHead"> Support </div>
+ <div class="menuItem">
+ <ul class="menuitem">
+ <li class="menuItem"> <a href="<? echo $spath ?>/?page=support"> Getting Support </a> </li>
+ <li class="menuItem"> <a href="<? echo $spath ?>/?page=maillists"> Email Lists </a> </li>
+ <li class="menuItem"> <a href="<? echo $spath ?>/?page=bugs"> Bug Reports </a> </li>
+ <li class="menuItem"> <a href="<? echo $spath ?>/?page=professional"> Professional </a></li>
+ <li class="menuItem"> <a href="<? echo $spath ?>/?page=feature-request"> Feature Requests </a></li>
+ </ul>
+ </div>
<!-- Projects -->
<div class="menuHead"> Projects </div>
</ul>
</div>
- <!-- Downloads -->
- <div class="menuHead"> Downloads </div>
+ <!-- Donations -->
+ <div class="menuHead"> Donations </div>
<div class="menuItem">
<ul class="menuitem">
- <li class="menuItem"> <a href="http://sourceforge.net/project/showfiles.php?group_id=50727"> Current Files </a> </li>
- <li class="menuItem"> <a href="http://sourceforge.net/project/showfiles.php?group_id=50727#files"> All Files </a> </li>
- <li class="menuItem"> <a href="http://sourceforge.net/cvs/?group_id=50727"> CVS Repository </a> </li>
+ <li class="menuItem"> <a href="<? echo $spath ?>/?page=makedonation"> Make a Donation </a> </li>
+ <!--
+ - <li class="menuItem"> <a href="<? echo $spath ?>/?page=donations"> Donations Received </a> </li>
+ -->
</ul>
</div>
+
<div class="menuHead">
<div class="icons">
<a href="http://www.sectoor.de"><img src="http://www.sectoor.de/grafiken/button_klein2.png" alt="Sectoor Logo"></a>
<!-- a href="http://validator.w3.org/check?uri=referer"><img src="images/valid-xhtml10.png" alt="valix w3c logo"></a -->
<!-- a href="http://jigsaw.w3.org/css-validator/validator?uri=<? echo $_SERVER['HTTP_REFERER']; ?>"><img src="images/vcss.png" alt="valid css logo"></a-->
</div>
+
+
</div>
</div>
-Kern;;;2006/01/16;;;14:30
-The Bacula Version 1.38.3 tar file is released to Source Forge.
+Kern;;;2006/04/16;;;14:30
+ Release Notes for Bacula 1.38.8
- Release Notes for Bacula 1.38.3
-
- Bacula code: Total files = 424 Total lines = 140,955 (*.h *.c *.in)
+ Bacula code: Total files = 419 Total lines = 137,078 (*.h *.c *.in)
20,440 additional lines of code since version 1.36.3
-Changes to 1.38.3:
+!!!! Important !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+ In Bacula version 1.38.5 and prior, there was apparently a
+ compiler bug that caused the Storage daemon to seg fault.
+ I have applied a workaround in version 1.38.6 and greater that
+ seems to work. If you experience problems, follow the instructions
+ below.
+
+ If you are compiling for a 64 bit machine, you need to ensure
+ that the code is compiled with the -O0 (- oh zero) option otherwise
+ the SD will crash on most all operations -- apparently due to
+ a compiler bug in gcc's 64 bit code generation.
+!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+
+Warning:
+- The Windows FD no longer automatically folds the case
+ in wild-card comparions. To get the same behavior as before,
+ you must explicitly use "Ignore Case = yes" in your FileSet.
+- Backslashes are no longer permitted in File directives
+ (typical error for Windows users), unless the string is
+ enclosed in double quotes, in which case, the backslashes
+ must be doubled.
+- The new algorithm for selecting Volumes from the Scratch
+ pool that was implemented in 1.38.6 and 1.38.7 is abandoned
+ in favor of a corrected version of the 1.38.5 algorithm.
+
+New features for 1.38.8:
+- Regex, RegexFile, and RegexDir are now implemented in the
+ Win32 FD. However, this is new experimental code that is
+ largely untested. It may not work, it may cause memory
+ leaks, or it may even crash the FD. Please test carefully
+ before using. Unfortunately, at this time, the Ignore Case
+ directive is not implemented in the Windows regex, so
+ you must explictly take into account the case in your
+ patterns.
+- On Linux/Unix systems there are two new programs, bregex
+ and bwild that allow you to test regular expressions and
+ wild-cards. These programs are installed with the other
+ binaries. They are not available on Win32 systems.
+
+Fixes:
+- See below.
+
+New Features from pre-1.38.8 releases:
+- For autochanger get Scratch tape if in autochanger if
+ no appendable Volumes are available.
+- New virtual disk autochanger. See scripts/disk-changer for
+ documentation.
+- New optional Device resource directive in SD. 'Device Type =',
+ which may have types: File, DVD, Tape, or FIFO. This can
+ be useful for writing DVDs on FreeBSD where Bacula cannot
+ correctly detect the DVD.
+- Faster restore tree building and uses less memory.
+- The command line keyword job (or jobname) now refers to the
+ name of the job specified in the Job resource; jobid refers
+ as before to the non-unique numeric jobid; and ujobid refers
+ to the unique job identification that Bacula creates for each
+ job.
+- The job report for Backups has a few more user friendly ways
+ of displaying the information.
+- The wait command can now be made to wait for jobids.
+- New command line keywords are permitted in update volume. They
+ are Inchanger=yes/no, slot=nn.
+- Add two new console commands: enable job=<job-name> and
+ disable job=<job-name>. When a job is disabled, it will not
+ be started by the scheduler. If you disable a job and restart
+ Bacula or reload the .conf file, the job will be re-enabled.
+- Add a new Job resource directive "enable = yes|no".
+- There is a new program named regex in the tools directory that
+ allows you to try regular expressions on your system.
+
+Major bug fixes:
+- Fix race condition in multiple-drive autochangers where
+ both drives want the same Volume.
+- Do not allow opening default catalog for restricted console
+ if it is not in ACL.
+- Writable FIFOs now work for restore.
+- ACLs are now checked in all dot commands.
+- Multiple drive autochangers and multiple different autochangers
+ should now work correctly (no race conditions for Volume names,
+ update slots use correct StorageId).
+- Fix bug where drive was always reserved if a restore job failed
+ while in the reservation process.
+
+
+Minor bug fixes:
+- See below:
+
+Release 1.38.8 (14Apr06)
+14Apr06
+- Correct Makefile for Solaris /bin/sh
+- Correct mtx-changer.in for Solaris /bin/sh
+- Abort if a conf resource does not have a Name =
+12Apr06
+- Change the name of the regex program to bregex.
+- Add the bwild program to the tools directory. It is similar
+ to the bregex program.
+- Implement create bregex.h and bregex.c in src/lib from the
+ Python regexp program.
+- Use the new bregex.c to implement Regex expressions on Win32.
+11Apr06
+- Modify Makefile to change the permissions on Working Directory
+ to 770 if the directory is created.
+- Do not fail the Makefile if changing the permissions or
+ owner/group on WorkingDir fails.
+- Correct the old recycling algorithm so that Scratch Volumes
+ are selected when looking for a Volume in the changer.
+- Correct a typo in the Verify SQL reported by Joe Park.
+10Apr06
+- Remove automatic case folding on Windows FDs. You must
+ explictly use the 'Ignore Case = yes' option.
+- Remove the code added to 1.38.6 and 1.38.7 that pulls a
+ scratch volume in an Autochanger early in the 'recycling'
+ algorithm.
+08Apr06
+- Tweak license to include Microsoft restrictions.
+- Move mysql.reconnect to after real_connect(). Thanks to
+ Frank Sweetser for the patch.
+- Disallow a backslash in a File = directive (Windows junk)
+ unless the string is quoted.
+- Apply Eric's patch to ua_label.c so that daemon protocol
+ is not translated.
+
+Release 1.38.7 (06Apr06) released 07Apr06
+06Apr06
+- Remove timed wait for VSS on Win2K3 as it is not yet
+ implemented.
+- Correct bacula.in script to reference bacula-ctl-xx in the
+ sysconfig directory rather than the bin directory.
+
+Release 1.38.6 (28Mar06) released 29Mar06
+28Mar06
+- Back port from 1.39 fixes to lib/jcr.c to use foreach_jcr()
+ and new jcr chain locking.
+26Mar06
+- Fix a long standing bug in the bacula start/stop scripts.
+- Attempt to add the new bacula-ctl-* files to the rpm.
+- Switch to using typeof() for list traversing to avoid
+ as many FC5 g++ compiler warnings as possible.
+25Mar06
+- Split the bacula start/start script into four files:
+ bacula -- starts and stops calling other scripts
+ bacula-ctl-dir -- starts/stops the director
+ bacula-ctl-fd -- starts/stops the File daemon
+ bacula-ctl-sd -- starts/stops the Storage daemon
+- Create datestyle fix for PostgreSQL. Fixes bug #574.
+- Correct editing of JobId from int to int64 in fd_cmds.c
+- Eliminate FileSet name race with bash_spaces() and multiple
+ threads by bashing in a local.
+- Fix error return from 'use storage' to print a correct error
+ message rather than nothing.
+- Correct false re-read last block error message when two jobs
+ are simultaneously writing at the end of a tape.
+- Simplify exit conditions in the reserve.c code to avoid
+ possible non-release of reservation_lock().
+- Suffle lock order in reserve to avoid deadlock between
+ reservation lock and device mutex.
+- Add Thorsten's VSS timeout code to 1.38 branch.
+- Initialize jcr mutex before first use. Thanks to Thorsten for
+ tracking this down for me !!!! as it broke the Win32 build.
+- Integrate addition of line count limitation to bsmtp -l from
+ Sebastian Stark <stark at tuebingen.mpg.de>
+- Implement regex test program in tools directory.
+- Attempt to fix time problem with bsmtp with foreign langs.
+- Add strip_trailing_newline() submitted by user.
+
+Release 1.38.6 beta6 16Mar06
+- Fix bug #537 to allow arbitrary time to mount a volume for
+ restore, if polling is turned on.
+- Disallow multiple storage specifications for a job. Should fix Arno's
+ problem.
+- Add back a missing store of poolid in jr.poolid.
+- If dir_user or dir-group is specified in ./configure apply it to
+ the working-dir. Fixes bug #533.
+- If rescheduling a job cancel the previous incarnation with the SD.
+ Fixes bugs #566 and 557.
+- Fix bug #567 do_message() definition type conflict.
+
+Release 1.38.6 beta5 14Mar06
+- Add more jcr methods and make mutex and use_count private.
+- Create lock/unlock methods for jcr.
+- Fix PostgreSQL bug doing sql_data_seeek() by explicitly reading
+ records to get to seek position.
+- Integrate patch from bug #561 to correct conio.c signal definitions.
+- Fix Rescheduling failed Jobs. Ensure that SD message thread
+ terminates correctly by doing pthread_kill(). Do not destroy
+ SD cond wait variable between executions of the job. Use local
+ mutex for cond variable to avoid blocking jcr chain. Fix poor
+ use of jcr use count in jobq.c for restarted jobs.
+- Fix obsolete usage of foreach_dlist() to use foreach_jcr() in
+ lib/jcr.c -- prevents locking the jcr chaing.
+- Apply patch from bug #564, which corrects listing volumes with
+ multiple autochangers. Apply same fix to next volume list.
+- Fix bug #562 where restore bootstrap file is not unique.
+- Use new routine lock_reservations() to lock the reservations
+ system, and call it while looking for a volume in askdir.c.
+ This could possibly fix bug #543.
+- Stop SD command loop if job is canceled.
+
+Release 1.38.6 beta3 4Mar06
+04Mar06
+- The po files should now be current.
+- Fix new sql_use_result() code to properly release the
+ buffers in all cases.
+- Convert to using new Python class definitons with (object).
+- Use the keyword ujobid to mean the unique job id; job or jobname
+ to mean the Job name given on the Name directive, and jobid to
+ be the numeric (non-unique) job id.
+- Allow listing by any of the above.
+- Add the user friendly job report code for reporting job elapsed time
+ and rates with suffexes.
+- Add Priority and JobLevel as Python settable items.
+- Use TEMPORARY table creation where the table is created by
+ Bacula.
+- Add new code submitted by Eric for waiting on specific jobid.
+- Add ACL checking for the dot commands.
+- Fix restore of writable FIFOs.
+- Fix a bug in bpipe where the string was freed too early.
+
+26Feb06
+- Fix bug reported by Arno listing blocks with bls
+- Update the po files at Eric's request.
+
+Release 1.38.6-beta2 25Feb06
+25Feb06
+- Add sql_use_result() define.
+
+Changes to 1.38.6-beta1
+- Don't open default catalog if not in ACL.
+- Add virtual disk autochanger code.
+- Add user supplied bug fix to make two autochangers work
+ correctly using StorageId with InChanger checks.
+- Correct new/old_jcr confusion in copy_storage().
+- Remove & from Job during scan in msgchan.c -- probably
+ trashed the stack.
+- When getting the next Volume if no Volume in Append mode
+ exists and we are dealing with an Autochanger, search
+ for a Scratch Volume.
+- Check for missing value in dot commands -- bug fix.
+- Fix bug in update barcodes command line scanning.
+- Make sure Pool Max Vols is respected.
+- Check that user supplied a value before referencing
+ it in restore -- pointed out by Karl Hakimian.
+- Add Karl Hakimian's table insert code.
+- Don't ask user to select a specific Volume when
+ updating all volumes in a Pool.
+- Remove reservation if set for read when removing dcr.
+- Lock code that requests next appendable volume so that
+ two jobs to get the same Volume at the same time.
+- Add new Device Type = xxx code. Values are file, tape,
+ dvd, and fifo.
+- Preserve certain modes (ST_LABEL|ST_APPEND|ST_READ) across
+ a re-open to change read/write permission on a device.
+- Correct a misplaced double quote in certain autochanger
+ scripts.
+- Make make_catalog_backup.in a bit more portable.
+- Implement Karl Hakimian's sql_use_result(), which speeds
+ up restore tree building and reduces the memory load.
+- Correct a number of minor bugs in getting a Volume from
+ the Scratch Pool.
+- Implement additional command line options for update Volume.
+- Don't require user to enter a Volume name when updating
+ all Volumes in a pool.
+
+Release 1.38.5 released 19Jan06:
+- Apply label barcodes fix supplied by Rudolf Cejka.
+- Modify standard rpm installation to set SD group to disk
+ so that SD will by default have access to tape drives.
+- Allow users to specify user/group and start options
+ for each daemon in /etc/sysconf/bacula file.
+
+Changes to 1.38.4 released 17Jan06:
+- The main changes are to the Director and the Storage daemon,
+ thus there is no need to update your File daemons. Just the
+ same, I do recommend running with the release 1.38.3 Win32
+ FD or later.
+- Add two new queries to query.sql provided by Arno. One
+ list volumes known to the Storage device, and the other
+ lists volumes possibly needing replacement (error, ...).
+- Add periodic (every 24 hours) garbage collection of memory
+ pool by releasing free buffers.
+- Correct bug counting sized (for display only) in smartall.c
+- Print FD mempool stats if debug > 0 rather than 5.
+- Correct bug in alist.c that re-allocated the list if the
+ number of items goes to zero.
+- Move the reservation system thread locking to the top level
+ so that one job at a time tries all possible drives before
+ waiting.
+- Implement a reservation 'fail' message queue that is built
+ and destroyed on each pass through the reservation system.
+ These messages are displayed in a 'Jobs waiting to reserve
+ a drive' list during a 'status storage='. Note, multiple
+ messages will generally print for each JobId because they
+ represent the different problems with either the same drive
+ or different drives. If this output proves too confusing
+ of voluminous, I will display it only when debug level 1
+ or greater is enabled in the SD.
+- Add enable/disable job=<job-name>. This command prevents
+ the specified job from being scheduled. Even when disabled,
+ the job can be manually started from the console.
+- During 'update slots' clear all InChanger flags where the
+ StorageId is zero (old Media records).
+- Fix autochanger code to strip leading spaces from returned
+ slots number. Remove bc from chio-changer.
+- Back port a bit of 1.39 crypto code to reduce diffs.
+- Fix first call to autochanger that missed close()ing the
+ drive. Put close() just before each run_program(). Fixes
+ Arno's changer bug.
+- Add PoolId to Job record when updating it at job start time.
+- Pull in more code from 1.39 so that there are fewer file
+ differences (the new ua_dotcmds.c, base64.h, crypto.h
+ hmac.c jcr.c (dird and lib) lib.h md5.h parse_conf.c
+ util.c. Aside from ua_dotcmds.c these are mostly crypto
+ upgrades.
+- Implement new method of walking the jcr chain. The
+ incr/dec of the use_count is done within the walking
+ routines. This should prevent a jcr from being freed
+ from under the walk routines.
+
+
+Changes to 1.38.3 released 05Jan06:
- This is mainly a bug release fix. In addition, the multiple drive
reservation algorithm has been rewritten.
- In addition, the method of handling waiting for tapes to be
- Simplify code in askdir.c that waits for creating an appendable
volume so that it can handle multiple returns from the wait code.
- Modify the wait code to permit multiple returns.
-- Return a zero when "autochanger drives" is called and
+- Return a zero when 'autochanger drives' is called and
it is not an autochanger.
- Make rewind_dev() a method taking a DCR as an argument.
This permits closing and reopening the drive if the
at the same time.
- Apply days keyword patch from Alexander.Bergolth at wu-wien.ac.at
If this patch is applied, the number of days can be specified with
- "list nextvol days=xx"
+ 'list nextvol days=xx'
or
- "status dir days=xx"
+ 'status dir days=xx'
My use case is to be able to preview the next scheduled job (and the
next tape to be used) on fridays if there are no scheduled jobs during
the weekend.
- Volume Shadow Copy support for Win32 thus the capability to
backup exclusively opened files (thanks to Thorsten Engel).
A VSS enabled Win32 FD is available. You must explicitly
- turn on VSS with "Enable VSS = yes" in your FileSet resource.
+ turn on VSS with 'Enable VSS = yes' in your FileSet resource.
- New manual format with an index (thanks to Karl Cunningham).
- New Web site format (thanks to Michael Scherer).
- SQLite3 support.
in native languages. Thanks to Nicolas Boichat.
New Directives:
-- New Job directive "Prefer Mounted Volumes = yes|no" causes the
+- New Job directive 'Prefer Mounted Volumes = yes|no' causes the
SD to select either an Autochanger or a drive with a valid
Volume already mounted in preference. If none is available,
it will select the first available drive.
- New Run directive in Job resource of DIR. It permits
cloning of jobs. To clone a copy of the current job, use
- Run = "job-name level=%l since=\"%s\""
+ Run = 'job-name level=%l since=\'%s\''
Note, job-name is normally the same name as the job that
is running but there is no restriction on what you put. If you
want to start the job by hand and use job overrides such as
of the manual.
New Commands:
-- "python restart" restarts the Python interpreter. Rather brutal, make
+- 'python restart' restarts the Python interpreter. Rather brutal, make
sure no Python scripts are running. This permits you to change
a Python script and get Bacula to use the new script.
- The Storage daemon now keeps track of what tapes it is using
(was not the case in 1.36.x). This means that you must be much
more careful when removing tapes and putting up a new one. In
- general, you should always do a "unmount" prior to removing a
- tape, and a "mount" after putting a new one into the drive.
+ general, you should always do a 'unmount' prior to removing a
+ tape, and a 'mount' after putting a new one into the drive.
- If you use an Autochanger, you MUST update your SD conf file
to use the new Autochanger resource. Otherwise, certain commands
- such as "update slots" may not work.
+ such as 'update slots' may not work.
- You must add --with-python=[DIR] to the configure command line
if you want Python support. Python 2.2, 2.3 and 2.4 should be
automatically detected if in the standard place.
compiling.
-Other Items:
+Other Items Fixed:
- Security fixes for temp files created in mtx-changer, during
./configure, and during making of Rescue disk.
- A new script, dvd-handler, in the scripts directory,
<bacula-source>/patches/dvd+rw-tools-5.21.4.10.8.bacula.patch
You must have Python installed to run the scripts.
- Part files support: File volumes can now be split into multiple
- files, called "parts".
+ files, called 'parts'.
- For the details of the Python scripting support, please see the new
Python Scripting chapter in the manual.
- The default user/group for the Director and Storage daemon installed
<tr>
<td class="content">
-<b>Bacula</b> has four email lists which are described below with
+<b>Bacula</b> has a number of email lists which are described below with
links to subscribe, unsubscribe, or modify your account.
For general information on these lists, please see
<a href="http://sourceforge.net/mail/?group_id=50727">Bacula Mailing Lists at SourceForge</a>.
<a href="http://lists.sourceforge.net/lists/listinfo/bacula-bugs">
http://lists.sourceforge.net/lists/listinfo/bacula-bugs</a>.
+<h3>bacula-beta</h3>
+The <b>bacula-beta</b> list is a read only
+list for those packagers or users who wish to be notified
+when a new release is in preparation or is ready.
+Please do not send email to this list.
+
+To subscribe, follow follow the instructions at:
+<a href="http://lists.sourceforge.net/lists/listinfo/bacula-beta">
+http://lists.sourceforge.net/lists/listinfo/bacula-beta</a>.
+
+
<h3>bacula-commits</h3>
The <b>bacula-commits</b> list is a read only
list for those users who wish to be receive a diff of each
</tr>
<tr>
<td class="content">
- Although one talks about Free Software, in fact, software such
+ Although one talks about Free Software, in fact, Open Software such
as Bacula was not developed without some cost. The software
may be free for the user, but it wasn't free for the developer
or developers, either in terms of time or in terms of financial
desire to have them reimbursed.
Bacula is now a fairly mature product, and to ensure its long
- term survival, I believe it should start to pay its own way.
+ term survival, I believe it is time that Bacula begins to
+ stand on its own, both financially and for the development.
<p>
- There are multiple ways of contributing to the Bacula
+ There are ways you can contribute to the Bacula
project, some of which are: ideas, user support,
documentation review, translation, programming and
contributing code, testing the new releases, hosting
services, testing machines, donating needed equipment, and
financial support.
- Previously all but the last one were possible.
+ Previously all but the last one (financial support) were possible.
It is now possible for you to contribute financial aid
the Bacula project. All funds collected will be used to help
further the Bacula project by covering out of pocket expenses
portion of travel/conference expenses.
<p>
- The project actually has the following needs (approximate costs): <br>
- Three Microsoft Visual C++ licenses: $3000<br>
- Autochanger for FreeBSD testing: $3200<br>
- Autochanger for Solaris testing: $3200<br>
-
- If you have licenses or equipment to donate, please don't
- hesitate to let me (Kern) know. You may also provide financial
- support for these items.
-
-
- <p>
- Contributions may not be US tax deductible as this is a individual
- Bacula project account with PayPal.
+ Contributions may not be US tax deductible as Bacula is
+ based in Switzerland.
<p>
If you are a government or for-profit corporation and cannot
make "donations", please consider paying a (non-obligatory)
binary license fee for any Bacula built binaries that you download.
- By providing you with these pre-built, pre-tested binaries, we are
- really providing you with an extra service, which merits you
+ By making these pre-built, pre-tested binaries available, we are
+ providing users who download them with an extra service, which merits
careful consideration for making a contribution or paying a
"license fee".
- A reasonable license fee would be:
- <p>
- <table>
- <tr> <td>Number of Machines</td> <td>Fee</td></tr>
- <tr> <td>1-10</td> <td>$10 per machine</td></tr>
- <tr> <td>11-20</td> <td>$100 + $5.00 per machine over 10</td></tr>
- <tr> <td>21-50</td> <td>$150 + $2.00 per machine over 20</td></tr>
- <tr> <td>51-...</td> <td>$250 + $1.00 per machine over 50</td></tr>
- </table>
- <p>Example: 55 machines = $250 + 5 X $1.00 = $255<br>
- <p>Upgrades are 10% of the original license fee.
- <p>
- The above table is just a suggestion. You are, of course, free
- to make a larger or smaller contribution as you see fit.
-
- If you wish your payment to be anonymous, please put the word
- ANONYMOUS in the "Payment For:" field on the PayPal
- payment form.
-
<p>
To make a contribution, please click on the donate button at
the top of the screen, and your transaction will be secured
you want to contribute, and the project you are supporting (or simply
Bacula development).
-
-<p>
-To see the donations made to date, please click on the
-Donations Received menu item to the left of your screen.
<p>
</tr>
<td><img src="images/spacer.gif" width="50px" height="1px"></td>
<td>
<a href="mailto:danNOSPAM@langille.org">Dan Langille</a><br>
- 46D Whelan Drive <br>
- Nepean, ON, K2J 3K7<br>
+ Suite 474<br>
+ 900 Greenbank Road<br>
+ Ottawa, ON K2J 4P6<br>
+1 613 863 9741<br>
<br>
- <a href="http://www.langille.org">http://www.langille.org</a>
+ <a href="http://www.langille.org/">http://www.langille.org/</a>
</td>
</tr>
<tr> <td colspan="3"><img src="images/spacer.gif" width="50px" height="25px"></td> </tr>
<a href="mailto:matsNOSPAM@kdb.se">Mats Vilhelmsson</a><br>
Tel: +46 708 901042<br>
<br>
- Backup hosting - internet backups, Bacula traings, installations and support.<br>
+ Backup hosting - Internet backups, Bacula training, installations and support.<br>
<br>
<a href="http://www.kdb.se">http://www.kdb.se</a><br>
</td>
<a href="http://www.matrix-computer.com">http://www.matrix-computer.com</a><br>
</td>
</tr>
+
+ <tr> <td colspan="3"><img src="images/spacer.gif" width="50px" height="25px"></td> </tr>
+ <tr> <td colspan="3"><hr></td>
+ <tr> <td colspan="3"><img src="images/spacer.gif" width="50px" height="25px"></td> </tr>
+ <tr>
+ <td style="font-weight: bold">
+ NETWAYS GmbH
+ </td>
+ <td><img src="images/spacer.gif" width="50px" height="1px"></td>
+ <td>
+ <a href="mailto:infoNOSPAM@netways.de">NETWAYS GmbH</a><br>
+ Deutschherrnstrasse 47a<br>
+ 90429 Nürnberg<br>
+ Germany<br>
+ <br>
+ Telephone +49 911 92885-0<br>
+ Fax +49 911 92885-77<br>
+ <br>
+ <br>
+ We support our customers managing complex and
+ heterogeneous networks. Our services and
+ solutions, based on Open Source software, help
+ you run your servers and applications
+ failure-free. Special focus on Nagios, Bacula,
+ Request Tracker, and cluster solutions. <br> <a
+ href="http://www.netways.de">http://www.netways.de</a><br>
+ </td>
+ </tr>
+
+
<tr> <td colspan="3"><img src="images/spacer.gif" width="50px" height="25px"></td> </tr>
<tr> <td colspan="3"><hr></td>
<tr> <td colspan="3"><img src="images/spacer.gif" width="50px" height="25px"></td> </tr>
<? require_once("inc/header.php"); ?>
<table>
<tr>
- <td class="contentTopic">
- System Requirements
- </td>
+ <td class="contentTopic">
+ System Requirements
+ </td>
</tr>
<tr>
- <td class="content">
+ <td class="content">
- <ul class="hardware">
- <li><b>Bacula</b> has been compiled and run on Linux RedHat, FreeBSD,
- and Solaris systems.</li>
- <li>It requires GNU C++ version 2.95 or higher to compile. You can try
- with other compilers and older versions, but you are on your own.
- We have successfully compiled and used Bacula on RH8.0/RH9/RHEL 3.0
- with GCC 3.2. Note, in general GNU C++ is a separate package (e.g.
- RPM) from GNU C, so you need them both loaded. On RedHat systems,
- the C++ compiler is part of the <b>gcc-c++</b> rpm package. </li>
+ <ul class="hardware">
+ <li><b>Bacula</b> has been compiled and run on Linux RedHat, FreeBSD,
+ and Solaris systems.</li>
+ <li>It requires GNU C++ version 2.95 or higher to compile. You can try
+ with other compilers and older versions, but you are on your
+ own. We have successfully compiled and used Bacula on
+ RH8.0/RH9/RHEL 3.0 with GCC 3.2. Note, in general GNU C++ is a
+ separate package (e.g. RPM) from GNU C, so you need them both
+ loaded. On RedHat systems, the C++ compiler is part of the
+ <b>gcc-c++</b> rpm package. </li>
- <li>There are certain third party packages that Bacula needs.
- Except for MySQL and PostgreSQL, they can all be found in the
- <b>depkgs</b> and <b>depkgs1</b> releases.</li>
- <li>If you want to build the Win32 binaries, you will need a
- Microsoft Visual C++ compiler (or Visual Studio).
- Although all components build (console has
- some warnings), only the File daemon has been tested. </li>
- <li><b>Bacula</b> requires a good implementation of pthreads to work.
- This is not the case on some of the BSD systems.</li>
- <li>The source code has been written with portability in mind and is
- mostly POSIX compatible. Thus porting to any POSIX compatible
- operating system should be relatively easy.</li>
- <li>The GNOME Console program is developed and tested under GNOME 2.x. It
- also runs under GNOME 1.4 but this version is deprecated and
- thus no longer maintained.</li>
+ <li>There are certain third party packages that Bacula needs.
+ Except for MySQL and PostgreSQL, they can all be found in the
+ <b>depkgs</b> and <b>depkgs1</b> releases.</li>
+ <li>If you want to build the Win32 binaries, you will need a
+ Microsoft Visual C++ compiler (or Visual Studio).
+ Although all components build (console has
+ some warnings), only the File daemon has been tested. </li>
+ <li><b>Bacula</b> requires a good implementation of pthreads to work.
+ This is not the case on some of the BSD systems.</li>
+ <li>The source code has been written with portability in mind and is
+ mostly POSIX compatible. Thus porting to any POSIX compatible
+ operating system should be relatively easy.</li>
+ <li>The GNOME Console program is developed and tested under GNOME 2.x.
+ It also runs under GNOME 1.4 but this version is deprecated and
+ thus no longer maintained.</li>
- <li>The wxWidgets Console program is developed and tested with the latest
- stable version of <a href="http://www.wxwidgets.org/">wxWidgets</a> (2.4.2).
- It works fine with the Windows and GTK+-1.x version of wxWidgets, and should
- also works on other platforms supported by wxWidgets.</li>
- <li>The Tray Monitor program is developed for GTK+-2.x. It needs
- Gnome >=2.2, KDE >=3.1 or any window manager supporting the
- <a href="http://www.freedesktop.org/Standards/systemtray-spec">
- FreeDesktop system tray standard</a>.</li>
- <li>If you want to enable command line editing and history, you will
- need to have /usr/include/termcap.h and either the termcap or the
- ncurses library loaded (libtermcap-devel or ncurses-devel).</li>
- </ul>
+ <li>The wxWidgets Console program is developed and tested with the
+ latest stable version of <a
+ href="http://www.wxwidgets.org/">wxWidgets</a> (2.6). It
+ works fine with the Windows and GTK+-1.x version of wxWidgets,
+ and should also works on other platforms supported by
+ wxWidgets.</li>
+ <li>The Tray Monitor program is developed for GTK+-2.x. It needs
+ Gnome >=2.2, KDE >=3.1 or any window manager supporting the
+ <a href="http://www.freedesktop.org/Standards/systemtray-spec">
+ FreeDesktop system tray standard</a>.</li>
+ <li>If you want to enable command line editing and history, you will
+ need to have /usr/include/termcap.h and either the termcap or the
+ ncurses library loaded (libtermcap-devel or ncurses-devel).</li>
+ </ul>
- </td>
+ </td>
</tr>
</table>
<? require_once("inc/footer.php"); ?>
<ul>
<li>The kind of tape drive you have </li>
<li>Have you run the <b>btape</b> "test" command?</li>
+</ul>
+If you are having database problems, please include:
+<ul>
+ <li>The database you are using: MySQL, PostgreSQL, SQLite, SQLite3 </li>
+ <li>The version of the database you are using</li>
</ul>
+
The first two of these items can be fulfilled by sending
us a copy of your <b>config.out</b> file, which is in the
main <b>Bacula</b> source directory after you have done
%%
%%
-\section*{What is Bacula?}
+\section*{Was ist Bacula?}
\label{_ChapterStart41}
-\index[general]{Bacula!What is }
-\index[general]{What is Bacula? }
-\addcontentsline{toc}{section}{What is Bacula?}
-
-{\bf Bacula} is a set of computer programs that permits you (or the system
-administrator) to manage backup, recovery, and verification of computer data
-across a network of computers of different kinds. Bacula can also run entirely
-upon a single computer, and can backup to various types of media, including tape
-and disk.
-
-In technical terms, it is a
-network Client/Server based backup program. Bacula is relatively easy to use
-and efficient, while offering many advanced storage management features that
-make it easy to find and recover lost or damaged files. Due to its modular
-design, Bacula is scalable from small single computer systems to systems
-consisting of hundreds of computers located over a large network.
-
-\subsection*{Who Needs Bacula?}
-\index[general]{Who Needs Bacula? }
-\index[general]{Bacula!Who Needs }
-\addcontentsline{toc}{subsection}{Who Needs Bacula?}
-
-If you are currently using a program such as {\bf tar}, {\bf dump}, or {\bf
-bru} to backup your computer data, and you would like a network solution, more
-flexibility, or catalog services, Bacula will most likely provide the
-additional features you want. However, if you are new to Unix systems or do
-not have offsetting experience with a sophisticated backup package, we do not
-recommend using Bacula as it is much more difficult to setup and use than {\bf
-tar} or {\bf dump}.
-
-If you want Bacula to behave like the above mentioned simple
-programs and write over any tape that you put in the drive, then you will find
-working with Bacula difficult. Bacula is designed to protect your data
-following the rules you specify, and this means reusing a tape only
-as the last resort. It is possible to "force" Bacula to write
-over any tape in the drive, but it is easier and more efficient to use a
-simpler program for that kind of operation.
-
-If you are running {\bf Amanda} and would like a backup program that can write
-to multiple volumes (i.e. is not limited by your tape drive capacity), Bacula
-can most likely fill your needs. In addition, quite a number of our users
-report that Bacula is simpler to setup and use than other equivalent programs.
-
-If you are currently using a sophisticated commercial package such as Legato
-Networker. ARCserveIT, Arkeia, or PerfectBackup+, you may be interested in
-Bacula, which provides many of the same features, and is free software
-available under the GNU Version 2 software license.
-
-\subsection*{Bacula Components or Services}
-\index[general]{Bacula Components or Services }
-\index[general]{Services!Bacula Components or }
-\addcontentsline{toc}{subsection}{Bacula Components or Services}
-
-Bacula is made up of the following five major components or services:
+\index[general]{Bacula!Was ist }
+\index[general]{Was ist Bacula? }
+\addcontentsline{toc}{section}{Was ist Bacula?}
+
+
+{\bf Bacula} ist ein System von Computerprogrammen, mit denen Sie
+(oder der System-Administrator) in der Lage sind, Computerdaten innerhalb eines
+heterogenen Netzwerkes zu sichern, die Sicherungen wiederherzustellen und diese zu überprüfen. Bacula kann auch auf einem einzigen Computer laufen und auf verschiedene Arten von Medien wie Bänder oder CDs sichern.
+Technisch gesprochen ist es ein netzwerkfähiges
+Sicherungsprogramm mit Client/Server-Architektur.
+Bacula ist leistungsfähig und vergleichsweise einfach zu benutzen.
+Dabei hat es viele anspruchsvolle Funktionen zur Verwaltung der Sicherung,
+die das Auffinden und die Wiederherstellung beschädigter oder verlorener
+Dateien erleichtern. Durch seinen modularen Aufbau lässt es sich jedem System
+anpassen: Vom Einzelplatzrechner bis zu einem großen System mit hunderten von
+Computern, die über ein weiträumiges Netzwerk verteilt sind.
+\subsection*{Wer benötigt Bacula?}
+\index[general]{Wer benötigt Bacula? }
+\index[general]{Bacula!Wer benötigt }
+\addcontentsline{toc}{subsection}{Wer benötigt Bacula?}
+
+
+Wenn Sie momentan Programme wie {\bf tar}, {\bf dump}, oder {\bf
+bru} zur Datensicherung verwenden und eine Netzwerklösung, größere Flexibilität
+oder einen Verzeichnis-Dienst suchen, wird Bacula wahrscheinlich die
+zusätzlichen Funktionen zur Verfügung stellen, die Sie suchen. Wenn Sie dagegen
+ein UNIX-Neuling sind oder keine weitergehenden Erfahrung mit
+anspruchsvollen Sicherungsprogrammen haben, raten wir von Bacula ab, da es in
+der Einrichtung und der Benutzung sehr viel komplizierter ist als z.B.
+{\bf tar} oder {\bf dump}.
+
+Wenn Bacula wie die oben beschriebenen einfachen Programme funktionieren und
+nur ein Band in Ihrem Laufwerk beschreiben soll, wird Ihnen der Umgang
+mit Bacula kompliziert vorkommen. Bacula ist so entworfen, dass es Ihre
+Daten nach von Ihnen festgelegten Regeln sichert, was bedeutet, dass die
+Wiederverwendung eines Bandes nur die letzte Wahl sein kann. Natürlich ist es möglich, Bacula dazu zu bringen, jedes beliebige Band im Laufwerk zu beschreiben, jedoch ist es einfacher und wirkungsvoller hierfür ein anderes Programm zu
+verwenden.
+Wenn Sie {\bf Amanda} verwenden und ein Sicherungsprogramm suchen, das auf
+mehrere Volumes schreiben kann (also nicht durch die Speicherkapazität Ihres
+Bandlaufwerkes beschränkt ist) wird Bacula wahrscheinlich Ihren Bedürfnissen
+entsprechen. Viele unserer Benutzer finden außerdem, dass Bacula
+einfacher zu konfigurieren und zu benutzen ist als entsprechende andere Programme.
+
+Wenn Sie gegenwärtig ein anspruchsvolles kommerzielles Programm wie ``Legato'',
+``Networker'', ``ARCserveIT'', ``Arkeia'', oder ``PerfectBackup+'' verwenden,
+könnte Sie Bacula interessieren, da es viele Eigenschaften und Funktionen dieser Programme hat, dabei aber als freie Software unter der GNU Software Lizenz Version 2 verfügbar
+ist.
+
+\newpage
+
+\subsection*{Bacula Komponenten oder Dienste}
+\index[general]{Bacula Komponenten oder Dienste }
+\index[general]{Dienste!Bacula Komponenten oder }
+\addcontentsline{toc}{subsection}{Bacula Komponenten oder Dienste}
+
+
+Bacula besteht aus den folgenden fünf Hauptkomponenten bzw. Diensten:
\addcontentsline{lof}{figure}{Bacula Applications}
\includegraphics{./bacula-applications.eps}
-(thanks to Aristedes Maniatis for this graphic and the one below)
+(Dank an Aristedes Maniatis für diese und die folgende Grafik)
\begin{itemize}
\item
\label{DirDef}
- {\bf Bacula Director} service consists of the program that supervises
- all the backup, restore, verify and archive operations. The system
- administrator uses the Bacula Director to schedule backups and to
- recover files. For more details see the Director Services Daemon Design
- Document in the Bacula Developer's Guide. The Director runs as a daemon
- or a service (i.e. in the background).
+ Der {\bf Bacula Director}-Dienst ist das Programm, das alle Sicherungs-, Wiederherstellungs-, Verifizierungs- und Archivierungsvorgänge überwacht. DerSystemadministrator verwendet den Bacula Director, um die Zeitpunkte der Sicherungen festzulegen und Dateien wiederherzustellen. Näheres hierzu im Dokument ``Director Services Daemon Design'' im ``Bacula Developer's Guide''.
+Der Director läuft als Dämon bzw. Dienst (also im Hintergrund).
\item
\label{UADef}
- {\bf Bacula Console} services is the program that allows the
- administrator or user to communicate with the {\bf Bacula Director} (see
- above). Currently, the Bacula Console is available in three versions.
- The first and simplest is to run the Console program in a shell window
- (i.e. TTY interface). Most system administrators will find this
- completely adequate. The second version is a GNOME GUI interface that
- is far from complete, but quite functional as it has most the
- capabilities of the shell Console. The third version is a wxWidgets GUI
- with an interactive file restore. It also has most of the capabilities
- of the shell console, allows command completion with tabulation, and
- gives you instant help about the command you are typing. For more
- details see the \ilink{Bacula Console Design Document}{_ConsoleChapter}.
+ Der {\bf Bacula Console}-Dienst ist jenes Programm, welches es einem
+Systemadministrator oder Benutzer erlaubt, mit dem {\bf Bacula Director} zu
+kommunizieren (siehe oben). Zur Zeit ist die Bacula Console in drei Versionen75%
+verfügbar. Die erste und einfachste ist das Consolen Programm in einer
+Shell zu starten (also eine TTY-Schnittstelle). Für die meisten
+Systemadministratoren ist dies völlig angemessen. Die zweite Möglichkeit ist ein
+grafisches GNOME-Interface, das weit davon entfernt
+ist, vollständig zu sein, aber schon ganz gut funktioniert und die meisten
+Möglichkeiten bietet, die auch die Shell-Konsole hat. Die dritte
+Version ist eine grafische wxWidgets-Benutzeroberfläche, über die Daten
+interaktiv wiederhergestellt werden können. Auch sie hat die meisten Funktionen
+der Shell-Konsole, bietet eine Befehlsvervollständigung per Tabulatorentaste
+und Kontexthilfe während der Befehlseingabe.
+Näheres hierzu im Kapitel \ilink{Bacula Console
+Design Document}{_ChapterStart23}.
\item
\label{FDDef}
- {\bf Bacula File} services (or Client program) is the software program
- that is installed on the machine to be backed up. It is specific to the
- operating system on which it runs and is responsible for providing the
- file attributes and data when requested by the Director. The File
- services are also responsible for the file system dependent part of
- restoring the file attributes and data during a recovery operation. For
- more details see the File Services Daemon Design Document in the Bacula
- Developer's Guide. This program runs as a daemon on the machine to be
- backed up, and in some of the documentation, the File daemon is referred
- to as the Client (for example in Bacula's configuration file). In
- addition to Unix/Linux File daemons, there is a Windows File daemon
- (normally distributed in binary format). The Windows File daemon runs
- on current Windows versions (NT, 2000, XP, 2003, and possibly Me and
- 98).
+ {\bf Bacula File} (Datei)-Dienste (bzw. Client-Programme) sind jene
+Programme, die auf den Rechnern installiert sind, deren Daten gesichert
+werden sollen. Sie sind je nach Betriebssystem verschieden, immer aber
+verantwortlich für die Auslieferung der Daten und deren Attribute, die der
+Director von ihnen anfordert. Die Datendienste sind auch für den
+betriebssystemabhängigen Teil der Wiederherstellung der Daten und deren
+Attribute im Falle einer Wiederherstellung zuständig. Näheres
+hierzu im Dokument ``File Services Daemon Design'' im ``Bacula Developer's
+Guide''. Auf dem Rechner, dessen Daten gesichert werden sollen, läuft dieses
+Programm als Dämonprozess. Der File-Dämon wird in dieser Dokumentation auch als
+``Client'' bezeichnet (zum Beispiel in den Konfigurationsdatei von Bacula).
+Ausser den Unix/Linux File-Dämonen gibt es einen File-Dämon für Windows
+(der in der Regel als kompiliertes Programm erhältlich ist). Der File-Dämon für Windows läuft
+unter allen gängigen Windows-Versionen (95, 98, Me, NT, 2000, XP).
\item
\label{SDDef}
- {\bf Bacula Storage} services consist of the software programs that
- perform the storage and recovery of the file attributes and data to the
- physical backup media or volumes. In other words, the Storage daemon is
- responsible for reading and writing your tapes (or other storage media,
- e.g. files). For more details see the Storage Services Daemon Design
- Document in the Bacula Developer's Guild. The Storage services runs as
- a daemon on the machine that has the backup device (usually a tape
- drive).
+ Den {\bf Bacula Storage} (Sicherungs)-Dienst leisten Programme, die
+Sicherung und Wiederherstellung der Dateien und ihrer Attribute auf das
+physikalische Sicherungsmedium bzw. die \textbf{Volumes} leisten. Der Storage-Dämon ist also für das
+Beschreiben und Lesen Ihrer Bänder (oder eines anderen Sicherungsmediums wie
+z.B. Dateien) zuständig. Näheres hierzu im Kapitel ``Storage Services Daemon
+Design'' im ``Bacula Developer's Guide''. Der Sicherungsdienst läuft als
+Dämonprozess auf dem Rechner, der über das Datensicherungsgerät verfügt (in der
+Regel ein Bandlaufwerk).
\item
\label{DBDefinition}
- {\bf Catalog} services are comprised of the software programs
- responsible for maintaining the file indexes and volume databases for
- all files backed up. The Catalog services permit the System
- Administrator or user to quickly locate and restore any desired file.
- The Catalog services sets Bacula apart from simple backup programs like
- tar and bru, because the catalog maintains a record of all Volumes used,
- all Jobs run, and all Files saved, permitting efficient restoration and
- Volume management. Bacula currently supports three different databases,
- MySQL, PostgreSQL, and SQLite, one of which must be chosen when building
- {\bf Bacula}.
-
- The three SQL databases currently supported (MySQL, PostgreSQL or
- SQLite) provide quite a number of features, including rapid indexing,
- arbitrary queries, and security. Although we plan to support other
- major SQL databases, the current Bacula implementation interfaces only
- to MySQL, PostgreSQL and SQLite. For the technical and porting details
- see the Catalog Services Design Document in the developer's documented.
-
- The RPMs for MySQL and PostgreSQL ship as part of the Linux RedHat and
- several other releases. Alternatively, building the rpms from the
- source is quite easy, see the \ilink{ Installing and Configuring
- MySQL}{_ChapterStart} chapter of this document for the details. For
- more information on MySQL, please see:
- \elink{www.mysql.com}{http://www.mysql.com}. Or see the \ilink{
- Installing and Configuring PostgreSQL}{_ChapterStart10} chapter of this
- document for the details. For more information on PostgreSQL, please
- see: \elink{www.postgresql.org}{http://www.postgresql.org}.
-
- Configuring and building SQLite is even easier. For the details of
- configuring SQLite, please see the \ilink{ Installing and Configuring
- SQLite}{_ChapterStart33} chapter of this document.
+ Die {\bf Catalog} (Verzeichnis)-Dienste werden von Programmen
+geleistet, die für die Wartung der Datieindizes und \textbf{Volume}-Datenbanken
+aller gesicherten Dateien zuständig sind. Über einen Verzeichnis-Dienst kann der
+Systemadministrator oder Benutzer jede gewünschte Datei rasch wiederfinden
+und wiederherstellen. Durch den Verzeichnisdienst unterscheidet sich Bacula von
+einfachen Sicherungsprogrammen wie ``tar'' oder ``bru'', da dieser
+Dienst die Aufzeichnung aller verwendeten \textbf{Volumes}, aller gelaufener
+Sicherungen und aller gesicherter Dateien pflegt und dadurch eine
+effiziente Wiederherstellung und eine Verwaltung der Volumes erlaubt. Bacula
+unterstützt momentan drei verschiedene Datenbanksysteme, MySQL, PostgreSQL
+und SQLite, von denen eines vor der Kompilierung von {\bf Bacula} ausgewählt sein
+muss.
+
+Die drei Datenbanksysteme (MySQL, PostgreSQL und SQLite), die z.Z. unterstützt
+werden, haben eine ganze Reihe von Besonderheiten wie z.B. schnelle Indizierung,
+Baumsuche und Sicherheitsfunktionen. Wir planen die Unterstützung weiterer
+größerer SQL-Datenbanksysteme, doch hat die momentane Bacula-Version nur
+Schnittstellen zu MySQL, PostgreSQL und SQLite. Näheres hierzu im Kapitel
+\ilink{``Catalog Services Design Document''}{_ChapterStart30}.
+
+Die RPM-Archive von MySQL und PostgreSQL sind Teil der RedHat-Linux- und mehrerer
+anderer Distributionen, zudem ist die Erstellung der RPMs aus den Quelldateien
+ganz einfach. Näheres hierzu im Kapitel \ilink{``Installation und Konfiguration
+von MySQL''}{_ChapterStart} in diesem Handbuch. Weitere Informationen zu MySQL
+im Internet: \elink{www.mysql.com}{http://www.mysql.com}.
+Zu PostgreSQL lesen Sie bitte das Kapitel \ilink{``Installation und
+Konfiguration von PostgreSQL''}{_ChapterStart10} in diesem Dokument.
+Weiter Informationen zu PostgreSQL finden Sie hier:
+\elink{www.postgresql.org}{http://www.postgresql.org}.
+
+Die Konfiguration und Installation eines SQLite-Datenbanksystems ist noch
+einfacher. Einzelheiten dazu im Kapitel \ilink{``Installation und Konfiguration
+von SQLite''}{_ChapterStart33} in diesem Handbuch.
\item
\label{MonDef}
- {\bf Bacula Monitor} services is the program that allows the
- administrator or user to watch current status of {\bf Bacula Directors},
- {\bf Bacula File Daemons} and {\bf Bacula Storage Daemons} (see above).
- Currently, only a GTK+ version is available, which works with Gnome and
- KDE (or any window manager that supports the FreeDesktop.org system tray
- standard). \end{itemize}
-
- To perform a successful save or restore, the following four daemons must be
- configured and running: the Director daemon, the File daemon, the Storage
- daemon, and MySQL, PostgreSQL or SQLite.
-
-\subsection*{Bacula Configuration}
-\index[general]{Configuration!Bacula }
-\index[general]{Bacula Configuration }
-\addcontentsline{toc}{subsection}{Bacula Configuration}
-
-In order for Bacula to understand your system, what clients you want backed
-up, and how, you must create a number of configuration files containing
-resources (or objects). The following presents an overall picture of this:
+ Der {\bf Bacula Monitor}-Dienst ist das Programm, welches es dem
+Administrator oder Benutzer erlaubt, den aktuellen Zustand des {\bf Bacula
+Directors}, der {\bf Bacula File Dämonen} und der {\bf Bacula Storage Dämonen}
+zu beobachten (siehe oben). Zur Zeit ist hierfür nur eine GTK+-Version
+verfügbar, die auf Gnome und KDE aufsetzt (oder jedem anderen Fenstermanager,
+der den Standard von FreeDesktop.org für das System-Tray unterstützt).
+\end{itemize}
+
+Um erfolgreich sichern und wiederherstellen zu können, müssen die folgenden
+vier Dämonprozesse konfiguriert und gestartet sein: Der Director-Dämon, der
+File-Dämon, der Storage-Dämon und MySQL, PostgreSQL oder SQLite.
+%vonmir bf!
+\newpage
+
+\subsection*{Die Bacula Konfiguration}
+\index[general]{Konfiguration!Die Bacula }
+\index[general]{Die Bacula Konfiguration }
+\addcontentsline{toc}{subsection}{Die Bacula Konfiguration}
+
+Damit sich Bacula in Ihrem System zurechtfindet und es weiss welche
+Client-Rechner wie zu sichern sind, müssen mehrere Konfigurationsdateien
+erstellt werden, die ``Resourcen'' (bzw. ``Objekte'') enthalten. Die
+folgende Abbildung gibt hierzu eine Übersicht:
\addcontentsline{lof}{figure}{Bacula Objects}
\includegraphics{./bacula-objects.eps}
-\subsection*{Conventions Used in this Document}
-\index[general]{Conventions Used in this Document }
-\index[general]{Document!Conventions Used in this }
-\addcontentsline{toc}{subsection}{Conventions Used in this Document}
-
-{\bf Bacula} is in a state of evolution, and as a consequence, this manual
-will not always agree with the code. If an item in this manual is preceded by
-an asterisk (*), it indicates that the particular feature is not implemented.
-If it is preceded by a plus sign (+), it indicates that the feature may be
-partially implemented.
-
-If you are reading this manual as supplied in a released version of the
-software, the above paragraph holds true. If you are reading the online
-version of the manual,
-\elink{ www.bacula.org}{http://www.bacula.org}, please bear in
-mind that this version describes the current version in development (in the
-CVS) that may contain features not in the released version. Just the same, it
-generally lags behind the code a bit.
+\subsection*{Die in diesem Dokument verwendeten Konventionen}
+\index[general]{Die in diesem Dokument verwendeten Konventionen }
+\index[general]{Dokument!verwendete Konventionen}
+\addcontentsline{toc}{subsection}{Die in diesem Dokument verwendeten
+Konventionen}
+
+{\bf Bacula} ist in der Entwicklung und daher wird dieses Handbuch nicht in
+jedem Fall mit dem Stand des Programmcodes übereinstimmen. Steht in diesem
+Handbuch vor einem Abschnitt ein Stern (*), bedeutet dies, dass das Beschriebene
+noch nicht implementiert ist. Die Kennzeichnung durch ein Pluszeichen (+)
+bedeutet, dass die Funktion möglicherweise teilweise implementiert ist.
+
+Wenn Sie dieses Handbuch als Teil eines offiziellen Release der
+Software lesen, ist diese Kennzeichnung verläßlich. Lesen Sie hingegen die
+Online-Version dieses Handbuches auf \elink{ www.bacula.org}{http://www.bacula.org}, denken Sie
+bitte daran, dass hier die aktuelle Entwicklungsversion (wie sie im CVS
+vorhanden ist) beschrieben wird. In beiden Fällen wird aber das Handbuch dem
+Code ein Stückchen hinterherhinken.
\subsection*{Quick Start}
\index[general]{Quick Start }
\index[general]{Start!Quick }
\addcontentsline{toc}{subsection}{Quick Start}
-To get Bacula up and running quickly, we recommend that you first scan the
-Terminology section below, then quickly review the next chapter entitled
-\ilink{The Current State of Bacula}{_ChapterStart2}, then the
-\ilink{Getting Started with Bacula}{_ChapterStart37}, which will
-give you a quick overview of getting Bacula running. After which, you should
-proceed to the chapter on
-\ilink{Installing Bacula}{_ChapterStart17}, then
-\ilink{How to Configure Bacula}{_ChapterStart16}, and finally the
-chapter on
-\ilink{ Running Bacula}{_ChapterStart1}.
+Um Bacula schnell zu konfigurieren und zum Laufen zu bringen, empfehlen wir,
+zuerst den untenstehenden Abschnitt mit den Fachausdrücken und das nächste
+Kapitel \ilink{``Baculas gegenwärtiger Zustand''}{_ChapterStart2} durchzusehen.
-\subsection*{Terminology}
-\index[general]{Terminology }
-\addcontentsline{toc}{subsection}{Terminology}
+Lesen Sie dann das Kapitel \ilink{``Mit Bacula beginnen''}{_ChapterStart37}, das
+eine kurze Übersicht darüber gibt, wie man Bacula startet. Lesen
+Sie danach das Kapitel über \ilink{``Die Installation von
+Bacula''}{_ChapterStart17}, dann \ilink{``Die Konfiguration
+von Bacula''}{_ChapterStart16} und schließlich das Kapitel \ilink{
+``Bacula in Betrieb nehmen''}{_ChapterStart1}.
-To facilitate communication about this project, we provide here the
-definitions of the terminology that we use.
+\subsection*{Terminologie}
+\index[general]{Terminologie }
+\addcontentsline{toc}{subsection}{Terminologie}
+
+Um die Kommunikation über diese Projekt zu erleichtern, sind hier die
+verwendeten Begriffe erläutert
\begin{description}
\item [Administrator]
\index[fd]{Administrator }
- The person or persons responsible for administrating the Bacula system.
+ Die Person bzw. die Personen, die für die Pflege des Bacula-Systems
+verantwortlich sind.
\item [Backup]
\index[fd]{Backup }
- We use the term {\bf Backup} to refer to a Bacula Job that saves files.
+ Wir verwenden den Ausdruck {\bf Backup} (Sicherung) wenn wir von einem
+Bacula-Job sprechen, bei dem Dateien gesichert werden.
\item [Bootstrap File]
\index[fd]{Bootstrap File }
- The bootstrap file is an ASCII file containing a compact form of
- commands that allow Bacula or the stand-alone file extraction utility
- ({\bf bextract}) to restore the contents of one or more Volumes, for
- example, the current state of a system just backed up. With a bootstrap
- file, Bacula can restore your system without a Catalog. You can create
- a bootstrap file from a Catalog to extract any file or files you wish.
+ Das bootstrap file (Bootstrap-Datei) ist eine ASCII-Datei, die in kompakter
+Form jene Befehle enthält, mit denen Bacula oder das eigenständige
+Dateiextrahierungswerkzeug {\bf bextract} den Inhalt eines oder mehrerer
+\textbf{Volumes} wiederherstellen kann, wie z.B. einen vorher gesicherten Systemzustand.
+Mit einer Bootstrap-Datei kann Bacula Ihr System wiederherstellen, ohne auf
+einen \textbf{Catalog} angewiesen zu sein. Aus einem \textbf{Catalog} kann eine Bootstrap-Datei
+erzeugt werden, um jede gewünschte Datei/Dateien zu entpacken.
\item [Catalog]
\index[fd]{Catalog }
- The Catalog is used to store summary information about the Jobs,
- Clients, and Files that were backed up and on what Volume or Volumes.
- The information saved in the Catalog permits the administrator or user
- to determine what jobs were run, their status as well as the important
- characteristics of each file that was backed up, and most importantly,
- it permits you to choose what files to restore.
- The Catalog is an
- online resource, but does not contain the data for the files backed up.
- Most of the information stored in the catalog is also stored on the
- backup volumes (i.e. tapes). Of course, the tapes will also have a
- copy of the file data in addition to the File Attributes (see below).
-
- The catalog feature is one part of Bacula that distinguishes it from
- simple backup and archive programs such as {\bf dump} and {\bf tar}.
+ Der \textbf{Catalog} (das Verzeichnis) wird verwendet, um zusammenfassene
+Informationen über Jobs, Clients und Dateien zu speichern und Informationen
+darüber, in welchem \textbf{Volume} oder in welchen \textbf{Volumen} dies geschehen ist. Die
+Informationen, die im \textbf{Catalog} gespeichert sind, ermöglichen es dem Administrator
+bzw. Benutzer zu bestimmen, welche Jobs gelaufen sind, geben Auskunft über ihren
+Status und wichtige Eigenschaften der gesicherten Dateien. Der Catalog ist eine
+``online resource'', enthält aber nicht die Daten der gesicherten Dateien. Vieles
+der \textbf{Catalog}-Informationen ist auch in den \textbf{Volumes} (z.B. auf den Bändern)
+gespeichert. Natürlich sind auf den Bändern auch die Kopien der Dateien und
+deren Attribute (siehe unten).
+
+Der \textbf{Catalog} ist ein Besonderheit Baculas, das es von einfachen Backup- und
+Archiv-Programmen wie {\bf dump} und {\bf tar} unterscheidet.
\item [Client]
\index[fd]{Client }
- In Bacula's terminology, the word Client refers to the machine being
- backed up, and it is synonymous with the File services or File daemon,
- and quite often, we refer to it as the FD. A Client is defined in a
- configuration file resource.
+ In Baculas Terminologie bezeichnet das Wort Client jenen Rechner,
+dessen Daten gesichert werden. Client ist auch ein anderes Wort für
+den File-Dienst oder File-Dämon, der oft auch nur mit FD bezeichnet wird.
+Clients werden in einer Resource der Konfigurationsdatei definiert.
\item [Console]
\index[fd]{Console }
- The program that interfaces to the Director allowing the user or system
- administrator to control Bacula.
+ Die Console(Konsole) ist ein Programm, das die Schnittstelle zum Director
+bildet und über welches der Benutzer oder Systemadministrator Bacula
+steuern kann.
\item [Daemon]
\index[fd]{Daemon }
- Unix terminology for a program that is always present in the background to
-carry out a designated task. On Windows systems, as well as some Linux
-systems, daemons are called {\bf Services}.
+ (Dämonprozess) ist ein Unix-Fachausdruck für ein Programm, das
+ständig im Hintergrund läuft um spezielle Aufgaben
+auszuführen. Auf Windows- und manchen Linux-Systemen werden
+Dämonprozesse {\bf Services}(Dienste) genannt.
\item [Directive]
\index[fd]{Directive }
- The term directive is used to refer to a statement or a record within a
- Resource in a configuration file that defines one specific thing. For
- example, the {\bf Name} directive defines the name of the Resource.
+ Der Ausdruck directive (Anweisung) bezeichnet eine einzelne Angabe oder
+eine Niederschrift innerhalb einer Resource einer Konfigurationsdatei, welche
+einen speziellen Sachverhalt definiert. Beispielsweise definiert die {\bf
+Name}-directive den Namen einer Resource.
\item [Director]
\index[fd]{Director }
- The main Bacula server daemon that schedules and directs all Bacula
- operations. Occasionally, we refer to the Director as DIR.
+ Baculas wichtigster Dämonprozess, der alle Aktivitäten des Bacula-Systems
+zeitlich festlegt und beaufsichtigt. Gelegentlich bezeichnen wir ihn als
+DIR.
\item [Differential]
\index[fd]{Differential }
- A backup that includes all files changed since the last Full save started.
- Note, other backup programs may define this differently.
+ Differentiell ist eine Sicherung, wenn sie alle Dateien einbezieht, die
+seit Beginn der letzten Vollsicherung geändert wurden. Beachten Sie bitte, dass
+dies von anderen Sicherungsprogrammen möglicherweise anders definiert wird.
\item [File Attributes]
\index[fd]{File Attributes }
- identify it and all its properties such as size, creation date, modification
- date, permissions, etc. Normally, the attributes are handled entirely by
- Bacula so that the user never needs to be concerned about them. The
- attributes do not include the file's data.
- The File Attributes are all the information necessary about a file to
+ File Attributes (Dateiattribute) sind all diejenigen Informationen, die
+nötig sind, um eine Datei zu identifizieren. Dazu gehören alle ihre
+Eigenschaften wie Größe, Zeitpunkt der Erzeugung, Zeitpunkt der letzten
+Änderung, Berechtigungen, usw. Im Normalfall wird der Umgang mit den Attributen vollständig von Bacula übernommen, so dass sich der Benutzer darüber keine
+Gedanken machen muss. Zu den Attributen gehört nicht der Inhalt der
+Datei.
\item [File Daemon]
\index[fd]{File Daemon }
- The daemon running on the client computer to be backed up. This is also
- referred to as the File services, and sometimes as the Client services or the
- FD.
+ Derjenige Dämonprozess, welcher auf dem Client-Computer läuft, dessen Daten
+gesichert werden sollen. Wird manchmal auch als File-Service (Datendienst),
+Client-Service (Client-Dienst) oder als FD bezeichnet.
+
-\label{FileSetDef}
-\item [FileSet]
+ \label{FileSetDef}
+ \item [FileSet]
\index[fd]{a name }
- A FileSet is a Resource contained in a configuration file that defines
- the files to be backed up. It consists of a list of included files or
- directories, a list of excluded files, and how the file is to be stored
- (compression, encryption, signatures). For more details, see the
- \ilink{FileSet Resource definition}{FileSetResource} in the Director
- chapter of this document.
+Ein FileSet (Zusammenstellung von Dateien) ist eine Resource einer
+Konfigurationsdatei, die festlegt, welche Dateien gesichert werden sollen.
+Sie besteht aus einer Liste mit eingeschlossenen Dateien oder
+Verzeichnissen, einer Liste mit ausgeschlossenen Dateien und Informationen
+darüber, wie diese Dateien zu sichern sind (komprimiert, verschlüsselt,
+signiert). Näheres hierzu im Abschnitt \ilink{``Definition der FileSet
+Resource''}{FileSetResource} im \textbf{Director}-Kapitel dieses Dokuments.
\item [Incremental]
\index[fd]{Incremental }
- A backup that includes all files changed since the last Full, Differential,
- or Incremental backup started. It is normally specified on the {\bf Level}
- directive within the Job resource definition, or in a Schedule resource.
+ Inkrementiell ist eine Sicherung dann, wenn sie alle Dateien einbezieht, die
+seit Beginn der letzten vollen, differentiellen oder inkrementiellen Sicherung
+geändert wurden. Normalerweise wird dies entweder durch die {\bf
+Level}-Direktive innerhalb der Definition einer \textbf{Job Resource} oder in
+einer \textbf{Schedule}-Resource festgelegt.
+
-\label{JobDef}
+ \label{JobDef}
\item [Job]
\index[fd]{a name }
- A Bacula Job is a configuration resource that defines the work that
- Bacula must perform to backup or restore a particular Client. It
- consists of the {\bf Type} (backup, restore, verify, etc), the {\bf
- Level} (full, incremental,...), the {\bf FileSet}, and {\bf Storage} the
- files are to be backed up (Storage device, Media Pool). For more
- details, see the \ilink{Job Resource definition}{JobResource} in the
- Director chapter of this document.
+Ein Bacula-Job ist eine Konfigurations-Resource, die die Art und
+Weise definiert, in der Bacula die Daten eines bestimmten Client-Rechners
+sichert oder wiederherstellt. Sie besteht aus den Definitionen des {\bf Type}
+(Sicherung, Wiederherstellung, Überprüfung, usw.), des {\bf Level} (voll,
+inkrementiell,...), des {\bf FileSet} und des Speicherorts ({\bf Storage}) an
+welchem die Dateien gesichert werden sollen (Speichergerät, Media-Pool). Näheres
+hierzu im Abschnitt \ilink{``Definition der Job-Resource''
+}{JobResource} im \textbf{Director}-Kapitel dieses Dokuments.
\item [Monitor]
\index[fd]{Monitor }
- The program that interfaces to all the daemons allowing the user or
- system administrator to monitor Bacula status.
+ Dieses Programm hat eine Schnittstelle zu allen Dämonprozessen, um dem
+Benutzer oder Systemadministrator die Beobachtung von Baculas Zustand zu
+ermöglichen.
\item [Resource]
\index[fd]{Resource }
- A resource is a part of a configuration file that defines a specific
- unit of information that is available to Bacula. It consists of several
- directives (individual configuration statements). For example, the {\bf
- Job} resource defines all the properties of a specific Job: name,
- schedule, Volume pool, backup type, backup level, ...
+ Eine \textbf{Resource} ist ein Teil einer Konfigurationsdatei, die eine
+bestimmte Informationseinheit definiert, die Bacula verfügbar ist. Eine
+\textbf{Resorce} enthält mehrere Direktiven (einzelne
+Konfigurations-Anweisungen). Die {\bf Job}-Resource beispielsweise definiert
+alle Eigenschaften eines bestimmten Jobs: Name, Zeitplan, Volume-Pool, Art der
+Sicherung, Level der Sicherung...
\item [Restore]
\index[fd]{Restore }
- A restore is a configuration resource that describes the operation of
- recovering a file from backup media. It is the inverse of a save,
- except that in most cases, a restore will normally have a small set of
- files to restore, while normally a Save backs up all the files on the
- system. Of course, after a disk crash, Bacula can be called upon to do
- a full Restore of all files that were on the system.
+ ist eine \textbf{Resource} innerhalb einer Konfigurationsdatei, die den
+Vorgang der Wiederherstellung einer verlorenen oder beschädigten Datei von
+einem Sicherungsmedium beschreibt. Es ist der umgekehrte Vorgang wie bei
+einer Sicherung, außer dass in den meisten Fällen bei einem \textbf{Restore} nur
+einige wenige Dateien wiederhergestellt werden, während bei einer Sicherung
+normalerweise alle Dateien eines Systems gesichert werden. Selbstverständlich
+kann nach dem Ausfall einer Festplatte Bacula dazu benutzt werden, ein
+vollständiges \textbf{Restore} aller im System vorhandenen Dateien auszuführen.
\item [Schedule]
\index[fd]{Schedule }
- A Schedule is a configuration resource that defines when the Bacula Job
- will be scheduled for execution. To use the Schedule, the Job resource
- will refer to the name of the Schedule. For more details, see the
- \ilink{Schedule Resource definition}{ScheduleResource} in the Director
- chapter of this document.
+ Ein \textbf{Schedule} (Zeitplan) ist eine \textbf{Resource} innerhalb einer
+Konfigurationsdatei, die definiert, wann ein \textbf{Bacula-Job} ausgeführt
+wird. Hierzu benutzt die \textbf{Job-Resource} den Namen des \textbf{Schedules}.
+Näheres hierzu im Abschnitt \ilink{``Definition
+der Schedule-Resource''}{ScheduleResource} im
+``Director''-Kapitel diese Handbuches.
\item [Service]
\index[fd]{Service }
- This is Windows terminology for a {\bf daemon} -- see above. It is now
- frequently used in Unix environments as well.
+ (Dienst) ist die Bezeichnung für einen {\bf Daemon}(Dämonprozess) unter
+Windows (siehe oben). Diese Bezeichnung wird in letzter Zeit auch häufig in
+Unix-Umgebungen benutzt.
\item [Storage Coordinates]
\index[fd]{Storage Coordinates }
- The information returned from the Storage Services that uniquely locates
- a file on a backup medium. It consists of two parts: one part pertains
- to each file saved, and the other part pertains to the whole Job.
- Normally, this information is saved in the Catalog so that the user
- doesn't need specific knowledge of the Storage Coordinates. The Storage
- Coordinates include the File Attributes (see above) plus the unique
- location of the information on the backup Volume.
+ Diejenige Information, die der \textbf{Storage-Dienst} zurückgibt und eine
+Datei eindeutig im Sicherungsmedium lokalisiert. Sie besteht aus einem Teil der
+zu jeder gespeicherten Datei gehört und einem Teil, der zum ganzen Job
+gehört.
+Normalerweise wird diese Information im \textbf{Catalog} gespeichert, so dass der
+Benutzer keine besonderen Kenntnisse der \textbf{Storage Coordinates} braucht.
+Zu den \textbf{Storage Coordinates} gehören die Dateiattribute und der eindeutige Ort der Sicherung auf dem Sicherungs-Volume.
\item [Storage Daemon]
\index[fd]{Storage Daemon }
- The Storage daemon, sometimes referred to as the SD, is the code that
- writes the attributes and data to a storage Volume (usually a tape or
- disk).
+ Der \textbf{Storage daemon} (Speicherdämon), manchmal auch mit SD bezeichnet,
+ist jenes Programm, das die Attribute und die Daten auf ein Sicherungs-Volume
+schreibt (normalerweise ein Band oder eine Festplatte).
\item [Session]
- \index[sd]{Session }
- Normally refers to the internal conversation between the File daemon and
- the Storage daemon. The File daemon opens a {\bf session} with the
- Storage daemon to save a FileSet, or to restore it. A session has a one
- to one correspondence to a Bacula Job (see above).
+ \index[sd]{Session } (Sitzung) bezeichnet in der Regel die interne Kommunikation
+zwischen dem File-Dämon und dem Storage-Dämon. Der File-Dämon eröffnet
+eine {\bf Session} mit dem Storage-Dämon, um ein \textbf{FileSet} zu sichern
+oder wiederherzustellen. Jede \textbf{Session} entspricht einem \textbf{Bacula-Job} (siehe oben).
\item [Verify]
\index[sd]{Verify }
- A verify is a job that compares the current file attributes to the
- attributes that have previously been stored in the Bacula Catalog. This
- feature can be used for detecting changes to critical system files
- similar to what {\bf Tripwire} does. One of the major advantages of
- using Bacula to do this is that on the machine you want protected such
- as a server, you can run just the File daemon, and the Director, Storage
- daemon, and Catalog reside on a different machine. As a consequence, if
- your server is ever compromised, it is unlikely that your verification
- database will be tampered with.
-
- Verify can also be used to check that the most recent Job data written
- to a Volume agrees with what is stored in the Catalog (i.e. it compares
- the file attributes), *or it can check the Volume contents against the
- original files on disk.
+ Ein \textbf{Verify} ist ein Job, bei dem die aktuellen Dateiattribute mit
+jenen verglichen werden, die zuvor im \textbf{Bacula-Catalog}
+hinterlegt worden sind. Diese Funktion kann verwendet werden, um Änderungen an
+wichtigen Systemdateien zu erkennen und ist damit {\bf Tripwire} ähnlich. Einer
+der größeren Vorteile dieser Funktionalität ist es, dass es genügt,
+auf dem Rechner, den man schützen will, den \textbf{File-Dämon} laufen zu haben.
+\textbf{Director}, \textbf{Storage-Dämon} und der \textbf{Catalog} sind auf
+einem anderen Rechner installiert. Wenn der Server dann gefährdet wird, ist es
+äußerst unwahrscheinlich, dass die Datenbank mit den Verifikationen davon
+mitbetroffen ist.
+
+\textbf{Verify} kann auch zur Überprüfung benutzt werden, ob die Daten des
+zuletzt gelaufenen Jobs mit denen übereinstimmen, welche davon im \textbf{Catalog}
+gespeichert ist (es werden also die Dateiattribute verglichen). *\textbf{Verify}
+vergleicht auch den Inhalt eines Volumes mit den Originaldateien auf der
+Platte.
\item [*Archive]
\index[fd]{*Archive }
- An Archive operation is done after a Save, and it consists of removing the
-Volumes on which data is saved from active use. These Volumes are marked as
-Archived, and may no longer be used to save files. All the files contained
-on an Archived Volume are removed from the Catalog. NOT YET IMPLEMENTED.
+ Eine \textbf{Archive}-Funktion wird nach einer Sicherung durchgeführt. Dabei
+werden die \textbf{Volumes}, in denen die Daten gesichert sind, der aktiven
+Benutzung entzogen, als ``Archived'' gekennzeichnet und für weitere
+Sicherungen nicht mehr verwendet. Alle Dateien, die ein archiviertes
+\textbf{Volume} enthält, werden aus dem Catalog entfernt. NOCH NICHT
+IMPLEMENTIERT.
\item [*Update]
\index[fd]{*Update }
- An Update operation causes the files on the remote system to be updated to be
-the same as the host system. This is equivalent to an {\bf rdist} capability.
-NOT YET IMPLEMENTED.
+ Mit der \textbf{Update}-Funktion werden die Dateien auf dem entfernten
+Rechner durch die entsprechenden vom Host-Rechner ersetzt. Dies entspricht der
+Funktionalität von {\bf rdist}. NOCH NICHT IMPLEMENTIERT.
\item [Retention Period]
\index[fd]{Retention Period }
- There are various kinds of retention periods that Bacula recognizes.
- The most important are the {\bf File} Retention Period, {\bf Job}
- Retention Period, and the {\bf Volume} Retention Period. Each of these
- retention periods applies to the time that specific records will be kept
- in the Catalog database. This should not be confused with the time that
- the data saved to a Volume is valid.
-
- The File Retention Period determines the time that File records are kept
- in the catalog database. This period is important because the volume of
- the database File records by far use the most storage space in the
- database. As a consequence, you must ensure that regular "pruning" of
- the database file records is done. (See the Console {\bf retention}
- command for more details on this subject).
-
- The Job Retention Period is the length of time that Job records will be
- kept in the database. Note, all the File records are tied to the Job
- that saved those files. The File records can be purged leaving the Job
- records. In this case, information will be available about the jobs
- that ran, but not the details of the files that were backed up.
- Normally, when a Job record is purged, all its File records will also be
- purged.
-
- The Volume Retention Period is the minimum of time that a Volume will be
- kept before it is reused. Bacula will normally never overwrite a Volume
- that contains the only backup copy of a file. Under ideal conditions,
- the Catalog would retain entries for all files backed up for all current
- Volumes. Once a Volume is overwritten, the files that were backed up on
- that Volume are automatically removed from the Catalog. However, if
- there is a very large pool of Volumes or a Volume is never overwritten,
- the Catalog database may become enormous. To keep the Catalog to a
- manageable size, the backup information should be removed from the
- Catalog after the defined File Retention Period. Bacula provides the
- mechanisms for the catalog to be automatically pruned according to the
- retention periods defined.
+ Bacula kennt verschiedene Arten von \textbf{Retention Periods} (Zeitspannen
+während derer etwas bewahrt wird, Aufbewahrungszeiten). Die wichtigsten sind
+die {\bf File Retention Period}, die {\bf Job Retention Period} und die {\bf
+Volume Retention Period}. Jede dieser Retention-Periods bezieht sich auf die
+Zeit, während der bestimmte Aufzeichnungen in der \textbf{Catalog}-Datenbank
+gehalten werden. Dies sollte nicht mit jener Zeit verwechselt werden während
+der Daten eines Volume gültig sind.
+
+Die \textbf{File Retention Period} bestimmt wie lange die Einträge zu den
+Dateien in der \textbf{Catalog}-Datenbank gehalten werden. Diese Zeitspanne ist
+wichtig, da diese Einträge bei weitem den größten Teil des Speicherplatzes in
+der Datenbank belegen. Daher muss gewährleistet sein, dass überflüssige oder
+obsolete Einträge regelmäßig aus der Datenbank entfernt werden (hierzu Näheres im Abschnitt zum {\bf Retention}-Befehl in der Beschreibung der \textbf{Console}-Befehle).
+
+Die \textbf{Job Retention Period} ist die Zeitspanne, während der Einträge zu
+den Jobs in der Datenbank gehalten werden. Beachten Sie, dass alle Dateieinträge
+mit dem Job, mit dem sie gesichert wurden, verbunden sind. Die Einträge zu den
+Dateien können gelöscht sein, während die Aufzeichnungen zu den Jobs erhalten
+bleiben. In diesem Fall wird man Informationen über gelaufene Sicherungsjobs
+haben, jedoch keine Einzelheiten über die Dateien, die dabei gesichert
+wurden. Normalerweise werden mit dem Löschen eines
+Job-Eintrags auch alle seine Aufzeichnungen zu den Dateien gelöscht.
+
+Die \textbf{Volume Retention Period} bestimmt die Mindestzeit, während der
+ein bestimmtes \textbf{Volume} erhalten bleibt, bevor es wiederverwendet wird.
+Bacula wird in der Regel niemals ein \textbf{Volume} überschreiben, das als
+einziges die Sicherungskopie einer bestimmten Datei enthält. Im Idealfall wird
+der \textbf{Catalog} für alle benutzten \textbf{Volume} die Einträge aller
+gesicherten Daeien enthalten. Wenn ein \textbf{Volume} überschrieben wird,
+werden die Dateieeinträge, die zuvor in ihm gespeichert waren aus dem
+\textbf{Catalog} entfernt. Gibt es allerdings einen sehr großen Pool von
+\textbf{Volumes} oder gibt es \textbf{Volumes}, die nie überschrieben werden,
+kann die \textbf{Catalog}-Datenbank riesig werden. Um den \textbf{Catalog} in
+einer handhabbaren Größe zu halten, sollten Informationen zu den Sicherungen
+nach der definierten \textbf{File Retention Period} aus ihm entfernt werden.
+Bacula hat Mechanismen, um den \textbf{Catalog} entsprechend der
+definierten \textbf{Retention Periods} automatisch zu bereinigen.
\item [Scan]
\index[sd]{Scan }
- A Scan operation causes the contents of a Volume or a series of Volumes
- to be scanned. These Volumes with the information on which files they
- contain are restored to the Bacula Catalog. Once the information is
- restored to the Catalog, the files contained on those Volumes may be
- easily restored. This function is particularly useful if certain
- Volumes or Jobs have exceeded their retention period and have been
- pruned or purged from the Catalog. Scanning data from Volumes into the
- Catalog is done by using the {\bf bscan} program. See the \ilink{ bscan
- section}{bscan} of the Bacula Utilities Chapter of this manual for more
- details.
+ Bei einer \textbf{Scan}-Operation wird der Inhalt eines oder mehrerer
+\textbf{Volumes} durchsucht. Diese \textbf{Volumes} und die Informationen über
+die Dateien, welche sie enthalten, werden wieder in den Bacula-\textbf{Catalog}
+eingetragen. Danach können die Dateien in diesen \textbf{Volumes} auf
+einfache Weise wiederhergestellt werden. Diese Funktion ist teilweise
+hilfreich, wenn bestimmte \textbf{Volumes} oder \textbf{Jobs} ihre \textbf{Retention Period}
+überschritten haben und aus dem \textbf{Catalog} entfernt worden sind. Um die
+Daten von den \textbf{Volumes} in die Datenbank einzulesen, wird das Programm
+{\bf bscan} verwendet. Näheres hierzu im Abschnitt \ilink{bscan}{bscan} im Kapitel ``Bacula Hilfsprogramme'' dieses Handbuches.
\item [Volume]
\index[sd]{Volume }
- A Volume is an archive unit, normally a tape or a named disk file where
- Bacula stores the data from one or more backup jobs. All Bacula Volumes
- have a software label written to the Volume by Bacula so that it
- identifies what Volume it is really reading. (Normally there should be
- no confusion with disk files, but with tapes, it is easy to mount the
- wrong one).
+ Ein \textbf{Volume} ist eine Einheit, auf der gesichert wird, normalerweise
+ein Band oder eine benannte Datei auf der Festplatte auf welche/s Bacula die
+Daten einer oder mehrerer Sicherungsjobs speichert. Alle \textbf{Volumes}
+erhalten von Bacula eine digitale Kennzeichnung, so dass Bacula jederzeit weiß,
+welches \textbf{Volume} es tatsächlich liest. (Normalerweise sollte es mit
+Dateien auf der Festplatte keine Verwechslungen geben, doch bei Bändern mountet
+man aus Versehen leicht das Falsche).
\end{description}
-\subsection*{What Bacula is Not}
-\index[general]{What Bacula is Not}
-\addcontentsline{toc}{subsection}{What Bacula is Not}
-
-{\bf Bacula} is a backup, restore and verification program and is not a
-complete disaster recovery system in itself, but it can be a key part of one
-if you plan carefully and follow the instructions included in the
-\ilink{ Disaster Recovery}{_ChapterStart38} Chapter of this manual.
-
-With proper planning, as mentioned in the Disaster Recovery chapter {\bf
-Bacula} can be a central component of your disaster recovery system. For
-example, if you have created an emergency boot disk, a Bacula Rescue disk to
-save the current partitioning information of your hard disk, and maintain a
-complete Bacula backup, it is possible to completely recover your system from
-"bare metal" that is starting from an empty disk.
-
-If you have used the {\bf WriteBootstrap} record in your job or some other
-means to save a valid bootstrap file, you will be able to use it to extract
-the necessary files (without using the catalog or manually searching for the
-files to restore).
-
-\subsection*{Interactions Between the Bacula Services}
-\index[general]{Interactions Between the Bacula Services}
-\index[general]{Services!Interactions Between the Bacula}
-\addcontentsline{toc}{subsection}{Interactions Between the Bacula Services}
-
-The following block diagram shows the typical interactions between the Bacula
-Services for a backup job. Each block represents in general a separate process
-(normally a daemon). In general, the Director oversees the flow of
-information. It also maintains the Catalog.
-
-\addcontentsline{lof}{figure}{Interactions between Bacula Services}
+\subsection*{Was Bacula nicht ist}
+\index[general]{Was Bacula nicht ist }
+\index[general]{nicht ist!Was Bacula }
+\addcontentsline{toc}{subsection}{Was Bacula nicht ist}
+
+{\bf Bacula} ist ein Sicherungs-, Wiederherstellungs- und Verifikationsprogramm, aber von sich aus noch kein komplettes Rettungsprogramm für den Katastrophenfall. Allerdings kann
+Bacula Teil eines Rettungsprogramms sein, falls Sie sorgfältig planen und die
+Anweisungen im Kapitel \ilink{Disaster Recovery}{_ChapterStart38} dieses
+Handbuches beachten.
+
+Bei sorgfältiger Planung, wie sie im Kapitel ``Disaster Recovery'' dargestellt
+ist, kann {\bf Bacula} ein wesentlicher Bestandteil eines
+Rettungssystems sein. Wenn Sie zum Beispiel eine Bootdiskette
+erstellt haben, dazu eine Bacula-Rettungs-CD, auf der sie die aktuellen
+Partitionsdaten Ihrer Festplatte gespeichert haben und eine komplette Bacula
+Sicherung vorhalten, ist es möglich, Ihr System auf einer leeren Festplatte
+wieder herzustellen.
+
+Wenn Sie die den Befehl {\bf WriteBootstrap} in einem Ihrer Sicherungs-Jobs
+verwendet oder auf irgend eine andere Art eine gültige
+\textbf{Bootstrap}-Datei gesichert haben, werden Sie damit in der Lage sein, die notwendigen Dateien zu entpacken (ohne den \textbf{Catalog} zu verwenden
+oder von Hand nach Dateien suchen zu müssen).
+
+\newpage
+
+\subsection*{Interaktionen zwischen den Bacula-Diensten}
+\index[general]{Interaktionen zwischen den Bacula-Diensten }
+\index[general]{Diensten!Interaktionen zwischen den Bacula- }
+\addcontentsline{toc}{subsection}{Interaktionen zwischen den Bacula-Diensten}
+
+Das untenstehende Diagramm zeigt typische Interaktionen zwischen den einzelnen
+Bacula-Diensten bei einem Sicherungs-Job. Jeder Block steht ungefähr für einen
+eigenen Prozess (normalerweise ein Dämon). Im großen und ganzen hat der
+Director den Überblick über die Aktionen und pflegt die
+\textbf{Catalog}-Datenbank.
+
+\addcontentsline{lof}{figure}{Interaktionen zwischen den Bacula-Diensten}
\includegraphics{./flow.eps}
%%
%%
-\section*{Installing Bacula}
+\section*{Bacula installieren}
\label{_ChapterStart17}
-\index[general]{Bacula!Installing }
-\index[general]{Installing Bacula }
-\addcontentsline{toc}{section}{Installing Bacula}
-
-\subsection*{General}
-\index[general]{General }
-\addcontentsline{toc}{subsection}{General}
-
-In general, you will need the Bacula source release, and if you want to run a
-Windows client, you will need the Bacula Windows binary release. However,
-Bacula needs certain third party packages (such as {\bf SQLite}, {\bf MySQL}, or
-{\bf PostgreSQL}
-to build properly depending on the options you specify. To simplify your task,
-we have combined a number of these packages into two {\bf depkgs} releases
-(Dependency Packages). This can vastly simplify your life by providing you
-with all the necessary packages rather than requiring you to find them on the
-Web, load them, and install them.
+\index[general]{Installation!von Bacula }
+\index[general]{Bacula installieren }
+\addcontentsline{toc}{section}{Bacula installieren}
+
+\subsection*{Allgemeines}
+\index[general]{Allgemeines }
+\addcontentsline{toc}{subsection}{Allgemeines}
+
+Normalerweise benötigen Sie ein Release mit Baculas Quellcode und, wenn ein Windows-Client benutzt werde soll, ein ausführbares Release von Bacula für Windows. Entprechend Ihrer Konfigurationsoptionen benötigt Bacula bestimmte Pakete von Drittanbietern (wie z.B. {\bf SQLite}, {\bf MySQL} oder {\bf PostgreSQL}) zur Kompilierung. Um Ihnen die Arbeit zu erleichtern, haben wir einige dieser Softwarepakete als zwei {\bf depkgs}-Releases veröffentlicht (Dependency Packages). Dies kann Ihr Leben ungemein erleichtern, da Sie so mit allen notwendigen Pakaten versorgt anstatt gezwungen sind, sie selbst einzeln im Internet zu finden und zu installieren.
\subsection*{Source Release Files}
\index[general]{Source Files}
\index[general]{Release Files}
\addcontentsline{toc}{subsection}{Source Release File}
-Beginning with Bacula 1.38.0, the source code has been broken into
-four separate tar files each corresponding to a different module in
-the Bacula CVS. The released files are:
+
+Seit Baculas Version 1.38.0 ist der Quellcode in vier einzelne Tar-Dateien aufgeteilt, die jeweils einem Modul in Baculas CVS entsprechen. Im einzelnen sind dies:
\begin{description}
\item [bacula-1.38.0.tar.gz]
- This is the primary source code release for Bacula. On each
- release the version number (1.38.0) will be updated.
+Dies ist Baculas Quellcode. Mit jedem Release erhöht sich die Versionsnummer.
\item [bacula-docs-1.38.0.tar.gz]
- This file contains a copy of the docs directory with the
- documents prebuild. English html directory, single html
- file, and pdf file. The French and German translations
- are in progress, but are not built.
+Diese Datei enthält eine Kopie des Verzeichnisses der Dokumente im CVS. Einige Dokumente sind vorkompiliert. Für Englisch existiert ein HTML-Verzeichnis, ein einzelnes HTML-File und eine PDF-Datei. Die französische und die deutsche Übersetzung sind in Arbeit, aber nicht kompiliert.
\item [bacula-gui-1.38.0.tar.gz]
- This file contains the non-core GUI programs. Currently,
- it contains bacula-web, a PHP program for producing management
- viewing of your Bacula job status in a browser; and bimagemgr
- a browser program for burning CDROM images with Bacula Volumes.
+Diese Datei enthält grafische Benutzeroberflächen, die nicht Bestandteil des Hauptprogrammes sind. Momentan sind dies ``bacula-web'' zur Generierung von Verwaltungsansichten Ihrer Bacula-Jobs innerhalb eines Web-Browsers und ``bimagemgr'', ein Dateibrowser, der verwendet wird, um aus Bacula-Volumes CD-Images zu brennen.
\item [bacula-rescue-1.8.1.tar.gz]
- This is the Bacula Rescue CDROM code. Note, the version number
- of this package is not tied to the Bacula release version, so
- it will be different. Using this code, you can burn a CDROM
- with your system configuration and containing a statically
- linked version of the File daemon. This can permit you to easily
- repartition and reformat your hard disks and reload your
- system with Bacula in the case of a hard disk failure.
+Dies ist der Code für die Bacula Rettungs-CD. Die Versionsnummer diese Paketes ist nicht an die Versionsummer von Bacula gebunden und wird sich daher unterscheiden. Mit diesem Code können Sie eine CD brennen, die unter anderem eine Beschreibung Ihrer Systemkonfiguration und die statisch gelinkte Version des File-Dämons enthält. Damit können Sie im Falle eines Festplattenausfalles mit Hilfe von Bacula Ihre Festplatten neu partitionieren, formatieren und Ihr System auf einfache Art wiederherstellen.
\end{description}
+
\label{upgrading1}
-\subsection*{Upgrading Bacula}
-\index[general]{Bacula!Upgrading }
-\index[general]{Upgrading Bacula }
-\addcontentsline{toc}{subsection}{Upgrading Bacula}
-
-If you are upgrading from one Bacula version to another, you should first
-carefully read the ReleaseNotes of all versions between your current version
-and the version to which you are upgrading. If the Bacula catalog database has
-been upgraded, you will either need to reinitialize your database starting
-from scratch, or save an ASCII copy of your database, then proceed to upgrade
-it. This is normally done after Bacula is build and installed by:
+
+\subsection*{Bacula upgraden}
+\index[general]{Bacula!als Upgrade }
+\index[general]{Bacula upgraden }
+\addcontentsline{toc}{subsection}{Bacula upgraden}
+
+Wenn Sie Bacula von einer Version auf die nächste upgraden, sollten Sie erst die ReleaseNotes aller Versionen zwischen Ihrer laufenden und jener, auf die sie upgraden wollen, sorgfältig lesen. Wenn die Bacula Catalog-Datenbank upgegraded wurde, müssen Sie entweder ganz von vorne anfangen und Ihre Datenbank neu initialisieren oder diese als ASCII-Datei sichern und dann mit dem Upgrade fortfahren.
+Dies geschieht normalerweise nachdem Bacula kompiliert und installiert ist durch Eingabe von:
\begin{verbatim}
cd <installed-scripts-dir> (default /etc/bacula)
./update_bacula_tables
\end{verbatim}
-This update script can also be find in the Bacula source src/cats
-directory.
+Dieses Update-Skript finden Sie auch in Baculas Quellcode im Verzeichnis ``src/cats'':
-If there are several database upgrades between your version and the
-version to which you are upgrading, you will need to apply each database
-upgrade script. For your convenience, you can find all the old upgrade scripts
-in the {\bf upgradedb} directory of the source code. You will need to edit the
-scripts to correspond to your system configuration. The final upgrade script,
-if any, can be applied as noted above.
+Gab es zwischen Ihrer Version und der aktuellen mehrere Datenbank-Upgrades, werden Sie jedes einzelne Datenbank Upgradeskript ausführen müssen. Um Ihnen dies zu erleichtern, sind alle alten Upgrade-Skripte im Verzeichnis {\bf upgradedb} des Quellcodes. Sie werden diese Skripte den Gegebenheiten Ihrer Systemkonfiguration anpassen müssen.
-If you are upgrading from one major version to another, you will need to
-replace all your components at the same time as generally the inter-daemon
-protocol will change. However, within any particular release (e.g. version
-1.32.x) unless there is an oversight or bug, the daemon protocol will not
-change. If this is confusing, simply read the ReleaseNotes very carefully as
-they will note if all daemons must be upgraded at the same time.
+Das letzte Upgrade-Skript (wenn vorhanden) wird dann so ausgeführt, wie es oben beschrieben ist.
-Finally, please note that in general it is not necessary to do a
-{\bf make uninstall} before doing an upgrade. In fact, if you do so, you will
-most likely delete all your conf files, which could be disastrous.
-The normal procedure during an upgrade is simply {\bf make install}.
-In general none of your existing .conf or .sql files will be overwritten.
+Wenn Sie von einer Hauptversion auf die nächste upgraden, müssen alle Komponenten gleichzeitig ersetzt werden, da sich in der Regel das Übertragungs-Protokoll zwischen den Dämonen ändert. Innerhalb eines bestimmten Release (z.B. Version 1.32.x) wird sich das Dämon-Protokoll jedoch nicht ändern solange nicht ein Bug oder ein Versehen zu beheben ist. Wenn das alles für Sie verwirrend ist, lesen Sie einfach die ReleaseNotes sehr sorgfältig. Es wird hier stehen, wenn alle Dämonen gleichzeitig upgegraded werden müssen.
-For additional information on upgrading, please see the \ilink{Upgrading Bacula
-Versions}{upgrading} in the Tips chapter of this manual.
+Beachten Sie schließlich, dass es in der Regel nicht notwendig ist, vor dem Upgrade ein {\bf make uninstall} auszuführen. Tatsächlich werden Sie so sehr wahrscheinlich alle ihre Konfigurationsdateien zerstören, was verheerend sein könnte.
+Die normale Upgrade-Prozedur besteht einfach in der Eingabe von {\bf make install}.
+Im allgemeinen werden dabei keine Ihrer ``.conf''- oder ``.sql''-Dateien überschrieben.
+ Weiteres zum Upgraden lesen sie im Abschnitt \ilink{Upgrading Bacula Versions}{upgrading} im Kapitel ``Tips'' in diesem Handbuch.
-\subsection*{Dependency Packages}
+\subsection*{Dependency-Packages}
\label{Dependency}
-\index[general]{Dependency Packages }
+\index[general]{Dependency-Packages }
\index[general]{Packages!Dependency }
-\addcontentsline{toc}{subsection}{Dependency Packages}
+\addcontentsline{toc}{subsection}{Dependency-Packages}
-As discussed above, we have combined a number of third party packages that
-Bacula might need into the {\bf depkgs} and {\bf depkgs1} releases. You can,
-of course, get the latest packages from the original authors. The locations of
-where we obtained the packages are in the README file in each package.
-However, be aware that the packages in the depkgs files have been tested by us
-for compatibility with Bacula.
+Wie oben erwähnt, haben wir einige Pakete von Drittanbietern, die Bacula möglicherweise benötigt, in den Releases {\bf depkgs} und {\bf depkgs1} zusammengefasst. Natürlich können Sie sich auch die neuesten Versionen von den Original-Autoren besorgen. Die Quellen der einzelnen Pakete stehen in der README-Datei jedes einzelnen Paketes. Beachten Sie jedoch, dass die Pakete der \textbf{depkgs}-Dateien von uns auf ihre Kompatibilität zu Bacula getestet wurden.
-Typically, a dependency package will be named {\bf depkgs-ddMMMyy.tar.gz} and
-{\bf depkgs1-ddMMyy.tar.gz} where {\bf dd} is the day we release it, {\bf MMM}
-is the abbreviated month (e.g. Jan), and {\bf yy} is the year. An actual
-example is: {\bf depkgs-07Apr02.tar.gz}. To install and build this package (if
-needed), you do the following:
+Typischerweise heißen die Dependency-Packages {\bf depkgs-ddMMMyy.tar.gz} und
+{\bf depkgs1-ddMMyy.tar.gz} wobei {\bf dd} der Tag, {\bf MMM} der Monat in abgekürzter Form (z.B. ``Jan'') und {\bf yy} das Jahr ist, an dem es herausgegeben wurde. Ein aktuelles Beispiel ist: {\bf depkgs-07Apr02.tar.gz}. Um es zu installiern und zu kompilieren (wenn es benötigt wird) gehen Sie wie folgt vor:
\begin{enumerate}
-\item Create a {\bf bacula} directory, into which you will place both the
- Bacula source as well as the dependency package.
-\item Detar the {\bf depkg} into the {\bf bacula} directory.
+\item Erstellen sie ein {\bf bacula}-Verzeichnis, in das Sie sowohl die Bacula-Quelldateien als auch das Dependency-Packages legen.
+\item Entpacken Sie das {\bf depkg} mit ``detar'' in das {\bf bacula}-Verzeichnis.
\item cd bacula/depkgs
\item make
-\end{enumerate}
+ \end{enumerate}
-Although the exact composition of the dependency packages may change from time
-to time, the current makeup is the following:
+Die genaue Zusanmmensetzung der Dependency-Packages wird sich von Zeit zu Zeit ändern. Momentan sehen sie so aus:
-\addcontentsline{lot}{table}{Dependency Packages}
+\addcontentsline{lot}{table}{Dependency-Packages}
\begin{longtable}{|l|l|l|l|}
\hline
-\multicolumn{1}{|c| }{\bf 3rd Party Package } & \multicolumn{1}{c| }{\bf
+\multicolumn{1}{|c| }{\bf Drittanbieterpaket } & \multicolumn{1}{c| }{\bf
depkgs } & \multicolumn{1}{c| }{\bf depkgs1 } & \multicolumn{1}{c| }{\bf
depkgs-win32 } \\
\hline {SQLite } & \multicolumn{1}{c| }{X } & \multicolumn{1}{c| }{- } &
\end{longtable}
-Note, some of these packages are quite large, so that building them can be a
-bit time consuming. The above instructions will build all the packages
-contained in the directory. However, when building Bacula, it will take only
-those pieces that it actually needs.
-Alternatively, you can make just the packages that are needed. For example,
+Beachten Sie, dass einige dieser Pakete recht umfangreich sind, so dass ihre Compilierung einige Zeit beanspruchen kann. Mit den obigen Anweisungen werden alle Pakete im entsprechenden Verzeichnis kompiliert. Bacula wird allerdings bei seine Kompilierung nur jene Teile verwenden, die es tatsächlich benötigt.
+
+Alternativ können Sie nur jene Pakete kompilieren, die Sie tatsächlich benötigen. Beispielsweise wird
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-will configure and build only the SQLite package.
+nur das ``SQLite''-Paket konfigurieren und kompilieren.
-You should build the packages that you will require in {\bf depkgs} and/or
-{\bf depkgs1} prior to configuring and building Bacula, since Bacula will need
-them during the build process.
+Sie sollten die benötigten Pakete aus {\bf depkgs} und/oder {\bf depkgs1} kompilieren bevor Sie Bacula konfigurieren und kompilieren, da Bacula diese während seiner eigenen Kompilierung benötigt.
-Even if you do not use SQLite, you might find it worthwhile to build {\bf mtx}
-because the {\bf tapeinfo} program that comes with it can often provide you
-with valuable information about your SCSI tape drive (e.g. compression,
-min/max block sizes, ...).
+Auch wenn Sie SQLite nicht verwenden, könnte es sich für Sie lohnen {\bf mtx} zu kompilieren, da das enthaltenen {\bf tapeinfo}-Programm oft wertvolle Informationen über Ihr SCSI-Bandlaufwerk (z.B. Kompression, min./max. Blockgröße...) liefern kann.
-The {\bf depkgs-win32} package contains the source code for the pthreads,
-zlib, and wxWidgets libraries used by the native Win32 client program. It
-will only be needed if you intend to build the Win32 client from source.
+Das {\bf depkgs-win32}-Paket enthält den Qullcode der ``Pthreads''-, ``wxWidgets''- und ``zlib''-Bibliotheken, die das Win32-Clientprogramm verwendet. Man benötigt diese nur, wenn Sie das Win32-Programm selbst kompilieren wollen.
-\subsection*{Supported Operating Systems}
+\subsection*{Unterstützte Betriebssysteme}
\label{Systems}
-\index[general]{Systems!Supported Operating }
-\index[general]{Supported Operating Systems }
-\addcontentsline{toc}{subsection}{Supported Operating Systems}
+\index[general]{Betriebssysteme!Unterstützte }
+\index[general]{Unterstützte Betriebssysteme }
+\addcontentsline{toc}{subsection}{Unterstützte Betriebssysteme}
-Please see the
-\ilink{ Supported Operating Systems}{SupportedOSes} section
-of the QuickStart chapter of this manual.
+Lesen sie bitte den Abschnitt
+\ilink{Unterstützte Betriebssysteme}{SupportedOSes} im Kapitel
+``QuickStart'' dieses Handbuches.
-\subsection*{Building Bacula from Source}
+\subsection*{Bacula aus dem Quellcode kompilieren}
\label{Building}
-\index[general]{Source!Building Bacula from }
-\index[general]{Building Bacula from Source }
-\addcontentsline{toc}{subsection}{Building Bacula from Source}
+\index[general]{Quellcode!Kompilation von Bacula aus dem }
+\index[general]{Bacula aus dem Quellcode kompilieren}
+\addcontentsline{toc}{subsection}{Bacula aus dem Quellcode kompilieren}
-The basic installation is rather simple.
+Die Grundinstallation ist ziehmlich einfach.
\begin{enumerate}
-\item Install and build any {\bf depkgs} as noted above.
-\item Configure and install MySQL or PostgreSQL (if desired).
- \ilink{Installing and Configuring MySQL Phase I}{_ChapterStart} or
- \ilink{Installing and Configuring PostgreSQL Phase
- I}{_ChapterStart10}. If you are installing from rpms, and are
- using MySQL, please be sure to install {\bf mysql-devel}, so that the MySQL
- header files are available while compiling Bacula. In addition, the MySQL
- client library {\bf mysqlclient} requires the gzip compression library {\bf
- libz.a} or {\bf libz.so}. If you are using rpm packages, these libraries are
- in the {\bf libz-devel} package. On Debian systems, you will need to load the
- {\bf zlib1g-dev} package. If you are not using rpms or debs, you will need to
- find the appropriate package for your system.
-
- Note, if you already have a running MySQL or PostgreSQL on your system, you
- can skip this phase provided that you have built the thread safe libraries.
- And you have already installed the additional rpms noted above.
-
-\item As an alternative to MySQL and PostgreSQL, configure and install SQLite,
- which is part of the {\bf depkgs}.
- \ilink{Installing and Configuring SQLite}{_ChapterStart33}.
-
-\item Detar the Bacula source code preferably into the {\bf bacula} directory
- discussed above.
-
-\item {\bf cd} to the directory containing the source code.
-
-\item ./configure (with appropriate options as described below)
-
-\item Check the output of ./configure very carefully, especially the Install
- binaries and Install config directories. If they are not correct,
- please rerun ./configure until they are. The output from ./configure is
- stored in {\bf config.out} and can be re-displayed at any time without
- rerunning the ./configure by doing {\bf cat config.out}.
-
-\item If after running ./configure once, you decide to change options and
- re-run it, that is perfectly fine, but before re-running it, you should run:
-
+\item Installieren und kompilieren sie alle benötgten {\bf depkgs} wie oben beschrieben.
+\item Konfigurieren und installieren Sie ``MySQL'' oder ``PostgreSQL'' (wenn gewünscht)
+\ilink{Installation und Konfiguration von MySQL Phase I}{_ChapterStart} oder
+\ilink{Installation und Konfiguration von PostgreSQL Phase I}{_ChapterStart10}. Wenn Sie für die Installation von ``MySQL'' ein RPM verwenden, müssen Sie auch {\bf mysql-devel} installieren, so dass die Header-Dateien verfügbar sind, wenn Sie Bacula kompilieren. Zusätzlich erfordert die MySQL Client-Bibliothek die gzip-Kompressionsbibliotheken {\bf libz.a} oder {\bf libz.so}. Wenn Sie RPM-Pakete verwenden, sind diese Bibliotheken im Paket {\bf zlib1g-dev}. Auf Debian-Systemen müssen Sie das {\bf zlib1g-dev}-Paket laden. Wenn Sie weder RPMs noch debs verwenden, müssen Sie die passenden Pakete für Ihr System selbst finden.
+Wenn auf Ihrem System schon MySQL oder PostgreSQL läuft, können Sie diese Phase überspringen, wenn Sie ``thread safe''-Bibliotheken kompiliert und die oben erwähnten zusätzlichen RPMs installiert haben.
+
+\item Anstatt ``MySQL'' und ``PostgreSQL'' können Sie auch SQLite konfigurieren und installieren \ilink{Installation und Konfiguration von SQLite}{_ChapterStart33}. Dessen Quellcode ist Teil des {\bf depkgs}-Paketes.
+\item Entpacken sie Baculas Quellcode vorzugsweise in das {\bf bacula}-Verzeichnis, welches oben erwähnt wurde.
+\item Wechseln ({\bf cd}) Sie in das Verzeichnis mit dem Quellcode.
+\item Führen Sie \textbf{./configure} aus (mit den entsprechenden Konfigurationsoptionen, die weiter unten näher beschrieben sind.
+\item Prüfen Sie die Ausgabe des \textbf{./configure}-Befehls sehr sorgfältig, besonders die Ausgaben zum Installationsverzeichnis der Programm- und der Konfigurationsdateien. Sind diese nicht korrekt, wiederholen Sie \textbf{./configure} bis sie stimmen. Die Ausgabe des ./configure-Befehls ist in der Datei {\bf config.out} abgespeichert und kann jederzeit wieder angesehen werden, ohne \textbf{./configure} neu zu starten, indem man {\bf cat config.out} eingibt.
+\item Wenn Sie Optionen ändern, nachdem \textbf{./configure} gelaufen war und Sie es neu starten müssen, geben Sie vorher das folgende ein.
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-so that you are sure to start from scratch and not have a mixture of the two
-options. This is because ./configure caches much of the information. The {\bf
-make distclean} is also critical if you move the source directory from one
-machine to another. If the {\bf make distclean} fails, just ignore it and
-continue on.
+Damit gehen Sie sicher, dass Sie wirklich von vorne anfangen und keine Mischung der verschiedenen Optionen haben. Dies liegt daran, dass \textbf{./configure} einen Großteil der Informationen zwischenspeichert. {\bf make distclean} ist auch sehr wichtig, wenn Sie die Quellverzeichnisse auf einen anderen Rechner verlagern. Schlägt der Befehl fehl, ignorieren Sie das einfach und machen mit
\item make
- If you get errors while linking in the Storage daemon directory
- (src/stored), it is probably because you have not loaded the static
- libraries on your system. I noticed this problem on a Solaris system.
- To correct it, make sure that you have not added {\bf
- {-}{-}enable-static-tools} to the {\bf ./configure} command.
+
+weiter.
+
+Wenn es hierbei Fehlermeldungen beim Linken in das Verzeichnis (src/stored) des Storage-Dämon gibt, liegt es vielleicht daran, dass sie die statischen Bibliotheken in Ihrem System nicht geladen sind. Diese Problem bemerkte ich auf einem Solaris-System. Verwenden sie den {\bf ./configure}-Befehl ohne die Option {\bf \verb{--{enable-static-tools} um den Fehler zu beheben.
\item make install
-\item If you are new to Bacula, we {\bf strongly} recommend that you skip
- the next step and use the default configuration files, then run the
- example program in the next chapter, then come back and modify your
- configuration files to suit your particular needs.
-
-\item Customize the configuration files for each of the three daemons
- (Directory, File, Storage) and for the Console program. For the details
- of how to do this, please see \ilink{Setting Up Bacula Configuration
- Files}{_ChapterStart16} in the Configuration chapter of this manual. We
- recommend that you start by modifying the default configuration files
- supplied, making the minimum changes necessary. Complete customization
- can be done after you have Bacula up and running. Please take care when
- modifying passwords, which were randomly generated, and the {\bf Name}s
- as the passwords and names must agree between the configuration files
- for security reasons. \item Create the Bacula MySQL database and tables
- (if using MySQL)
- \ilink{Installing and Configuring MySQL Phase II}{mysql_phase2} or
- create the Bacula PostgreSQL database and tables
- \ilink{Installing and Configuring PostgreSQL Phase
- II}{PostgreSQL_phase2} or alternatively if you are using
- SQLite
- \ilink{Installing and Configuring SQLite Phase II}{phase2}.
-
-\item Start Bacula ({\bf ./bacula start}) Note. the next chapter shows you
- how to do this in detail.
-
-\item Interface with Bacula using the Console program
-
-\item For the previous two items, please follow the instructions in the
- \ilink{Running Bacula}{_ChapterStart1} chapter of this manual,
- where you will run a simple backup and do a restore. Do this before you make
- heavy modifications to the configuration files so that you are sure that
- Bacula works and are familiar with it. After that changing the conf files
- will be easier.
-\item If after installing Bacula, you decide to "move it", that is to
- install it in a different set of directories, proceed as follows:
+\item
+Wenn Sie ein Bacula-Neuling sind, empfehlen wir \textbf{dringend}, den nächsten Schritt zu überspringen und die Vorgabe-Konfigurationsdateien zu verwenden. Probieren Sie damit das Beispiel im nächsten Kapitel aus und ändern sie danach Ihre Konfigurationsdateien, so dass sie Ihren eigenen Anforderungen entsprechen.
+
+\item Passen Sie die Konfigurationsdateien aller drei Dämonprozesse und die des Console-Programms an. Einzelheiten hierzu im Abschnitt \ilink{Setting Up Bacula Configuration Files}{_ChapterStart16} des Kapitels ``Konfiguration'' in diesem Handbuch. Wir empfehlen Ihnen, an den beigefügten Vorgabe-Konfigurationsdateien zunächst nur soviel zu ändern wie unbedingt notwendig ist. Eine endgültige Anpassung ist immer noch möglich, wenn Bacula zuverlässig läuft. Passen Sie bitte auf, wenn sie die (zufällig generierten) Passwörter und die {\bf Name}n verändern. Aus Sicherheitsgründen müssen diese in den Konfigurationsdateien übereinstimmen.
+
+\item Erzeugen Sie die Datenbank und die Tabellen für Bacula in MySQL (wenn sie MySQL verwenden)(\ilink{MySQL installieren und Konfigurieren Phase II}{mysql_phase2}, in PostgreSQL (\ilink{PostgreSQL installieren und Konfigurieren Phase II}{PostgreSQL_phase2}) oder gegebenenfalls in SQLite (\ilink{SQLite installieren und Konfigurieren Phase II}{phase2}).
+
+\item Starten Sie Bacula ({\bf ./bacula start}). Im nächsten Kapitel wird dies im einzelnen erklärt.
+\item Kommunizieren Sie mit Bacula über das Console-Programm.
+
+\item Folgen Sie für die letzten beiden Punkte den Anweisungen im Kapitel \ilink{Running Bacula}{_ChapterStart1} diese Handbuches, wo Sie eine einfache Sicherung und eine Wiederherstellung durchführen. Tun Sie dies bevor Sie die Konfiguratinsdateien in größerem Umfang verändern, so dass Sie sicher sein können, dass Bacula funktioniert und Sie damit vertraut sind. Danach wird es einfacher sein, die Konfigurationsdateien anzupassen.
+
+\item Wenn Sie nach der Installation beschließen, mit Bacula ``umzuziehen'', d.h. es in anderen Verzeichnissen installieren zu wollen, gehen Sie wie folgt vor:
\footnotesize
\begin{verbatim}
make uninstall
make distclean
- ./configure (your-new-options)
+ ./configure (mit-den-neuen-Optionen)
make
make install
-
\end{verbatim}
\normalsize
\end{enumerate}
-If all goes well, the {\bf ./configure} will correctly determine which
-operating system you are running and configure the source code appropriately.
-Currently, FreeBSD, Linux (RedHat), and Solaris are supported. MacOS X 10.3 is
-reported to work with the Client only as long as readline support is disabled.
+Wenn alles gut geht, wird der {\bf ./configure}-Prozess Ihr laufendes Betriebssystem korrekt erkennen und den Quellcode entsprechend konfigurieren. Momentan werden FreeBSD, Linux (Red Hat) und Solaris unterstützt. Von MacOS X 10.3 wird berichtet, dass der Client nur dann darauf läuft, wenn die readline-Unterstützung deaktiviert ist.
-
-If you install Bacula on more than one system, and they are identical, you can
-simply transfer the source tree to that other system and do a "make
-install". However, if there are differences in the libraries or OS versions,
-or you wish to install on a different OS, you should start from the original
-compress tar file. If you do transfer the source tree, and you have previously
-done a ./configure command, you MUST do:
+Wenn Sie Bacula auf mehr als einem System installieren, können Sie einfach den Verzeichnisbaum des Quellcodes auf den anderen Rechner übertragen und ein ``make install'' ausführen. Gibt es jedoch Unterschiede in den Bibliotheken, den Betriebssystemversionen oder soll es auf einem anderen Betriebssystem installiert werden, sollten Sie mit der originalen tar-Datei beginnen. Wenn Sie die Verzeichnisstruktur des Quellcodes übertragen und den ./configure-Befehl schon ausgeführt haben, müssen Sie unbedingt
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-prior to doing your new ./configure. This is because the GNU autoconf tools
-cache the configuration, and if you re-use a configuration for a Linux machine
-on a Solaris, you can be sure your build will fail. To avoid this, as
-mentioned above, either start from the tar file, or do a "make distclean".
+ausführen, bevor Sie ``./configure'' erneut aufrufen. Dies liegt daran, dass ``GNU autoconf'' die Konfiguration zwischenspeichert und wenn Sie beispielsweise die Konfiguration eines Linux-Rechners auf einem Solaris-System wiederverwenden, können Sie sicher sein, dass die Kompilierung fehlschlägt. Um dies zu vermeiden starten Sie entweder mit der tar-Datei oder führen ``make distclean'' aus, wie oben erwähnt.
-In general, you will probably want to supply a more complicated {\bf
-configure} statement to ensure that the modules you want are built and that
-everything is placed into the correct directories.
+Gewöhnlich werden Sie einen etwas komplizierteren {\bf configure}-Befehl absetzen wollen, um sicher zu gehen, dass die von Ihnen gewünschten Module kompiliert werden und alles in den richtigen Verzeichnissen abgelegt wird.
-For example, on RedHat, one could use the following:
+Auf RedHat zum Beispiel könnte ``./configure'' so aussehen:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-Note, the advantage of using the above configuration to start is that
-everything will be put into a single directory, which you can later delete
-once you have run the examples in the next chapter and learned how Bacula
-works. In addition, the above can be installed and run as non-root.
-For the developer's convenience, I have added a {\bf defaultconfig} script to
-the {\bf examples} directory. This script contains the statements that you
-would normally use, and each developer/user may modify them to suit his needs.
-You should find additional useful examples in this directory as well.
+Beachten Sie bitte, dass der Vorteil der Verwendung der obigen Konfiguration für den Anfang darin liegt, dass hierbei alles in ein einziges Verzeichnis geschrieben wird, welches später gelöscht werden kann, wenn Sie die Beispiele des nächsten Kapitels ausgeführt und gelernt haben wie Bacula funktioniert. Ausserdem kann das Obige auch ohne root-Rechte installiert und ausgeführt werden.
+
+Um den Entwicklern die Arbeit zu erleichtern, haben wir dem Verzeichnis {\bf examples} ein {\bf defaultconfig}-Skript beigefügt. Diese Skript enthält alle Statements, die man normalerweise benutzt und jeder Entwickler oder Benutzer kann sie nach seinen Bedürfnissen verändern. In diesem Verzeichnis sind auch andere nützliche Beispiele.
-The {\bf \verb:--:enable-conio} or {\bf \verb:--:enable-readline} options are useful because
-they provide a command line history and editing capability for the Console
-program. If you have included either option in the build, either the {\bf
-termcap} or the {\bf ncurses} package will be needed to link. On some systems,
-such as SuSE, the termcap library is not in the standard library directory. As
-a consequence, the option may be disabled or you may get an error message such
-as:
+Die \textbf{./configure}-Schalter {\bf \verb{--{enable-conio} oder {\bf \verb{--{enable-readline} sind nützlich, da man dadurch eine Kommandozeilen-History und ein Editorfunktionen für die Kommandozeile des Console-Programms erhält. Wenn Sie eine dieser Optionen verwenden, benötigen Sie beim Linken entweder das {\bf termcap}- oder das {\bf ncurses}-Paket. Auf manchen Systemen wie z.B. ``SuSE'' ist die termcap-Bibliothek nicht im Verzeichnis der Standard-Bibliotheken. Daher kann diese Option wirkungslos sein oder Sie erhalten folgende Fehlermeldung
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-while building the Bacula Console. In that case, you will need to set the {\bf
-LDFLAGS} environment variable prior to building.
+während Sie die Bacula-Console kompilieren. In diesem Fall müsssen Sie die {\bf
+LDFLAGS}-Umgebungsvariable vor der Kompilierung wie folgt setzen:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-The same library requirements apply if you wish to use the readline
-subroutines for command line editing and history or
- if you are using a MySQL library that requires encryption. If you need encryption,
-you can either export the appropriate additional library options as shown
-above or, alternatively, you can include them directly on the ./configure line
-as in:
+Die gleichen Erfordernisse an die Systembibliothek gelten, wenn sie die ``Readline''-Subroutinen für das Editieren und die History der Kommandozeile benutzen wollen oder eine MySQL-Bibliothek, die Verschlüsselung erfordert. Wenn Sie Verschlüsselung benötigen, können Sie entweder die entsprechenden zusätzlichen Bibliotheks-Pfade wie oben gezeigt setzen oder wie unten gezeigt direkt in der Befehlzeile des Befehls mit angeben.
\footnotesize
\begin{verbatim}
LDFLAGS="-lssl -lcyrpto" \
./configure \
- <your-options>
+ <Ihre-Optionen>
\end{verbatim}
\normalsize
-On some systems such as Mandriva, readline tends to
-gobble up prompts, which makes it totally useless. If this happens to you, use
-the disable option, or if you are using version 1.33 and above try using {\bf
-\verb:--:enable-conio} to use a built-in readline replacement. You will still need
-either the termcap or the ncurses library, but it is unlikely that the {\bf conio}
-package will gobble up prompts.
+Auf manchen Systemen wie Mandriva neigt ``readline'' dazu, die Eingaben zu verstümmeln, was es völlig unbrauchbar macht. Wenn das bei Ihnen geschieht, wählen Sie die Option ab oder, wenn Sie Version 1.33 oder höher verwenden, versuchen Sie mit der Option \verb{--{enable-conio den eingebauten ``readline''-Ersatz zu verwenden. Auch hierzu werden Sie entweder die ``termcap''- oder ``ncurses''-Bibliothek benötigen, doch es ist unwahrscheinlich, dass das {\bf conio}-Paket Ihre Eingaben dann verstümmelt.
-readline is no longer supported after version 1.34. The code is still
-available and if users submit patches for it, I will be happy to apply them.
-However, due to the fact that each version of readline seems to be
-incompatible with previous versions, and that there are significant
-differences between systems, I can no longer afford to support it.
+``readline'' wird ab Version 1.34. nicht weiter unterstützt. Der Code ist noch verfügbar und wenn Benutzer dafür Patches schicken, wird es mir ein Vergnügen sein, diese einzubauen. Da jedoch jede Version von ``readline'' mit den Vorgängerversionen inkompatibel zu sein scheint und zwischen den Systemen wesentliche Unterschiede bestehen, kann ich es mir nicht mehr länger leisten, es zu unterstützen.
-\subsection*{What Database to Use?}
+\subsection*{Welches Datenbanksystem soll verwendet werden?}
\label{DB}
-\index[general]{What Database to Use? }
-\index[general]{Use!What Database to }
-\addcontentsline{toc}{subsection}{What Database to Use?}
-
-Before building Bacula you need to decide if you want to use SQLite, MySQL, or
-PostgreSQL. If you are not already running MySQL or PostgreSQL, you might
-want to start by testing with SQLite. This will greatly simplify the setup for you
-because SQLite is compiled into Bacula an requires no administration. It
-performs well and is suitable for small to medium sized installations (maximum
-10-20 machines). However, we should note that a number of users have
-had unexplained database corruption with SQLite. For that reason, we
-recommend that you install either MySQL or PostgreSQL for production
-work.
-
-If you wish to use MySQL as the Bacula catalog, please see the
-\ilink{Installing and Configuring MySQL}{_ChapterStart} chapter of
-this manual. You will need to install MySQL prior to continuing with the
-configuration of Bacula. MySQL is a high quality database that is very
-efficient and is suitable for any sized installation. It is slightly more
-complicated than SQLite to setup and administer because it has a number of
-sophisticated features such as userids and passwords. It runs as a separate
-process, is truly professional and can manage a database of any size.
-
-If you wish to use PostgreSQL as the Bacula catalog, please see the
-\ilink{Installing and Configuring PostgreSQL}{_ChapterStart10}
-chapter of this manual. You will need to install PostgreSQL prior to
-continuing with the configuration of Bacula. PostgreSQL is very similar to
-MySQL, though it tends to be slightly more SQL92 compliant and has many more
-advanced features such as transactions, stored procedures, and the such. It
-requires a certain knowledge to install and maintain.
-
-If you wish to use SQLite as the Bacula catalog, please see
-\ilink{Installing and Configuring SQLite}{_ChapterStart33} chapter of
-this manual.
+\index[general]{Welches Datenbanksystem soll verwendet werden? }
+\index[general]{verwenden!Welches Datenbanksystem }
+\addcontentsline{toc}{subsection}{Welches Datenbanksystem soll verwendet werden?}
+
+Vor der Kompilierung von Bacula müssen Sie sich entscheiden, ob Sie SQLite, MySQL oder
+PostgreSQL verwenden werden. Wenn bei Ihnen nicht sowieso schon MySQl oder PostgrSQL läuft, empfehlen wir versuchsweise mit SQLite zu beginnen. Dies wird Ihnen die Einrichtung wesentlich erleichtern, da SQLite in Bacula hineinkompiliert wird und keine Administration erfordert. Es hat hat eine ganz ordentliche Performanz und ist für kleine bis mittlere Installationen gut geeignet (maximal 10 bis 20 Rechner).
+Allerdings sollten wir erwähnen, dass einige unserer Benutzer mit SQLite unerklärliche Datenbankkorruptionen hatten. Für ein Produktiv-System empfehlen wir daher die Installation von MySQL oder PostgreSQL:
+
+Wenn Sie für den Bacula-Catalog MySQL verwenden wollen, lesen Sie bitte das Kapitel \ilink{MySQL installieren und konigurieren}{_ChapterStart} in diesem Handbuch. Sie werden hierzu MySQL installieren müssen, bevor Sie Bacula konfigurieren. MySQL ist ein Datenbanksystem von hoher Qualität, das sehr effizient arbeitet und für Installationen jeder Größe geeignet ist. Seine Einrichtung und Administration sind ein wenig komplizierter als die von SQLite, da es einige Besonderheiten wie userids und Passwörter bietet. Es läuft als eigenständiger Prozess, ist wirklich professionell und kommt mit Datenbanken jeder Größe zurecht.
+
+Wenn Sie PostgreSQL als Bacula-Catalog verwenden wollen, lesen Sie bitte das Kapitel \ilink{PostgreSQL installieren und konfigurieren}{_ChapterStart10} in diesem Handbuch. Bevor Bacula konfiguriert wird, muss PostgreSQl installiert sein. Es ist MySQL sehr ähnlich, dabei aber eher etwas mehr SQL92-kompatibel und hat viele Features wie ``Transaktionen'', ``Stored Procedures'' und ähnliches. Man braucht eine gewisses Erfahrung, um es zu installieren und zu warten.
+
+Wenn Sie als Bacula Catalog SQLite verwenden wollen, lesen Sie bitte das Kapitel \ilink{SQLite installieren und konfigurieren}{_ChapterStart33} in diesem Handbuch.
\subsection*{Quick Start}
\index[general]{Quick Start }
\index[general]{Start!Quick }
\addcontentsline{toc}{subsection}{Quick Start}
-There are a number of options and important considerations given below
-that you can skip for the moment if you have not had any problems building
-Bacula with a simplified configuration as shown above.
-
-If the ./configure process is unable to find specific libraries (e.g.
-libintl, you should ensure that the appropriate package is installed on
-your system. Alternatively, if the package is installed in a non-standard
-location (as far as Bacula is concerned), then there is generally an
-option listed below (or listed with "./configure {-}{-}help" that will
-permit you to specify the directory that should be searched. In other
-cases, there are options that will permit you to disable to feature
-(e.g. {-}{-}disable-nls).
-
-If you want to dive right into it, we recommend you skip to the next chapter,
-and run the example program. It will teach you a lot about Bacula and as an
-example can be installed into a single directory (for easy removal) and run as
-non-root. If you have any problems or when you want to do a real installation,
-come back to this chapter and read the details presented below.
-
-\subsection*{Configure Options}
+Unten werden nun einige Optionen und wichtige Vorüberlegungen ausgeführt, die Sie jedoch für den Moment überspringen können, wenn Sie mit der vereinfachten Konfiguration, wie sie oben gezeigt wurde, keine Probleme hatten.
+
+Falls der ``./configure''-Prozess bestimmte Bibliotheken (z.B. ``libintl'') nicht findet, vergewissern Sie sich, dass das entsprechende Paket auf Ihrem Rechner installiert ist. Wenn das Paket an einem Ort installiert ist, denn Bacula nicht erwartet, kann in der Regel mit einem der im Folgenden aufgeführten Optionsschalter ein Suchpfad übergeben werden. "./configure {-}{-}help" liefert eine Liste aller Optionen. Das letzte Mittel ist, ein Feature durch einen entsprechenden Optionschalter zu deaktivieren (z.B. ``{-}{-}disable-nls'').
+
+Wenn Sie richtig loslegen wollen, empfehlen wir, zum nächsten Kapitel weitergehen und das Beispielprogramm zum Laufen zu bringen. Es wird Sie viel über Bacula lehren und kann zum Ausprobieren in ein einzelnes Verzeichnis installiert (um es auf einfache Art wieder löschen zu können) und ohne root-Rechte betrieben werden. Wenn irgendwelche Probleme auftreten oder Sie richtig installieren wollen, kehren Sie zu diesem Kapitel zurück und lesen Sie die Einzelheiten, die nun folgen.
+
+\subsection*{Konfigurationsoptionen}
\label{Options}
-\index[general]{Options!Configure }
-\index[general]{Configure Options }
-\addcontentsline{toc}{subsection}{Configure Options}
+\index[general]{Optionen!der Konfiguration }
+\index[general]{Konfigurationsoptionen }
+\addcontentsline{toc}{subsection}{Konfigurationsoptionen}
-The following command line options are available for {\bf configure} to
-customize your installation.
+Um Ihre Installation anzupassen, hat der {\bf configure}-Befehl die folgenden Kommandozeilen-Schalter.
\begin{description}
-\item [ {-}{-}sysbindir=\lt{}binary-path\gt{}]
- \index[general]{{-}{-}sysbindir }
- Defines where the Bacula binary (executable) files will be placed during a
- {\bf make install} command.
-\item [ {-}{-}sysconfdir=\lt{}config-path\gt{}]
- \index[general]{{-}{-}sysconfdir }
- Defines where the Bacula configuration files should be placed during a
- {\bf make install} command.
+\item [{-}{-}sysbindir=\lt{}Pfad/zu/den/Programmdateien\gt{}]
+ \index[general]{--sysbindir }
+Legt fest, in welches Verzeichnis die Bacula Programmdateien bei Ausführung des {\bf make install}-Befehls installiert werden.
+
+\item [{-}{-}sysconfdir=\lt{}Pfad/zu/den/Konfigurationsdateien\gt{}]
+ \index[general]{--sysconfdir }
+ Legt fest, in welches Verzeichnis die Bacula Konfigurationsdateien bei Ausführung des {\bf make install}-Befehls installiert werden.
\item [ {-}{-}mandir=\lt{}path\gt{}]
\index[general]{{-}{-}mandir}
- By default, Bacula will install a simple Unix man page in
- /usr/share/man. If you wish the man page to be installed in
- a different location, use this option to specify the path.
- Note, the main HTML and PDF Bacula documents are in a separate
- tar file that is not part of the source distribution.
+Vorgabemäßig installiert Bacula eine einfache Unix-manpage in ``/usr/share/man''. Soll die manpage an einen anderen Ort, können Sie mit dieser Option einen Pfad setzen. Beachten Sie bitte, dass die Bacula-Handbücher (HTML- und PDF-Dateien) Bestandteil eines eigenen tar-Files sind, das nicht Bestandteil des Quellcode-Releases ist.
\item [ {-}{-}datadir=\lt{}path\gt{}]
\index[general]{{-}{-}datadir}
- If you translate Bacula or parts of Bacula into a different language
- you may specify the location of the po files using the {\bf
- {-}{-}datadir} option. You must manually install any po files as
- Bacula does not (yet) automatically do so.
-
-
-\item [ {-}{-}enable-smartalloc ]
- \index[general]{{-}{-}enable-smartalloc }
- This enables the inclusion of the Smartalloc orphaned buffer detection
- code. This option is highly recommended. Because we never build
- without this option, you may experience problems if it is not enabled.
- In this case, simply re-enable the option. We strongly recommend
- keeping this option enabled as it helps detect memory leaks. This
- configuration parameter is used while building Bacula
-
-\item [ {-}{-}enable-gnome ]
- \index[general]{{-}{-}enable-gnome }
- If you have GNOME installed on your computer and you want to use the
- GNOME GUI Console interface to Bacula, you must specify this option.
- Doing so will build everything in the {\bf src/gnome-console} directory.
-
-\item [ {-}{-}enable-wx-console ]
- \index[general]{{-}{-}enable-wx-console }
- If you have wxWidgets installed on your computer and you want to use the
- wxWidgets GUI Console interface to Bacula, you must specify this option.
- Doing so will build everything in the {\bf src/wx-console} directory.
- This could also be useful to users who want a GUI Console and don't want
- to install Gnome, as wxWidgets can work with GTK+, Motif or even X11
- libraries.
-
-
-\item [ {-}{-}enable-tray-monitor ]
- \index[general]{{-}{-}enable-tray-monitor }
- If you have GTK installed on your computer, you run a graphical
- environment or a window manager compatible with the FreeDesktop system
- tray standard (like KDE and GNOME) and you want to use a GUI to monitor
- Bacula daemons, you must specify this option. Doing so will build
- everything in the {\bf src/tray-monitor} directory.
-
-\item [ {-}{-}enable-static-tools]
- \index[general]{{-}{-}enable-static-tools }
- This option causes the linker to link the Storage daemon utility tools
- ({\bf bls}, {\bf bextract}, and {\bf bscan}) statically. This permits
- using them without having the shared libraries loaded. If you have
- problems linking in the {\bf src/stored} directory, make sure you have
- not enabled this option, or explicitly disable static linking by adding
- {\bf \verb:--:disable-static-tools}.
-
-
-\item [ {-}{-}enable-static-fd]
- \index[general]{{-}{-}enable-static-fd }
- This option causes the make process to build a {\bf static-bacula-fd} in
- addition to the standard File daemon. This static version will include
- statically linked libraries and is required for the Bare Metal recovery.
- This option is largely superseded by using {\bf make static-bacula-fd}
- from with in the {\bf src/filed} directory. Also, the {\bf
- \verb:--:enable-client-only} option described below is useful for just
- building a client so that all the other parts of the program are not
- compiled.
-
- When linking a static binary, the linker needs the static versions
- of all the libraries that are used, so frequently users will
- experience linking errors when this option is used. The first
- thing to do is to make sure you have the static glibc library
- installed on your system. The second thing to do is the make sure
- you do not specify {\bf {-}{-}openssl} or {\bf {-}{-}with-python}
- on your ./configure statement as these options require additional
- libraries. You may be able to enable those options, but you will
- need to load additional static libraries.
-
-
-\item [ {-}{-}enable-static-sd]
- \index[general]{{-}{-}enable-static-sd }
- This option causes the make process to build a {\bf static-bacula-sd} in
- addition to the standard Storage daemon. This static version will
- include statically linked libraries and could be useful during a Bare
- Metal recovery.
-
- When linking a static binary, the linker needs the static versions
- of all the libraries that are used, so frequently users will
- experience linking errors when this option is used. The first
- thing to do is to make sure you have the static glibc library
- installed on your system. The second thing to do is the make sure
- you do not specify {\bf {-}{-}openssl} or {\bf {-}{-}with-python}
- on your ./configure statement as these options require additional
- libraries. You may be able to enable those options, but you will
- need to load additional static libraries.
+Wenn Sie Bacula oder Teile davon übersetzen wollen, können Sie die ``{\bf
+ {-}{-}datadir}''-Option verwenden um den Speicherort der ``po''-Dateien festzulegen. Die ``po''-Dateien müssen ``von Hand'' installiert werden, da Bacula dies (noch) nicht automatisch tut.
-
+\item [{-}{-}enable-smartalloc ]
+ \index[general]{--enable-smartalloc }
+ Damit wird der ``Smartalloc orphaned buffer detection code'' mit eingebunden. Diese Option ist dringend empfohlen. Da wir nie ohne diese Option kompilieren, werden Sie vielleicht Probleme haben, wenn sie nicht gesetzt ist. Wir empfehlen dringend, diesen Schalter gesetzt zu lassen, da er hilft, Memory-Leaks zu entdecken. Dieser Konfigurationsparameter wird bei der Kompilierung von Bacula benutzt.
+
+\item [{-}{-}enable-gnome ]
+ \index[general]{--enable-gnome }
+ Ist auf Ihrem Computer GNOME installiert und wollen Sie das grafische GNOME-Interface benutzen, setzen Sie diesen Schalter. Dadurch wird alles im Verzeichnis {\bf src/gnome-console} kompiliert.
+
+\item [{-}{-}enable-wx-console ]
+ \index[general]{--enable-wx-console }
+ Wenn auf Ihrem Rechner wxWidgets installiert ist und sie das grafische wxWidgets Console-Interface benutzen wollen, müssen Sie diesen Schalter setzen. Hierdurch wird alles im Verzeichnis {\bf src/wx-console} kompiliert. Dies kann auch für Benutzer hilfreich sein, die eine grafische Konsole benutzen, aber GNOME nicht installieren wollen, da wxWidgets mit GTK+-, Motif- und sogar X11-Bibliotheken läuft
+
+\item [{-}{-}enable-tray-monitor ]
+ \index[general]{--enable-tray-monitor }
+Wenn Sie auf Ihrem Rechner GTK installiert haben und eine grafische Umgebung oder einen Window-Manager benutzen, der dem Standard für die System-Tray von FreeDesktop entspricht (wie KDE oder GNOME) und wenn sie Ihre GUI benutzen wollen, um die Bacula-Dämonen zu überwachen, sollten sie diesen Schalter setzen. Ist er gesetzt, wird alles im Verzeichnis {\bf src/tray-monitor} kompiliert.
+
+\item [{-}{-}enable-static-tools]
+ \index[general]{--enable-static-tools }
+Durch Setzen dieses Schalters werden die Hilfsprogramme des Storage-Dämons ({\bf bls}, {\bf bextract}, and {\bf bscan}) statisch gelinkt. Dadurch kann man sie auch verwenden, ohne dass die gemeinsamen Bibliotheken geladen sind. Wenn beim Linken Probleme im Verzeichnis {\bf src/stored} auftreten, sollten sie sich vergewissern, dass diese Option nicht gesetzt ist. Sie können durch Setzen des Schalters {\bf \verb{--{disable-static-tools} das statische Linken auch explizit unterdrücken.
+
+\item [{-}{-}enable-static-fd]
+ \index[general]{--enable-static-fd }
+Durch diese Option kompiliert der make-Prozess zusätzlich zum Standard File-Dämon einen statischen Bacula File-Dämon. Diese statische Version hat alle benötigten Bibliotheken statisch gelinkt und wird für eine Notfallwiederherstellung auf einer leeren Festplatte verwendet. Diese Option kann meistens durch den Befehl {\bf make static-bacula-fd} ersetzt werden, den man im Verzeichnis {\bf src/filed} ausführen kann. Daneben ist auch die unten beschriebene Option {\bf \verb{--{enable-client-only} nützlich, wenn man nur einen einzelnen Client kompilieren will und die übrigen Programmteile nicht.
+
+Wird ein statisches Programm gelinkt, benötigt der Linker alle verwendeten Bibliotheken in statischen Versionen. Benutzer, die diese Option häufiger verwenden, werden auch häufiger Linker-Fehler haben. Als Erstes sollte man dann überprüfen, ob auf dem System eine statische ``glibc''-Bibliothek installiert ist. Als nächstes sollte man `./configure'' ohne die Optionen {\bf {-}{-}openssl} und {\bf {-}{-}with-python} aufrufen, da hierbei zusätzliche Bibliotheken benötigt werden. Man kann diese Optionen verwenden, doch muss man dann zusätzliche statische Bibliotheken laden.
-\item [ {-}{-}enable-static-dir]
- \index[general]{{-}{-}enable-static-dir }
- This option causes the make process to build a {\bf static-bacula-dir}
- in addition to the standard Director. This static version will include
- statically linked libraries and could be useful during a Bare Metal
- recovery.
-
- When linking a static binary, the linker needs the static versions
- of all the libraries that are used, so frequently users will
- experience linking errors when this option is used. The first
- thing to do is to make sure you have the static glibc library
- installed on your system. The second thing to do is the make sure
- you do not specify {\bf {-}{-}openssl} or {\bf {-}{-}with-python}
- on your ./configure statement as these options require additional
- libraries. You may be able to enable those options, but you will
- need to load additional static libraries.
-
-
-\item [ {-}{-}enable-static-cons]
- \index[general]{{-}{-}enable-static-cons }
- This option causes the make process to build a {\bf static-console} and
- a {\bf static-gnome-console} in addition to the standard console. This
- static version will include statically linked libraries and could be
- useful during a Bare Metal recovery.
-
- When linking a static binary, the linker needs the static versions
- of all the libraries that are used, so frequently users will
- experience linking errors when this option is used. The first
- thing to do is to make sure you have the static glibc library
- installed on your system. The second thing to do is the make sure
- you do not specify {\bf {-}{-}openssl} or {\bf {-}{-}with-python}
- on your ./configure statement as these options require additional
- libraries. You may be able to enable those options, but you will
- need to load additional static libraries.
-
-
-\item [ {-}{-}enable-client-only]
- \index[general]{{-}{-}enable-client-only }
- This option causes the make process to build only the File daemon and
- the libraries that it needs. None of the other daemons, storage tools,
- nor the console will be built. Likewise a {\bf make install} will then
- only install the File daemon. To cause all daemons to be built, you
- will need to do a configuration without this option. This option
- greatly facilitates building a Client on a client only machine.
-
- When linking a static binary, the linker needs the static versions
- of all the libraries that are used, so frequently users will
- experience linking errors when this option is used. The first
- thing to do is to make sure you have the static glibc library
- installed on your system. The second thing to do is the make sure
- you do not specify {\bf {-}{-}openssl} or {\bf {-}{-}with-python}
- on your ./configure statement as these options require additional
- libraries. You may be able to enable those options, but you will
- need to load additional static libraries.
-
-
-\item [ {-}{-}enable-largefile]
- \index[general]{{-}{-}enable-largefile }
- This option (default) causes Bacula to be built with 64 bit file address
- support if it is available on your system. This permits Bacula to read and
- write files greater than 2 GBytes in size. You may disable this feature and
- revert to 32 bit file addresses by using {\bf \verb:--:disable-largefile}.
+\item [{-}{-}enable-static-sd]
+ \index[general]{--enable-static-sd }
+Damit wird zusätzlich zum Standard-Storage-Dämon ein statischer Storage-Dämon kompiliert. Die statische Version hat die Bibliotheksfunktionen fest eingebaut und ist bei der Datenwiederherstellung im Notfall hilfreich.
+
+Wird ein statisches Programm gelinkt, benötigt der Linker alle verwendeten Bibliotheken in statischen Versionen. Benutzer, die diese Option häufiger verwenden, werden auch häufiger Linker-Fehler haben. Als Erstes sollte man dann überprüfen, ob auf dem System eine statische ``glibc''-Bibliothek installiert ist. Als nächstes sollte man `./configure'' ohne die Optionen {\bf {-}{-}openssl} und {\bf {-}{-}with-python} aufrufen, da hierbei zusätzliche Bibliotheken benötigt werden. Man kann diese Optionen verwenden, doch muss man dann zusätzliche statische Bibliotheken laden.
+
+\item [{-}{-}enable-static-dir]
+ \index[general]{--enable-static-dir }
+Damit wird zusätzlich zum Standard-Director ein statischer Director kompiliert. Die statische Version hat die Bibliotheksfunktionen fest eingebaut und ist bei der Datenwiederherstellung im Notfall hilfreich.
+
+Wird ein statisches Programm gelinkt, benötigt der Linker alle verwendeten Bibliotheken in statischen Versionen. Benutzer, die diese Option häufiger verwenden, werden auch häufiger Linker-Fehler haben. Als Erstes sollte man dann überprüfen, ob auf dem System eine statische ``glibc''-Bibliothek installiert ist. Als nächstes sollte man `./configure'' ohne die Optionen {\bf {-}{-}openssl} und {\bf {-}{-}with-python} aufrufen, da hierbei zusätzliche Bibliotheken benötigt werden. Man kann diese Optionen verwenden, doch muss man dann zusätzliche statische Bibliotheken laden.
+
+\item [{-}{-}enable-static-cons]
+ \index[general]{--enable-static-cons }
+Damit werden zusätzlich zur Standard-Console eine statische Console und statische GNOME-Console kompiliert. Die statischen Versionen haben die Bibliotheksfunktionen fest eingebaut und sind bei der Datenwiederherstellung im Notfall hilfreich.
+
+Wird ein statisches Programm gelinkt, benötigt der Linker alle verwendeten Bibliotheken in statischen Versionen. Benutzer, die diese Option häufiger verwenden, werden auch häufiger Linker-Fehler haben. Als Erstes sollte man dann überprüfen, ob auf dem System eine statische ``glibc''-Bibliothek installiert ist. Als nächstes sollte man `./configure'' ohne die Optionen {\bf {-}{-}openssl} und {\bf {-}{-}with-python} aufrufen, da hierbei zusätzliche Bibliotheken benötigt werden. Man kann diese Optionen verwenden, doch muss man dann zusätzliche statische Bibliotheken laden.
+
+\item [{-}{-}enable-client-only]
+ \index[general]{--enable-client-only }
+Durch Setzen dieses Schalters werden nur der File-Dämon und die von ihm benötigten Bibliotheken kompiliert. Keiner der anderen Dämonen, nicht die Sicherungswerkzeuge oder die Console werden kompiliert. Daher wird mit dem Befehl {\bf make install} auch nur der File-Dämon installiert. Um alle Dämonen zu kompilieren, müssen Sie eine Konfiguration ohne diese Option verwenden. Mit dieser Option wird die Kompilierung nur eines Client-Prozesses auf einem Client-Rechner sehr erleichtert.
+
+Wird ein statisches Programm gelinkt, benötigt der Linker alle verwendeten Bibliotheken in statischen Versionen. Benutzer, die diese Option häufiger verwenden, werden auch häufiger Linker-Fehler haben. Als Erstes sollte man dann überprüfen, ob auf dem System eine statische ``glibc''-Bibliothek installiert ist. Als nächstes sollte man `./configure'' ohne die Optionen {\bf {-}{-}openssl} und {\bf {-}{-}with-python} aufrufen, da hierbei zusätzliche Bibliotheken benötigt werden. Man kann diese Optionen verwenden, doch muss man dann zusätzliche statische Bibliotheken laden.
+
+\item [{-}{-}enable-largefile]
+ \index[general]{--enable-largefile }
+Mit diesem Schalter (voreingestellt) wird Bacula mit der Unterstützung für 64 Bit breite Adressen kompiliert, sofern dies Ihr Rechner unterstützt. Damit kann Bacula Dateien lesen und schreiben, die größer sind als 2 GBytes. Dieses Feature kann durch setzen des Schalters {\bf \verb{--{disable-largefile} abgewählt werden. Damit sind nur 32 Bit breite Adressen möglich.
\item [ {-}{-}disable-nls]
\index[general]{{-}{-}disable-nls}
- By default, Bacula uses the GNU Native Language Support (NLS) libraries. On
- some machines, these libraries may not be present or may not function
- correctly (especially on non-Linux implementations). In such cases, you
- may specify {\bf {-}{-}disable-nls} to disable use of those libraries.
- In such a case, Bacula will revert to using English.
-
-\item [ {-}{-}with-sqlite=\lt{}sqlite-path\gt{}]
- \index[general]{{-}{-}with-sqlite }
- This enables use of the SQLite version 2.8.x database. The {\bf sqlite-path} is not
- normally specified as Bacula looks for the necessary components in a
- standard location ({\bf depkgs/sqlite}). See
- \ilink{Installing and Configuring SQLite}{_ChapterStart33} chapter of
- this manual for more details.
-
- See the note below under the {-}{-}with-postgresql item.
-
-\item [ {-}{-}with-sqlite3=\lt{}sqlite3-path\gt{}]
+Vorgabemäßig verwendet Bacula ``GNU Native Language Support''-Bibliotheken (NLS). Auf manchen Rechnern sind diese Bibliotheken nicht verfügbar oder funktionieren nicht richtig (beonders auf nicht-Linux Implementierungen). In diesen Fällen kann man durch Setzen von {\bf {-}{-}disable-nls} die Verwendung dieser Bibliotheken unterbinden. In diesem Fall benutzt Bacula Englisch.
+
+\item [{-}{-}with-sqlite=\lt{}Pfad/zu/SQLite\gt{}]
+ \index[general]{--with-sqlite }
+Mit dieser Option wird die Benutzung eines SQlite-Datenbanksystems ermöglicht. Da Bacula an einem Standard-Speicherort ({\bf depkgs/sqlite}) sucht, wird der Pfad {\bf sqlite-path} normalerweise nicht angegeben. Näheres hierzu im Kapitel \ilink{SQLite installieren and konfigurieren }{_ChapterStart33} in diesem Handbuch.
+Beachten Sie auch den Hiinweis zur Option ``{-}{-}with-postgresql''.
+
+\item [ {-}{-}with-sqlite3=\lt{}Pfad/zu/sqlite3\gt{}]
\index[general]{{-}{-}with-sqlite3 }
- This enables use of the SQLite version 3.x database. The {\bf
- sqlite3-path} is not normally specified as Bacula looks for the
- necessary components in a standard location ({\bf depkgs/sqlite3}). See
- \ilink{Installing and Configuring SQLite}{_ChapterStart33} chapter of
- this manual for more details.
-
-\item [ {-}{-}with-mysql=\lt{}mysql-path\gt{}]
- \index[general]{{-}{-}with-mysql }
- This enables building of the Catalog services for Bacula. It assumes
- that MySQL is running on your system, and expects it to be installed in
- the {\bf mysql-path} that you specify. Normally, if MySQL is installed
- in a standard system location, you can simply use {\bf {-}{-}with-mysql}
- with no path specification. If you do use this option, please proceed
- to installing MySQL in the \ilink{Installing and Configuring
- MySQL}{_ChapterStart} chapter before proceeding with the configuration.
-
- See the note below under the {-}{-}with-postgresql item.
-
-\item [ {-}{-}with-postgresql=\lt{}path\gt{}]
- \index[general]{{-}{-}with-postgresql }
- This provides an explicit path to the PostgreSQL libraries if Bacula
- cannot find it by default. Normally to build with PostgreSQL, you would
- simply use {\bf {-}{-}with-postgresql}.
-
- Note, for Bacula to be configured properly, you must specify one
- of the four database options supported. That is:
- {-}{-}with-sqlite, {-}{-}with-sqlite3, {-}{-}with-mysql, or
- {-}{-}with-postgresql, otherwise the ./configure will fail.
+Dies erlaubt die Verwendung von SQLite in der Version 3.x. Der Pfad ({\bf sqlite3-path}) muss normalerweise nicht gesetzt werden, da Bacula die benötigten Komponenten an den Standardspeicherorten ({\bf depkgs/sqlite3}) sucht. Im Kapitel \ilink{SQLite installieren und konfigurieren}{_ChapterStart33} dieses Handbuches finden sie weitere Einzelheiten.
-\item [ {-}{-}with-openssl=\lt{}path\gt{}]
- This configuration option is necessary if you want to enable TLS (ssl)
- in Bacula. Normally, the {\bf path} specification is not necessary since
- the configuration searches for the OpenSSL libraries in standard system
- locations. Enabling OpenSSL in Bacula permits secure communications
- between the daemons. For more information on using TLS, please see the
- \ilink{Bacula TLS}{_ChapterStart61} chapter of this manual.
+\item [{-}{-}with-mysql=\lt{}Pfad/zu/MySQL\gt{}]
+ \index[general]{--with-mysql }
+Mit dieser Option werden die Catalog-Dienste für Bacula kompiliert. Sie setzt voraus, dass MySQL bereits auf Ihrem Rechner läuft, und erwartet, dass es im Verzeichnis, das Sie mit der Pfadangabe ({\bf mysql-path}) angeben, installiert ist. Wenn dieser Schalter nicht gesetzt ist, wird Bacula automatisch den Code der internen Bacula-Datenbank einbeziehen. Nach Möglichkeit empfehlen wir, diesen Schalter zu setzen. Wenn Sie ihn verwenden, installieren Sie bitte zuerst MySQL und lesen das Kapitel \ilink{MySQL installieren and konfigurieren }{_ChapterStart} in diesem Handbuch bevor Sie mit der Konfiguration fortfahren.
+
+\item [{-}{-}with-postgresql=\lt{}Pfad/zu/PostgreSQL\gt{}]
+ \index[general]{--with-postgresql }
+Dieser Schalter erfordert die Angabe des Pfades zum PostgreSQL-Programmverzeichnis, da Bacula ihn nicht von selbst finden kann. Zur Kompilierung mit PostgreSQL verwendet man einfach {\bf {-}{-}with-postgresql}.
+Um Bacula richtig zu konfigurieren, muss eine der vier unterstützten Datenbank-Optionen spezifiziert sein. Entweder also
+``{-}{-}with-sqlite'', ``{-}{-}with-sqlite3'', ``{-}{-}with-mysql'' oder `{-}{-}with-postgresql''. Andernfalls wird der ``./configure''-Prozess fehlschlagen.
-\item [ {-}{-}with-python=\lt{}path\gt{}]
+\item [ {-}{-}with-openssl=\lt{}path\gt{}]
+Diese Schalter wird benötigt, wenn Bacula TLS (ssl) verwenden soll. In der Regel muss der Pfad nicht spezifiziert werden, da der Konfigurationsprozess die OpenSSL-Bibliotheken an deren Standardorten sucht. Wenn OpenSSL aktiviert ist, gestattet Bacula eine sichere Kommunikation zwischen seinen Dämonprozessen. Weitere Informationen zur Verwendung von TLS im Kapitel \ilink{Bacula TLS}{_ChapterStart61} in diesem Handbuch.
+
+\item [ {-}{-}with-python=\lt{}Pfad/zu/Python\gt{}]
\index[general]{{-}{-}with-python }
- This option enables Bacula support for Python. If no path is
- supplied, configure will search the
- standard library locations for Python 2.2, 2.3, or 2.4. If it cannot
- find the library, you will need to supply a path to your Python
- library directory. Please see the
- \ilink{Python chapter}{_ChapterStart60} for the details of using
- Python scripting.
+Mit diese Option wird die Bacula-Unterstützung für Python aktiviert. Wird kein Pfad mit angegeben, sucht der Konfigurationsprozess Bibliotheken an den Standard-Installationsorten von Python 2.2., 2.3 und 2.4. Wird die Bibliothek nicht gefunden, muss die Option mit dem Pfad zum Verzeichnis Ihrer Python-Bibliotheken aufgerufen werden. Im Kapitel \ilink{Python}{_ChapterStart60} sind Einzelheiten dazu, wie man Python-Scripting verwenden kann.
\item [ {-}{-}with-libintl-prefix=\lt{}DIR\gt{}]
\index[general]{{-}{-}with-libintl-prefix}
- This option may be used to tell Bacula to search DIR/include and
- DIR/lib for the libintl headers and libraries needed for Native
- Language Support (NLS).
-
-\item [ {-}{-}enable-conio]
- \index[general]{{-}{-}enable-conio }
- Tells Bacula to enable building the small, light weight readline
- replacement routine. It is generally much easier to configure than
- readline, although, like readline, it needs either the termcap or
- ncurses library.
-
-\item [ {-}{-}with-readline=\lt{}readline-path\gt{}]
- \index[general]{{-}{-}with-readline }
- Tells Bacula where {\bf readline} is installed. Normally, Bacula will
- find readline if it is in a standard library. If it is not found and no
- {-}{-}with-readline is specified, readline will be disabled. This
- option affects the Bacula build. Readline provides the Console program
- with a command line history and editing capability and is no longer
- supported, so you are on your own if you have problems.
+Mit dieser Option durchsucht Bacula die Verzeichnisse ``DIR/include'' und ``DIR/lib'' nach den ``libintl''-Headern und -Bibliotheken, die es für den ``Native Language Support'' (NLS) benötigt.
+
+\item [{-}{-}enable-conio]
+ \index[general]{--enable-conio }
+Teilt Bacula mit, die kleine, leichtgewichtige, ``readline'' ersetzende Routine zu kompilieren. Diese ist im allgemeinen sehr viel einfacher zu konfigurieren als ``readline'', benötigt aber entweder die ``termcap''- oder ``ncurses''-Bibliothek.
+
+\item [{-}{-}with-readline=\lt{}Pfad/zu/readline\gt{}]
+ \index[general]{--with-readline }
+Teilt Bacula mit, wo {\bf readline} installiert ist. Sofern es Teil der Standard-Bibliothek ist, findet Bacula normalerweise ``readline''. Wird es nicht gefunden, und ist der Schalter \verb{--{with-readline gesetzt, wird readline deaktiviert. Diese Option betrifft Baculas Kompilierung. Mit Readline ist im der Console-Programm eine History und ein Editieren der Kommandozeile möglich. Readline wird nicht mehr unterstützt. Sie sind daher bei Problemen auf sich allein gestellt.
\item [ {-}{-}enable-readline]
- \index[general]{{-}{-}enable-readline }
- Tells Bacula to enable readline support. It is normally disabled due to the
- large number of configuration problems and the fact that the package seems to
- change in incompatible ways from version to version.
-
-\item [ {-}{-}with-tcp-wrappers=\lt{}path\gt{}]
- \index[general]{{-}{-}with-tcp-wrappers }
- This specifies that you want TCP wrappers (man hosts\_access(5)) compiled in.
- The path is optional since Bacula will normally find the libraries in the
- standard locations. This option affects the Bacula build. In specifying your
- restrictions in the {\bf /etc/hosts.allow} or {\bf /etc/hosts.deny} files, do
- not use the {\bf twist} option (hosts\_options(5)) or the Bacula process will
- be terminated. Note, when setting up your {\bf /etc/hosts.allow}
- or {\bf /etc/hosts.deny}, you must identify the Bacula daemon in
- question with the name you give it in your conf file rather than the
- name of the executable.
+ \index[general]{--enable-readline }
+Damit wird Bacula mitgeteilt, die Readline-Unterstütung zu ermöglichen. Das Paket scheint sich in inkompatibler Weise von Version zu Version zu ändern. Daher ist wegen der Vielzahl der Konfigurationsprobleme dieser Schalter normalerweise nicht gesetzt.
+
+\item [{-}{-}with-tcp-wrappers=\lt{}Pfad/zur/TCP-Wrapper/Bibliothek\gt{}]
+ \index[general]{--with-tcp-wrappers }
+Damit wird spezifiziert, dass Bacula mit TCP-Wrappern (man hosts\_access(5)) kompiliert werden soll. Die Angabe des Pfades ist optional, da Bacula die Bibliotheken an den Standard-Speicherorten findet. Diese Option betrifft Baculas Kompilierung. Wenn Sie bei der Spezifikation der Einschränkungen in ihren {\bf /etc/hosts.allow}- und {\bf /etc/hosts.deny}-Dateien die {\bf twist}-Option (hosts\_options(5)) verwenden, wird sich der Bacula-Prozess beenden.
+Beachten Sie bitte, dass Sie beim Einrichten Ihrer {\bf /etc/hosts.allow}- und {\bf /etc/hosts.deny}-Dateien die infrage kommenden Bacula-Dämonen mit deren Namen aus der Konfigurationsdatei und nicht mit deren jeweiligen Programmnamen bezeichnen.
+
+Weitere Informationen zur Konfiguration und zum Test der TCP-Wrapper im Abschnitt \ilink{TCP Wrapper konfigurieren und testen}{wrappers} des Kapitels zur Sicherheit.
+
+\item [{-}{-}with-working-dir=\lt{}Pfad/zum/Arbeitsverzeichnis\gt{} ]
+ \index[general]{--with-working-dir }
+Die Angabe dieser Option ist zwingend und spezifizert das Verzeichnis, in welches Bacula zwischen seinen Ausführungen seine Dateien sichert. Wenn z.B. die interne Datenbank verwendet wird, werden deren Dateien hier abgelegt. Diese Option wird nur benutzt, um die Konfigurationsdateien der Dämonen zu verändern. Das Gleiche erreichen Sie, wenn Sie die Konfigurationsdateien nachträglich ändern. Das Arbeitsverzeichnis wird bei der Installation nicht automatisch erstellt, so dass Sie sicherstellen müssen, dass es vor der ersten Benutzung von Bacula vorhanden ist.
+
+\item [{-}{-}with-base-port=\lt{}Port=Nummer\gt{}]
+ \index[general]{--with-base-port }
+Um funktioniern zu können, benötigt Bacula drei TCP/IC-Ports (einen für die Bacula-Console, einen für den Storage-Dämon und einen für den File-Dämon). Die Direktive {\bf \verb{--{with-baseport} weist automatisch drei Port Nummern zu, die mit der Basisadresse beginnen, die Sie spezifizieren. Auch in den sich ergebenden Konfigurationsdateien können Sie die Portnummern ändern. Sie müssen jedoch aufpassen, dass die Nummern in allen drei Konfigurationsdateien genau übereinstimmen. Der Vorgabe-Basisport hat die Nummer 9101. Damit sind die Ports 9101 bis 9103 zugewiesen. Diese Portnummern (9101, 9102, 9103) wurden von der IANA Bacula offiziell zugeteilt. Durch Setzen dieser Option verändern Sie nur die Konfigurationsdateien. Diese können Sie auch nach der Installation noch verändern.
+
+\item [{-}{-}with-dump-email=\lt{}E-mail-Adresse\gt{}]
+ \index[general]{--with-dump-email }
+Dieser Schalter spezifiziert die E-Mail-Adresse an die alle ``core dumps'' gesendet werden und wird normalerweise nur von Entwicklern verwendet.
+
+\item [{-}{-}with-pid-dir=\lt{}Pfad\gt{} ]
+ \index[general]{--with-pid-dir }
+Damit wird jenes Verzeichnis spezifiziert, in welchem Bacula die Datei mit den Prozess-IDs während seiner Ausführung ablegt. Vorgabemäßig ist dies {\bf /var/run}. Diese Verzeichnis wird bei der Installation nicht angelegt. Daher sollten Sie sicher sein, dass es vorhanden ist, bevor Sie Bacula zum ersten Mal verwenden.
+
+\item [{-}{-}with-subsys-dir=\lt{}Pfad\gt{}]
+ \index[general]{--with-subsys-dir }
+Dieser Schalter spezifiziert den Ort, an dem Bacula die Subsystem-Lock Datei während seiner Ausführung ablegt. Vorgabe ist {\bf /var/run/subsys}. Stellen Sie sicher, dass sie hierfür und das {\bf sbindir}-Verzeichnis nicht das gleiche Verzeichnis spezifizieren. Dieses Verzeichnis wird nur innerhalb der Autostart-Skripten verwendet. Das ``subsys''-Verzeichnis wird bei Baculas Installation nicht erstellt, so dass Sie selbst sicherstellen müssen, dass es erstellt ist, bevor Sie Bacula verwenden.
- For more information on configuring and testing TCP wrappers, please see the
- \ilink{Configuring and Testing TCP Wrappers}{wrappers} section
- in the Security Chapter.
-
-\item [ {-}{-}with-working-dir=\lt{}working-directory-path\gt{} ]
- \index[general]{{-}{-}with-working-dir }
- This option is mandatory and specifies a directory into which Bacula may
- safely place files that will remain between Bacula executions. For example,
- if the internal database is used, Bacula will keep those files in this
- directory. This option is only used to modify the daemon configuration
- files. You may also accomplish the same thing by directly editing them later.
- The working directory is not automatically created by the install process, so
- you must ensure that it exists before using Bacula for the first time.
-
-\item [ {-}{-}with-base-port=\lt{}port=number\gt{}]
- \index[general]{{-}{-}with-base-port }
- In order to run, Bacula needs three TCP/IP ports (one for the Bacula
- Console, one for the Storage daemon, and one for the File daemon). The {\bf
- \verb:--:with-baseport} option will automatically assign three ports beginning at
- the base port address specified. You may also change the port number in the
- resulting configuration files. However, you need to take care that the
- numbers correspond correctly in each of the three daemon configuration
- files. The default base port is 9101, which assigns ports 9101 through 9103.
- These ports (9101, 9102, and 9103) have been officially assigned to Bacula by
- IANA. This option is only used to modify the daemon configuration files. You
- may also accomplish the same thing by directly editing them later.
-
-\item [ {-}{-}with-dump-email=\lt{}email-address\gt{}]
- \index[general]{{-}{-}with-dump-email }
- This option specifies the email address where any core dumps should be set.
- This option is normally only used by developers.
-
-\item [ {-}{-}with-pid-dir=\lt{}PATH\gt{} ]
- \index[general]{{-}{-}with-pid-dir }
- This specifies where Bacula should place the process id file during
- execution. The default is: {\bf /var/run}. This directory is not created by
- the install process, so you must ensure that it exists before using Bacula
- the first time.
-
-\item [ {-}{-}with-subsys-dir=\lt{}PATH\gt{}]
- \index[general]{{-}{-}with-subsys-dir }
- This specifies where Bacula should place the subsystem lock file during
- execution. The default is {\bf /var/run/subsys}. Please make sure that you do
- not specify the same directory for this directory and for the {\bf sbindir}
- directory. This directory is used only within the autostart scripts. The
- subsys directory is not created by the Bacula install, so you must be sure to
- create it before using Bacula.
-
-\item [ {-}{-}with-dir-password=\lt{}Password\gt{}]
- \index[general]{{-}{-}with-dir-password }
- This option allows you to specify the password used to access the Directory
- (normally from the Console program). If it is not specified, configure will
- automatically create a random password.
-
-\item [ {-}{-}with-fd-password=\lt{}Password\gt{} ]
- \index[general]{{-}{-}with-fd-password }
- This option allows you to specify the password used to access the File daemon
- (normally called from the Director). If it is not specified, configure will
- automatically create a random password.
-
-\item [ {-}{-}with-sd-password=\lt{}Password\gt{} ]
- \index[general]{{-}{-}with-sd-password }
- This option allows you to specify the password used to access the Directory
- (normally called from the Director). If it is not specified, configure will
- automatically create a random password.
-
-\item [ {-}{-}with-dir-user=\lt{}User\gt{} ]
- \index[general]{{-}{-}with-dir-user }
- This option allows you to specify the Userid used to run the Director. The
- Director must be started as root, but doesn't need to run as root, and after
- doing preliminary initializations, it can "drop" to the UserId specified on
- this option.
+\item [{-}{-}with-dir-password=\lt{}Passwort\gt{}]
+ \index[general]{--with-dir-password }
+Mit diesem Schalter kann ein Passwort für den Zugang (in der Regel über das Console-Programm) zum Director spezifiziert werden. Ist der Schalter nicht gesetzt, generiert der Konfigurationsprozess ein zufälliges Passwort.
+
+\item [{-}{-}with-fd-password=\lt{}Passwort\gt{} ]
+ \index[general]{--with-fd-password }
+Mit diesem Schalter kann ein Passwort für den Zugang zum File-Dämon spezifiziert werden (normalerweise vom Director aufgerufen). Wenn es nicht spezifiziert wurde, generiert der Konfigurationsprozess ein zufälliges Passwort.
+
+\item [{-}{-}with-sd-password=\lt{}Passwort\gt{} ]
+ \index[general]{--with-sd-password }
+Mit diesem Schalter kann ein Passwort für den Zugang zum Storage-Dämon spezifiziert werden (normalerweise vom Director aufgerufen). Wenn es nicht spezifiziert wurde, generiert der Konfigurationsprozess ein zufälliges Passwort.
+
+\item [{-}{-}with-dir-user=\lt{}User\gt{} ]
+ \index[general]{--with-dir-user }
+
+Durch Setzen dieses Schalters kann die User-ID festgelegt werden unter welcher der Director läuft. Der Director-Prozess muss als root gestartet werden, doch muss er nicht unter root laufen. Nach den ersten Initialisierungen kann er dem User übergeben werden, dessen ID Sie hier spezifizieren.
\item [ {-}{-}with-dir-group=\lt{}Group\gt{} ]
- \index[general]{{-}{-}with-dir-group }
- This option allows you to specify the GroupId used to run the Director. The
- Director must be started as root, but doesn't need to run as root, and after
- doing preliminary initializations, it can "drop" to the GroupId specified
- on this option.
-
-\item [ {-}{-}with-sd-user=\lt{}User\gt{} ]
- \index[general]{{-}{-}with-sd-user }
- This option allows you to specify the Userid used to run the Storage daemon.
- The Storage daemon must be started as root, but doesn't need to run as root,
- and after doing preliminary initializations, it can "drop" to the UserId
- specified on this option. If you use this option, you will need to take care
- that the Storage daemon has access to all the devices (tape drives, ...) that
- it needs.
-
-\item [ {-}{-}with-sd-group=\lt{}Group\gt{} ]
- \index[general]{{-}{-}with-sd-group }
- This option allows you to specify the GroupId used to run the Storage daemon.
- The Storage daemon must be started as root, but doesn't need to run as root,
- and after doing preliminary initializations, it can "drop" to the GroupId
- specified on this option.
-
-\item [ {-}{-}with-fd-user=\lt{}User\gt{} ]
- \index[general]{{-}{-}with-fd-user }
- This option allows you to specify the Userid used to run the File daemon. The
- File daemon must be started as root, and in most cases, it needs to run as
- root, so this option is used only in very special cases, after doing
- preliminary initializations, it can "drop" to the UserId specified on this
- option.
-
-\item [ {-}{-}with-fd-group=\lt{}Group\gt{} ]
- \index[general]{{-}{-}with-fd-group }
- This option allows you to specify the GroupId used to run the File daemon.
- The File daemon must be started as root, and in most cases, it must be run as
- root, however, after doing preliminary initializations, it can "drop" to
- the GroupId specified on this option.
+ \index[general]{--with-dir-group }
+
+Durch Setzen dieses Schalters kann die Group-ID festgelegt werden unter welcher der Director läuft. Der Director-Prozess muss als root gestartet werden, doch muss er nicht unter root laufen. Nach den ersten Initialisierungen kann er der Gruppe übergeben werden, deren ID Sie hier spezifizieren.
+
+\item [{-}{-}with-sd-user=\lt{}User\gt{} ]
+ \index[general]{--with-sd-user }
+Mit diesem Schalter kann die User-ID festgelegt werden unter welcher der Storage-Dämon läuft. Der Storage-Dämon muss als root gestartet werden, doch muss er nicht unter root laufen. Nach den ersten Initialisierungen kann er dem User übergeben werden, dessen ID Sie hier spezifizieren. Wenn Sie diese Option verwenden, müssen Sie auch sicherstellen, dass der Storageprozess alle Geräte(Bandlaufwerke, usw.) verwenden darf, die er benötigt.
+
+\item [{-}{-}with-sd-group=\lt{}Group\gt{} ]
+ \index[general]{--with-sd-group }
+Durch Setzen dieses Schalters kann die Group-ID festgelegt werden unter welcher der Storage-Dämon läuft. Der Storage-Dämon muss als root gestartet werden, doch muss er nicht unter root laufen. Nach den ersten Initialisierungen kann er der Gruppe übergeben werden, deren ID Sie hier spezifizieren.
+
+\item [{-}{-}with-fd-user=\lt{}User\gt{} ]
+ \index[general]{--with-fd-user }
+Durch Setzen dieses Schalters kann die User-ID festgelegt werden unter welcher der File-Dämon läuft. Der File-Dämon muss als root gestartet werden und muss in den meisten Fällen auch unter root laufen. In ganz besonderen Fällen kann mit dieser Option der File-Dämon-Prozess nach den ersten Initialisierungen einem User übergeben werden, dessen ID Sie hier spezifizieren.
+
+\item [{-}{-}with-fd-group=\lt{}Group\gt{} ]
+ \index[general]{--with-fd-group }
+Durch Setzen dieses Schalters kann die Group-ID festgelegt werden unter welcher der File-Dämon läuft. Der File-Dämon muss als root gestartet werden und muss in den meisten Fällen auch unter root laufen. Trotzdem kann der File-Dämon-Prozess nach den ersten Initialisierungen der Gruppe übergeben werden, deren ID Sie hier spezifizieren.
\end{description}
-Note, many other options are presented when you do a {\bf ./configure
-\verb:--:help}, but they are not implemented.
+Beachten Sie bitte, dass durch Eingabe von {\bf ./configure \verb{--{help} noch viele andere Optionen angezeigt werden, diese aber bislang nicht implementiert sind.
-\subsection*{Recommended Options for most Systems}
-\index[general]{Systems!Recommended Options for most }
-\index[general]{Recommended Options for most Systems }
-\addcontentsline{toc}{subsection}{Recommended Options for most Systems}
+\subsection*{Optionen, die wir für die meisten Systeme empfehlen}
+\index[general]{Systeme!Empfohlenen Optionen für die meisten }
+\index[general]{Optionen, die wir für die meisten Systeme empfehlen }
+\addcontentsline{toc}{subsection}{Optionen, die wir für die meisten Systeme empfehlen}
-For most systems, we recommend starting with the following options:
+Wir empfehlen für die meisten Systeme mit folgenden Optionen zu beginnen:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-If you want to install Bacula in an installation directory rather than run it
-out of the build directory (as developers will do most of the time), you
-should also include the \verb:--:sbindir and \verb:--:sysconfdir options with appropriate
-paths. Neither are necessary if you do not use "make install" as is the case
-for most development work. The install process will create the sbindir and
-sysconfdir if they do not exist, but it will not automatically create the
-pid-dir, subsys-dir, or working-dir, so you must ensure that they exist before
-running Bacula for the first time. See below for an example of how Kern does
-it.
+Wenn Sie Bacula lieber in ein Installationsverzeichnis installieren wollen, als es aus seinem Kompilationsverzeichnis heraus zu betreiben (wie es Entwickler tun) müssen Sie den Schalter \verb{--{sbindir and \verb{--{sysconfdir mit den entsprechenden Pfaden verwenden. Dies ist nicht notwendig, wenn Sie ``make install'' nicht verwenden, wie es meistens bei der Programm-Entwicklung der Fall ist. Der Installationsprozess erzeugt die mit ``sbindir'' und ``sysconfdir'' angegebenen Verzeichnisse, aber nicht jene, die als ``pid-dir'', ``subsys-dir'' oder ``working-dir'' spezifiziert wurden. Sie müssen selbst sicherstellen, dass diese existieren, bevor Bacula das erste Mal läuft. Es folgt ein Beispiel dafür wie Kern das tut.
\subsection*{RedHat}
\index[general]{RedHat }
\addcontentsline{toc}{subsection}{RedHat}
-Using SQLite:
+Bei der Verwendung von SQLite:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-or
+oder
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-or finally, a completely traditional RedHat Linux install:
+oder, zum Schluss, eine vollständig traditionelle RedHat-Linux Installation:
\footnotesize
\begin{verbatim}
--enable-conio
\end{verbatim}
\normalsize
+Beachten Sie bitte, dass Bacula davon ausgeht, dass die Verzeichnisse /var/bacula, /var/run, und /var/loc/subsys bereits existieren und es diese während der Installation nicht automatisch erzeugt.
-Note, Bacula assumes that /var/bacula, /var/run, and /var/loc/subsys exist so
-it will not automatically create them during the install process.
-
-Note, with gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5) on
-an AMD64 CPU running 64 bit CentOS4, there is a compiler bug that generates
-bad code that causes Bacula to segment fault. Typically you will see this
-in the Storage daemon first. The solution is to compile Bacula ensuring
-that no optimization is turned on (normally it is -O2).
+Beachten Sie bitte, dass bei Benutzung einer AMD64 CPU, die unter 64 bit CentOS4 läuft, mit gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5) ein Compiler Bug auftritt, so dass Code erzeugt wird, der eine Segmentverletzung verusacht. Typischerweise macht sich dies zuerst beim Storage-Dämon bemerkbar. Eine Lösung ist es, Bacula ohne Optimierung zu kompilieren (normalerweise ist dies -O2).
\subsection*{Solaris}
\index[general]{Solaris }
\addcontentsline{toc}{subsection}{Solaris}
-To build Bacula from source, you will need the following installed on your
-system (they are not by default): libiconv, gcc 3.3.2, stdc++, libgcc (for
-stdc++ and gcc\_s libraries), make 3.8 or later.
+Um Bacula aus den Quellcodedateien zu erzeugen, muss auf dem Solaris-System bereits das folgende installiert sein (das ist es standardmäßig nicht):
+libiconv, gcc 3.3.2, stdc++, libgcc (wegen der stdc++- und gcc\_s-Bibliotheken), make 3.8 oder neuer.
-You will probably also need to: Add /usr/local/bin to PATH and Add
-/usr/ccs/bin to PATH for ar.
+Möglicherweise muss die PATH-Umgebungsvariable um ``/usr/local/bin'' und ``/usr/ccs/bin'' (wegen ar) ergänzt werden
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-As mentioned above, the install process will create the sbindir and sysconfdir
-if they do not exist, but it will not automatically create the pid-dir,
-subsys-dir, or working-dir, so you must ensure that they exist before running
-Bacula for the first time.
+Wie oben schon erwähnt, erzeugt der Installationsprozess die mit ``sbindir'' und ``sysconfdir'' bezeichneten Verzeichnisse, falls sie nicht schon vorhanden sind. Die Verzeichnisse ``pid-dir'', ``subsys-dir'' und ``working-dir'' werden nicht automatisch erzeugt. Vergewissern Sie sich daher, dass sie existieren, bevor Bacula zum ersten Mal laufen soll.
-Note, you may need to install the following packages to build Bacula
-from source:
+Beachten Sie bitte, dass Sie möglicherweise die folgenden Pakete installieren müssen, um Bacula kompilieren zu können:
\footnotesize
\begin{verbatim}
SUNWbinutils,
\index[general]{FreeBSD }
\addcontentsline{toc}{subsection}{FreeBSD}
-Please see:
-\elink{The FreeBSD Diary}{http://www.freebsddiary.org/bacula.php} for a
-detailed description on how to make Bacula work on your system. In addition,
-users of FreeBSD prior to 4.9-STABLE dated Mon Dec 29 15:18:01 2003 UTC who
-plan to use tape devices, please see the
-\ilink{Tape Testing Chapter}{FreeBSDTapes} of this manual for
-{\bf important} information on how to configure your tape drive for
-compatibility with Bacula.
+Unter \elink{The FreeBSD Diary}{http://www.freebsddiary.org/bacula.php} gibt es eine detailierte Beschreibung wie Bacula unter diesem Betriebssystem intalliert wird. Benutzer von FreeBSD, die eine Version von vor 4.9-STABLE (Montag, 29. Dezember 2003, 15:18:01 UTC) verwenden, sollten das Kapitel \ilink{Test der Bandlaufwerke}{FreeBSDTapes} in diesem Handbuch lesen. Darin sind \textbf{wichtige} Informationen, wie man das Bandlaufwerk so konfiguriert, dass es mit Bacula zusammenarbeitet.
-If you are using Bacula with MySQL, you should take care to compile MySQL with
-FreeBSD native threads rather than LinuxThreads, since Bacula is normally built
-with FreeBSD native threads rather than LinuxTreads. Mixing the two will
-probably not work.
+Wenn Sie Bacula zusammen mit MySQL verwenden, sollten Sie darauf achten, MySQL eher mit den Thread-Bibliotheken von FreeBSD als mit denen von Linux zu kompilieren, weil Bacula selbst normalerweise so kompiliert wird. Eine Mischung von Beiden wird möglicherweise nicht funktionieren.
\subsection*{Win32}
\index[general]{Win32 }
\addcontentsline{toc}{subsection}{Win32}
+Um die Win32-Version des File-Client zu installieren, lesen Sie bitte das Kapitel \ilink{Win32 Installation}{_ChapterStart7} in diesem Handbuch.
-To install the binary Win32 version of the File daemon please see the
-\ilink{Win32 Installation Chapter}{_ChapterStart7} in this document.
-
-\subsection*{Windows Systems with CYGWIN Installed}
+\subsection*{Windows-Systeme mit installiertem CYGWIN}
\label{Win32}
-\index[general]{Windows Systems with CYGWIN Installed }
-\index[general]{Installed!Windows Systems with CYGWIN }
-\addcontentsline{toc}{subsection}{Windows Systems with CYGWIN Installed}
+\index[general]{Windows-Systeme mit installiertem CYGWIN }
+\index[general]{CYGWIN!Windows-Systeme mit installiertem }
+\addcontentsline{toc}{subsection}{Windows-Systeme mit installiertem CYGWIN}
-As of version 1.34, Bacula no longer uses CYGWIN for the Win32 File daemon.
-However, it is still built under a CYGWIN build environment -- though you
-can probably do it with VC Studio only. If you wish to build the Win32
-File daemon from the source, you will need Microsoft C++ version 7.1.
-Details for building the Win32 FD are in the README.win32 file of the
-src/win32 directory.
+Seit der Version 1.34 verwendet Bacula für den Win32-File-Dämon CYGWIN nicht mehr. Er wird allerdings immer noch in einer CYGWIN-Umgebung kompiliert - möglicherweise funktioniert das aber auch mit dem Visual C -Studio allein. Wenn Sie den Win32-File-Dämon selbst kompilieren wollen, benötigen sie Microsoft C++ in der Version 6.0 oder höher. Für Bacula in den Versionen vor 1.3 wurde CYGWIN verwendet. Einzelheiten zur Kompilierung stehen in der README-Datei im Verzeichnis ``src/win32''.
-Note, although most parts of Bacula build on Windows systems, the only part
-that we have tested and used is the File daemon.
+Beachten Sie, dass, obwohl sich fast alle Elemente von Bacula unter Windows kompilieren lassen, nur der File-Dämon getestet und verwendet wurde.
-Finally, you should follow the installation instructions in the
-\ilink{Win32 Installation}{_ChapterStart7} section of this document.
+Beachten Sie auf jeden Fall die Installationsanweisungen des Kapitels \ilink{Win32-Installation}{_ChapterStart7} in diesem Dokument.
-\subsection*{Kern's Configure Script}
-\index[general]{Script!Kern's Configure }
-\index[general]{Kern's Configure Script }
-\addcontentsline{toc}{subsection}{Kern's Configure Script}
+\subsection*{Kerns Konfigurations-Skript}
+\index[general]{Skript!Kerns Konfigurations }
+\index[general]{Kerns Konfigurations-Skript }
+\addcontentsline{toc}{subsection}{Kerns Konfigurations-Skript}
-The script that I use for building on my "production" Linux machines is:
+Dieses Skript verwende ich für meinen ``produktiven'' Linux-Rechner:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-Note that I define the base port as 9101, which means that Bacula will use
-port 9101 for the Director console, port 9102 for the File daemons, and port
-9103 for the Storage daemons. These ports should be available on all systems
-because they have been officially assigned to Bacula by IANA (Internet
-Assigned Numbers Authority). We strongly recommend that you use only these
-ports to prevent any conflicts with other programs. This is in fact the
-default if you do not specify a {\bf \verb:--:with-baseport} option.
+Beachten Sie bitte, dass ich 9101 als Basis-Port definiere. Dadurch verwendet Bacula Port 9101 für die Director-Console, Port 9102 für die File-Dämonen und Port 9103 für die Storage-Dämonen. Diese Ports müssten auf allen Systemen verfügbar sein, da sie von der IANA (Internet Assigned Numbers Authority) offiziell für Bacula reserviert wurden. Wir raten dringend, nur diese Ports zu verwenden, um Konflikte mit anderen Programmen zu vermeiden. Wenn Sie die Option {\bf \verb{--{with-baseport} nicht verwenden, ist dies die Voreinstellung.
-You may also want to put the following entries in your {\bf /etc/services}
-file as it will make viewing the connections made by Bacula easier to
-recognize (i.e. netstat -a):
+Eventuell können Sie auch noch das Folgende in Ihre {\bf /etc/services}-Datei eintragen, was das Erkennen der Verbindungen, die Bacula verwendet, erleichtert (z.B. mit netstat -a):
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-\subsection*{Installing Bacula}
-\index[general]{Bacula!Installing }
-\index[general]{Installing Bacula }
-\addcontentsline{toc}{subsection}{Installing Bacula}
+\subsection*{Bacula installieren}
+\index[general]{installieren!Bacula }
+\index[general]{Bacula installieren }
+\addcontentsline{toc}{subsection}{Bacula installieren}
+
-Before setting up your configuration files, you will want to install Bacula in
-its final location. Simply enter:
+Bevor man die Konfigurations-Dateien bearbeitet, wird man Bacula in dessen Zielverzeichnisse installieren wollen. Dies geschieht mit:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-If you have previously installed Bacula, the old binaries will be overwritten,
-but the old configuration files will remain unchanged, and the "new"
-configuration files will be appended with a {\bf .new}. Generally if you have
-previously installed and run Bacula you will want to discard or ignore the
-configuration files with the appended {\bf .new}.
-
-\subsection*{Building a File Daemon or Client}
-\index[general]{Client!Building a File Daemon or }
-\index[general]{Building a File Daemon or Client }
-\addcontentsline{toc}{subsection}{Building a File Daemon or Client}
-
-If you run the Director and the Storage daemon on one machine and you wish to
-back up another machine, you must have a copy of the File daemon for that
-machine. If the machine and the Operating System are identical, you can simply
-copy the Bacula File daemon binary file {\bf bacula-fd} as well as its
-configuration file {\bf bacula-fd.conf} then modify the name and password in
-the conf file to be unique. Be sure to make corresponding additions to the
-Director's configuration file ({\bf bacula-dir.conf}).
-
-If the architecture or the O/S level are different, you will need to build a
-File daemon on the Client machine. To do so, you can use the same {\bf
-./configure} command as you did for your main program, starting either from a
-fresh copy of the source tree, or using {\bf make\ distclean} before the {\bf
-./configure}.
-
-Since the File daemon does not access the Catalog database, you can remove
-the {\bf \verb:--:with-mysql} or {\bf \verb:--:with-sqlite} options, then
-add {\bf \verb:--:enable-client-only}. This will compile only the
-necessary libraries and the client programs and thus avoids the necessity
-of installing one or another of those database programs to build the File
-daemon. With the above option, you simply enter {\bf make} and just the
-client will be built.
+Wenn Bacula zuvor schon installiert worden war, werden die Programmdateien überschrieben werden, die Konfigurationsdateien jedoch erhalten bleiben. An die Namen der ``neuen'' Konfigurationsdateien wird ein {\bf .new} angehängt. Wenn Sie Bacula bereits installiert und betrieben hatten, werden Sie diese normalerweise verwerfen wollen oder ignorieren.
+
+\subsection*{Einen File-Dämon oder Client-Prozess kompilieren}
+\index[general]{Kompilierung!eines File-Dämons oder Client_Prozesses }
+\index[general]{Einen File-Dämon oder Client-Prozess kompilieren }
+\addcontentsline{toc}{subsection}{Einen File-Dämon oder Client-Prozess kompilieren}
+
+Wenn der Director und Storage-Dämon bei Ihnen auf einem Rechner läuft und Sie die Daten eines anderen Rechners sichern wollen, brauchen Sie auf diesem Rechner eine Kopie des File-Dämons. Sind der Rechner und das Betriebsystem gleich, genügt es, die Programmdatei {\bf bacula-fd} und die Konfigurationsdatei {\bf bacula-fd.conf} zu kopieren und dann den Name und das Passwort in der Konfigurationsdatei anzupassen, sodass diese eindeutig sind. Die entsprechenden Erweiterungen muss man auch in der Konfigurationsdatei des Directors ({\bf bacula-dir.conf}) machen.
+
+Ist die Rechnerachitektur und/oder das Betriebsystem verschieden, so muss der File-Dämon auf dem Client-Rechner kompiliert werden. Man verwendet hierzu den gleichen {\bf ./configure}-Befehl wie für das Hauptprogramm und beginnt in einer neuen Kopie des Quellcode-Verzeichnisses oder indem man vor dem {\bf ./configure} ein {\bf make\ distclean} ausführt.
+
+Da der File-Dämon nicht mit der Datenbank arbeitet, können die Optionen {\bf \verb{--{with-mysql} oder {\bf \verb{--{with-sqlite} entfernt werden. Durch die Verwendung des Schalters {\bf \verb{--{enable-client-only} werden nur die benötigten Bibliotheken und die Client-Programme erzeugt. Dadurch ist es nicht notwendig, die Datenbank-Programme zu installieren, nur um den File-Dämon zu erzeugen. Geben Sie zum Schluss einfach {\bf make} ein. Damit wird nur das Client-Programm erzeugt.
\label{autostart}
-\subsection*{Auto Starting the Daemons}
-\index[general]{Daemons!Auto Starting the }
-\index[general]{Auto Starting the Daemons }
-\addcontentsline{toc}{subsection}{Auto Starting the Daemons}
+\subsection*{Auto-Start der Dämon-Prozesse}
+\index[general]{Dämon-Prozesse!Auto-Start der }
+\index[general]{Auto-Start der Dämon-Prozesse }
+\addcontentsline{toc}{subsection}{Auto-Start der Dämon-Prozesse}
-If you wish the daemons to be automatically started and stopped when your
-system is booted (a good idea), one more step is necessary. First, the
-./configure process must recognize your system -- that is it must be a
-supported platform and not {\bf unknown}, then you must install the platform
-dependent files by doing:
+Sollen die Dämon-Prozesse beim Booten Ihres Systems automatisch gestartet bzw. beendet werden (was sinnvoll ist), ist ein weiterer Schritt erforderlich. Als erstes muss der ``./configure''-Prozess Ihr System erkennen - es muss also unterstützt werden und darf nicht als {\bf unknown} erkannt sein. Dann müssen die plattformspezifischen Dateien wie folgt installiert werden:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-Please note, that the auto-start feature is implemented only on systems
-that we officially support (currently, FreeBSD, RedHat/Fedora Linux, and
-Solaris), and has only been fully tested on Fedora Linux.
+Die Möglichkeit des Auto-Starts ist nur für Systeme implementiert, die wir offiziell unterstützen (momentan FreeBSD, RedHat/Fedora-Linux und Solaris) und wurde bislang nur auf Fedora-Linux vollständig getestet.
-The {\bf make install-autostart} will cause the appropriate startup scripts
-to be installed with the necessary symbolic links. On RedHat/Fedora Linux
-systems, these scripts reside in {\bf /etc/rc.d/init.d/bacula-dir} {\bf
-/etc/rc.d/init.d/bacula-fd}, and {\bf /etc/rc.d/init.d/bacula-sd}. However
-the exact location depends on what operating system you are using.
+Mit dem Befehl {\bf make install-autostart} werden die entsprechenden Start-Skripte zusammen mit den notwendigen symbolischen Links installiert. Unter RedHat-Linux sind diese Skripte in den Verzeichnisssen {\bf /etc/rc.d/init.d/bacula-dir}, {\bf /etc/rc.d/init.d/bacula-fd} und {\bf /etc/rc.d/init.d/bacula-sd}. Der genaue Speicherort hängt vom verwendeten Beriebssystem ab.
-If you only wish to install the File daemon, you may do so with:
+Wenn nur der File-Dämon installiert werden soll, können Sie dies mit folgendem Befehl tun:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-\subsection*{Other Make Notes}
-\index[general]{Notes!Other Make }
-\index[general]{Other Make Notes }
-\addcontentsline{toc}{subsection}{Other Make Notes}
+\subsection*{Weitere Hinweise zur Kompilierung}
+\index[general]{Kompilierung!Weitere Hinweise zur }
+\index[general]{Weitere Hinweise zur Kompilierung }
+\addcontentsline{toc}{subsection}{Weitere Hinweise zur Kompilierung}
-To simply build a new executable in any directory, enter:
+Um eine Programmdatei in einem beliebigen Verzeichnis zu erzeugen, geben Sie einfach das folgende ein:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-To clean out all the objects and binaries (including the files named 1, 2, or
-3, which Kern uses as temporary files), enter:
+Um alle Objekt- und Programmdateien (auch die mit ``1'', ``2'' oder ``3'' bezeichneten Dateien, die Kern als temporäre Dateien verwendet) geben Sie folgendes ein:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-To really clean out everything for distribution, enter:
+Um wirklich alles für eine Distribution zu bereinigen:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-note, this cleans out the Makefiles and is normally done from the top level
-directory to prepare for distribution of the source. To recover from this
-state, you must redo the {\bf ./configure} in the top level directory, since
-all the Makefiles will be deleted.
+Beachten Sie bitte, dass dies alle Makefiles löscht und normalerweise auf der obersten Verzeichnisebene ausgeführt wird, um den Quellcode für eine Distribution vorzubereiten. Um dies rückgängig zu machen, muss {\bf ./configure} auch von der obersten Verzeichnisebene ausgeführt werden, da alle Makefiles gelöscht sind.
-To add a new file in a subdirectory, edit the Makefile.in in that directory,
-then simply do a {\bf make}. In most cases, the make will rebuild the Makefile
-from the new Makefile.in. In some case, you may need to issue the {\bf make} a
-second time. In extreme cases, cd to the top level directory and enter: {\bf
-make Makefiles}.
+Um einem Unterverzeichnis eine neue Datei hinzuzufügen, muss die Datei ``Makefile.in'' in jenem Verzeichnis bearbeitet werden. Danach genügt es, {\bf make} einzugeben. In den meisten Fällen erzeugt der make-Befehl ein neues Makefile aus ``Makefile.in''. In manchen Fällen muss der {\bf make}-Befehl wiederholt werden. In extremen Fällen wechselt man in die oberste Verzeichnisebene und gibt ein: {\bf make Makefiles}.
-To add dependencies:
+Um Abhängigkeiten hinzuzufügen:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-The {\bf make depend} appends the header file dependencies for each of the
-object files to Makefile and Makefile.in. This command should be done in each
-directory where you change the dependencies. Normally, it only needs to be run
-when you add or delete source or header files. {\bf make depend} is normally
-automatically invoked during the configuration process.
+Mit {\bf make depend} werden die Abhängigkeiten der Header-Dateien aller Objekt-Dateien dem Makefile und der Datei ``Makefile.in" hinzugefügt. Dieser Befehl sollte in allen Verzeichnissen ausgeführt werden, in welchen Sie die Abhängigkeiten ändern. Normalerweise muss der Befehl nur ausgeführt werden, wenn sie Quell- oder Header-Dateien hinzufügen oder löschen. {\bf make depend} wird normalerweise während des Konfigurations-Prozesses automatisch aufgerufen.
-To install:
+Um zu installieren:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-This not normally done if you are developing Bacula, but is used if you are
-going to run it to backup your system.
-
-After doing a {\bf make install} the following files will be installed on your
-system (more or less). The exact files and location (directory) for each file
-depends on your {\bf ./configure} command (e.g. gnome-console and
-gnome-console.conf are not installed if you do not configure GNOME. Also, if
-you are using SQLite instead of mysql, some of the files will be different).
+Dieser Befehl wird verwendet, wenn Sie Bacula als Backup-System installieren wollen, nicht aber wenn Sie an Bacula selbst programmieren.
+Nach Ausführen des Befehls {\bf make install} werden die folgenden Dateien auf Ihrem System installiert (mehr oder weniger). Welche Dateien und Verzeichnisse es im einzelnen sind, hängt von Ihrem {\bf ./configure}-Befehl ab (wird z.B. GNOME nicht konfiguriert, wird auch ``gnome-console'' und ``gnome-console.conf'' nicht installiert. Wenn Sie SQLite anstatt MySQL verwenden, werden einige der Dateien andere sein).
\footnotesize
\begin{verbatim}
tray-monitor.conf
bextract
bls
-bscan
+bscanBacula
btape
btraceback
btraceback.gdb
query.sql
bsmtp
startmysql
-stopmysql
+stopmysqlBacula
wx-console
wx-console.conf
\end{verbatim}
\label{monitor}
-\subsection*{Installing Tray Monitor}
-\index[general]{Monitor!Installing Tray }
-\index[general]{Installing Tray Monitor }
-\addcontentsline{toc}{subsection}{Installing Tray Monitor}
+\subsection*{Die Installation des Tray-Monitors}
+\index[general]{Tray-Monitors!Die Installation des }
+\index[general]{Die Installation des Tray-Monitors }
+\addcontentsline{toc}{subsection}{Die Installation des Tray-Monitors}
-The Tray Monitor is already installed if you used the {\bf
-\verb:--:enable-tray-monitor} configure option and ran {\bf make install}.
+Wenn Sie den Konfigurationsschalter {\bf \verb{--{enable-tray-monitor} verwendet und {\bf make install} ausgeführt haben, ist der Tray-Monitor schon installiert.
-As you don't run your graphical environment as root (if you do, you should
-change that bad habit), don't forget to allow your user to read {\bf
-tray-monitor.conf}, and to execute {\bf bacula-tray-monitor} (this is not a
-security issue).
+Da Sie Ihre grafische Umgebung nicht als root betreiben (wenn doch, sollten sie das abstellen), müssen Sie den Usern Leserechte auf {\bf tray-monitor.conf} und Ausführungsrechte für {\bf bacula-tray-monitor} geben. Dies ist kein Sicherheitsrisiko.
-Then log into your graphical environment (KDE, Gnome or something else), run
-{\bf bacula-tray-monitor} as your user, and see if a cassette icon appears
-somewhere on the screen, usually on the task bar.
-If it doesn't, follow the instructions below related to your environment or
-window manager.
+Melden Sie sich bei Ihrer grafischen Umgebung an (KDE, Gnome oder eine andere), starten sie den {\bf bacula-tray-monitor} als gewöhnlicher Benutzer und achten Sie darauf, ob das Cassetten-Icon irgendwo auf Ihrem Bildschirm erscheint (gewöhnlich in der Task-Leiste). Tut es das nicht, werfen Sie einen Blick auf die unten aufgeführten Anweisungen entsprechend Ihrer Umgebung oder Ihres Window-Managers.
\subsubsection*{GNOME}
\index[general]{GNOME }
\addcontentsline{toc}{subsubsection}{GNOME}
-System tray, or notification area if you use the GNOME terminology, has been
-supported in GNOME since version 2.2. To activate it, right-click on one of
-your panels, open the menu {\bf Add to this Panel}, then {\bf Utility} and
-finally click on {\bf Notification Area}.
+Ein System-Tray oder einen ``Benachrichtigungs-Bereich'' (um die GNOME-Terminologie zu verwenden), wird von GNOME seit der Version 2.2 unterstützt. Um sie zu aktivieren, klicken Sie rechts auf Ihre Kontrollleiste, öffnen das Menü {\bf Add to this Panel}, dann auf {\bf Utility} und klicken schließlich auf {\bf Notification Area}.
\subsubsection*{KDE}
\index[general]{KDE }
\addcontentsline{toc}{subsubsection}{KDE}
-System tray has been supported in KDE since version 3.1. To activate it,
-right-click on one of your panels, open the menu {\bf Add}, then {\bf Applet}
-and finally click on {\bf System Tray}.
+Seit der Version 3.1 unterstützt KDE das System-Tray. Um es zu aktivieren, klicken Sie Ihre Kontrollleiste rechts, öffnen das Menü {\bf Zur Kontrollleiste hinzufügen}, dann auf {\bf Miniprogramm} und klicken schließlich auf {\bf Systemabschnitt der Kontrollleiste}.
-\subsubsection*{Other window managers}
-\index[general]{Managers!Other window }
-\index[general]{Other window managers }
-\addcontentsline{toc}{subsubsection}{Other window managers}
+\subsubsection*{Andere Fenster-Manager}
+\index[general]{Fenster-Manager!Andere }
+\index[general]{Andere Fenster-Manager }
+\addcontentsline{toc}{subsubsection}{Andere Fenster-Manager}
-Read the documentation to know if the Freedesktop system tray standard is
-supported by your window manager, and if applicable, how to activate it.
+Lesen Sie die Dokumentation um zu erfahren, ob der Freedesktop System-Tray-Standard von Ihrem Fenster-Manager unterstützt wird und - wenn vorhanden - wie er aktiviert wird.
-\subsection*{Modifying the Bacula Configuration Files}
-\index[general]{Modifying the Bacula Configuration Files }
-\index[general]{Files!Modifying the Bacula Configuration }
-\addcontentsline{toc}{subsection}{Modifying the Bacula Configuration Files}
+\subsection*{Die Bacula Konfigurations-Dateien bearbeiten}
+\index[general]{Die Bacula Konfigurations-Dateien bearbeiten }
+\index[general]{Bearbeiten!Die Bacula Konfigurations-Dateien }
+\addcontentsline{toc}{subsection}{Die Bacula Konfigurations-Dateien bearbeiten}
-See the chapter
-\ilink{Configuring Bacula}{_ChapterStart16} in this manual for
-instructions on how to set Bacula configuration files.
+Schlagen Sie im Kapitel \ilink{Bacula konfigurieren}{_ChapterStart16} dieses Handbuches nach, wie sie die Konfigurationsdateien von Bacula einrichten.
%%
%%
-\section*{Getting Started with Bacula}
+
+\section*{Mit Bacula beginnen}
\label{_ChapterStart37}
-\index[general]{Getting Started with Bacula }
-\addcontentsline{toc}{section}{Getting Started with Bacula}
-
-If you are like me, you want to get Bacula running immediately to get a feel
-for it, then later you want to go back and read about all the details. This
-chapter attempts to accomplish just that: get you going quickly without all
-the details. If you want to skip the section on Pools, Volumes and Labels, you
-can always come back to it, but please read to the end of this chapter, and in
-particular follow the instructions for testing your tape drive.
-
-We assume that you have managed to build and install Bacula, if not, you might
-want to first look at the
-\ilink{System Requirements}{SysReqs} then at the
-\ilink{Compiling and Installing Bacula}{_ChapterStart17} chapter of
-this manual.
+\index[general]{Mit Bacula beginnen }
+\addcontentsline{toc}{section}{Mit Bacula beginnen}
-\label{JobsandSchedules}
-\subsection*{Understanding Jobs and Schedules}
-\index[general]{Jobs!Understanding}
-\index[general]{Schedules!Understanding}
-\addcontentsline{toc}{subsection}{Understanding Jobs and Schedules}
-
-In order to make Bacula as flexible as possible, the directions given
-to Bacula are specified in several pieces. The main instruction is the
-job resource, which defines a job. A backup job generally consists of a
-FileSet, a Client, a Schedule for one or several types or times of backups,
-a Pool, as well as additional instructions. Another way of looking
-at it is the FileSet is what to backup; the Client is who to backup; the
-Schedule defines when, and the Pool defines where (i.e. what Volume).
-
-Typically one FileSet/Client combination will have one corresponding job.
-Most of the directives, such as FileSets, Pools, Schedules, can be mixed
-and matched among the jobs. So you might have two different Job
-definitions (resources) backing up different servers using the same
-Schedule, the same Fileset (backing up the same directories on 2 machines)
-and maybe even the same Pools. The Schedule will define what type of
-backup will run when (e.g Full on Monday, incremental the rest of the
-week), and when more than one job uses the same schedule, the job priority
-determines which actually runs first. If you have a lot of jobs, you might
-want to use JobDefs, where you can set defaults for the jobs, which can
-then be changed int the job resource, but this saves rewriting the
-identical parameters for each job. In addition to the FileSets you want to
-back up, you should also have a job that backs up your catalog.
-
-Finally, be aware that in addition to the backup jobs there are
-restore, verify, and admin jobs, which have different requirements.
+Wenn Sie wie ich sind, wollen Sie dass Bacula sofort läuft, damit Sie ein Gefühl für das Programm bekommen und sich erst später mit den Details befassen. Dieses Kapitel möchte genau dieses erreichen: Das Programm ohne die ganzen Einzelheiten rasch zum Laufen zu bringen. Wenn Sie den Abschnitt über Pools, Volumes und Labels überspringen wollen, können Sie ihn später immer noch nachholen, aber lesen Sie bitte bis zum Ende des Kapitels und beachten Sie die Anweisungen zum Test Ihres Bandlaufwerkes genau.
+
+Wir gehen davon aus, dass Sie es geschafft haben, Bacula zu kompilieren und zu installieren. Wenn nicht, werfen sie vielleicht zuerst einen Blick auf die
+\ilink{System-Anforderungen}{SysReqs} und dann auf das Kapitel
+\ilink{Bacula kompilieren und installieren}{_ChapterStart17} in diesem Handbuch.
\label{PoolsVolsLabels}
-\subsection*{Understanding Pools, Volumes and Labels}
-\index[general]{Labels!Understanding Pools Volumes and }
-\index[general]{Understanding Pools, Volumes and Labels }
-\addcontentsline{toc}{subsection}{Understanding Pools, Volumes and Labels}
-
-If you have been using a program such as {\bf tar} to backup your system,
-Pools, Volumes, and labeling may be a bit confusing at first. A Volume is a
-single physical tape (or possibly a single file) on which Bacula will write
-your backup data. Pools group together Volumes so that a backup is not
-restricted to the length of a single Volume (tape). Consequently, rather than
-explicitly naming Volumes in your Job, you specify a Pool, and Bacula will
-select the next appendable Volume from the Pool and request you to mount it.
-
-Although the basic Pool options are specified in the Director's Pool resource,
-the {\bf real} Pool is maintained in the Bacula Catalog. It contains
-information taken from the Pool resource (bacula-dir.conf) as well as
-information on all the Volumes that have been added to the Pool. Adding
-Volumes to a Pool is usually done manually with the Console program using the
-{\bf label} command.
-
-For each Volume, Bacula maintains a fair amount of catalog information such as
-the first write date/time, the last write date/time, the number of files on
-the Volume, the number of bytes on the Volume, the number of Mounts, etc.
-
-Before Bacula will read or write a Volume, the physical Volume must have a
-Bacula software label so that Bacula can be sure the correct Volume is
-mounted. This is usually done using the {\bf label} command in the Console
-program.
-
-The steps for creating a Pool, adding Volumes to it, and writing software
-labels to the Volumes, may seem tedious at first, but in fact, they are quite
-simple to do, and they allow you to use multiple Volumes (rather than being
-limited to the size of a single tape). Pools also give you significant
-flexibility in your backup process. For example, you can have a "Daily" Pool
-of Volumes for Incremental backups and a "Weekly" Pool of Volumes for Full
-backups. By specifying the appropriate Pool in the daily and weekly backup
-Jobs, you thereby insure that no daily Job ever writes to a Volume in the
-Weekly Pool and vice versa, and Bacula will tell you what tape is needed and
-when.
-
-For more on Pools, see the
-\ilink{Pool Resource}{PoolResource} section of the Director
-Configuration chapter, or simply read on, and we will come back to this
-subject later.
-
-\subsection*{Setting Up Bacula Configuration Files}
+\label{JobsandSchedules}
+\subsection*{Jobs und Zeitpläne verstehen}
+\index[general]{Jobs!verstehen}
+\index[general]{Zeitpläne!verstehen}
+\addcontentsline{toc}{subsection}{Jobs und Zeitpläne verstehen}
+
+Um Bacula so anpassungsfähig wie möglich zu machen, bestehen die Anweisungen, die sein Verhalten bestimmen, aus verschiedenen Teilen. Die wichtigste Direktive ist die Job-Resource, welche jeweils eine Sicherungsaufgabe beschreibt. Ein Sicherungs-Job besteht im allgemeinen aus einem FileSet, einem (Sicherungs-)Client und einem Zeitplan mit einer oder mehreren Arten und Zeiten der Sicherung, einem Pool und zusätzlichen Instruktionen. Mit anderen Worten: Mit dem FileSet wird bestimmt was gesichert werden soll, mit dem Client, wer sichern soll, der Zeitplan bestimmt wann dies geschehen soll und der Pool wohin gesichert werden soll (z.B. auf welches Volume).
+Typischerweise bestimmt jeweils eine Kombination FileSet/Client einen Job. Die meisten der Direktiven wie FileSets, Pools und Zeitpläne können für mehrere Jobs verwendet werden und so beliebig kombiniert werden. Sie könnten z.B. zwei verschiedene Job-Definitionen (resources) haben, welche die Daten verschiedener Server sichern, dabei aber den gleichen Zeitplan, das gleiche FileSet (auf beiden Rechnern werden die gleichen Verzeichnisse gesichert) und vielleicht sogar die gleichen Pools nutzen. Der Zeitplan wird festlegen, welche Art der Sicherung wann läuft (z.B. Montags eine Vollsicherung, an den übrigen Wochentage inkrementielle Sicherung) und wenn mehr als ein Job den gleichen Zeitplan hat, wird die Job-Priorität bestimmen, welcher Job tatsächlich als erster läuft. Wenn Sie viele Jobs haben, werden Sie möglicherweise JobDefs benutzen wollen, in denen Sie Vorgaben für alle Jobs festlegen, die dann in den einzelnen Job-Resourcen individuell angepasst werden können, es Ihnen aber ersparen, für jeden Job die gleichen Parameter zu definieren. Zusätzlich zu den durch die FileSets festgelegten zu sichernden Dateien sollte es auch einen Job geben, der Ihre Catalog-Dateien sichert.
+
+Schließlich gibt es neben den Sicherungs-Jobs Wiederherstellungs-Jobs, Verifikationen und administrative Jobs, die andere Direktiven erfordern.
+
+\subsection*{Pools, Volumes und Labels verstehen}
+\index[general]{Verstehen!von Pools, Volumes und Labels}
+\index[general]{Pools, Volumes und Labels verstehen }
+\addcontentsline{toc}{subsection}{Pools, Volumes und Labels verstehen}
+
+Wenn Sie bisher Programme wie {\bf tar} zur Datensicherung verwendet haben, werden Ihnen Begriffe Pools, Volumes und Label auf den ersten Blick vielleicht etwas verwirrend vorkommen. Ein Volume ist ein einzelnes physikalisches Band (oder möglicherweise eine einzelne Datei), auf die Bacula die Daten Ihrer Sicherung schreibt. Pools sind Gruppen von Volumes, so dass eine Sicherung nicht auf die Größe eines einzelnen Volumes (die Länge eines Bandes) beschränkt ist. Daher werden Sie bei der Definition eines Job eher einen Pool anstatt einzelner Volumes spezifizieren. Bacula wird das nächste verfügbare Volume dem Pool entnehmen und Sie auffordern, es zu mounten.
+
+Während die grundlegenden Eigenschaften eines Pools in der Pool-Resource des Directors festgelegt sind, werden die Daten der realen Pools im Bacula-Catalog gehalten. Er enthält alle Informationen der Pool-Resourcen und auch die Informationen über alle Volumes, die einem Pool zugefügt wurden. Ein Volume wird normalerweise mit dem {\bf label}-Befehl des Konsolen-Proramms dem Pool hinzugefügt.
+
+Für jedes Volume hält Bacula eine ziehmliche Menge von Catalog-Informationen vor, wie z.B. den Zeitpunkt des ersten Lesens/Beschreibens, den Zeitpunkt des letzten Lesens/Beschreibens, die Anzahl der Dateien, die es enthält, die Anzahl der Mounts, usw.
+
+Bevor Bacula ein Volume beschreibt, muss das physikalische Volume eine digitale Kennzeichnung erhalten, damit Bacula sicher sein kann, dass das richtige Volumen gemountet ist. Dies erledigt normalerweise der {\bf label}-Befehl des Konsolen-Programms.
+
+Das Vorgehen, zuerst eine Pool zu schaffen, dann Volumes hinzuzufügen und die Volumes digital zu kennzeichnen, mag zu Anfang mühselig erscheinen, ist aber ganz einfach und erlaubt es, mehrere Volumes zu verwenden (anstatt auf die Speicherkapaziät eines Bandes beschränkt zu sein). Durch Pools wird man bei der Sicherung auch ausgesprochen flexibel. Man kann sich z.B einen ``täglichen'' Pool für inkrementielle und einen ``wöchentlichen'' Pool für Vollsicherungen anlegen. Sind bei der Definition der Sicherungsjobs die richtigen Pools angegeben, wird Bacula niemals einen Tagesjob in ein Volume des wöchentlichen Pools schreiben oder umgekehrt und Ihnen stets sagen, wann welches Band benötigt wird.
+
+Weiteres zu Pools im Abschnitt \ilink{Pool-Resource}{PoolResource} des Kapitels ``Director-Konfiguration''. Auch in diesem Kapitel werden wir später auf dieses Thema zurückkommen.
+
+\subsection*{Baculas Konfigurations-Dateien einrichten}
\label{config}
-\index[general]{Setting Up Bacula Configuration Files }
-\index[general]{Files!Setting Up Bacula Configuration }
-\addcontentsline{toc}{subsection}{Setting Up Bacula Configuration Files}
-
-After running the appropriate {\bf ./configure} command and doing
-a {\bf make}, and a {\bf make install}, if this is the first time
-you are running Bacula, you must create valid configuration files
-for the Director, the File daemon, the Storage daemon, and the
-Console programs. If you have followed our recommendations,
-default configuration files as well as the daemon binaries will
-be located in your installation directory. In any case, the
-binaries are found in the directory you specified on the {\bf
-\verb:--:sbindir} option to the {\bf ./configure} command, and
-the configuration files are found in the directory you specified
-on the {\bf \verb:--:sysconfdir} option.
-
-When initially setting up Bacula you will need to invest a bit of time in
-modifying the default configuration files to suit your environment. This may
-entail starting and stopping Bacula a number of times until you get everything
-right. Please do not despair. Once you have created your configuration files,
-you will rarely need to change them nor will you stop and start Bacula very
-often. Most of the work will simply be in changing the tape when it is full.
+\index[general]{Baculas Konfigurations-Dateien einrichten }
+\index[general]{einrichten!von Baculas Konfigurations-Dateien }
+\addcontentsline{toc}{subsection}{Baculas Konfigurations-Dateien einrichten}
+
+Wenn Sie Bacula zum ersten Mal verwenden, müssen Sie, nachdem Sie den entsprechenden {\bf ./configure}-Befehl, ein {\bf make} und ein {\bf make install} ausgeführt haben, gültige Konfigurationsdateien für den Director, den File-Dämon, den Storage-Dämon und die Console erstellen. Wenn Sie sich nach unseren Empfehlungen gerichtet haben, finden Sie in Ihrem Installationsverzeichnis sowohl Vorgabe-Konfigurationsdateien als auch die ausführbaren Dateien der Dämonen. In jedem Fall sind die Programmdateien in jenem Verzeichnis, welches bei der Ausführung des {\bf ./configure}-Befehls mit der Option {\bf \verb{--{sbindir} und die Konfigurationsdateien in jenem Verzeichnis, welches mit der {\bf \verb{--{sysconfdir}-Option angegeben wurde.
+
+
+Wenn Sie Bacula zum ersten Mal installieren, werden Sie etwas Zeit brauchen, um die Konfigurationsdateien so zu verändern, dass Sie zu Ihrer Umgebung passen. Das wird mit sich bringen, dass Sie Bacula einige Male starten und wieder beenden müssen bis alles stimmt. Verzweifeln Sie nicht! Sind die Konfigurationsdateien einmal erstellt, werden Sie diese nur noch selten ändern und auch Bacula nicht sehr oft starten oder stoppen müssen. Die meiste Arbeit wird darin bestehen, Bänder zu wechseln, wenn sie voll sind.
\subsubsection*{
-\ilink{Configuring the Console Program}{_ChapterStart36}}
-\index[general]{Configuring the Console Program }
-\index[general]{Program!Configuring the Console }
-\addcontentsline{toc}{subsubsection}{Configuring the Console Program}
+\ilink{Die Konfiguration des Console-Programms}{_ChapterStart36}}
+\index[general]{Konfiguration des Console-Programms }
+\index[general]{Console-Programm!die Konfiguration des }
+\addcontentsline{toc}{subsubsection}{Die Konfiguration des Console-Programms}
-The Console program is used by the administrator to interact with the Director
-and to manually start/stop Jobs or to obtain Job status information.
+Das Condsole-Programm wird vom Administrator benutzt, um mit dem Director-Prozess zu interagiern und Jobs manuell zu starten und zu beenden oder Informationen zu einzelnen Jobs zu erhalten.
-The Console configuration file is found in the directory specified on the {\bf
-\verb:--:sysconfdir} option that you specified on the {\bf ./configure} command
-and
-by default is named {\bf console.conf}.
+Die Konfigurationsdatei der Console ist in jenem Verzeichnis, das mit der {\bf
+\verb{--{sysconfdir}-Option bei der Ausführung des {\bf ./configure}-Befehl spezifiziert wurde und heißt vorgabemäßig {\bf console.conf}.
-If you choose to build the GNOME console with the {\bf \verb:--:enable-gnome}
-option,
-you also find a default configuration file for it, named {\bf
-gnome-console.conf}.
+Wenn Sie auch die GNOME-Console mit der {\bf \verb{--{enable-gnome}-Option kompiliert haben, finden Sie auch hierfür eine Vorgabe-Konfigurationsdatei die {\bf gnome-console.conf} heißt.
-The same applies to the wxWidgets console, which is build with the {\bf
-\verb:--:enable-wx-console} option, and the name of the default configuration
-file
-is, in this case, {\bf wx-console.conf}.
+Gleiches gilt für die wxWidgets-Console, die mit der {\bf
+\verb{--{enable-wx-console}-Option kompiliert wird und deren Vorgabe-Konfigurationdsdatei {\bf wx-console.conf} ist.
-Normally, for first time users, no change is needed to these files. Reasonable
-defaults are set.
+Benutzen Sie Bacula zum ersten Mal, wüssen Sie diese Dateien nicht ändern, da brauchbare Vorgabewerte schon gesetzt sind
\subsubsection*{
-\ilink{Configuring the Monitor Program}{_MonitorChapter}}
-\index[general]{Program!Configuring the Monitor }
-\index[general]{Configuring the Monitor Program }
-\addcontentsline{toc}{subsubsection}{Configuring the Monitor Program}
+\ilink{Die Konfiguration des Monitor-Programms}{_ChapterStart35}}
+\index[general]{Monitor-Programm!die Konfiguration des }
+\index[general]{Konfiguration des Monitor-Programms }
+\addcontentsline{toc}{subsubsection}{Die Konfiguration des Monitor-Programms}
-The Monitor program is typically an icon in the system tray. However, once the
-icon is expanded into a full window, the administrator or user can obtain
-status information about the Director or the backup status on the local
-workstation or any other Bacula daemon that is configured.
+Das Monitor-Programm erscheint typischerweise als Icon in der Kontrollleiste. Wird dieses zu einem Fenster vergrößert, liefert es dem Administrator Informationen über den Director, den Sicherungsstatus des lokalen Rechners oder jeden anderen konfigurierten Dämon-Prozess.
\addcontentsline{lof}{figure}{Bacula Tray Monitor}
\includegraphics{./Bacula-tray-monitor.eps}
-The image shows a tray-monitor configured for three daemons. By clicking on
-the radio buttons in the upper left corner of the image, you can see the
-status for each of the daemons. The image shows the status for the Storage
-daemon (MainSD) that is currently selected.
-
-The Monitor configuration file is found in the directory specified on the {\bf
-\verb:--:sysconfdir} option that you specified on the {\bf ./configure} command
-and
-by default is named {\bf tray-monitor.conf}. Normally, for first time users,
-you just need to change the permission of this file to allow non-root users to
-run the Monitor, as this application must run as the same user as the
-graphical environment (don't forget to allow non-root users to execute {\bf
-bacula-tray-monitor}). This is not a security problem as long as you use the
-default settings.
+Die Abbildung zeigt ein Fenster des Tray-Monitors, der für drei Dämon-Prozesse konfiguriert wurde. Wenn man auf die Schaltflächen in der oberen rechten Ecke des Fensters klickt, sieht man den Zustand jedes einzelnen Prozesses. Die Abbildung zeigt den Zustand des momentan ausgewählten Storage-Dämons (MainSD).
+
+Die Konfigurationsdatei des Monitor-Programms befindet sich in jenem Verzeichnis, das bei Ausführung des {\bf ./configure}-Befehls mit der Option {\bf \verb{--{sysconfdir} angegeben wurde. In der Regel müssen Sie als Erstbenutzer die Berechtigung für diese Datei ändern, um Benutzern, die keine root-Rechte haben, zu erlauben, den Monitor zu starten, da diese Anwendung unter dem gleichen Benutzer laufen muss wie die grafische Umgebung (vergessen Sie nicht, nicht-root-Benutzern die Ausführung von {\bf bacula-tray-monitor} zu erlauben). Solange Sie die Vorgabewerte verwenden, ist dies kein Sicherheitsproblem.
\subsubsection*{
-\ilink{Configuring the File daemon}{_ChapterStart25}}
-\index[general]{Daemon!Configuring the File }
-\index[general]{Configuring the File daemon }
-\addcontentsline{toc}{subsubsection}{Configuring the File daemon}
-
-The File daemon is a program that runs on each (Client) machine. At the
-request of the Director, finds the files to be backed up and sends them (their
-data) to the Storage daemon.
-
-The File daemon configuration file is found in the directory specified on
-the {\bf \verb:--:sysconfdir} option that you specified on the {\bf ./configure}
-command. By default, the File daemon's configuration file is named {\bf
-bacula-fd.conf}. Normally, for first time users, no change is needed to this
-file. Reasonable defaults are set. However, if you are going to back up more
-than one machine, you will need to install the File daemon with a unique
-configuration file on each machine to be backed up. The information about each
-File daemon must appear in the Director's configuration file.
+\ilink{Die Konfiguration des File-Dämon}{_ChapterStart25}}
+\index[general]{File-Dämon!die Konfiguration des}
+\index[general]{Konfiguration des File-Dämon }
+\addcontentsline{toc}{subsubsection}{Die Konfiguration des File-Dämon}
+
+Der File-Dämon ist ein Programm, das auf jedem (Client-)Rechner läuft. Auf Anforderung des Directors sucht er die zu sichernden Dateien und schickt sie (bzw. ihre Daten) an den Storage-Dämon.
+
+Die Konfigurationsdatei des File-Dämon ist in jenem Verzeichnis, das bei Ausführung des {\bf ./configure}-Befehls mit der Option {\bf \verb{--{sysconfdir} angegeben wurde. Vorgabemäßig heißt diese Datei {\bf bacula-fd.conf}. Normalerweise muss für erste Versuche hier nichts geändert werden, da vernünftige Vorgabewerte gesetzt sind. Will man allerdings die Daten von mehreren Rechnern sichern, muss auf jedem dieser Rechner ein File-Dämon mit einer eigenen Konfigurationsdatei installiert sein. Die Daten aller dieser File-Dämons müssen in der Konfigurationsdatei des Directors erscheinen.
\subsubsection*{
-\ilink{Configuring the Director}{_ChapterStart40}}
-\index[general]{Director!Configuring the }
-\index[general]{Configuring the Director }
-\addcontentsline{toc}{subsubsection}{Configuring the Director}
-
-The Director is the central control program for all the other daemons. It
-schedules and monitors all jobs to be backed up.
-
-The Director configuration file is found in the directory specified on the
-{\bf \verb:--:sysconfdir} option that you specified on the {\bf ./configure}
-command. Normally the Director's configuration file is named {\bf bacula-dir.conf}.
-
-In general, the only change you must make is modify the FileSet resource so
-that the {\bf Include} configuration directive contains at least one line with
-a valid name of a directory (or file) to be saved.
-
-If you do not have a DLT tape drive, you will probably want to edit the
-Storage resource to contain names that are more representative of your actual
-storage device. You can always use the existing names as you are free to
-arbitrarily assign them, but they must agree with the corresponding names in
-the Storage daemon's configuration file.
-
-You may also want to change the email address for notification from the
-default {\bf root} to your email address.
-
-Finally, if you have multiple systems to be backed up, you will need a
-separate File daemon or Client specification for each system, specifying its
-name, address, and password. We have found that giving your daemons the same
-name as your system but post fixed with {\bf -fd} helps a lot in debugging.
-That is, if your system name is {\bf foobaz}, you would give the File daemon
-the name {\bf foobaz-fd}. For the Director, you should use {\bf foobaz-dir},
-and for the storage daemon, you might use {\bf foobaz-sd}.
-Each of your Bacula components {\bf must} have a unique name. If you
-make them all the same, aside fromt the fact that you will not
-know what daemon is sending what message, if they share the same
-working directory, the daemons temporary file names will not
-be unique, and you will get many strange failures.
+\ilink{Die Konfiguration des Directors}{_ChapterStart40}}
+\index[general]{Director!die Konfiguration des }
+\index[general]{Die Konfiguration des Directors}
+\addcontentsline{toc}{subsubsection}{Die Konfiguration des Directors}
+
+Der Director ist das zentrale Steuerungsprogramm aller anderen Dämon-Prozesse. Er terminiert und überwacht alle Sicherungsjobs.
+
+Die Konfigurationsdatei des Directors liegt in jenem Verzeichnis, das durch die Option {\bf \verb{--{sysconfdir} bei der Ausführung des {\bf ./configure}-Befehls angegeben wurde. Der Name dieser Konfigurationsdatei ist normalerweise {\bf bacula-dir.conf}.
+
+Im Allgemeinen muss darin nur die Ressource ``FileSet'' geändert werden, so dass ihre {\bf Include}-Direktive mindestens eine Zeile mit einem gültigen Verzeichnis (oder einer Datei) enthält, die/das zu sichern ist.
+
+Wenn Sie kein DLT-Bandlaufwerk haben, werden Sie möglicherweise die Storage-Resource ändern wollen, so dass diese Ihrem tatsächlichen Sicherungsgerät mehr entspricht. Sie können hier immer die tatsächlichen Namen verwenden und können diese auch beliebig zuweisen, doch müssen sie mit jenen übereinstimmen, die in der Konfigurationsdatei des Storage-Dämon angegeben sind.
+
+Möglicherweise wollen Sie auch die E-Mailadresse zur Benachrichtigung von der Vorgabe {\bf root} auf Ihre eigene ändern.
+
+Schließlich brauchen Sie, wenn Sie mehrere Rechner sichern wollen, für jedes System einen eigenen File-Dämon bzw. Client und müssen seinen Namen, seine Adresse und ein Passwort spezifizieren. Wir meinen, dass es die Fehlersuche sehr erleichtert, wenn wir den Dämonen den Namen des Rechners geben und ein {\bf -fd} anhängen. Wenn Ihr Rechner also z.B. {\bf foobaz} heißt, würden Sie den File-Dämon {\bf foobaz-fd} nennen. Der Director könnte {\bf foobaz-dir} heißen und der Storage-Dämon {\bf foobaz-sd}.
+Jede Ihrer Bacula-Komponenten \textbf{muss} einen eindeutigen Namen haben. Wenn Sie alle gleich benennen, werden Sie - abgesehen davon, dass sie nicht wissen werden, welcher Dämon Ihnen welche Botschaft schickt - eigenartige Fehlermeldungen erhalten, da die Namen ihrer Temporärdateien nicht eindeutig sind, sofern sie das gleiche Arbeitsverzeichnis benutzen.
\subsubsection*{
-\ilink{Configuring the Storage daemon}{_ChapterStart31}}
+\ilink{Die Konfiguration des Storage-Dämon}{_ChapterStart31}}
\index[general]{Daemon!Configuring the Storage }
-\index[general]{Configuring the Storage daemon }
-\addcontentsline{toc}{subsubsection}{Configuring the Storage daemon}
-
-The Storage daemon is responsible, at the Director's request, for accepting
-data from a File daemon and placing it on Storage media, or in the case of a
-restore request, to find the data and send it to the File daemon.
-
-The Storage daemon's configuration file is found in the directory specified on
-the {\bf \verb:--:sysconfdir} option that you specified on the {\bf ./configure}
-command. By default, the Storage daemon's file is named {\bf bacula-sd.conf}.
-Edit this file to contain the correct Archive device names for any tape
-devices that you have. If the configuration process properly detected your
-system, they will already be correctly set. These Storage resource name and
-Media Type must be the same as the corresponding ones in the Director's
-configuration file {\bf bacula-dir.conf}. If you want to backup to a file
-instead of a tape, the Archive device must point to a directory in which the
-Volumes will be created as files when you label the Volume.
+\index[general]{Die Konfiguration des Storage-Dämon}
+\addcontentsline{toc}{subsubsection}{Die Konfiguration des Storage-Dämon}
+
+Auf Veranlassung des Director-Prozesses ist der Storage-Dämon für die Übernahme der Daten vom File-Dämon und ihrer Speicherung auf dem Sicherungsmedium verantwortlich, bzw. im Falle einer Wiederherstellung für das Finden und die Übergabe der Daten an den File-Dämon.
+
+Die Konfigurationsdatei der Storage-Dämons ist in dem Verzeichnis, das bei Ausführung des {\bf ./configure}-Befehls mit der {\bf \verb{--{sysconfdir}-Option angegeben wurde und heißt vorgabemäßig {\bf bacula-sd.conf}. Bearbeiten Sie diese Datei, damit sie die korrekten Archivierungsgerätenamen für jedes Ihrer Bandgeräte enthält. Wenn bei der Konfiguration Ihr System richtig erkannt wurde, werden sie schon richtig gesetzt sein. Die Namen dieser Storage-Resourcen und der Media Type müssen mit jenen übereinstimmen, die in der Konfigurationsdatei des Directors stehen. Wenn Sie in eine Datei anstatt auf ein Band sichern wollen, muss als Archive-Gerät ein Verzeichnis angegeben sein, in dem dann die Volumes erzeugt werden und schließlich die Dateien, sobald ein Volume gelabelt wird.
+
\label{ConfigTesting}
-\subsection*{Testing your Configuration Files}
-\index[general]{Testing your Configuration Files }
-\index[general]{Files!Testing your Configuration }
-\addcontentsline{toc}{subsection}{Testing your Configuration Files}
+\subsection*{Test der Konfigurationsdateien}
+\index[general]{Test der Konfigurationsdateien}
+\index[general]{Konfigurationsdateien!Test der }
+\addcontentsline{toc}{subsection}{Test der Konfigurationsdateien}
-You can test if your configuration file is syntactically correct by running
-the appropriate daemon with the {\bf -t} option. The daemon will process the
-configuration file and print any error messages then terminate. For example,
-assuming you have installed your binaries and configuration files in the same
-directory.
+Sie können die Konfigurationsdateien auf korrekte Syntax testen, indem sie den entsprechenden Dämon mit der {\bf -t}-Option starten. Der Dämon wird die Konfigurationsdatei abarbeiten, gegebenenfalls eine Fehlermeldung ausgeben und sich dann beenden. Das folgende Beispiel geht davon aus, dass die Programm- und die Konfigurationsdateien im gleichen Verzeichnis installiert sind.
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-will test the configuration files of each of the main programs. If the
-configuration file is OK, the program will terminate without printing
-anything. Please note that, depending on the configure options you choose,
-some, or even all, of the three last commands will not be available on your
-system. If you have installed the binaries in traditional Unix locations
-rather than a single file, you will need to modify the above commands
-appropriately (no ./ in front of the command name, and a path in front of the
-conf file name).
+Hiermit werden alle Konfigurationsdateien der wichtigsten Programme getestet. Sind diese in Ordnung, beendet sich das Programm, ohne irgendetwas auszugeben. Beachten sie bitte, dass je nach gewählten Konfigurationsoptionen einige oder sogar alle der letzten drei Befehle auf Ihrem System nicht verfügbar sein werden. Wenn Sie die ausführbaren Dateien in die üblichen Unix-Verzeichnisse statt in ein einziges Verzeichnis installiert haben, müssen Sie die obigen Befehle entsprechend anpassen (das ``./'' vor dem Befehlsname weglassen und den Pfad vor den Namen der Konfigurationsdatei angeben).
+
\label{TapeTesting}
-\subsection*{Testing Bacula Compatibility with Your Tape Drive}
-\index[general]{Drive!Testing Bacula Compatibility with Your Tape }
-\index[general]{Testing Bacula Compatibility with Your Tape Drive }
-\addcontentsline{toc}{subsection}{Testing Bacula Compatibility with Your Tape
-Drive}
-
-Before spending a lot of time on Bacula only to find that it doesn't work
-with your tape drive, please read the \ilink{btape -- Testing Your Tape
-Drive}{_ChapterStart27} chapter of this manual. If you have a modern
-standard SCSI tape drive on a Linux or Solaris, most likely it will work,
-but better test than be sorry. For FreeBSD (and probably other xBSD
-flavors), reading the above mentioned tape testing chapter is a must.
-Also, for FreeBSD, please see \elink{The FreeBSD
-Diary}{http://www.freebsddiary.org/bacula.php} for a detailed description
-on how to make Bacula work on your system. In addition, users of FreeBSD
-prior to 4.9-STABLE dated Mon Dec 29 15:18:01 2003 UTC who plan to use tape
-devices, please see the file {\bf platforms/freebsd/pthreads-fix.txt} in
-the main Bacula directory concerning important information concerning
-compatibility of Bacula and your system. \label{notls}
-
-\subsection*{Get Rid of the /lib/tls Directory}
-\index[general]{Directory!Get Rid of the /lib/tls }
-\index[general]{Get Rid of the /lib/tls Directory }
-\addcontentsline{toc}{subsection}{Get Rid of the /lib/tls Directory}
-
-The new pthreads library {\bf /lib/tls} installed by default on recent Red Hat
-systems running kernel 2.4.x is defective. You must remove it or rename it,
-then reboot your system before running Bacula otherwise after a week or so of
-running, Bacula will either block for long periods or deadlock entirely.
-You may want to use the loader environment variable override rather
-than removing /lib/tls. Please see \ilink{ Supported Operating
-Systems}{SupportedOSes} for more
-information on this problem.
-
-This problem does not seem to occur on systems running 2.6.x kernels.
+\subsection*{Test der Kompatibilität von Bacula mit Ihrem Bandlaufwerk}
+\index[general]{Bandlaufwerk! Kompatibilitätstest}
+\index[general]{Test der Kompatibilität von Bacula mit Ihrem Bandlaufwerk }
+\addcontentsline{toc}{subsection}{Test der Kompatibilität von Bacula mit Ihrem Bandlaufwerk}
+
+Bevor Sie viel Zeit mit Bacula verschwenden, um schließlich herauszufinden, dass das Programm doch nicht mit Ihrem Bandlaufwerk zusammenarbeitet, lesen Sie bitte das Kapitel \ilink{btape -- Test Ihres Bandlaufwerkes}{_ChapterStart27} in diesem Handbuch.
+
+Wenn Sie ein neueres SCSI-Bandlaufwerk unter Linux oder Solaris benutzen, wird Bacula vermutlich funktionieren, aber probieren Sie das lieber vorher aus. Benutzer von FreeBSD (und möglicherweise andere xBSD-Varianten) müssen das oben erwähnte Kapitel lesen. Für FreeBSD gibt es unter \elink{The FreeBSD Diary}{http://www.freebsddiary.org/bacula.php} eine eingehende Beschreibung, wie man Bacula auf Ihrem System zum Laufen bringt. Benutzer von FreeBSD in einer Version vor 4.9-STABLE vom Montag, dem 29.12.2003, 15:18:01, die vorhaben ein Bandlaufwerk zu verwenden, sollten ausserdem die Datei {\bf platforms/freebsd/pthreads-fix.txt} in Baculas Hauptverzeichnis lesen. Darin sind wichtige Informationen zur Kompatibilität von Bacula und Ihrem System.
+
+\label{notls}
+
+\subsection*{Das /lib/tls Verzeichnis entfernen}
+\index[general]{Das /lib/tls Verzeichnis entfernen }
+\addcontentsline{toc}{subsection}{Das /lib/tls Verzeichnis entfernen}
+
+Die neue Pthreads-Bibliothek {\bf /lib/tls}, welche standardmäßig von neueren ``RedHat''-Systemen (Kernelversion 2.4.x) installiert wird, ist fehlerhaft. Dieses Verzeichnis muss entfernt oder umbenannt werden, bevor Bacula dann nach einem Neustart lauffähig ist. Geschieht dies nicht, wird sich Bacula nach etwa einer Woche Laufzeit entweder für längere Zeitspannen oder dauerhaft blockieren. Man wird hier wohl eher die entsprechende Umgebungsvariable überschreiben, anstatt das Verzeichnis /lib/tls zu entfernen. Mehr zu diesem Problem im Kapitel \ilink{Unterstützte Betriebssysteme}{SupportedOSes}.
+
+Auf Systemen mit Kernel-Version 2.6.x scheint dieses Problem nicht aufzutreten.
\label{Running1}
-\subsection*{Running Bacula}
-\index[general]{Bacula!Running }
-\index[general]{Running Bacula }
-\addcontentsline{toc}{subsection}{Running Bacula}
+\subsection*{Bacula in Betrieb}
+\index[general]{Bacula in Betrieb }
+\addcontentsline{toc}{subsection}{Bacula in Betrieb}
-Probably the most important part of running Bacula is being able to restore
-files. If you haven't tried recovering files at least once, when you actually
-have to do it, you will be under a lot more pressure, and prone to make
-errors, than if you had already tried it once.
+Der vielleicht wichtigste Teil beim Betrieb on Bacula ist die Fähigkeit, Dateien wiederherzustellen. Wenn Sie dies nicht wenigstens einmal ausprobiert haben, bevor Sie tatsächlich gezwungen sind, es zu tun, werden Sie viel mehr unter Druck stehen und dazu neigen, Fehler zu machen, als wenn sie diesen Vorgang schon einmal getestet haben.
-To get a good idea how to use Bacula in a short time, we {\bf strongly}
-recommend that you follow the example in the
-\ilink{Running Bacula Chapter}{_ChapterStart1} of this manual where
-you will get detailed instructions on how to run Bacula.
+Um eine Vorstellung davon zu bekommen, wie man Bacula in kurzer Zeit zum Laufen bringt empfehlen wir \textbf{dringend}, das Beispiel im Kapitel \ilink{Running Bacula Chapter}{_ChapterStart1} in diesem Handbuch nachzuvollziehen, wo im einzelnen erklärt wird, wie man Bacula laufen lässt.
\subsection*{Log Rotation}
\index[general]{Rotation!Log }
\index[general]{Log Rotation }
\addcontentsline{toc}{subsection}{Log Rotation}
-If you use the default {\bf bacula-dir.conf} or some variation of it, you will
-note that it logs all the Bacula output to a file. To avoid that this file
-grows without limit, we recommend that you copy the file {\bf logrotate} from
-the {\bf scripts/logrotate} to {\bf /etc/logrotate.d/bacula}. This will cause
-the log file to be rotated once a month and kept for a maximum of 5 months.
-You may want to edit this file to change the default log rotation preferences.
+
+Wenn Sie die vorgegebene {\bf bacula-dir.conf} oder eine Abwandlung davon benutzen, werden Sie bemerken, dass alle Ausgaben von Bacula in eine Datei gespeichert werden. Um zu verhindern, dass diese Datei ohne Grenze wächst, empfehlen wir, die Datei {\bf logrotate} aus dem Verzeichnis {\bf scripts/logrotate} nach {\bf /etc/logrotate.d/bacula} zu kopieren. Dadurch wird die Logdatei einmal im Monat rotiert und höchstens fünf Monate lang erhalten. Um die Logrotation Ihren Wünschen anzupassen, können Sie diese Datei bearbeiten.
\subsection*{Log Watch}
\index[general]{Watch!Log}
\index[general]{Log Watch}
\addcontentsline{toc}{subsection}{Log Watch}
-Some systems such as RedHat and Fedora run the logwatch program
-every night, which does an analysis of your log file and sends an
-email report. If you wish to include the output from your Bacula
-jobs in that report, please look in the {\bf scripts/logwatch}
-directory. The {\bf README} file in that directory gives a brief
-explanation on how to install it and what kind of output to expect.
-
+Auf manchen Systemen wie RedHat und Fedora läuft jede Nacht ein Logwatch-Programm, das Ihre Log-Dateien analysiert und per E-Mail berichtet. Wenn Sie die Ausgaben Ihrer Bacula-Sicherungsjobs diesen Berichten hinzufügen wollen, werfen sie einen Blick in das Verzeichnis {\bf scripts/logwatch}. In der {\bf README}-Datei in diesem Verzeichnis wird kurz erklärt, wie man es installiert und welche Ausgaben zu erwarten sind.
\subsection*{Disaster Recovery}
\index[general]{Recovery!Disaster }
\index[general]{Disaster Recovery }
\addcontentsline{toc}{subsection}{Disaster Recovery}
-If you intend to use Bacula as a disaster recovery tool rather than simply a
-program to restore lost or damaged files, you will want to read the
-\ilink{Disaster Recovery Using Bacula Chapter}{_ChapterStart38} of
-this manual.
+Wenn sie vorhaben, Bacula eher als Werkzeug zur Wiederherstellung Ihres Systems im Notfall, als nur dazu zu verwenden, beschädigte oder verlorengegangene Dateien wiederherzustellen, werden sie vielleicht das Kapitel \ilink{Disaster Recovery Using Bacula Chapter}{_ChapterStart38} in diesem Handbuch lesen wollen.
-In any case, you are strongly urged to carefully test restoring some files
-that you have saved rather than wait until disaster strikes. This way, you
-will be prepared.
+Auf jeden Fall raten wir Ihnen dringend, die Wiederherstellung einiger gesicherte Dateien zu testen anstatt zu warten, bis ein Notfall eintritt.
%%
%%
-\section*{System Requirements}
+\section*{Systemvoraussetzungen}
\label{_ChapterStart51}
-\index[general]{System Requirements }
-\index[general]{Requirements!System }
-\addcontentsline{toc}{section}{System Requirements}
+\index[general]{Systemvoraussetzungen }
+\index[general]{Voraussetzungen!des System }
+\addcontentsline{toc}{section}{Systemvoraussetzungen}
\label{SysReqs}
-\subsection*{System Requirements}
-\index[general]{System Requirements }
-\index[general]{Requirements!System }
-\addcontentsline{toc}{subsection}{System Requirements}
+\subsection*{Systemvoraussetzungen}
+\index[general]{Systemvoraussetzungen }
+\index[general]{Voraussetzungen!des System }
+\addcontentsline{toc}{subsection}{Systemvoraussetzungen}
\begin{itemize}
-\item {\bf Bacula} has been compiled and run on Linux RedHat, FreeBSD, and
- Solaris systems.
-\item It requires GNU C++ version 2.95 or higher to compile. You can try with
- other compilers and older versions, but you are on your own. We have
- successfully compiled and used Bacula on RH8.0/RH9/RHEL 3.0/FC3 with GCC 3.4.
-Note, in general GNU C++ is a separate package (e.g. RPM) from GNU C, so you
-need them both loaded. On RedHat systems, the C++ compiler is part of the
-{\bf gcc-c++} rpm package.
-\item There are certain third party packages that Bacula needs. Except for
- MySQL and PostgreSQL, they can all be found in the {\bf depkgs} and {\bf
- depkgs1} releases.
-\item If you want to build the Win32 binaries, you will need a Microsoft
- Visual C++ compiler (or Visual Studio). Although all components build
- (console has some warnings), only the File daemon has been tested.
-\item {\bf Bacula} requires a good implementation of pthreads to work. This
- is not the case on some of the BSD systems.
-\item The source code has been written with portability in mind and is mostly
- POSIX compatible. Thus porting to any POSIX compatible operating system
- should be relatively easy.
-\item The GNOME Console program is developed and tested under GNOME 2.x. It
- also runs under GNOME 1.4 but this version is deprecated and thus no longer
- maintained.
-\item The wxWidgets Console program is developed and tested with the latest
- stable ANSI or Unicode version of
- \elink{wxWidgets}{http://www.wxwidgets.org/} (2.6.1). It works fine with the
- Windows and GTK+-2.x version of wxWidgets, and should also work on other
- platforms supported by wxWidgets.
-\item The Tray Monitor program is developed for GTK+-2.x. It needs Gnome less
- or equal to 2.2, KDE greater or equal to 3.1 or any window manager supporting
- the
- \elink{ FreeDesktop system tray
- standard}{http://www.freedesktop.org/Standards/systemtray-spec}.
-\item If you want to enable command line editing and history, you will need
- to have /usr/include/termcap.h and either the termcap or the ncurses library
- loaded (libtermcap-devel or ncurses-devel).
-\item If you want to use DVD as backup medium, you will need to download the
- \elink{dvd+rw-tools 5.21.4.10.8}{http://fy.chalmers.se/~appro/linux/DVD+RW/},
- apply the \elink{patch}{http://cvs.sourceforge.net/viewcvs.py/*checkout*/bacula/bacula/patches/dvd+rw-tools-5.21.4.10.8.bacula.patch}
- to make these tools compatible with Bacula, then compile and install them.
- Do not use the dvd+rw-tools provided by your distribution, they will not work
- with Bacula.
+\item {\bf Bacula} ist auf RedHat-Linux, FreeBSD- und
+ Solaris-Systemen kompiliert und installiert worden.
+\item Zur Kompilierung benötigen Sie GNU C++ in der Version 2.95 oder höher. Sie können es mit anderen Compilern oder älteren Versionen versuchen, doch bieten wir hierfür keine Unterstützung.
+Wir haben Bacula unter RH8.0/RH9/RHEL 3.0/FC3 mit GCC 3.4 erfolgreich kompiliert und verwendet.
+Beachten Sie bitte, dass GNU C++ normalerweise ein eigenes Paket (z.B. RPM) neben GNU C ist. Auf RedHat-Systemen ist der C++-Compiler im RPM-Paket {\bf gcc-c++}.
+
+\item Bacula benötigt bestimmte Pakete von Drittanbietern, die Sie außer ``MySQL'' und ``PostgreSQL'' alle in den Releases {\bf depkgs} und {\bf depkgs1} finden.
+
+\item Wenn Sie die Win32-Quelldateien kompilieren wollen, benötigen Sie einen Microsoft
+ Visual C++-Compiler (oder Visual Studio). Obwohl sich alle Komponenten kompilieren lassen
+ (Console bringt einige Warnmeldungen), wurde nur der File-Dämon getestet.
+
+\item {\bf Bacula} erfordert um zu funktionieren eine gute Implementierung der PThreads. Auf einigen BSD-Systemen ist das nicht gegeben.
+
+\item Bei der Codierung achteten wir auf Portabilität. Daher ist der Code größtenteils POSIX-kompatibel und müsste sich daher verhältnismäßig leicht auf POSIX-Systeme übertragen lassen.
+
+\item Die GNOME-Konsole wurde unter GNOME 2.x. entwickelt und getestet. Sie läuft auch unter GNOME 1.4, doch ist diese Version veraltet und wird daher nicht mehr gewartet.
+
+\item Das wxWidgets-Konsolenprogramm wurde mit der letzten stabilen ANSI- (nicht Unicode-)Version von \elink{wxWidgets}{http://www.wxwidgets.org/} (2.6.1) entwickelt und getestet. Es arbeitet gut mit der Windows- und GTK+-Version von wxWidgets zusammen und sollte auch auf anderen Plattformen laufen, die wxWidgets unterstützen.
+
+\item Das Tray-Monitorprogramm wurde für GTK+-2.x entwickelt. Es benötigt Gnome in der Version 2.2 oder höher, KDE in der Version 3.1 oder höher oder einen anderen Window-Manager, der den Standard für System-Trays von \elink{FreeDesktop}{http://www.freedesktop.org/Standards/systemtray-spec} unterstützt.
+
+\item Wenn sie eine Kommandozeileneditierung und -history nutzen wollen, brauchen sie die Headerdatei /usr/include/termcap.h und müssen entweder die ``Termcap''- oder die ``Ncurses''- Bibliothek geladen haben (libtermcap-devel oder ncurses-devel).
+
+\item Wenn sie DVDs als Sicherungsmedium benutzen wollen, müssen Sie sich die \elink{dvd+rw-tools 5.21.4.10.10.8}{http://fy.chalmers.se/~appro/linux/DVD+RW/} herunterladen. Benutzen sie den \elink{patch}{http://cvs.sourceforge.net/viewcvs.py/*checkout*/bacula/bacula/patches/dvd+rw-tools-5.21.4.10.8.bacula.patch}, um diese Hilfsprogramme zu Bacula kompatibel zu machen, kompilieren und installieren Sie sie. Verwenden Sie nicht die ``dvd+rw-tools'', die Ihrer Distribution beiliegen. Diese werden zusammen mit Bacula nicht funktionieren.
\end{itemize}
%%
%%
-\section*{The Current State of Bacula}
+\section*{Baculas Stand}
\label{_ChapterStart2}
-\index[general]{Current State of Bacula }
-\addcontentsline{toc}{section}{Current State of Bacula}
+\index[general]{Baculas momentaner Stand }
+\addcontentsline{toc}{section}{Baculas momentaner Stand}
-In other words, what is and what is not currently implemented and functional.
+(was gegenwärtig implementiert und funktionsfähig ist und was nicht)
-\subsection*{What is Implemented}
-\index[general]{Implemented!What}
-\index[general]{What is Implemented}
-\addcontentsline{toc}{subsection}{What is Implemented}
+\subsection*{Was implementiert ist}
+\index[general]{implementiert!Was ist }
+\index[general]{Was implementiert ist }
+\addcontentsline{toc}{subsection}{Was implementiert ist}
\begin{itemize}
-\item Network backup/restore with centralized Director.
-\item Internal scheduler for automatic
- \ilink{Job}{JobDef} execution.
-\item Scheduling of multiple Jobs at the same time.
-\item You may run one Job at a time or multiple simultaneous Jobs.
-\item Job sequencing using priorities.
-\item Restore of one or more files selected interactively either for the
- current backup or a backup prior to a specified time and date.
-\item Restore of a complete system starting from bare metal. This is mostly
- automated for Linux systems and partially automated for Solaris. See
- \ilink{Disaster Recovery Using Bacula}{_ChapterStart38}. This is also
- reported to work on Win2K/XP systems.
-\item Listing and Restoration of files using stand-alone {\bf bls} and {\bf
- bextract} tool programs. Among other things, this permits extraction of files
- when Bacula and/or the catalog are not available. Note, the recommended way
- to restore files is using the restore command in the Console. These programs
- are designed for use as a last resort.
-\item Ability to recreate the catalog database by scanning backup Volumes
- using the {\bf bscan} program.
-\item
- \ilink{Console}{UADef} interface to the Director allowing complete
- control. A shell, GNOME GUI and wxWidgets GUI versions of the Console program
- are available. Note, the GNOME GUI program currently offers very few
- additional features over the shell program.
-\item Verification of files previously cataloged, permitting a Tripwire like
- capability (system break-in detection).
-\item CRAM-MD5 password authentication between each component (daemon).
-\item Configurable
- \ilink{TLS (ssl) encryption}{_ChapterStart61} between each component.
-\item A comprehensive and extensible
- \ilink{configuration file}{_ChapterStart40} for each daemon.
-\item Catalog database facility for remembering Volumes, Pools, Jobs, and
- Files backed up.
-\item Support for SQLite, PostgreSQL, and MySQL Catalog databases.
-\item User extensible queries to the SQLite, PostgreSQL and MySQL databases.
-\item Labeled Volumes, preventing accidental overwriting (at least by
- Bacula).
-\item Any number of Jobs and Clients can be backed up to a single Volume.
- That is, you can backup and restore Linux, Unix, Sun, and Windows machines to
- the same Volume.
-\item Multi-volume saves. When a Volume is full, {\bf Bacula} automatically
- requests the next Volume and continues the backup.
-\item
- \ilink{Pool and Volume}{PoolResource} library management
- providing Volume flexibility (e.g. monthly, weekly, daily Volume sets, Volume
- sets segregated by Client, ...).
-\item Machine independent Volume data format. Linux, Solaris, and Windows
- clients can all be backed up to the same Volume if desired.
-\item A flexible
- \ilink{ message}{MessageResource} handler including routing
- of messages from any daemon back to the Director and automatic email
- reporting.
-\item Multi-threaded implementation.
-\item Programmed to handle arbitrarily long filenames and messages.
-\item GZIP compression on a file by file basis done by the Client program if
- requested before network transit.
-\item Computation of MD5 or SHA1 signatures of the file data if requested.
-\item Saves and restores POSIX ACLs on most OSes if enabled.
-\item Autochanger support using a simple shell interface that can interface
- to virtually any autoloader program. A script for {\bf mtx} is provided.
-\item Support for autochanger barcodes -- automatic tape labeling from
- barcodes.
-\item Automatic support for multiple autochanger magazines either using
- barcodes or by reading the tapes.
-\item Support for multiple drive autochangers.
-\item Raw device backup/restore. Restore must be to the same device.
-\item All Volume blocks (approx 64K bytes) contain a data checksum.
-\item Access control lists for Consoles that permit restricting user access
- to only their data.
-\item Data spooling to disk during backup with subsequent write to tape from
- the spooled disk files. This prevents tape "shoe shine" during
- Incremental/Differential backups.
-\item Support for save/restore of files larger than 2GB.
-\item Support for 64 bit machines, e.g. amd64.
-\item Ability to encrypt communications between daemons using stunnel.
-\item Support ANSI and IBM tape labels.
-\item Support for Unicode filenames (e.g. Chinese) on Win32 machines on
- version 1.37.28 and greater.
-\item Consistent backup of open files on Win32 systems (WinXP, Win2003),
- but not Win2000, using Volume Shadow Copy (VSS).
+\item Sicherung/Wiederherstellung im Netzwerkes unter der Regie eines
+zentralen \textbf{Director}-Prozess.
+
+\item automatische Ausführung von
+ \ilink{Job}{JobDef}s nach einem festgelegten Zeitplan.
+
+\item Terminplanung für mehrere Jobs zur gleichen Zeit.
+
+\item die Möglichkeit einen oder mehrere Jobs zur gleichen Zeit auszuführen.
+
+\item zeitliche Staffelung der Jobs entsprechend ihrer Priorität.
+
+\item die Wiederherstellung einer oder mehrerer Dateien, die interaktiv
+aus der letzten Sicherung oder einer Sicherung vor einem festgelegten
+Zeitpunkt ausgewählt werden können.
+
+\item die Wiederherstellung aller Dateien eines Systems auf einer
+leeren Festplatte. Dieser Vorgang kann bei Linux- und Solaris-Systemen (mit
+Einschränkungen) größtenteils automatisch ablaufen. Näheres hierzu im Kapitel
+\ilink{``Disaster Recovery Using Bacula''}{_ChapterStart38}. Benutzer
+berichten, dass dies auch mit Win2K/XP-Systemen funktioniert.
+
+\item die Ermittlung und Wiederherstellung von Dateien mittels eigenständiger
+Hilfsprogramme wie {\bf bls} und {\bf bextract}. Unter anderem ist es damit
+möglich, Dateien wiederherzustellen, wenn Bacula und/oder die
+\textbf{Catalog}-Datenbank nicht verfügbar ist/sind. Beachten Sie aber, dass wir
+hierfür den ``restore''-Befehl an der \textbf{Console} empfehlen und diese
+Hilfsprogramme nur für den Notfall vorgesehen sind.
+
+\item die Möglichkeit, die \textbf{Catalog}-Datenbank durch Auslesen
+der \textbf{Volumes} mit dem Hilfsprogramm {\bf bscan} wieder herzustellen.
+
+\item eine \ilink{Konsolen}{UADef}-Schnittstelle zum \textbf{Director}, über die
+dieser vollkommen gesteuert werden kann. Die \textbf{Console} ist als
+Shell-Programm, GNOME-GUI und wxWidgets-GUI verfügbar. Beachten Sie bitte, dass
+das GNOME-GUI gegenüber dem Shell-Programm zur Zeit nur sehr wenige zusätzliche
+Funktionen aufweist.
+
+\item die Verifikation der Dateien, die zuvor in das
+\textbf{Catalog}-Verzeichnis aufgenommen wurden, erlaubt eine Funktionalität
+wie sie das Programm ``Tripwire'' hat (Intrusion Detection).
+
+\item die Authentifizierung der Komponenten (Dämonen) untereinander
+durch CRAM-MD5 Passwörter.
+
+\item eine konfigurierbare \ilink{TLS (ssl)-Verschlüsselung }{_ChapterStart61}
+zwischen den einzelnen Komponenten.
+
+\item leicht verständliche und erweiterbare
+\ilink{Konfigurationsdateien}{_ChapterStart40} für jeden einzelnen
+Dämonprozess.
+
+\item eine \textbf{Catalog}-Datenbank zur Aufzeichnung der \textbf{Volumes},
+\textbf{Pools}, \textbf{Jobs} und der Informationen über die gesicherten
+Dateien.
+
+\item Unterstützung von \textbf{SQLite}, \textbf{PostgreSQL} und
+\textbf{MySQL} \textbf{Catalog}-Datenbanksystemen.
+
+\item vom Benutzer erweiterbare Datenbankabfragen an \textbf{SQLite}-,
+\textbf{PostgreSQL} und \textbf{MySQL}-Datenbanksysteme.
+
+\item gekennzeichnete \textbf{Volumes}, die ein versehentliches
+Überschreiben (zumindest durch Bacula) verhindern.
+
+\item eine beliebige Anzahl verschiedener \textbf{Jobs} und
+\textbf{Clients} kann auf ein einzelnes \textbf{Volume} gesichert werden. Dies
+bedeutet, dass von Linux-, Unix-, Sun- und Windows-Rechnern auf das gleiche
+\textbf{Volume} gesichert werden kann. Das gleiche gilt für die
+Wiederherstellung.
+
+\item eine Sicherung kann sich über mehrere \textbf{Volumes} erstrecken. Sobald ein
+\textbf{Volume} voll ist, fordert {\bf Bacula} automatisch das nächste
+\textbf{Volume} an und setzt die Sicherung fort.
+
+\item die Verwaltung von \ilink{\textbf{Pools}
+und \textbf{Volumes}}{PoolResource} erlaubt einen anpassungsfähigen Umgang mit
+\textbf{Volumes} (z.B. Gruppen von \textbf{Volumes} für die monatliche,
+wöchentliche, tägliche Sicherung, Gruppen von \textbf{Volumes} für bestimmte
+\textbf{Clients}...).
+
+\item das Datenformat der \textbf{Volumes} ist systemunabhängig. Bei Bedarf
+können die Daten von Linux-, Solaris- und Windows-Clients in
+dasselbe \textbf{Volumen} gespeichert werden.
+
+\item ein konfigurierbares \ilink{Messages}-Handling.
+Dazu gehört der Versand von Botschaften aller Dämon-Prozesse an den \textbf{Director}
+und die automatische Benachrichtigung des Benutzers über das Mailsystem.
+
+\item Implementierung der Prozesse als Multithread-Programme.
+
+\item Programmtechnisch keine Begrenzung der Länge der Dateinamen oder
+der Botschaften.
+
+\item GZIP-Komprimierung für jede einzelne Datei, die schon der Client
+erledigt, sofern dies vor einer Übertragung im Netzwerk angefordert wird.
+
+\item bei Bedarf die Berechnung von MD5 oder SHA1 Signaturen der
+Dateidaten.
+
+\item POSIX ACLs werden - wenn aktiviert - unter den meisten Betriebssystemen gesichert und wiederhergestellt.
+
+\item die Unterstützung von Autochangern über ein einfache Shell-Schnittstelle.
+Damit ist es möglich, praktisch mit jedem Autoloader-Programm zu kommunizieren.
+Ein Skript für {\bf mtx} ist bereitgestellt.
+
+\item unterstützt Autochanger-Barcodes -- entsprechend der Barcodes
+wird das Band gekennzeichnet.
+
+\item automatische Unterstützung mehrerer Autochanger-Magazine. Hierbei wird entweder der Barcode oder das Band gelesen.
+
+\item Unterstützung von Autochangern mit mehreren Laufwerken
+
+\item Sicherung/Wiederherstellung als raw-Backup. Hierbei muß die Wiederherstellung auf den gleichen Datenträger erfolgen.
+
+\item jeder Datenblock (etwa 64KByte) der \textbf{Volumes} enthält die
+Prüfsumme der Daten.
+
+\item Zugangskontrolllisten für \textbf{Consolen}, die dem Benutzer einen Zugang nur zu den eigenen Daten erlauben.
+
+\item Zwischenspeicherung der zu sichernden Daten auf der Festplatte und
+fortlaufende Beschreibung des Bandes mit den zwischengespeicherten Daten
+verhindert den ``Schoe-Shine-Effekt'' bei einer inkrementiellen oder
+differentiellen Sicherung.
+
+\item Sicherung/Wiederherstellung von Dateien, die größer sind als 2GB.
+
+\item Unterstützung von 64Bit-Systemen wie z.B. AMD64.
+
+\item es ist möglich, die Kommunikation der Dämonen untereinander durch
+STunnel zu verschlüsseln.
+
+\item Unterstützung von ANSI- und IBM Band-Labels.
+
+\item Unterstützung von Unicode-Dateinamen (z.B. Chinesisch) auf Win32-Rechnern mit der Version 1.37.28 und höher.
+
+\item konsistente Sicherung von geöffneten Dateien von Win32-Systemen (WinXP, Win2003, nicht Win2000) durch Verwendung von Volume Shadow Copy (VSS).
+
\end{itemize}
-\subsection*{Advantages of Bacula Over Other Backup Programs}
-\index[general]{Advantages of Bacula Over Other Backup Programs }
-\index[general]{Programs!Advantages of Bacula Over Other Backup }
-\addcontentsline{toc}{subsection}{Advantages of Bacula Over Other Backup
- Programs}
+\subsection*{Die Vorteile von Bacula gegenüber anderen Sicherungsprogrammen}
+\index[general]{Die Vorteile von Bacula gegenüber anderen Sicherungsprogrammen}
+\index[general]{Sicherungsprogrammen!Die Vorteile von Bacula gegenüber anderen}
+\addcontentsline{toc}{subsection}{Die Vorteile von Bacula gegenüber anderen
+Sicherungsprogrammen}
\begin{itemize}
-\item Since there is a client for each machine, you can backup
- and restore clients of any type ensuring that all attributes
- of files are properly saved and restored.
-\item It is also possible to backup clients without any client
- software by using NFS or Samba. However, if possible, we
- recommend running a Client File daemon on each machine to be
- backed up.
-\item Bacula handles multi-volume backups.
-\item A full comprehensive SQL standard database of all files backed up. This
- permits online viewing of files saved on any particular Volume.
-\item Automatic pruning of the database (removal of old records) thus
- simplifying database administration.
-\item Any SQL database engine can be used making Bacula very flexible.
-\item The modular but integrated design makes Bacula very scalable.
-\item Since Bacula uses client file servers, any database or
- other application can be properly shutdown by Bacula using the
- native tools of the system, backed up, then restarted (all
- within a Bacula Job).
-\item Bacula has a built-in Job scheduler.
-\item The Volume format is documented and there are simple C programs to
- read/write it.
-\item Bacula uses well defined (IANA registered) TCP/IP ports -- no rpcs, no
- shared memory.
-\item Bacula installation and configuration is relatively simple compared to
- other comparable products.
-\item According to one user Bacula is as fast as the big major commercial
- applications.
-\item According to another user Bacula is four times as fast as another
- commercial application, probably because that application stores its catalog
- information in a large number of individual files rather than an SQL database
- as Bacula does.
-\item Aside from a GUI administrative interface, Bacula has a
- comprehensive shell administrative interface, which allows the
- administrator to use tools such as ssh to administrate any part of
- Bacula from anywhere (even from home).
-
-\item Bacula has a Rescue CD for Linux systems with the following features:
+\item da für jeden Rechner ein eigener Client existiert, können die Daten von Betriebssystemen aller Art gesichert und wiederhergestellt werden, wobei immer gewährleistet ist,
+dass ihre Dateiattribute korrekt gesichert und wiederhergestellt werden.
+
+\item Man kann auch Clients sichern ohne eine Client-Software zu benutzen und
+verwendet hierzu NFS oder Samba. Wir empfehlen jedoch, sofern möglich, auf jedem
+Rechner, von dem Daten gesichert werden sollen, einen eigenen File-Dämon laufen zu
+haben.
+
+\item Bacula kann mit Sicherungen umgehen, die auf mehrere Volumes verteilt
+sind.
+
+\item eine umfassende SQL-Datenbank aller gesicherter Dateien ermöglicht den Überblick über alle gespeicherte Dateien in jedem einzelnen Volume.
+
+\item automatische Bereinigung der Datenbank (die Entfernung alter Aufzeichnungen) und dadurch eine Vereinfachung der Datenbankadministration.
+
+\item durch die Verwendung beliebiger SQL-Datenbanksysteme ist Bacula sehr anpassungsfähig.
+
+\item durch den modularen, dabei aber einheitlichen Entwurf ist Bacula in hohem Maße skalierbar.
+
+\item da Bacula Dämonen auf den Client-Rechnern benutzt, ist es möglich, dort laufende Datenbank- oder sonstige Anwendungen mit systemeigenen Befehlen zu beenden und nach einer Sicherung die entsprechenden Anwendungen wieder zu starten. Dies alles kann aus einem einzigen Bacula-Job heraus geschehen.
+
+\item Bacula hat ein eingebautes Steuerungsprogramm für die Sicherungsjobs.
+
+\item Das Format der \textbf{Volumes} ist dokumentiert und es gibt einfache C-Programme mit denen sie gelesen und beschrieben werden können
+
+\item Bacula benutzt eindeutige (bei der IANA registrierte) TCP/IP-Ports -- also weder RPCs noch Shared Memory.
+
+\item Baculas Installation und Konfiguration ist gegenüber anderen vergleichbaren Produkten relativ einfach.
+
+\item laut einem unserer Benutzer ist Bacula genau so schnell wie die wichtigen großen kommerziellen Programme.
+
+\item laut einem anderen Benutzer ist Bacula vier mal so schnell wie eine andere kommerzielle Anwendung. Das vielleicht deswegen, weil diese Anwendung ihre Verzeichnisinformationen in vielen einzelnen Dateien anstatt in einer SQL-Datenbank speichert, wie Bacula es tut.
+
+\item neben der grafischen Benutzeroberfläche zur Verwaltung hat Bacula eine umfassende Shell-Schnittstelle für die Wartungsaufgaben, wobei der Administrator Werkzeuge wie z.B. ``ssh'' verwenden kann, um jeden Teil von Bacula von überall (sogar von Zuhause) zu administrieren.
+
+\item Bacula hat eine Rettungs-CD für Linux-Systeme mit den folgenden Eigenschaften:
\begin{itemize}
- \item You build it on your own system from scratch with one simple command:
- make -- well, then make burn.
- \item It uses your kernel
- \item It captures your current disk parameters and builds scripts that allow
- you to automatically repartition a disk and format it to put it back to what
- you had before.
- \item It has a script that will restart your networking (with the right IP
- address)
- \item It has a script to automatically mount your hard disks.
- \item It has a full Bacula FD statically linked
- \item You can easily add additional data/programs, ... to the disk.
+ \item Sie kompilieren sie von Grund auf auf ihrem eigenen System mit einem einzigen einfachen Befehl:
+ ``make'' (...OK, Sie brauchen dann noch ``make burn''...).
+ \item die Rettungs-CD verwendet Ihren Kernel
+ \item sie schreibt Skripte entsprechend der Parameter Ihrer Festplatte mit denen Sie diese automatisch repartitionieren und formatieren können, um den Ausgangszustand wieder herzustellen.
+
+ \item sie hat ein Skript, das Ihr Netzwerk wieder starten wird (mit der korrekten IP-Adresse)
+
+ \item sie hat ein Skript, mit dem Ihre Festplatten automatisch gemountet werden.
+
+ \item eine vollwertiger Bacula-FD ist statisch eingebunden
+
+ \item sie können der Rettungs-CD auf einfache Weise zusätzliche Daten und Programme hinzufügen.
\end{itemize}
\end{itemize}
-\subsection*{Current Implementation Restrictions}
-\index[general]{Current Implementation Restrictions }
-\index[general]{Restrictions!Current Implementation }
-\addcontentsline{toc}{subsection}{Current Implementation Restrictions}
+\subsection*{Einschränkungen der aktuellen Implementierung}
+\index[general]{Einschränkungen der aktuellen Implementierung }
+\index[general]{aktuelle Implementierung! Einschränkungen der}
+\addcontentsline{toc}{subsection}{Einschränkungen der aktuellen Implementierung}
\begin{itemize}
-\item Path and filenames longer than 260 characters on Win32 systems are
- not supported. They will be backed up, but they cannot be restored. By
- using the {\bf Portable=yes} directive in your FileSet, files with
- long names can be restored to Unix and Linux systems.
-
- Long filenames for Win32 will be implemented in a later version.
-\item If you have over 4 billion file entries stored in your database, the
- database FileId is likely to overflow. This is a monster database, but still
- possible. At some point, Bacula's FileId fields will be upgraded from 32 bits
- to 64 bits and this problem will go away. In the mean time, a good workaround
- is to use multiple databases.
-\item Files deleted after a Full save will be included in a restoration.
-\item File System Modules (configurable routines for saving/restoring special
- files) are not yet implemented.
-\item Data encryption of the Volume contents.
-\item Bacula cannot automatically restore files for a single Job
- from two or more different storage devices or different media types.
- That is, if you use more than one storage device or media type to
- backup a single job, the restore process will require some manual
- intervention.
-\end{itemize}
+\item Pfade und Dateinamen mit mehr als 260 Zeichen werden auf Win32-Systemen nicht unterstützt. Diese werden zwar gesichert, können aber nicht wiederhergestellt werden. Durch Verwendung der Direktive {\bf Portable=yes} in Ihrem FileSet können Dateien mit langen Namen auf Unix- bzw. Linux-Systemen wiederhergestellt werden.
+Lange Dateinamen für Win32-Systeme werden in einer späteren Version implementiert sein.
+
+\item Sollten Sie mehr als 4 Milliarden Dateieinträge in Ihrer Datenbank gespeichert haben, wird der FileID der Datenbank vermutlich überlaufen. Dies wäre eine ziemlich große Datenbank, aber immerhin ist sie denkbar. Irgendwann einmal wird das Feld für den FileID von Bacula von 32 auf 64 Bit erweitert werden und das Problem ist gelöst. In der Zwischenzeit ist die Verwendung mehrerer Datenbanken eine gute Lösung.
+
+\item Dateien, die nach einer Vollsicherung gelöscht wurden, werden bei einer Wiederherstellung eingeschlossen.
-\subsection*{Design Limitations or Restrictions}
+\item Datei-System-Module fehlen(dies wären konfigurierbare Routinen, um spezielle Dateien zu sichern/wiederherzustellen).
+
+\item Verschlüsselung des Dateninhalts der \textbf{Volumes}.
+
+\item Bacula kann die Dateien eines einzelnen Jobs nicht von zwei oder mehreren Speichergeräten oder verschiedenen Speichermedien wiederherstellen. Daher wird eine Wiederherstellung einige Handarbeit erfordern, wenn sie auf mehr als ein Sicherungsgerät oder verschiedene Medientypen speichern.
+
+ \end{itemize}
+
+\subsection*{Grenzen und Beschränkungen des Software Design}
\index[general]{Restrictions!Design Limitations or }
\index[general]{Design Limitations or Restrictions }
\addcontentsline{toc}{subsection}{Design Limitations or Restrictions}
\begin{itemize}
-\item Names (resource names, Volume names, and such) defined in Bacula
- configuration files are limited to a fixed number of characters. Currently
- the limit is defined as 127 characters. Note, this does not apply to
- filenames, which may be arbitrarily long.
-\item On Win32 machines filenames are limited by the non-Unicode Windows
- API that we use to 260 characters. This is planned to be corrected in
- a future version by switching to the Unicode API.
+\item Namen (\textbf{Resource}-Namen, \textbf{Volume}-Names und ähnliche) in Baculas Konfigurationsdateien sind auf eine bestimmte Länge beschränkt . Momentan liegt die Grenze bei 127 Zeichen. Beachten Sie bitte, dass diese Einschränkungen nicht die Dateinamen betrifft, die beliebig lang sein können.
+
+\item Durch die Nicht-Unicode Windows API, die wir auf Win32-Maschinen verwenden, sind wir bei Dateinamen auf 260 Zeichen beschränkt. Wir planen dies in einer zukünftigen Version zu korrigieren, indem wir die Unicode-API verwenden.
+
\end{itemize}
%%
%%
-\section*{Supported Tape Drives}
+\section*{Unterstützte Bandlaufwerke}
\label{_ChapterStart19}
-\index[general]{Drives!Supported Tape }
-\index[general]{Supported Tape Drives }
-\addcontentsline{toc}{section}{Supported Tape Drives}
+\index[general]{Bandlaufwerke!unterstützte}
+\index[general]{Unterstützte Bandlaufwerke }
+\addcontentsline{toc}{section}{Unterstützte Bandlaufwerke}
-\subsection*{Supported Tape Drives}
+\subsection*{Unterstützte Bandlaufwerke}
\label{SupportedDrives}
-\index[general]{Drives!Supported Tape }
-\index[general]{Supported Tape Drives }
-\addcontentsline{toc}{subsection}{Supported Tape Drives}
-
-Even if your drive is on the list below, please check the
-\ilink{Tape Testing Chapter}{btape1} of this manual for
-procedures that you can use to verify if your tape drive will work with
-Bacula. If your drive is in fixed block mode, it may appear to work with
-Bacula until you attempt to do a restore and Bacula wants to position the
-tape. You can be sure only by following the procedures suggested above and
-testing.
-
-It is very difficult to supply a list of supported tape drives, or drives that
-are known to work with Bacula because of limited feedback (so if you use
-Bacula on a different drive, please let us know). Based on user feedback, the
-following drives are known to work with Bacula. A dash in a column means
-unknown:
+\index[general]{Bandlaufwerke!unterstützte}
+\index[general]{Unterstützte Bandlaufwerke }
+\addcontentsline{toc}{subsection}{Unterstützte Bandlaufwerke}
+
+Auch wenn Ihr Bandlaufwerk in der untenstehenden Liste eingetragen ist, lesen Sie bitte im Kapitel \ilink{Test der Bandlaufwerke}{btape1} in diesem Handbuch wie Sie sich vergewissern können, dass Ihr Bandlaufwerk mit Bacula zusammen funktionieren wird.
+
+Wenn Ihr Laufwerk im festen Block-Modus arbeitet, könnte es zunächst so aussehen, als ob es funkioniert, bis sie dann eine Wiederherstellung machen und Bacula versucht, das Band zu positionieren. Sie können nur sicher sein, wenn sie die oben vorgeschlagenen Verfahren befolgen und testen.
+
+Weil wir so wenige Rückmeldungen haben, ist es sehr schwierig, eine Liste der unterstützten Laufwerke oder zumindest jener zu liefern, mit denen Bacula funktioniert (wenn sie also Bacula mit einem anderen Laufwerk benutzen, melden Sie es bitte). Laut unseren Benutzern arbeiten die folgenden Laufwerke unter Bacula. Ein Strich in einer Spalte bedeutet ``unbekannt''.
\addcontentsline{lot}{table}{Supported Tape Drives}
-\begin{longtable}{|p{2.0in}|l|l|p{2.5in}|l|}
+%war: zwei mal 2.5 in
+\begin{longtable}{|p{1.0in}|l|l|p{1.5in}|l|}
\hline
-\multicolumn{1}{|c| }{\bf OS } & \multicolumn{1}{c| }{\bf Man. } &
-\multicolumn{1}{c| }{\bf Media } & \multicolumn{1}{c| }{\bf Model } &
-\multicolumn{1}{c| }{\bf Capacity } \\
+\multicolumn{1}{|c| }{\bf BS } & \multicolumn{1}{c| }{\bf Herst.} &
+\multicolumn{1}{c| }{\bf Media } & \multicolumn{1}{c| }{\bf Modell } &
+\multicolumn{1}{c| }{\bf Kapazität } \\
\hline {- } & {ADIC } & {DLT } & {Adic Scalar 100 DLT } & {100GB } \\
\hline {- } & {ADIC } & {DLT } & {Adic Fastor 22 DLT } & {- } \\
- \hline {FreeBSD 5.4-RELEASE-p1 amd64 } & {Certance} & {LTO } & {AdicCertance CL400 LTO Ultrium 2 } & {200GB } \\
\hline {- } & {- } & {DDS } & {Compaq DDS 2,3,4 } & {- } \\
- \hline {SuSE 8.1 Pro} & {Compaq} & {AIT } & {Compaq AIT 35 LVD } & {35/70GB } \\
- \hline {- } & {Exabyte } & {- } & {Exabyte drives less than 10 years old } & {- } \\
- \hline {- } & {Exabyte } & {- } & {Exabyte VXA drives } & {- } \\
+ \hline {- } & {Exabyte } & {- } & {Exabyte LWe, \lt 10 Jahre alt } & {- } \\
+ \hline {- } & {Exabyte } & {- } & {Exabyte VXA LWe } & {- } \\
\hline {- } & {HP } & {Travan 4 } & {Colorado T4000S } & {- } \\
- \hline {- } & {HP } & {DLT } & {HP DLT drives } & {- } \\
- \hline {- } & {HP } & {LTO } & {HP LTO Ultrium drives } & {- } \\
- \hline {- } & {IBM} & {??} & {3480, 3480XL, 3490, 3490E, 3580 and 3590 drives} & {- } \\
+ \hline {- } & {HP } & {DLT } & {HP DLT LWe } & {- } \\
+ \hline {- } & {HP } & {LTO } & {HP LTO Ultrium LWe } & {- } \\
+ \hline {- } & {IBM} & {??} & {3480, 3480XL, 3490, 3490E, 3580 and 3590 LWe} & {- } \\
\hline {FreeBSD 4.10 RELEASE } & {HP } & {DAT } & {HP StorageWorks DAT72i } & {- } \\
+ \hline {FreeBSD 5.4-RELEASE-p1 amd64 } & {Certance} & {LTO } & {AdicCertance CL400 LTO Ultrium 2 } & {200GB } \\
\hline {- } & {Overland } & {LTO } & {LoaderXpress LTO } & {- } \\
+ \hline {SuSE 8.1 Pro} & {Compaq} & {AIT } & {Compaq AIT 35 LVD } & {35/70GB } \\
\hline {- } & {Overland } & {- } & {Neo2000 } & {- } \\
- \hline {- } & {OnStream } & {- } & {OnStream drives (see below) } & {- } \\
- \hline {FreeBSD 4.11-Release} & {Quantum } & {SDLT } & {SDLT320 } & {160/320GB } \\
+ \hline {- } & {OnStream } & {- } & {OnStream LWe (siehe unten) } & {- } \\
\hline {- } & {Quantum } & {DLT } & {DLT-8000 } & {40/80GB } \\
\hline {Linux } & {Seagate } & {DDS-4 } & {Scorpio 40 } & {20/40GB } \\
\hline {FreeBSD 4.9 STABLE } & {Seagate } & {DDS-4 } & {STA2401LW } & {20/40GB } \\
- \hline {FreeBSD 5.2.1 pthreads patched RELEASE } & {Seagate } & {AIT-1 } & {STA1701W} & {35/70GB } \\
+ \hline {FreeBSD 5.2.1, Pthreads gepatcht } & {Seagate } & {AIT-1 } & {STA1701W} & {35/70GB } \\
\hline {Linux } & {Sony } & {DDS-2,3,4 } & {- } & {4-40GB } \\
\hline {Linux } & {Tandberg } & {- } & {Tandbert MLR3 } & {- } \\
\hline {FreeBSD } & {Tandberg } & {- } & {Tandberg SLR6 } & {- } \\
+ \hline {FreeBSD 4.11-Release} & {Quantum } & {SDLT } & {SDLT320 } & {160/320GB } \\
\hline {Solaris } & {Tandberg } & {- } & {Tandberg SLR75 } & {- } \\
\hline
\end{longtable}
-There is a list of \ilink{supported autochangers}{Models} in the Supported
-Autochangers chapter of this document, where you will find other tape drives
-that work with Bacula.
+Es gibt eine Liste mit \ilink{unterstützten Autochanger}{Models} im Kapitel ``Unterstützte Autochanger'' in diesem Dokument, in dem noch weitere Laufwerke aufgeführt sind, die mit Bacula funktionieren.
-\subsection*{Unsupported Tape Drives}
+\subsection*{Nicht unterstützte Bandlaufwerke}
\label{UnSupportedDrives}
-\index[general]{Unsupported Tape Drives }
-\index[general]{Drives!Unsupported Tape }
-\addcontentsline{toc}{subsection}{Unsupported Tape Drives}
-
-Previously OnStream IDE-SCSI tape drives did not work with Bacula. As of
-Bacula version 1.33 and the osst kernel driver version 0.9.14 or later, they
-now work. Please see the testing chapter as you must set a fixed block size.
-
-QIC tapes are known to have a number of particularities (fixed block size, and
-one EOF rather than two to terminate the tape). As a consequence, you will
-need to take a lot of care in configuring them to make them work correctly
-with Bacula.
-
-\subsection*{FreeBSD Users Be Aware!!!}
-\index[general]{FreeBSD Users Be Aware }
-\index[general]{Aware!FreeBSD Users Be }
-\addcontentsline{toc}{subsection}{FreeBSD Users Be Aware!!!}
-
-Unless you have patched the pthreads library on FreeBSD 4.11 systems, you will
-lose data when Bacula spans tapes. This is because the unpatched pthreads
-library fails to return a warning status to Bacula that the end of the tape is
-near. This problem is fixed in FreeBSD systems released after 4.11. Please see the
-\ilink{Tape Testing Chapter}{FreeBSDTapes} of this manual for
-{\bf important} information on how to configure your tape drive for
-compatibility with Bacula.
-
-\subsection*{Supported Autochangers}
-\index[general]{Autochangers!Supported }
-\index[general]{Supported Autochangers }
-\addcontentsline{toc}{subsection}{Supported Autochangers}
-
-For information on supported autochangers, please see the
+\index[general]{Nicht unterstützte Bandlaufwerke }
+\index[general]{Bandlaufwerke!nicht unterstützte }
+\addcontentsline{toc}{subsection}{Nicht unterstützte Bandlaufwerke}
+
+Bisher funktionierten OnStream IDE-SCSI Bandlaufwerke nicht unter Bacula. Seit der Bacula-Version 1.33 und der Version 0.9.14 des osst-Kerneldrivers funktionieren sie nun. Da sie eine feste Blockgröße einstellen müssen, beachten sie bitte das Kapitel zum Testen.
+
+Von QIC-Bändern weiß man, dass sie einige Besonderheiten haben (feste Blockgröße, eher ein EOF als zwei zur Markierung des Bandendes). Sie müssen diese daher sehr sorgfältig konfigurieren, wenn sie korrekt mit Bacula arbeiten sollen.
+
+\subsection*{Warnung für FreeBSD-Benutzer!!!}
+\index[general]{Warnung für FreeBSD-Benutzer!!! }
+\index[general]{FreeBSD-Benutzer!Warnung für}
+\addcontentsline{toc}{subsection}{Warnung für FreeBSD-Benutzer!!!}
+
+Solange die Pthreads-Bibliothek der meisten FreeBSD-Systeme nicht gepatcht ist, werden Sie Daten verlieren, wenn Sie mit Bacula Bänder vollschreiben. Die ungepatchte Pthreads-Bibliothek ist nicht in der Lage, Bacula eine Warnung zurückzugeben, wenn das Bandende naht. Beachten Sie bitte das Kapitel zum Test der Bänder in diesem Handbuch mit \textbf{wichtigen} Informationen, wie man das Bandlaufwerk so konfiguriert, dass es zu Bacula kompatibel ist.
+
+
+\subsection*{Unterstützte Autochanger}
+\index[general]{Autochanger!unterstützte }
+\index[general]{Unterstützte Autochanger }
+\addcontentsline{toc}{subsection}{Unterstützte Autochanger}
+
+
+Informationen zu den unterstützten Autochangern stehen im Abschnitt
\ilink{Autochangers Known to Work with Bacula}{Models}
-section of the Supported Autochangers chapter of this manual.
-
-\subsection*{Tape Specifications}
-\index[general]{Specifications!Tape}
-\index[general]{Tape Specifications}
-\addcontentsline{toc}{subsection}{Tape Specifications}
-If you want to know what tape drive to buy that will work with Bacula,
-we really cannot tell you. However, we can say that if you are going
-to buy a drive, you should try to avoid DDS drives. The technology is
-rather old and DDS tape drives need frequent cleaning. DLT drives are
-generally much better (newer technology) and do not need frequent
-cleaning.
-
-Below, you will find a table of DLT and LTO tape specifications that will
-give you some idea of the capacity and speed of modern tapes. The
-capacities that are listed are the native tape capacity without compression.
-All modern drives have hardware compression, and manufacturers often list
-compressed capacity using a compression ration of 2:1. The actual compression
-ratio will depend mostly on the data you have to backup, but I find that
-1.5:1 is a much more reasonable number (i.e. multiply the value shown in
-the table by 1.5 to get a rough average of what you will probably see).
-The transfer rates are rounded to the nearest GB/hr. All values are provided
-by various manufacturers.
-
-The Media Type is what is designated by the manufacturers and you are not
-required to use (but you may) the same name in your Bacula conf resources.
-
-
-\begin{tabular}{|c|c|c|c}
-Media Type & Drive Type & Media Capacity & Transfer Rate \\ \hline
-DDS-1 & DAT & 2 GB & ?? GB/hr \\ \hline
-DDS-2 & DAT & 4 GB & ?? GB/hr \\ \hline
-DDS-3 & DAT & 12 GB & 5.4 GB/hr \\ \hline
-Travan 40 & Travan & 20 GB & ?? GB/hr \\ \hline
-DDS-4 & DAT & 20 GB & 11 GB/hr \\ \hline
-VXA-1 & Exabyte & 33 GB & 11 GB/hr \\ \hline
-DAT-72 & DAT & 36 GB & 13 GB/hr \\ \hline
-DLT IV & DLT8000 & 40 GB & 22 GB/hr \\ \hline
-VXA-2 & Exabyte & 80 GB & 22 GB/hr \\ \hline
-Half-high Ultrum 1 & LTO 1 & 100 GB & 27 GB/hr \\ \hline
-Ultrium 1 & LTO 1 & 100 GB & 54 GB/hr \\ \hline
-Super DLT 1 & SDLT 220 & 110 GB & 40 GB/hr \\ \hline
-VXA-3 & Exabyte & 160 GB & 43 GB/hr \\ \hline
-Super DLT I & SDLT 320 & 160 GB & 58 GB/hr \\ \hline
-Ultrium 2 & LTO 2 & 200 GB & 108 GB/hr \\ \hline
-Super DLT II & SDLT 600 & 300 GB & 127 GB/hr \\ \hline
-VXA-4 & Exabyte & 320 GB & 86 GB/hr \\ \hline
-Ultrium 3 & LTO 3 & 400 GB & 216 GB/hr \\ \hline
-\end{tabular}
+im Kapitel ``Unterstützte Autochanger'' dieses Handbuches.
+
+\subsection*{Band-Spezifikationen}
+\index[general]{Spezifikationen!Band-}
+\index[general]{Band-Spezifikationen}
+\addcontentsline{toc}{subsection}{Band-Spezifikationen}
+Wir können Ihnen wirklich nicht sagen welche Bänder zusammen mit Bacula funktionieren werden. Wenn Sie ein Laufwerk kaufen wollen, sollten Sie versuchen, DDS-Laufwerke zu vermeiden. Deren Technologie ist relativ alt und die Laufwerke benötigen regelmäßige Reinigung. DLT-Laufwerke sind im allgemeinen viel besser (neuere Technologie) und benötigen keine regelmäßige Reinigung.
+
+Unten ist eine Tabelle mit den Spezifikationen von DLT- und LTO-Bändern, die Ihnen einen Eindruck der Geschwindigkeit und Kapazität aktueller Bänder geben soll. Die aufgeführte Kapazität ist die reine Bandkapazität ohne Kompression. Alle modernen Laufwerke arbeiten mit Hardware-Kompression und die Hersteller geben oft eine Kompressionsrate von 2:1 an. Die tatsächliche Kompressionsrate hängt hauptsächlich von den zu sichernden Daten ab, aber ich finde 1,5:1 ist ein viel vernünftigerer Wert (multiplizieren Sie die Werte der Tabelle mit 1,5 und Sie werden ein grobes Mittel dessen erhalten, was Sie möglicherweise sehen werden). Die Transferraten sind auf den nächsten GB/hr-Wert gerundet. Die Werte wurden von verschiedenen Herstellern zur Verfügung gestellt.
+In der Spalte ``Medien Typ'' stehen die Benennungen der Hersteller. Es ist nicht notwendig, diese Namen in den Konfigurationsdateien von Bacula zu benutzen. Allerdings können Sie das tun.
+
+
+ \begin{tabular}{|c|c|c|c}
+ Medien Typ & Laufwerks-Type & Medien Kapazität & Transferrate \\ \hline
+ DDS-1 & DAT & 2 GB & ?? GB/hr \\ \hline
+ DDS-2 & DAT & 4 GB & ?? GB/hr \\ \hline
+ DDS-3 & DAT & 12 GB & 5.4 GB/hr \\ \hline
+ Travan 40 & Travan & 20 GB & ?? GB/hr \\ \hline
+ DDS-4 & DAT & 20 GB & 11 GB/hr \\ \hline
+ VXA-1 & Exabyte & 33 GB & 11 GB/hr \\ \hline
+ DAT-72 & DAT & 36 GB & 13 GB/hr \\ \hline
+ DLT IV & DLT8000 & 40 GB & 22 GB/hr \\ \hline
+ VXA-2 & Exabyte & 80 GB & 22 GB/hr \\ \hline
+ Half-high Ultrum 1 & LTO 1 & 100 GB & 27 GB/hr \\ \hline
+ Ultrium 1 & LTO 1 & 100 GB & 54 GB/hr \\ \hline
+ Super DLT 1 & SDLT 220 & 110 GB & 40 GB/hr \\ \hline
+ VXA-3 & Exabyte & 160 GB & 43 GB/hr \\ \hline
+ Super DLT I & SDLT 320 & 160 GB & 58 GB/hr \\ \hline
+ Ultrium 2 & LTO 2 & 200 GB & 108 GB/hr \\ \hline
+ Super DLT II & SDLT 600 & 300 GB & 127 GB/hr \\ \hline
+ VXA-4 & Exabyte & 320 GB & 86 GB/hr \\ \hline
+ Ultrium 3 & LTO 3 & 400 GB & 216 GB/hr \\ \hline
+ \end{tabular}
+
%%
%%
-\section*{Supported Operating Systems}
+\section*{Unterstützte Betriebssysteme}
\label{_ChapterStart46}
-\index[general]{Systems!Supported Operating }
-\index[general]{Supported Operating Systems }
+\index[general]{Betriebssysteme!Unterstützte }
+\index[general]{Unterstützte Betriebssysteme }
\addcontentsline{toc}{section}{Supported Operating Systems}
-\subsection*{Supported Operating Systems}
+\subsection*{Unterstützte Betriebssysteme}
\label{SupportedOSes}
-\index[general]{Systems!Supported Operating }
-\index[general]{Supported Operating Systems }
-\addcontentsline{toc}{subsection}{Supported Operating Systems}
+\index[general]{Betriebssysteme!Unterstützte }
+\index[general]{Unterstützte Betriebssysteme }
+\addcontentsline{toc}{subsection}{Unterstützte Betriebssysteme}
\begin{itemize}
-\item Linux systems (built and tested on RedHat Enterprise Linux 3.0).
-\item If you have a recent Red Hat Linux system running the 2.4.x kernel and
- you have the directory {\bf /lib/tls} installed on your system (normally by
- default), bacula will {\bf NOT} run. This is the new pthreads library and it
-is defective. You must remove this directory prior to running Bacula, or you
-can simply change the name to {\bf /lib/tls-broken}) then you must reboot
-your machine (one of the few times Linux must be rebooted). If you are not
-able to remove/rename /lib/tls, an alternative is to set the environment
-variable "LD\_ASSUME\_KERNEL=2.4.19" prior to executing Bacula. For this
-option, you do not need to reboot, and all programs other than Bacula will
-continue to use /lib/tls.
-
-The feedback that we have for 2.6 kernels is that the same problem exists.
-However, on 2.6 kernels, we would probably recommend using the environment
-variable override (LD\_ASSUME\_KERNEL=2.4.19) rather than removing /lib/tls.
-
-\item Most flavors of Linux (Gentoo, SuSE, Mandriva, Debian, ...).
-\item Solaris various versions.
-\item FreeBSD (tape driver supported in 1.30 -- please see some {\bf
- important} considerations in the
- \ilink{ Tape Modes on FreeBSD}{FreeBSDTapes} section of the
- Tape Testing chapter of this manual.)
-\item Windows (Win98/Me, WinNT/2K/XP) Client (File daemon) binaries.
-\item MacOS X/Darwin (see \elink{ http://fink.sourceforge.net/}{http://fink.sourceforge.net/} for
- obtaining the packages)
-\item OpenBSD Client (File daemon).
-\item Irix Client (File daemon).
+\item Linux-Systeme (kompiliert und getestet unter ``RedHat Enterprise Linux 3.0'').
+\item Wenn Sie ein neueres ``RedHat'' Linux-System mit Kernel 2.4.x haben und im System ein Verzeichnis {\bf /lib/tls} angelegt ist (normalerweise voreingestellt), wird Bacula {\bf NICHT} starten. Dies liegt an der neuen Pthreads-Bibliothek, die fehlerhaft ist. Um Bacula zum laufen zu bringen, muss dieses Verzeichnis entfernt oder umbenannt und der Computer neu gestartet werden (eine der seltenen Gelegenheiten, bei denen man Linux neu booten muss). Sollte es nicht möglich sein, /lib/tls zu entfernen oder umzubenennen, setzt man stattdessen die Umgebungsvariable ``LD\_ASSUME\_KERNEL=2.4.19'' bevor man Bacula startet. Hierbei muss der Rechner nicht neu gestartet werden und alle anderen Programme werden /lib/tls weiterhin benutzen.
+
+Aus Rückmeldungen unsere Benutzer wissen wir, dass das Problem auch mit Kerneln der Version 2.6 besteht. Hier würden wir eher dazu raten die Umgebungsvariable neu zu setzen (LD\_ASSUME\_KERNEL=2.4.19), als das Verzeichnis /lib/tls zu entfernen.
+
+\item die meisten Linux-Distributionen (Gentoo, SuSE, Mandriva, Debian...).
+
+\item verschiedene Solaris-Versionen.
+
+\item FreeBSD (zur Unterstützung der Bandlaufwerke in Version 1.30 lesen Sie bitte die \textbf{wichtige} Hinweise im Abschnitt \ilink{Band-Modi unter FreeBSD}{FreeBSDTapes} des Kapitels zum Test der Bandlaufwerke in diesem Handbuch.)
+
+\item Windows (Win98/Me, WinNT/2K/XP) Client-Programm (File-Dämon).
+
+\item MacOS X/Darwin (Näheres zum Bezug der Pakete unter \elink{ http://fink.sourceforge.net/}{http://fink.sourceforge.net/})
+
+\item OpenBSD Client (File-Dämon).
+\item Irix Client (File-Dämon).
\item Tru64
-\item Bacula is said to work on other systems (AIX, BSDI, HPUX, ...) but we
- do not have first hand knowledge of these systems.
-\item RHat 7.2 AS2, AS3, AS4, Fedora Core 2, SuSE SLES 7,8,9 and Debian Woody and Sarge Linux on
- S/390 and Linux on zSeries.
-\item See the Porting chapter of the Bacula Developer's Guide for information
- on porting to other systems.
+
+\item es heißt, Bacula funktioniere auch auf anderen Systemen (AIX, BSDI, HPUX...) doch haben wir mit diesen Systemen keine eigenen Erfahrungen.
+
+\item RedHat 7.2 AS2, AS3, AS4, Fedora Core 2, SuSE SLES 7,8,9 und Debian Woody und Sarge Linux auf S/390 und Linux auf zSeries.
+
+\item Lesen Sie zur Portierung im ``Bacula Developer's Guide'' Informationen, wie man Bacula auf andere Systeme überträgt.
\end{itemize}
-1.39.5 (20 February 2006)
+1.38.9 (02 May 2006)
pour correspondre \`a votre syst\`eme. Le sch\'ema suivant donne une vue
globale des ressources.
-\includegraphics{./bacula-objects.eps}
+\includegraphics{./bacula-objects.eps}
+\\
(Remerciements \`a Aristedes Maniatis pour ce sch\'ema.)
\label{ResFormat}
Bien qu'il ne soit pas n\'ecessaire de conna{\^\i}tre le d\'etail de toutes
les directives possibles, une connaissance basique des ressources Bacula est
indispensable. Chaque directive contenue dans une ressource (entre accollades)
-est compos\'e d'un mot-clef suivi du signe ``='', suivi d'une ou plusieurs
+est compos\'e d'un mot-clef suivi du signe "='', suivi d'une ou plusieurs
valeurs. Le mot clef doit \^etre l'un de ceux connus par Bacula, et peut
comporter des caract\`eres majuscules et minuscules ainsi que des espaces.
\end{verbatim}
\normalsize
-D\'efinit la ressource Director avec le nom ``MyDir'' et le r\'epertoire de
+D\'efinit la ressource Director avec le nom "MyDir'' et le r\'epertoire de
travail \$HOME/bacula/bin/working. En g\'en\'eral, si vous voulez utiliser des
-espaces dans le nom \`a droite du signe ``='', vous devez l'entourer de
+espaces dans le nom \`a droite du signe "='', vous devez l'entourer de
doubles quotes. Sinon, les quotes ne sont g\'en\'eralement pas requises car
une fois d\'efinies, les cha{\^\i}nes quot\'ees et non quot\'ees sont toutes
\'equivalentes.
La casse (majuscules/minuscules) et les espaces sont totalement ignor\'ees
dans les mots-clef des directives des ressources (la partie \`a gauche du
-signe ``='').
+signe "='').
-A l'int\'erieur des mots-clef (\`a gauche du signe ``=''), les espaces ne sont
+A l'int\'erieur des mots-clef (\`a gauche du signe "=''), les espaces ne sont
pas significatives. Ainsi, les mots-clef : {\bf name}, {\bf Name}, et {\bf N a
m e} sont tous identiques.
-Les espaces apr\`es le signe ``='' et avant le premier caract\`ere de la
+Les espaces apr\`es le signe "='' et avant le premier caract\`ere de la
valeur son ignor\'ees.
En g\'en\'eral, les espaces \`a l'int\'erieur d'une valeur sont significatives
127 caract\`eres. Actuellement, un nom peut contenir n'importe quel
caract\`ere ASCII. A l'int\'erieur d'une cha{\^\i}ne quot\'ee, tout
caract\`ere pr\'ec\'ed\'e d'un backslash (\textbackslash{}) est pris tel quel
-(utile pour ins\'erer des backslashes et doubles quotes (``)).
+(utile pour ins\'erer des backslashes et doubles quotes (")).
Veuillez cependant noter que les noms de ressource Bacula ainsi que certains
autres noms seront s\'ev\`erement limit\'es dans l'avenir pour ne plus
le trait d'union, underscore et dollar. Le premier caract\`ere d'un {\bf name}
doit \^etre une lettre. La longueur d'un {\bf name} est actuellement limit\'ee
\`a 127 caract\`eres. Typiquement, les mots-clef appara{\^\i}ssent \`a gauche
-d'un signe ''=``. Les mots-clef ne peuvent \^etre quot\'es.
+d'un signe ''=". Les mots-clef ne peuvent \^etre quot\'es.
\item [name-string]
\index[console]{name-string }
Une {\bf name-string} est similaire \`a un {\bf name} except\'e qu'elle peut
\^etre quot\'ee et ainsi contenir des caract\`eres suppl\'ementaires. La
longueur des {\bf name-strings} est limit\'ee \`a 127 caract\`eres.
-Typiquement, on les utilise \`a droite d'un signe ''=``, (i.e. ce sont les
+Typiquement, on les utilise \`a droite d'un signe ''=", (i.e. ce sont les
valeurs \`a associer aux mots-clef).
\item [string]
sont des sp\'ecifications valides (\`a partir de la version 1.35.1).
-Note! Dans les vrsions de Bacula ant\'erieures \`a 1.31, le modificateur
+Note! Dans les versions de Bacula ant\'erieures \`a 1.31, le modificateur
\'etait optionnel. Il est d\'esormais obligatoire.
\end{description}
\multicolumn{1}{|c| }{\bf Resource } & \multicolumn{1}{c| }{\bf Director } &
\multicolumn{1}{c| }{\bf Client } & \multicolumn{1}{c| }{\bf Storage } &
\multicolumn{1}{c| }{\bf Console } \\
+ \hline
+ {Autochanger } & {No } & {No } & {Yes } & {No } \\
+ \hline
\hline
{Catalog } & {Oui } & {Non } & {Non } & {Non } \\
\hline
\end{longtable}
-\section*{Noms, mots de passe et autorisations}
+\subsection*{Noms, mots de passe et autorisations}
\label{Names}
\index[general]{Autorisations!Noms mots de passe et }
\index[general]{Noms, mots de passe et autorisations }
+\index[general]{Mots de passe}
\addcontentsline{toc}{section}{Noms, mots de passe et autorisations}
Pour qu'un {\it daemon} puisse en contacter un autre, il lui faut
modifiez ces fichiers, vous devrez \^etre attentif \`a leur coh\'erence.
Voici un sch\'ema des correspondances que doivent respecter les couples
-''nom/mot de passe`` des diff\'erents fichiers de configurations.
+''nom/mot de passe" des diff\'erents fichiers de configurations.
\includegraphics{./Conf-Diagram.eps}
IP. Pour cette raison, vous devez utiliser soit une adresse IP, soit une
adresse pleinement qualifi\'ee. Une adresse telle que {\bf localhost},
n'\'etant pas pleinement qualifi\'ee, sera r\'esolue par le File Daemon en
-l'hote local du File Daemon, ce qui n'est probablement pas le r\'esultat
+l'h\^ote local du File Daemon, ce qui n'est probablement pas le r\'esultat
d\'esir\'e. Le mot de passe utilis\'e par le File Daemon pour autoriser la
communication avec le Storage Daemon est temporaire et unique pour chaque {\it
job}. Il n'est sp\'ecifi\'e dans aucun fichier de configuration.
\item [Name = \lt{}nom\gt{}]
\index[dir]{Name}
+ \index[dir]{Directive!Name}
Le nom du Director utilis\'e par l'administrateur syst\`eme. Cette directive
est requise
\item [Description = \lt{ }texte\gt{}]
\index[dir]{Description}
+ \index[dir]{Directive!Description}
Le champ texte contient une description du Director qui sera affich\'ee dans
l'interface graphique. Cette directive est optionnelle.
\item [Password = \lt{}UA-password\gt{}]
\index[dir]{Password}
+ \index[dir]{Directive!Password}
Sp\'ecifie le mot de passe qui doit \^etre fourni par la Console Bacula par
d\'efaut pour \^etre autoris\'ee. Le m\^eme mot de passe doit appara{\^\i}tre
dans la ressource {\bf Director} du fichier de configuration de la console.
\item [Messages = \lt{}Nom-de-ressource-Messages\gt{}]
\index[dir]{Messages}
+ \index[dir]{Directive!Messages}
La ressource {\bf messages} sp\'ecifie o\`u doivent \^etre d\'elivr\'es les messages du Director
qui ne sont pas associ\'es \`a un job sp\'ecifique. La plupart des messages sont relatifs
\`a un job et seront dirig\'es vers la ressource {\bf messages} sp\'ecifi\'ee par le job.
\item [Working Directory = \lt{}R\'epertoire\gt{}]
\index[dir]{Working Directory}
+ \index[dir]{Directive!Working Directory}
Cette directive sp\'ecifie un r\'epertoire o\`u le Director peut d\'eposer ses fichiers
d'\'etats. Ce r\'epertoire ne devrait \^etre utilis\'e que par Bacula, mais il peut \^etre
partag\'e par d'autres {\it daemons} Bacula. Notez cependant que si ce r\'epertoire est
Les substitutions shell standard sont effectu\'ees \`a la lecture du fichier de
configuration, de sorte que des valeurs telles que {\bf \$HOME} seront correctement
substitu\'ees. Cette directive est requise.
-
+
+ Si vous avez spécifié un utilisateur et/ou un groupe pour le Director lors de la
+ configuration avec les options {\bf {-}{-}with-dir-user} et/ou {\bf {-}{-}with-dir-group} de
+ la commande ./configure, le répertoire de travail Working Directory doit appartenir
+ doit appartenir à ce groupe et à cet utilisateur.
+
\item [Pid Directory = \lt{}R\'epertoire\gt{}]
\index[dir]{Pid Directory}
+ \index[dir]{Directive!Pid Directory}
Cette directive sp\'ecifie un r\'epertoire o\`u le Director peut d\'eposer son fichier
d'Id de processus. Ce fichier est utilis\'e pour stopper Bacula et pr\'evenir l'ex\'ecution
simultan\'ee de plusieurs copies de Bacula. Les substitutions shell standard sont
\item [Scripts Directory = \lt{}Directory\gt{}]
\index[dir]{Scripts Directory}
+ \index[dir]{Directive!Scripts Directory}
Cette directive sp\'ecifie le r\'epertoire dans lequel le Director devra rechercher
le script Python de d\'emarrage {\bf DirStartup.py}. Ce r\'epertoire peut \^etre
partag\'e par d'autres daemons Bacula.Les substitutions shell standard sont effectu\'ees
\item [QueryFile = \lt{}Path\gt{}]
\index[dir]{QueryFile}
+ \index[dir]{Directive!QueryFile}
Cette directive sp\'ecifie un r\'epertoire et un fichier dans lequel le
Director peut trouver les requ\^etes SQL pr\'e\'etablies pour la commande
{\bf Query} de la Console. Les substitutions shell standard sont
\item [Maximum Concurrent Jobs = \lt{}nombre\gt{}]
\index[dir]{Maximum Concurrent Jobs}
+ \index[dir]{Directive!Maximum Concurrent Jobs}
\index[general]{Jobs Simultan\'es}
\index[general]{Jobs Concurrents}
\item [FD Connect Timeout = \lt{}dur\'ee\gt{}]
\index[dir]{FD Connect Timeout}
+ \index[dir]{Directive!FD Connect Timeout}
O\`u {\bf dur\'ee} est le d\'elai durant lequel le Director tente de contacter
le File Daemon pour d\'emarrer un job. Une fois ce d\'elai \'ecoul\'e, le Director supprimera le job.
La valeur par d\'efaut est 30 minutes.
\item [SD Connect Timeout = \lt{}dur\'ee\gt{}]
\index[dir]{SD Connect Timeout}
+ \index[dir]{Directive!SD Connect Timeout}
O\`u {\bf dur\'ee} est le d\'elai durant lequel le Director tente de contacter
le Storage Daemon pour d\'emarrer un job. Une fois ce d\'elai \'ecoul\'e, le Director supprimera le job.
La valeur par d\'efaut est 30 minutes.
\item [DirAddresses = \lt{}Sp\'ecification-adresses-IP\gt{}]
\index[dir]{DirAddresses}
+ \index[dir]{Directive!DirAddresses}
Sp\'ecifie les ports et adresses sur lesquels le Director se met en attente de
connections de Consoles Bacula. La meilleure explication est sans doute un exemple :
la r\'esolution peut \^etre faite soit par IPv4, soit par IPv6. Si ip4 est sp\'ecifi\'e,
seules les r\'esolutions IPv4 seront permises. Il en va de m\^eme avec ip6.
+Notez que si vous utilisez la directive DirAddresses, vous ne devez utiliser ni la directive
+DirPort, ni la directive DirAddress dans la même ressource.
+
\item [DIRport = \lt{}num\'ero-de-port\gt{}]
\index[dir]{DIRport}
+ \index[dir]{Directive!DIRport}
Sp\'ecifie le port (un entier positif) sur lequel le Director est \`a l'\'ecoute
de connections de Consoles Bacula. Ce m\^eme num\'ero de port doit \^etre sp\'ecifi\'e
dans la ressource Director du fichier de configuration de la console. La
\item [DirAddress = \lt{}Adresse-IP\gt{}]
\index[dir]{DirAddress}
+ \index[dir]{Directive!DirAddress}
Cette directive est optionnelle. Lorsqu'elle est sp\'ecifi\'ee, le Director n'accepte
de connections Console que de l'adresse sp\'ecifi\'ee {\bf Adresse-IP}, qui peut \^etre
soit un nom de domaine, soit une adresse IP au format quadruplet point\'e ou chaîne quot\'ee.
\item [Job]
\index[dir]{Job}
+ \index[dir]{Directive!Job}
D\'ebut de la ressource Job. Il faut d\'efinir au moins une ressource Job.
\item [Name = \lt{}name\gt{}]
\index[dir]{Name}
+ \index[dir]{Directive!Name}
Le nom du Job. Ce nom peut \^etre utilis\'e avec la commande {\bf Run} du
programme Console pour lancer un Job. Si le nom contient des espaces,
il doit \^etre plac\'e entre quotes. C'est g\'en\'eralement une bonne id\'ee de
sp\'ecifi\'e ici suffix\'e avec la date et l'heure de sa planification.
Cette directive est requise.
+\item [Enabled = \lt{}yes|no\gt{}]
+ \index[dir]{Enable}
+ \index[dir]Directive!Enable}
+ Cette directive permet d'activer ou désactiver l'exécution automatique d'un job
+ par le planificateur.
+
\item [Type = \lt{}job-type\gt{}]
\index[dir]{Type}
+ \index[dir]{Directive!Type}
La directive {\bf Type} sp\'ecifie le type de Job, qui peut \^etre l'un des
suivants : {\bf Backup}, {\bf Restore}, {\bf Verify}, ou {\bf Admin}.
Cette directive est requise. Pour chaque type de Job, il existe diff\'erents
\label{Level}
\item [Level = \lt{}job-level\gt{}]
+ \index[dir]{Directive!Level}
\index[dir]{Level}
La directive Level sp\'ecifie le niveau d'ex\'ecutiondu job par d\'efaut.
Chaque type de job a son propre jeu de niveaux qui peuvent \^etre sp\'ecifi\'es.
\item {\bf Verify Job = \lt{}Job-Resource-Name\gt{}}
\index[dir]{Verify Job}
+ \index[dir]{Directive!Verify Job}
Si vous ex\'ecutez un job verify sans cette directive, le dernier job
ex\'ecut\'e sera compar\'e avec le catalogue, ce qui signifie que votre commande
verify doit succ\'eder imm\'ediatement \`a une sauvegarde. Si vous sp\'ecifiez
\item {\bf JobDefs = \lt{}JobDefs-Resource-Name\gt{}}
\index[dir]{JobDefs}
+ \index[dir]{Directive!JobDefs}
Si un nom de JobDef est sp\'ecifi\'e dans la d\'efinition d'un Job, toutes les valeurs
d\'efinies dans la ressource JobDef concern\'ee seront utilis\'ees en tant que valeurs
par d\'efaut pour le Job. Toute valeur explicitement sp\'ecifi\'ee dans la
\item {\bf Bootstrap = \lt{}bootstrap-file\gt{}}
\index[dir]{Bootstrap}
+ \index[dir]{Directive!Bootstrap}
La directive Bootstrap sp\'ecifie un fichier bootstrap qui, s'il est fourni,
sera utilis\'e lors des restaurations et ignor\'e par tout les autres Jobs.
Le fichier {\bf bootstrap} contient la liste des cartouches n\'ecessaires
consulter le chapitre \ilink{Restaurer des fichiers avec le fichier Bootstrap}{_ChapterStart43}
de ce manuel.
-\item {\bf \label{writebootstrap} Write Bootstrap = \lt{}bootstrap-file-specification\gt{}}
-\index[dir]{a name}
-
+\label{writebootstrap}
+\item {\bf Write Bootstrap = \lt{}bootstrap-file-specification\gt{}}
+ \index[dir]{Write Bootstrap}
+ \index[dir]{Directive!Write Bootstrap}
La directive {\bf writebootstrap} sp\'ecifie le de fichier Bootstrap o\`u Bacula
\'ecrira lors de chaque sauvegarde. Ainsi, cette directive s'applique
exclusivement aux jobs de type sauvegarde. Si la sauvegarde est une Full,
Bacula \'ecrase le contenu du fichier sp\'ecifi\'e. Sinon, Bacula ajoute les
- nouveaux enregistrements Bootstrap \`a la fin du fichier..
+ nouveaux enregistrements Bootstrap \`a la fin du fichier.
En utilisant cette fonction, vous aurez constamment un fichier bootstrap
capable de recouvrer l'\'etat le plus r\'ecent de votre syst\`eme. Le fichier
\item {\bf Client = \lt{}client-resource-name\gt{}}
\index[dir]{Client}
+ \index[dir]{Directive!Client}
La directive Client sp\'ecifie le Client (File Daemon) \`a utiliser dans le Job.
Le client est ex\'ecut\'e sur la machine \`a sauvegarder. Il exp\'edie les fichiers requis
au Storage Daemon lors des sauvegardes, et re\\ 3oit les fichiers du Storage Daemon
\item {\bf FileSet = \lt{}FileSet-resource-name\gt{}}
+ \index[dir]{FileSet}
\index[dir]{FileSet}
La directive FileSet sp\'ecifie le FileSet \`a utiliser dans le Job concern\'e. Le
FileSet d\'efinit les r\'epertoires et fichiers \`a sauvegarder, ainsi que les options
\item {\bf Messages = \lt{}messages-resource-name\gt{}}
\index[dir]{Messages}
+ \index[dir]{Directive!Messages}
La directive Messages d\'efinit la ressource Message qui doit \^etre utilis\'ee
pour le job concern\'e. Ainsi, elle d\'etermine le comment et o\`u seront
d\'elivr\'es les diff\'erents messages de Bacula. Par exemple, vous pouvez diriger
\item {\bf Pool = \lt{}pool-resource-name\gt{}}
\index[dir]{Pool}
+ \index[dir]{Directive!Pool}
La directive Pool sp\'ecifie le jeu de volumes qui doit \^etre utilis\'e pour
sauvegarder vos donn\'ees. De nombreuses installations de Bacula
n'utiliseront que le pool d\'efini par d\'efaut {\bf Default}. Toutefois,
\item {\bf Full Backup Pool = \lt{}pool-resource-name\gt{} }
\index[dir]{Full Backup Pool}
+ \index[dir]{Directive!Full Backup Pool}
La directive {\it Full Backup Pool} sp\'ecifie un Pool \`a utiliser pour les
sauvegardes Full. Cette directive outrepasse toute autre sp\'ecification
de Pool lors d'une sauvegarde Full. Cette directive est optionnelle.
\item {\bf Differential Backup Pool = \lt{}pool-resource-name\gt{} }
\index[dir]{Differential Backup Pool}
+ \index[dir]{Directive!Differential Backup Pool}
La directive {\it Differential Backup Pool} sp\'ecifie un Pool \`a utiliser pour les
sauvegardes Diff\'erentielles. Cette directive outrepasse toute autre sp\'ecification
de Pool lors d'une sauvegarde Diff\'erentielle. Cette directive est optionnelle.
\item {\bf Incremental Backup Pool = \lt{}pool-resource-name\gt{} }
\index[dir]{Incremental Backup Pool}
+ \index[dir]{Directive!Differential Backup Pool}
La directive {\it Incremental Backup Pool} sp\'ecifie un Pool \`a utiliser pour les
sauvegardes Incr\'ementales. Cette directive outrepasse toute autre sp\'ecification
de Pool lors d'une sauvegarde Incr\'ementale. Cette directive est optionnelle.
\item {\bf Schedule = \lt{}schedule-name\gt{}}
\index[dir]{Schedule}
+ \index[dir]{Directive!Schedule}
La directive Schedule d\'efinit la planification du job. Le {\it schedule} d\'etermine
la date et l'instant o\`u le job doit \^etre lanc\'e automatiquement, et le niveau
(Full, Diff\'erentiel, Incr\'emental...) du job en question. Cette directive est
\item {\bf Storage = \lt{}storage-resource-name\gt{}}
\index[dir]{Storage}
+ \index[dir]{Directive!Storage}
La directive Storage d\'efinit le nom du service storage que vous souhaitez
utiliser pour sauvegarder les donn\'ees du FileSet. Pour plus de d\'etails, consultez le
chapitre \ilink{Ressource Storage}{StorageResource2} de ce manuel.
\item {\bf Max Start Delay = \lt{}time\gt{}}
\index[sd]{Max Start Delay}
+ \index[dir]{Directive!Max Start Delay}
La directive Max Start Delay sp\'ecifie le d\'elai maximal entre l'horaire
planifi\'e (dans le schedule) et l'horaire effectif de d\'emarrage du job.
Par exemple, un job peut \^etre programm\'e pour d\'emarrer \`a 1h, mais \^etre
\item {\bf Max Run Time = \lt{}time\gt{}}
\index[sd]{Max Run Time}
+ \index[dir]{Directive!Max Run Time}
La directive Max Run Time sp\'ecifie le d\'elai allou\'e pour l'ex\'ecution
compl\`ete d'un job depuis son lancement (pas n\'ecessairement \`a l'heure
de sa programmation) jusqu'\`a sa fin. Cette directive est impl\'ement\'ee
\item {\bf Max Wait Time = \lt{}time\gt{}}
\index[sd]{Max Wait Time}
+ \index[dir]{Directive!Max Wait Time}
La directive Max Wait Time sp\'ecifie le d\'elai maximum durant lequel un
job peut rester bloqu\'e en attente d'une ressource (par exemple, en attente du
montage d'une cartouche ou encore en attente des Storage ou File Daemon occup\'es
\item [Incremental Max Wait Time = \lt{}time\gt{}]
\index[dir]{Incremental Max Wait Time}
+ \index[dir]{Directive!Incremental Max Wait Time}
Cette directive sp\'ecifie le temps maximum durant lequel une sauvegarde
incr\'ementale peut rester bloqu\'ee en attente d'une ressource (par exemple, en
attente d'une cartouche ou des File ou Storage daemons), compt\'e \`a partir
\item [Differential Max Wait Time = \lt{}time\gt{}]
\index[dir]{Differential Max Wait Time}
+ \index[dir]{Directive!Differential Max Wait Time}
Cette directive sp\'ecifie le temps maximum durant lequel une sauvegarde
diff\'erentielle peut rester bloqu\'ee en attente d'une ressource (par exemple, en
attente d'une cartouche ou des File ou Storage daemons), compt\'e \`a partir
\item [Prefer Mounted Volumes = \lt{}yes|no\gt{}]
\index[dir]{Prefer Mounted Volumes}
+ \index[dir]{Directive!Differential Max Wait Time}
Si cette directive est activ\'ee (c'est le cas par d\'efaut), le Director
ordonne au Storage daemon de s\'electionner de pr\'ef\'erence soit une
librairie, soit un lecteur avec un volume valide d\'ej\`a mont\'e, plut\^ot qu'un
\item {\bf Prune Jobs = \lt{}yes|no\gt{}}
\index[dir]{Prune Jobs}
+ \index[dir]{Directive!Prune Jobs}
En principe, l'\'elagage des jobs du catalogue est sp\'ecifi\'e pour chaque client
dans sa propre ressource Client par la directive {\bf AutoPrune}. Si cette
directive est sp\'ecifi\'ee (normalement, non) et si la valeur est {\bf yes},
\item {\bf Prune Files = \lt{}yes|no\gt{}}
\index[dir]{Prune Files}
+ \index[dir]{Directive!Prune Jobs}
En principe, l'\'elagage des fichiers du catalogue est sp\'ecifi\'e pour chaque client
dans sa propre ressource Client par la directive {\bf AutoPrune}. Si cette
directive est sp\'ecifi\'ee (normalement, non) et si la valeur est {\bf yes},
\item {\bf Prune Volumes = \lt{}yes|no\gt{}}
\index[dir]{Prune Volumes}
+ \index[dir]{Directive!Prune Jobs}
En principe, l'\'elagage des volumes du catalogue est sp\'ecifi\'e pour chaque client
dans sa propre ressource Client par la directive {\bf AutoPrune}. Si cette
directive est sp\'ecifi\'ee (normalement, non) et si la valeur est {\bf yes},
\item {\bf Run Before Job = \lt{}command\gt{}}
\index[dir]{Run Before Job}
+ \index[dir]{Directive!Run Before Job}
La commande sp\'ecifi\'ee est ex\'ecut\'ee en tant que programme externe avant le
lancement du job. Tout retour de la commande sur la sortie standard est
incluse dans le rapport de job de Bacula. La chaîne {bf command} doit \^etre
%% = %
%c = Nom du client
%d = Nom du Director
- %i = JobId
+
%e = Statut de sortie du job
+ %i = JobId
%j = Nom unique du job
%l = Niveau du job
%n = Nom du job
- %t = Type de job
+ %s = Temps Depuis (NDT : Since Time)
+ %t = Type de job (Backup,...)
%v = Nom de volume
\end{verbatim}
de vendredi.
\item {\bf Run After Job = \lt{}command\gt{}}
- \index[dir]{Run After Job }
+ \index[dir]{Run After Job}
+ \index[dir]{Directive!Run After Job}
La commande sp\'ecifi\'ee est ex\'ecut\'ee en tant que programme externe apr\`es la fin
du job. La chaîne {bf command} doit \^etre un nom de programme valide ou un
script shell. Cette directive n'est pas requise. Si le code de sortie du
- programme est non nul, le job se termine en erreur. Avant de soumettre
+ programme est non nul, Bacula affiche un message d'avertissement (warning).
+ Avant de soumettre
la commande sp\'ecifi\'ee au syst\`eme d'exploitation, Bacula effectue les
substitutions de caract\`eres d\'ecrites au paragraphe {\bf Run Before Job}
Un exemple d'utilisation de cette directive est donn\'e au chapitre
-\ilink{Astuces}{JobNotification} de ce manuel. depuis la version 1.30,
-Bacula contr\^ole le statut de sortie du program RunAfter. S'il est
-non nul, le job se termine en erreur.
+\ilink{Astuces}{JobNotification} de ce manuel.
+Lisez le paragraphe {\bf Run After Failed Job} si vous voulez exécuter
+une commande lorqu'un job se termine avec un statut anormal.
+
+\item [Run After Failed Job = \lt{}command\gt{}]
+ \index[dir]{Run After Job}
+ \index[dir]{Directive!Run After Job}
+ La commande spécifiée est exécutée en tant que programme externe après la fin
+ du job lorqu'il se termine avec un statut d'erreur. Cette directive est optionnelle.
+ La chaîne {\bf command} doit être le nom d'un programme ou d'un script shell.
+ Si le code de sortie du programme est non nul, Bacula affiche un mesage d'avertissement
+ (warning). Avant de soumettre
+ la commande sp\'ecifi\'ee au syst\`eme d'exploitation, Bacula effectue les
+ substitutions de caract\`eres d\'ecrites au paragraphe {\bf Run Before Job}. Notez que
+ vous pouvez, si vous le souhaitez, spécifier ici le même programme que
+ celui que vous avez utilisé pour la direcive {\bf Run After Job}, de sorte que
+ votre programme soit exécuté quel que soit l'issue du job.
+
+ Le chapitre \ilink{Trucs et astuces}{JobNotification} de ce manuel propose un
+ exemple d'utilisation de cette directive.
\item {\bf Client Run Before Job = \lt{}command\gt{}}
- \index[dir]{Client Run Before Job }
+ \index[dir]{Client Run Before Job}
+ \index[dir]{Directive!Client Run Before Job}
Cette directive est similaire \`a {\bf Run Before Job} except\'e que la
commande est ex\'ecut\'ee sur la machine cliente. Les m\^emes restrictions
s'appliquent aux syt\`emes Unix que celles signal\'ees pour {\bf Run Before Job}.
+
+ Lorsque vous spécifiez un chemin absolu vers un exécutable, si le chemin ou le nom
+ de l'exécutable contient des espaces ou des caractères spéciaux, il faut les
+ protéger par des quotes. Il en va de même des éventuels arguments.
+
+
+{\bf Consid\'erations particuli\`eres \`a Windows}
D'autre part, pour les clients Windows \`a partir de la version 1.33, notez bien
que vous devez fournir un chemin correct pour votre script, et que le script
peut avoir l'extension .com, .exe, ou .bat. Si vous sp\'ecifiez un chemin,
d'Unix ne fonctionneront pas, \`a moins que vous n'ayez install\'e et
correctement configur\'e Cygwin en plus (et s\'epar\'ement) de Bacula.
-
-{\bf Consid\'erations particuli\`eres \`a Windows}
La commande peut \^etre n'importe quel programme reconnu par cmd.exe ou command.com
comme un fichier ex\'ecutable. Sp\'ecifier une extension de fichier ex\'ecutable
est optionnel, \`a moins qu'il y ait une ambigu\"it\'e (par exemple ls.bat, ls.exe).
vers /dev/null pour \'eviter le bloquage du script.
\item {\bf Client Run After Job = \lt{}command\gt{}}
- \index[dir]{Client Run After Job }
+ \index[dir]{Client Run After Job}
+ \index[dir]{Directive!Client Run After Job}
Cette directive est similaire \`a {\bf Run After Job} sauf qu'elle est ex\'ecut\'ee
sur la machine cliente. Veuillez consulter les notes concernant les clients
Windows dans le paragraphe {\bf Client Run Before Job} ci-dessus.
\item {\bf Rerun Failed Levels = \lt{}yes|no\gt{}}
- \index[dir]{Rerun Failed Levels }
+ \index[dir]{Rerun Failed Levels}
+ \index[dir]{Directive!Rerun Failed Levels}
Si la valeur de cette directive est {\bf yes} ({\bf no} par d\'efaut), et si
Bacula d\'etecte qu'un job ant\'erieur d'un niveau plus \'elev\'e (Full ou
diff\'erentiel), alors le job est \'elev\'e au niveau le plus haut. Ceci est
plut\^ot qu'Incremental ou Diff\'erentiel.
\item {\bf Spool Data = \lt{}yes|no\gt{}}
- \index[dir]{Spool Data }
+ \index[dir]{Spool Data}
+ \index[dir]{Directive!Spool Data}
Si la valeur de cette directive est {\bf yes} ({\bf no} par d\'efaut), le
Storage Daemon aura pour consigne de stocker les donn\'ees dans un
fichier spoule sur disque plut\^ot que de les \'ecrire directement sur bande.
\item {\bf Spool Attributes = \lt{}yes|no\gt{}}
- \index[dir]{Spool Attributes }
+ \index[dir]{Spool Attributes}
+ \index[dir]{Directive!Spool Attributes}
La valeur par d\'efaut est {\bf no}, ce qui signifie que le Storage Daemon
envoie les attributs de fichiers au Director au moment o\`u ils (les fichiers)
sont ecrits sur la bande. Cependant, si vous souhaitez \'eviter le risque
transmettre au Director qu'\`a la fin de l'\'ecriture sur bande des donn\'ees du job.
\item {\bf Where = \lt{}directory\gt{}}
- \index[dir]{Where }
+ \index[dir]{Where}
+ \index[dir]{Directive!Where}
Cette directive ne concerne que les jobs de type Restauration. Elle permet
de sp\'ecifier un pr\'efixe au nom du r\'epertoire o\`u tous les fichiers sont
restaur\'es. Ceci permet de restaurer les fichiers en un emplacement
accidentel de vos fichiers.
\item {\bf Replace = \lt{}replace-option\gt{}}
- \index[dir]{Replace }
+ \index[dir]{Replace}
+ \index[dir]{Directive!Replace}
Cette directive ne concerne que les jobs de type Restauration. Elle pr\'ecise
la conduite \`a adopter dans l'\'eventualit\'e o\`u Bacula serait conduit \`a restaurer
un fichier ou un r\'epertoire qui existe d\'ej\`a. Les options suivantes sont
\end{description}
\item {\bf Prefix Links=\lt{}yes|no\gt{}}
- \index[dir]{Prefix Links }
+ \index[dir]{Prefix Links}
+ \index[dir]{Directive!Prefix Links}
Si la valeur de cette directive est {\bf Yes} et si un pr\'efixe de chemin
{\bf Where} est sp\'ecifi\'e, alors ce dernier s'applique aussi aux liens
absolus. La valeur par d\'efaut est {\bf No}. Lorsque cette directive est \`a
d'origine, tous les liens absolus seront bris\'es.
\item {\bf Maximum Concurrent Jobs = \lt{}number\gt{}}
- \index[dir]{Maximum Concurrent Jobs }
+ \index[dir]{Maximum Concurrent Jobs}
+ \index[dir]{Directive!Maximum Concurrent Jobs}
O\`u \lt{}number\gt{} est le nombre maximum de jobs de la ressource Job courrante
qui peuvent \^etre ex\'ecut\'es simultan\'ement. Notez que cette directive ne limite
que les jobs avec le m\^eme nom que la ressource dans laquelle elle
dans la section concernant la ressource Director.
\item {\bf Reschedule On Error = \lt{}yes|no\gt{}}
- \index[dir]{Reschedule On Error }
+ \index[dir]{Reschedule On Error}
+ \index[dir]{Directive!Reschedule On Error}
Si cette directive est activ\'ee, alors si le job se termine en erreur, il sera
reprogramm\'e en accord avec les directives {\bf Reschedule Interval} et
{\bf Reschedule Times}. Si vous supprimez le job, il ne sera pas reprogramm\'e.
les machines qui ne sont pas connect\'ees au r\'eseau en permanence.
\item {\bf Reschedule Interval = \lt{}time-specification\gt{}}
- \index[dir]{Reschedule Interval }
+ \index[dir]{Reschedule Interval}
+ \index[dir]{Directive!Reschedule Interval}
Si cette directive est activ\'ee, alors si le job se termine en erreur, il sera
reprogramm\'e apr\`es l'intervalle de temps stipul\'e par {\bf time-specification}.
Consultez la section \ilink{ the time specification formats}{Time} du chapitre
aucun intervalle n'est sp\'ecifi\'e, le job ne sera pas reprogramm\'e en cas d'erreur.
\item {\bf Reschedule Times = \lt{}count\gt{}}
- \index[dir]{Reschedule Times }
+ \index[dir]{Reschedule Times}
+ \index[dir]{Directive!Reschedule Times}
Cette directive pr\'ecise le nombre maximal de tentatives d'ex\'ecution du job.
S'il est fix\'e \`a z\'ero (valeur par d\'efaut), le job sera reprogramm\'e
ind\'efiniment.
\item [Run = \lt{}job-name\gt{}]
- \index[dir]{Directive Run}
+ \index[dir]{Run}
+ \index[dir]{Directive!Run}
\index[dir]{Cloner un Job}
La directive Run (\`a ne pas confondre avec l'option Run dans un
Schedule) vous permet de d\'emarrer ou de cloner des jobs. En utilisant les
\label{Priority}
\item {\bf Priority = \lt{}number\gt{}}
- \index[dir]{Priority }
+ \index[dir]{Priority}
+ \index[dir]{Directive!Priority}
Cette directive vous permet de contr\^oler l'ordre d'ex\'ecution des jobs en
sp\'ecifiant un entier positif non nul. Plus grand est ce nombre, plus basse
est la priorit\'e du job. En supposant que vous n'ex\'ecutiez pas de jobs
\label{WritePartAfterJob}
\item {\bf Write Part After Job = \lt{}yes|no\gt{}}
- \index[sd]{Write Part After Job }
+ \index[sd]{Write Part After Job}
+ \index[dir]{Directive!Write Part After Job}
Cette directive est impl\'ement\'ee depuis la version 1.37.
Si la valeur de cette directive est {\bf yes} ({\bf no} par d\'efaut), un nouveau
"fichier partition" (ndt : part file) sera cr\'e\'e apr\`es la fin du job.
\begin{description}
\item [Schedule]
- \index[sd]{Schedule }
+ \index[dir]{Schedule}
+ \index[dir]{Directive!Schedule}
D\'ebut des directives Schedule. La ressource {\bf Schedule} n'est pas requise,
mais il vous en faudra au moins une si vous souhaitez que vos jobs soient
ex\'ecut\'es automatiquement.
\item [Name = \lt{}name\gt{}]
- \index[sd]{Name }
+ \index[dir]{Name}
+ \index[dir]{Directive!Name}
Le nom du Schedule d\'efini. Cette directive est requise.
\item [Run = \lt{}Job-overrides\gt{} \lt{}Date-time-specification\gt{} ]
- \index[sd]{Run }
+ \index[dir]{Run}
+ \index[dir]{Directive!Run}
La directive Run d\'efinit quand un job doit \^etre ex\'ecut\'e, et les \'eventuelles
surcharges \`a appliquer. Il est possible de sp\'ecifier plusieurs directives
{\bf run} au sein d'une ressource {\bf Schedule}, elles seront toutes
\begin{description}
\item [Level=Full]
- \index[sd]{Level }
+ \index[dir]{Level}
+ \index[dir]{Directive!Level}
Tous les fichiers du FileSet qu'ils aient ou non chang\'e.
\item [Level=Incremental]
- \index[sd]{Level }
+ \index[dir]{Level}
+ \index[dir]{Directive!Level}
Tous les fichiers qui ont chang\'e depuis la derni\`ere sauvegarde.
\item [Pool=Weekly]
- \index[sd]{Pool }
+ \index[dir]{Pool}
+ \index[dir]{Directive!Pool}
Sp\'ecifie l'utilisation du Pool nomm\'e {\bf Weekly}.
\item [Storage=DLT\_Drive]
- \index[sd]{Storage }
+ \index[dir]{Storage }
+ \index[dir]{Directive!Storage}
Sp\'ecifie l'utilisation du lecteur {\bf DLT\_Drive} pour p\'eriph\'erique de stockage.
\item [Messages=Verbose]
- \index[sd]{Messages }
+ \index[dir]{Messages }
+ \index[dir]{Directive!Messages}
Sp\'ecifie l'utilisation de la ressource messages {\bf Verbose} pour le job.
\item [FullPool=Full]
- \index[sd]{FullPool }
+ \index[dir]{FullPool}
+ \index[dir]{Directive!FullPool}
+
Sp\'ecifie l'utilisation du Pool nomm\'e {\bf Full} si le job est une sauvegarde Full,
ou s'il a \'et\'e \'elev\'e en Full bien qu'ayant \'et\'e lanc\'e en tant que diff\'erentiel ou
incr\'emental.
\item [DifferentialPool=Differential]
- \index[sd]{DifferentialPool }
+ \index[dir]{DifferentialPool }
+ \index[dir]{Directive!DifferentialPool}
Sp\'ecifie l'utilisation du Pool nomm\'e {\bf Differential} si le job est une
sauvegarde diff\'erentielle.
\item [IncrementalPool=Incremental]
- \index[sd]{IncrementalPool }
+ \index[dir]{IncrementalPool}
+ \index[dir]{Directive!IncrementalPool}
Sp\'ecifie l'utilisation du Pool nomm\'e {\bf Incremental} si le job est une
sauvegarde incr\'ementale.
\item [SpoolData=yes|no]
- \index[sd]{SpoolData }
+ \index[dir]{SpoolData}
+ \index[dir]{Directive!SpoolData}
Indique \`a Bacula d'ordonner au Storage Daemon de placer les donn\'ees sur un
spool disque avant de les envoyer vers les cartouches.
\item [WritePartAfterJob=yes|no]
- \index[sd]{WritePartAfterJob }
+ \index[dir]{WritePartAfterJob}
+ \index[dir]{Directive!WritePartAfterJob}
Indique \`a Bacula d'ordonner au Storage Daemon d'\'ecrire le fichier partition
courant vers le p\'eriph\'erique lorsque le job s'ach\`eve (voir
\ilink{la directive Write Part After Job dans la ressource Job}{WritePartAfterJob}).
\begin{description}
\item [Client (ou FileDaemon)]
- \index[dir]{Client (ou FileDaemon) }
+ \index[dir]{Client (ou FileDaemon)}
+ \index[dir]{Directive!Client (or FileDaemon)}
D\'ebut des directives Client.
\item [Name = \lt{}name\gt{}]
- \index[dir]{Name }
+ \index[dir]{Name}
+ \index[dir]{Directive!Name}
Le nom du client qui sera utilis\'e dans la directive Job de la ressource ou
dans une commande run de la Console. Cette directive est requise.
\item [Address = \lt{}address\gt{}]
- \index[dir]{Address }
-
+ \index[dir]{Address}
+ \index[dir]{Directive!Address}
L'adresse d'un File Daemon Bacula est un nom d'h\^ote, un nom pleinement qualifi\'e
ou une adresse r\'eseau au format quatre octets point\'es. Cette directive est requise.
\item [FD Port = \lt{}port-number\gt{}]
- \index[dir]{FD Port }
+ \index[dir]{FD Port}
+ \index[dir]{Directive!FD Port}
O\`u le port est le num\'ero de port auquel le le File Daemon peut \^etre contact\'e.
La valeur par d\'efaut est 9102.
\item [Catalog = \lt{}Catalog-resource-name\gt{}]
- \index[dir]{Catalog }
+ \index[dir]{Catalog}
+ \index[dir]{Directive!Catalog}
Cette directive sp\'ecifie le nom de la ressource catalog \`a utiliser pour ce
client. Cette directive est requise.
\item [Password = \lt{}password\gt{}]
- \index[dir]{Password }
+ \index[dir]{Password}
+ \index[dir]{Directive!Password}
Il s'agit ici du mot de passe \`a utiliser lors de la connection avec le
File Daemon, aussi le fichier de configuration de la machine \`a sauvegarder
doit d\'efinir le m\^eme mot de passe pour \^etre connect\'e par ce Director.
\item [File Retention = \lt{}time-period-specification\gt{} ]
\index[dir]{File Retention }
-
+ \index[dir]{Directive!Password}
La directive File Retention d\'efinit la p\'eriode pendant laquelle Bacula conservera
les enregistrements File dans le catalogue. Lors de l'expiration de cette p\'eriode,
si la directive {\bf AutoPrune} est active ({\bf yes}), Bacula \'elague le catalogue
\item [Job Retention = \lt{}time-period-specification\gt{} ]
\index[dir]{Job Retention}
+ \index[dir]{Directive!Job Retention}
La directive Job Retention d\'efinit la p\'eriode pendant laquelle Bacula conservera
les enregistrements Job dans le catalogue. Lors de l'expiration de cette p\'eriode,
si la directive {\bf AutoPrune} est active ({\bf yes}), Bacula \'elague le catalogue
\item [AutoPrune = \lt{}yes|no\gt{}]
\index[dir]{AutoPrune}
-
+ \index[dir]{Directive!AutoPrune}
Si AutoPrune est r\'egl\'e \`a {\bf yes} (valeur par d\'efaut), Bacula (dans les versions au del\`a
de 1.20) applique automatiquement les p\'eriodes File retention et Job retention pour le
client \`a la fin du job. Si vous sp\'ecifiez {\bf AutoPrune = no}, l'\'elagage ne se fera pas
et non les donn\'ees stock\'ees sur les volumes.
\item [Maximum Concurrent Jobs = \lt{}number\gt{}]
- \index[dir]{Maximum Concurrent Jobs }
+ \index[dir]{Maximum Concurrent Jobs}
+ \index[dir]{Directive!Maximum Concurrent Jobs}
\lt{}number\gt{} d\'esigne le nombre maximum de jobs qui peuvent \^etre lanc\'es simultan\'ement
sur le client concern\'e. Notez que cette directive ne limite que les jobs pour les clients
qui ont le m\^eme nom que la ressource dans laquelle elle apparaît. Toutes les autres restrictions
Jobs}{DirMaxConJobs} du chapitre Configurer le Director.
-\item [*Priority = \lt{}number\gt{}]
- \index[dir]{*Priority }
+\item [Priority = \lt{}number\gt{}]
+ \index[dir]{Priority}
+ \index[dir]{Directive!Priority}
\lt{}number\gt{} sp\'ecifie la priorit\'e de ce client par rapport aux autres clients
que le Director sauvegarde simultan\'ement. La priorit\'e admet une valeur entre 1 et 1000.
Les clients sont ordonn\'es de sorte que ceux dont la valeur de priorit\'e sont les plus petites
\begin{description}
\item [Storage]
- \index[dir]{Storage }
+ \index[dir]{Storage}
+ \index[dir]{Directive!Storage}
D\'ebut des ressources Storage. Il faut en sp\'ecifier au moins une.
\item [Name = \lt{}name\gt{}]
- \index[sd]{Name }
+ \index[dir]{Name}
+ \index[dir]{Directive!Name}
Le nom de la ressource Storage. Ce nom apparaît au niveau de la directive
Storage sp\'ecifi\'ee dans la ressource Job et est requise.
\item [Address = \lt{}address\gt{}]
- \index[sd]{Address }
+ \index[dir]{Address}
+ \index[dir]{Directive!Address}
O\`u l'adresse est un nom d'h\^ote, une {\bf adresse pleinement qualifi\'ee}, ou une
{\bf adresse IP}. Notez bien que l'adresse sp\'ecifi\'ee ici sera transmise au
File Daemon qui l'utilisera alors pour contacter le Storage Daemon. Aussi, ce
Cette directive est requise.
\item [SD Port = \lt{}port\gt{}]
- \index[sd]{SD Port }
+ \index[dir]{SD Port}
+ \index[dir]{Directive!SD Port}
O\`u "port" est le port \`a utiliser pour contacter le Storage Daemon pour les
informations et pour ex\'ecuter les jobs. Ce m\^eme num\'ero de port doit
apparaître dans la ressource Storage du fichier de configuration du
Storage Daemon. Le port par d\'efaut est 9103.
\item [Password = \lt{}password\gt{}]
- \index[sd]{Password }
+ \index[dir]{Password}
+ \index[dir]{Directive!Password}
Il s'agit du mot de passe \`a utiliser lors de l'\'etablissement de la connection
avec les services Storage. Ce m\^eme mot de passe doit aussi apparaître dans la
ressource Director du fichier de configuration du Storage Daemon. Cette
de configuration. Dans le cas contraire, ce champ sera laiss\'e blanc.
\item [Device = \lt{}device-name\gt{}]
- \index[sd]{Device }
-Cette directive sp\'ecifie le nom du p\'eriph\'erique \`a utiliser pour le stockage.
+ \index[dir]{Device}
+ \index[dir]{Directive!Device}
+Cette directive sp\'ecifie le nom (pour le Storage Daemon) du p\'eriph\'erique \`a
+utiliser pour le stockage.
Ce nom n'est pas le nom de p\'eriph\'erique physique, mais le nom de p\'eriph\'erique
logique qui a \'et\'e d\'efini par la directive {\bf Name} de la ressource {\bf Device}
du fichier de configuration du Storage Daemon. Si le p\'eriph\'erique est une librairie, vous
tente d'utiliser le m\^eme p\'eriph\'erique deux fois. Cette directive est requise.
\item [Media Type = \lt{}MediaType\gt{}]
- \index[dir]{Media Type }
+ \index[dir]{Media Type}
+ \index[dir]{Directive!Media Type}
Cette directive sp\'ecifie le type de m\'edia \`a utiliser pour stocker les donn\'ees.
Il s'agit d'une chaîne de caract\`eres arbitraire n'exc\'edant pas 127 caract\`eres.
Ce peut \^etre ce que vous voulez, cependant, il est pr\'ef\'erable de la choisir de
certainement sp\'ecifier des {\bf Media Types} distincts. Lors d'une restauration,
supposons qu'un Media Type {\bf DDS-4} est associ\'e avec le le job, Bacula peut
d\'ecider d'utiliser tout Storage Daemon qui supporte le Media Type {\bf DDS-4} sur
-tout lecteur qui le supporte. Si vous voulez contraindre Bacula \`a utiliser un
+tout lecteur qui le supporte.
+
+Actuellement, Bacula n'autorise qu'un seul type de media. Par conséquent, si vous
+disposez d'un lecteur qui en supporte plusieurs, vous pouvez utiliser une chaîne
+unique pour désigner les volumes de l'un ou l'autre type, par exemple Media Type = DDS-3-4
+pour les types DDS-3 et DDS-4, mais ces volumes ne seront montés que sur les lecteurs
+spécifiés comme acceptant les deux types : DDS-3-4
+
+Si vous voulez contraindre Bacula \`a utiliser un
seul Storage Daemon ou un seul lecteur, vous devez sp\'ecifier un Media Type unique
pour ce lecteur. C'est un point important qui devrait \^etre bien compris. Notez que
ceci s'applique \'egalement aux volumes disque. Si vous d\'efinissez plus d'une ressource
\item [Autochanger = \lt{}yes|no\gt{} ]
\index[dir]{Autochanger }
+ \index[dir]{Directive!Autochanger}
Si vous sp\'ecifiez {\bf yes} pour cette commande (la valeur par d\'efaut est {\bf no}),
alors Bacula requ\'erira un num\'ero de Slot lorsque vous utiliserez les commandes
{\bf label} et {\bf add} pour cr\'eer un nouveau volume. Ceci simplifie la cr\'eation
\ilink{ Utiliser une librairie}{_ChapterStart18} de ce manuel.
\item [Maximum Concurrent Jobs = \lt{}number\gt{}]
- \index[dir]{Maximum Concurrent Jobs }
+ \index[dir]{Maximum Concurrent Jobs}
+ \index[dir]{Directive!Maximum Concurrent Jobs}
O\`u \lt{}number\gt{} est le nombre maximum de jobs utilisant la
ressource Storage courante qui peuvent \^etre ex\'ecut\'es simultan\'ement. Notez que cette
directive ne limite que les jobs qui utilisent ce Storage Daemon. Toute autre
\begin{description}
\item [Pool]
- \index[dir]{Pool }
+ \index[dir]{Pool}
+ \index[dir]{Directive!Pool}
D\'ebut de la ressource Pool. Il faut d\'efinir au moins une ressource Pool.
\item [Name = \lt{}name\gt{}]
- \index[dir]{Name }
+ \index[dir]{Name}
+ \index[dir]{Directive!Name}
Le nom du pool. Pour la plupart des applications, vous utiliserez le pool
par d\'efaut nomm\'e {\bf Default}. Cette directive est requise.
\label{MaxVolumes}
\item [Maximum Volumes = \lt{}number\gt{}]
- \index[dir]{Maximum Volumes }
-
+ \index[dir]{Maximum Volumes}
+ \index[dir]{Directive!Maximum Volumes}
Cette directive sp\'ecifie le nombre maximum de volumes contenus dans le pool.
Cette directive est optionnelle. Si elle est omise ou r\'egl\'ee \`a 0, tout nombre
de volumes est permis. En g\'en\'eral, cette directive est utile pour les librairies,
\item [Pool Type = \lt{}type\gt{}]
\index[dir]{Pool Type }
+ \index[dir]{Directive!Pool Type}
Cette directive d\'efinit le type du pool, qui correspond au type du job
ex\'ecut\'e. Cette directive est requise et peut prendre l'une des valeurs suivantes :
\end{itemize}
\item [Use Volume Once = \lt{}yes|no\gt{}]
- \index[dir]{Use Volume Once }
+ \index[dir]{Use Volume Once}
+ \index[dir]{Directive!Use Volume Once}
Cette directive, si elle est active (valeur {\bf yes}) stipule que chaque volume
ne doit \^etre utilis\'e qu'une seule fois. C'est particuli\`erement utile si le
volume est un fichier et si vous voulez un nouveau fichier pour chaque nouvelle
existant, vous devez utiliser la commande {\bf update} du programme Console.
\item [Maximum Volume Jobs = \lt{}positive-integer\gt{}]
- \index[dir]{Maximum Volume Jobs }
+ \index[dir]{Maximum Volume Jobs}
+ \index[dir]{Directive!Maximum Volume Jobs}
Cette directive sp\'ecifie le nombre maximum de jobs qui peuvent \^etre \'ecrits sur le volume.
La valeur par d\'efaut est z\'ero, ce qui signifie que le nombre de jobs sur un volume
n'est pas limit\'e. Sinon, lorsque le nombre de jobs sauvegard\'es sur le volume atteint
existant, vous devez utiliser la commande {\bf update} du programme Console.
\item [Maximum Volume Files = \lt{}positive-integer\gt{}]
- \index[dir]{Maximum Volume Files }
+ \index[dir]{Maximum Volume Files}
+ \index[dir]{Directive!Maximum Volume Files}
Cette directive sp\'ecifie le nombre maximum de fichiers qui peuvent \^etre \'ecrits sur
le volume. La valeur par d\'efaut est z\'ero, ce qui signifie que le nombre de fichiers
sur un volume n'est pas limit\'e. Sinon, lorsque le nombre de fichiers sauvegard\'es sur
existant, vous devez utiliser la commande {\bf update} du programme Console.
\item [Maximum Volume Bytes = \lt{}size\gt{}]
- \index[dir]{Maximum Volume Bytes }
+ \index[dir]{Maximum Volume Bytes}
+ \index[dir]{Directive!Maximum Volume Bytes}
Cette directive sp\'ecifie le nombre maximum d'octets qui peuvent \^etre \'ecrits sur le
volume. La valeur par d\'efaut est z\'ero, ce qui signifie qu'il n'y a d'autre limite
que la capacit\'e physique du volume. Sinon, lorsque le nombre d'octets sauvegard\'es sur
existant, vous devez utiliser la commande {\bf update} du programme Console.
\item [Volume Use Duration = \lt{}time-period-specification\gt{}]
- \index[dir]{Volume Use Duration }
+ \index[dir]{Volume Use Duration}
+ \index[dir]{Directive!Volume Use Duration}
Cette directive d\'efinit la p\'eriode durant laquelle le volume peut \^etre utilis\'e en
\'ecriture, \`a compter de la premi\`ere op\'eration d'\'ecriture de donn\'ees.
La valeur par d\'efaut est z\'ero, ce qui signifie que le volume peut \^etre \'ecrit
{\bf time-period-specification} sp\'ecifi\'ee, le volume est marqu\'e
{\bf Used}. D\`es lors, il ne peut plus \^etre utilis\'e pour y ajouter des jobs, tout comme
dans le cas d'un volume avec le statut {\bf Full}, mais il peut \^etre recycl\'e si le
-recyclage est activ\'e.
+recyclage est activ\'e. L'usage de la commande {\bf status dir} applique des algorithmes
+similaires à l'éxecution de jobs, aussi lors d'une telle commande, le statut du volume
+peut être modifié. Lorsque le volume est recyclé, il peut à nouveau être utilisé.
Vous pourriez utiliser cette directive, par exemple, si vous avez un volume d\'edi\'e
aux sauvegardes incr\'ementales, et un volume d\'edi\'e aux Fulls hebdomadaires. Une fois que
\item [Catalog Files = \lt{}yes|no\gt{}]
\index[dir]{Catalog Files}
+ \index[dir]{Directive!Catalog Files}
Cette directive pr\'ecise si les noms des fichiers sauvegard\'es doivent ou non \^etre
enregistr\'es dans le catalogue. La valeur par d\'efaut est {\bf yes}. L'avantage de
d\'esactiver cette option ({\bf Catalog Files = No}) est d'avoir un catalogue
\item [AutoPrune = \lt{}yes|no\gt{}]
\index[dir]{AutoPrune}
+ \index[dir]{Directive!AutoPrune}
Si AutoPrune est activ\'ee ({\bf yes}), ce qui est le cas par d\'efaut, Bacula
(depuis la version 1.20) applique automatiquement la p\'eriode de r\'etention des
volumes lorsqu'un nouveau volumes est requis ou lorsqu'il n'existe aucun volume
\item [Volume Retention = \lt{}time-period-specification\gt{}]
\index[dir]{Volume Retention}
+ \index[dir]{Directive!Volume Retention}
La directive Volume Retention d\'efinit la p\'eriode durant laquelle {\bf Bacula}
conserve les enregistrements Job associ\'es au volume dans le catalogue.
Lors de l'expiration de cette p\'eriode, si {\bf AutoPrune} est activ\'ee, Bacula
p\'eriode la plus courte est celle qui s'applique.Notez bien que lorsque la p\'eriode
{\bf Volume Retention} a \'et\'e atteinte les enregistrements de Job et ceux de fichiers
sont supprimm\'es les uns et les autres.
+Cet élagage peut aussi se produire à l'exécution de la commande {\bf status dir} car elle
+applique des algorithmes similaires à ceux utilisés pour déterminer le prochain volume
+disponible.
Il est important de savoir que lorsque la p\'eriode Volume Retention expire,
Bacula ne recycle pas syst\'ematiquement le volume concern\'e. Il tente de conserver
\item [Recycle = \lt{}yes|no\gt{}]
\index[dir]{Recycle}
+ \index[dir]{Directive!Recycle}
Cette directive sp\'ecifie la valeur par d\'efaut pour le recyclage des volumes purg\'es.
Si elle est activ\'ee ({\bf yes}) et si Bacula a besoin d'un volume mais n'en trouve
aucun utilisable, il recherche alors les volumes purg\'es (c'est \`a dire ceux dont tous
\label{RecycleOldest}
\item [Recycle Oldest Volume = \lt{}yes|no\gt{}]
- \index[dir]{Recycle Oldest Volume }
+ \index[dir]{Recycle Oldest Volume}
+ \index[dir]{Directive!Recycle Oldest Volume}
Cette directive indique au Director de rechercher le volume le plus ancien
du pool lorsq'un nouveau est requis par le Storage Daemon et qu'aucun autre
n'est disponible. Le catalog est alors {\bf \'elagu\'e} dans le respect des
\label{RecycleCurrent}
\item [Recycle Current Volume = \lt{}yes|no\gt{}]
- \index[dir]{Recycle Current Volume }
+ \index[dir]{Recycle Current Volume}
+ \index[dir]{Directive!Recycle Current Volume}
Si Bacula a besoin d'un nouveau volume, cette directive lui indique d'\'elaguer
le volume dans le respect des p\'eriodes {\bf Job}, {\bf File} et
{\bf Volume Retention}. Si tous les jobs sont \'elagu\'es, (c'est \`a dire si le
\label{PurgeOldest}
\item [Purge Oldest Volume = \lt{}yes|no\gt{}]
- \index[dir]{Purge Oldest Volume }
+ \index[dir]{Purge Oldest Volume}
+ \index[dir]{Directive!Purge Oldest Volume}
Cette directive indique au Director de rechercher le volume utilis\'e le plus
ancien dans le pool lorsqu'un nouveau volume est requis par le Storage
Daemon et qu'aucun n'est disponible. Le catalogue est alors purg\'e sans
La valeur par d\'efaut est {\bf no}
\item [Cleaning Prefix = \lt{}string\gt{}]
- \index[dir]{Cleaning Prefix }
+ \index[dir]{Cleaning Prefix}
+ \index[dir]{Directive!Cleaning Prefix}
Cette directive d\'efinit un pr\'efixe qui, s'il correspond au d\'ebut du nom d'un
volume lors de son \'etiquettage, indique \`a Bacula que le volume en question est
une cartouche de nettoyage, qui aura le statut {\bf VolStatus = Cleaning}.
\label{Label}
\item [Label Format = \lt{}format\gt{}]
- \index[dir]{Label Format }
+ \index[dir]{Label Format}
+ \index[dir]{Directive!Label Format}
Cette directive pr\'ecise le format des \'etiquettes des volumes de ce pool.
La directive {\bf Format} est utilis\'ee comme un patron pour cr\'eer de nouveaux
noms de volumes lors de l'\'etiquettage automatique.
\begin{description}
\item [Catalog]
- \index[dir]{Catalog }
+ \index[dir]{Catalog}
+ \index[dir]{Directive!Catalog}
D\'ebut de la ressource Catalog. Il faut au moins une ressource Catalogue.
\item [Name = \lt{}name\gt{}]
- \index[dir]{Name }
+ \index[dir]{Name}
+ \index[dir]{Directive!Name}
Le nom du Catalog. Il n'a pas besoin d'\^etre en relation avec le nom sur le serveur
de base de donn\'ees. Ce nom sera repris dans la ressource Client, indiquant ainsi
que toutes les donn\'ees relatives \`a ce client sont maintenues dans ce catalogue.
\item [password = \lt{}password\gt{}]
- \index[dir]{password }
+ \index[dir]{password}
+ \index[dir]{Directive!password}
Cette directive sp\'ecifie le mot de passe \`a utiliser pour se connecter au
catalogue. Cette directive est requise.
\item [DB Name = \lt{}name\gt{}]
- \index[dir]{DB Name }
+ \index[dir]{DB Name}
+ \index[dir]{Directive!DB Name}
Cette directive sp\'ecifie le nom de la base de donn\'ees. Si vous utilisez plusieurs
catalogues, vous sp\'ecifiez lequel ici. Si vous utilisez un serveur de bases de
donn\'ees externe plut\^ot que l'int\'egr\'e, vous devez sp\'ecifier un nom connu du
tables Bacula.). Cette directive est requise.
\item [user = \lt{}user\gt{}]
- \index[dir]{user }
+ \index[dir]{user}
+ \index[dir]{Directive!user}
L'utilisateur habilit\'e \`a se connecter au catalogue. Cette directive est requise.
\item [DB Socket = \lt{}socket-name\gt{}]
- \index[dir]{DB Socket }
+ \index[dir]{DB Socket}
+ \index[dir]{Directive!DB Socket}
Il s'agit du nom d'un {\it socket} \`a utiliser sur la machine locale pour se
connecter au catalogue. Cette directive n'est utilis\'ee que par MySQL, elle est
ignor\'ee par SQLite. Normalement, si ni {\bf DB Socket}, ni {\bf DB Address} ne sont
sp\'ecifi\'ees, MySQL utilise le socket par d\'efaut.
\item [DB Address = \lt{}address\gt{}]
- \index[dir]{DB Address }
+ \index[dir]{DB Address}
+ \index[dir]{Directive!DB Address}
Il s'agit de l'adresse du serveur de bases de donn\'ees. En principe, vous
utiliserez cette directive plut\^ot que {\bf DB Socket} si le serveur de bases de
donn\'ees est une autre machine. Dans ce cas, vous sp\'ecifierez aussi le port {\bf DB Port}.
optionnelle.
\item [DB Port = \lt{}port\gt{}]
- \index[dir]{DB Port }
+ \index[dir]{DB Port}
+ \index[dir]{Directive!DB Port}
Cette directive d\'efinit le port \`a utiliser en conjonction avec {\bf DB Address} pour
acc\'eder au catalogue s'il est h\'eberg\'e sur une autre machine. Elle n'est utilis\'ee que par
MySQL, et ignor\'ee par SQLite. Elle est optionnelle.
%% \item [Multiple Connections = \lt{}yes|no\gt{}]
-%% \index[dir]{Multiple Connections }
+%% \index[dir]{Multiple Connections}
+%% \index[dir]{Directive!Multiple Connections}
%% Par d\'efaut, cette directive est d\'esactiv\'ee, ce qui implique que tous les jobs utilisant
%% le m\^eme catalogue se partagent une m\^eme connection au catalogue, et que Bacula n'autorise
%% qu'un job \`a la fois \`a communiquer. Si vous activez cette directive ({\bf yes}), Bacula
\begin{description}
\item [Name = \lt{}name\gt{}]
- \index[dir]{Name }
+ \index[dir]{Name}
+ \index[dir]{Directive!Name}
Le nom de la console. Ce nom doit \^etre en conjonction avec celui sp\'ecifi\'e
dans le fichier de configuration de la Console (comme c'est le cas pour les
d\'efinitions de clients).
\item [Password = \lt{}password\gt{}]
- \index[dir]{Password }
+ \index[dir]{Password}
+ \index[dir]{Directive!Password}
Sp\'ecifie le mot de passe qu'une console nomm\'ee doit fournir pour \^etre autoris\'ee.
Le m\^eme mot de passe doit apparaître dans la ressource Console du fichier
de configuration de la Console. Pour plus de s\'ecurit\'e, le mot de passe n'est
processus de configuration, autrement, il sera laiss\'e blanc.
\item [JobACL = \lt{}name-list\gt{}]
- \index[dir]{JobACL }
+ \index[dir]{JobACL}
+ \index[dir]{Directive!JobACL}
Cette directive est utilis\'ee pour sp\'ecifier une liste de noms de ressources Job
qui peuvent \^etre acc\'ed\'es par la console. Sans cette directive, la console ne peut
acc\'eder \`a aucune des ressources Job d\'efinies dans le fichier de configuration
les quatre jobs d\'esign\'es par la directive JobACL, et uniquement \`a eux.
\item [ClientACL = \lt{}name-list\gt{}]
- \index[dir]{ClientACL }
+ \index[dir]{ClientACL}
+ \index[dir]{Directive!ClientACL}
Cette directive est utilis\'ee pour sp\'ecifier une liste de noms de ressources Client
iaccessibles par la console.
\item [StorageACL = \lt{}name-list\gt{}]
- \index[dir]{StorageACL }
+ \index[dir]{StorageACL}
+ \index[dir]{Directive!StorageACL}
Cette directive est utilis\'ee pour sp\'ecifier une liste de noms de ressources Storage
accessibles par la console.
\item [ScheduleACL = \lt{}name-list\gt{}]
- \index[dir]{ScheduleACL }
+ \index[dir]{ScheduleACL}
+ \index[dir]{Directive!ScheduleACL}
Cette directive est utilis\'ee pour sp\'ecifier une liste de noms de ressources Schedule
accessibles par la console.
\item [PoolACL = \lt{}name-list\gt{}]
- \index[dir]{PoolACL }
+ \index[dir]{PoolACL}
+ \index[dir]{Directive!PoolACL}
Cette directive est utilis\'ee pour sp\'ecifier une liste de noms de ressources Pool
accesibles ar la console.
\item [FileSetACL = \lt{}name-list\gt{}]
- \index[dir]{FileSetACL }
+ \index[dir]{FileSetACL}
+ \index[dir]{Directive!FileSetACL}
Cette directive est utilis\'ee pour sp\'ecifier une liste de noms de ressources FileSet
accessibles par la console.
\item [CatalogACL = \lt{}name-list\gt{}]
- \index[dir]{CatalogACL }
+ \index[dir]{CatalogACL}
+ \index[dir]{Directive!CatalogACL}
Cette directive est utilis\'ee pour sp\'ecifier une liste de noms de ressources Catalog
accessibles par la console.
\item [CommandACL = \lt{}name-list\gt{}]
- \index[dir]{CommandACL }
+ \index[dir]{CommandACL}
+ \index[dir]{Directive!CommandACL}
Cette directive est utilis\'ee pour sp\'ecifier une liste de commandes de la console
qui peuvent \^etre ex\'ecut\'ees par la console.
\begin{description}
\item [Counter]
- \index[dir]{Counter }
+ \index[dir]{Counter}
+ \index[dir]{Directive!Counter}
D\'ebut de la ressource Counter. les directives Counter sont optionnelles.
\item [Name = \lt{}name\gt{}]
- \index[dir]{Name }
+ \index[dir]{Name}
+ \index[dir]{Directive!Name}
iLe nom de la variable-compteur. Il s'agit du nom que vous utiliserez pour vous r\'ef\'erer
\`a cette variable et acc\'eder \`a sa valeur.
\item [Minimum = \lt{}integer\gt{}]
- \index[dir]{Minimum }
+ \index[dir]{Minimum}
+ \index[dir]{Directive!Minimum}
Sp\'ecifie la valeur minimale de la variable-compteur. Cette valeur devient celle par d\'efaut.
Si elle n'est pas fournie, sa valeur est z\'ero.
\item [Maximum = \lt{}integer\gt{}]
- \index[dir]{Maximum }
+ \index[dir]{Maximum}
+ \index[dir]{Directive!Maximum}
Sp\'ecifie la valeur maximale de la variable-compteur. Si elle n'est pas fournie, ou si elles
est r\'egl\'ee \`a z\'ero, la variable compteur peut prendre une valeur maximale de 2 147 483 648
($2^{31}$). Au del\`a de cette valeur, le compteur est remis au minimum.
\item [*WrapCounter = \lt{}counter-name\gt{}]
- \index[dir]{*WrapCounter }
+ \index[dir]{*WrapCounter}
+ \index[dir]{Directive!*WrapCounter}
Si cette valeur est sp\'ecifi\'ee, lorsque la variable-compteur d\'epasse le maximum et
est remise au minimum, le compteur sp\'ecifi\'e par la directive {\bf WrapCounter} est
incr\'ement\'e. (Ceci n'est, pour le moment, pas impl\'ement\'e.)
\item [Catalog = \lt{}catalog-name\gt{}]
- \index[dir]{Catalog }
+ \index[dir]{Catalog}
+ \index[dir]{Directive!Catalog}
Si cette directive est sp\'ecifi\'ee, le compteur et sa valeur sont sauvegard\'es dans le
catalogue sp\'ecifi\'e. Dans le cas contraire, le compteur est red\'efini \`a chaque
d\'emarrage de Bacula.
\newcommand\lthtmlboxmathZ{\@next\next\@currlist{}{\def\next{\voidb@x}}%
\expandafter\box\next\egroup}%
\newcommand\lthtmlmathtype[1]{\gdef\lthtmlmathenv{#1}}%
-\newcommand\lthtmllogmath{\lthtmltypeout{l2hSize %
+\newcommand\lthtmllogmath{\dimen0\ht\sizebox \advance\dimen0\dp\sizebox
+ \ifdim\dimen0>.95\vsize
+ \lthtmltypeout{%
+*** image for \lthtmlmathenv\space is too tall at \the\dimen0, reducing to .95 vsize ***}%
+ \ht\sizebox.95\vsize \dp\sizebox\z@ \fi
+ \lthtmltypeout{l2hSize %
:\lthtmlmathenv:\the\ht\sizebox::\the\dp\sizebox::\the\wd\sizebox.\preveqno}}%
\newcommand\lthtmlfigureA[1]{\let\@savefreelist\@freelist
\lthtmlmathtype{#1}\lthtmlvboxmathA}%
% !!! IMAGES START HERE !!!
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27331}%
+\lthtmlpictureA{tex2html_wrap27730}%
\includegraphics{./bacula-logo.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27338}%
+\lthtmlpictureA{tex2html_wrap27737}%
\includegraphics{./bacula-applications.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27340}%
+\lthtmlpictureA{tex2html_wrap27739}%
\includegraphics{./bacula-objects.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27346}%
+\lthtmlpictureA{tex2html_wrap27745}%
\includegraphics{./flow.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27547}%
+\lthtmlpictureA{tex2html_wrap27946}%
\includegraphics{./Bacula-tray-monitor.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap27675}%
+\lthtmlpictureA{tex2html_wrap28081}%
\includegraphics{./Conf-Diagram.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlfigureA{center27712}%
+\lthtmlfigureA{center28118}%
\begin{center}\vbox{\input{autochangerres}
}\end{center}%
\lthtmlfigureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap28164}%
+\lthtmlpictureA{tex2html_wrap28570}%
\includegraphics{./win32-nsis.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap28165}%
+\lthtmlpictureA{tex2html_wrap28571}%
\includegraphics{./win32-welcome.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap28166}%
+\lthtmlpictureA{tex2html_wrap28572}%
\includegraphics{./win32-pkg.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap28167}%
+\lthtmlpictureA{tex2html_wrap28573}%
\includegraphics{./win32-location.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap28168}%
+\lthtmlpictureA{tex2html_wrap28574}%
\includegraphics{./win32-service.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap28169}%
+\lthtmlpictureA{tex2html_wrap28575}%
\includegraphics{./win32-service-ok.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap28170}%
+\lthtmlpictureA{tex2html_wrap28576}%
\includegraphics{./win32-start.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap28171}%
+\lthtmlpictureA{tex2html_wrap28577}%
\includegraphics{./win32-finish.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap28172}%
+\lthtmlpictureA{tex2html_wrap28578}%
\includegraphics{./idle.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap28173}%
+\lthtmlpictureA{tex2html_wrap28579}%
\includegraphics{./tray-icon.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap28174}%
+\lthtmlpictureA{tex2html_wrap28580}%
\includegraphics{./menu.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap28175}%
+\lthtmlpictureA{tex2html_wrap28581}%
\includegraphics{./running.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap28176}%
+\lthtmlpictureA{tex2html_wrap28582}%
\includegraphics{./error.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap28257}%
+\lthtmlpictureA{tex2html_wrap28663}%
\includegraphics{./access-is-denied.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap28258}%
+\lthtmlpictureA{tex2html_wrap28664}%
\includegraphics{./view-only.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap28259}%
+\lthtmlpictureA{tex2html_wrap28665}%
\includegraphics{./properties-security.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap28260}%
+\lthtmlpictureA{tex2html_wrap28666}%
\includegraphics{./properties-security-advanced-owner.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
{\newpage\clearpage
-\lthtmlpictureA{tex2html_wrap28261}%
+\lthtmlpictureA{tex2html_wrap28667}%
\includegraphics{./confirm.eps}%
\lthtmlpictureZ
\lthtmlcheckvsize\clearpage}
En g\'en\'eral, il vous faudra les sources de la version courante de Bacula,
et si vous souhaitez ex\'ecuter un client Windows, vous aurez besoin de la
version binaire du client Bacula pour Windows. Par ailleurs, Bacula a besoin
-de certains paquettages externes (tels {\bf SQLite}, {\bf MySQL} ou {\bf
+de certains paquetages externes (tels {\bf SQLite}, {\bf MySQL} ou {\bf
PostgreSQL}) pour compiler correctement en accord avec les options que vous
aurez choisies. Pour vous simplifier la t\^ache, nous avons combin\'e
-plusieurs de ces programmes dans deux paquettages {\bf depkgs} (paquettages de
+plusieurs de ces programmes dans deux paquetages {\bf depkgs} (paquetages de
d\'ependances). Ceci peut vous simplifier la vie en vous fournissant tous les
paquets n\'ecessaires plut\^ot que de vous contraindre \`a les trouver sur la
Toile, les charger et installer.
+
+\subsection*{Distribution des fichiers source}
+\index[general]{fichiers source}
+\index[general]{distrribution fichiers}
+\addcontentsline{toc}{subsection}{Distribution des fichiers source}
+A partir de la version 1.38.0, le code source est \'eclat\'e en quatre
+fichiers tar correspondant \`a quatre modules diff\'erents dans le CVS
+Bacula. Ces fichiers sont :
+
+\begin{description}
+\item [bacula-1.38.0.tar.gz]
+ Il s'agit de la distribution primaire de Bacula. Pour chaque nouvelle
+ version, le num\'ero de version (ici, 1.38.0) sera mise \`a jour.
+
+\item [bacula-docs-1.38.0.tar.gz]
+ Ce fichier contient une copie du r\'epertoire docs, avec les documents
+ pr\'e-construits : R\'epertoire html anglais, fichier html unique et
+ fichier pdf. Les traductions allemande et fran\\ 3aise sont en cours mais
+ ne sont pas pr\'e-construites.
+
+\item [bacula-gui-1.38.0.tar.gz]
+ Ce fichier contient les programmes graphique en dehors du coeur
+ de l'application. Actuellement, il contient bacula-web, un programme
+ PHP pour produire une vue d'ensemble des statuts de vos jobs
+ Bacula consultable dans un navigateur ; et bimagemgr, un programme
+ qui permet de graver des images de CDROMS depuis un navigateur avec
+ les volumes Bacula.
+
+\item [bacula-rescue-1.8.1.tar.gz]
+ Ce fichier contient le code du CDROM de secours Bacula. Notez
+ que le num\'ero de version de ce paquetage n'est pas li\'e \`a celui
+ de Bacula. En utilisant ce code, vous pouvez graver un CDROM contenant
+ la configuration de votre syst\`eme et une version statiquement li\'ee du
+ File Daemon. Ceci peut vous permettre de repartitionner et reformater
+ ais\'ement vos disques durs et de recharger votre syst\`eme avec Bacula
+ en cas de d\'efaillance du disque dur.
+\end{description}
+
\label{upgrading1}
\subsection*{Mettre Bacula \`a jour}
de donn\'ees du catalogue a \'et\'e mise \`a jour, vous devrez soit
r\'einitialiser votre base de donn\'ees et repartir de z\'ero, soit en
sauvegarder une copie au format ASCII avant de proc\'eder \`a sa mise \`a
-jour. S'il y a eu plusieurs mises \`a jour de la base de donn\'ees entre votre
+jour. Ceci est normalement fait lorsque Bacula est compil\'e et install\'e par :
+
+\begin{verbatim}
+cd <installed-scripts-dir> (default /etc/bacula)
+./update_bacula_tables
+\end{verbatim}
+
+Ce script de mise \`a jour peut aussi \^etre trouv\'e dans le r\'epertoire
+src/cats des sources de Bacula.
+
+S'il y a eu plusieurs mises \`a jour de la base de donn\'ees entre votre
version et celle vers laquelle vous souhaitez \'evoluer, il faudra appliquer
chaque script de mise \`a jour de base de donn\'ees. Vous pouvez trouver tous
les anciens scripts de mise \`a jour dans le r\'epertoire {\bf upgradedb} des
semble confus, lisez simplement les ReleaseNotes tr\`es attentivement, elles
signaleront si les {\it daemons} doivent \^etre mis \`a jour simultan\'ement.
-\subsection*{Paquettage de D\'ependences}
+Enfin, notez qu'il n'est g\'en\'eralement pas n\'ecessaire d'utiliser
+{\bf make uninstall} avant de proc\'eder \`a une mise \`a jour. En fait, si vous le
+faites vous effacerez probablement vos fichiers de configuration, ce qui
+pourrait \^etre d\'esastreux. La proc\'edure normale de mise \`a jour est simplement
+{\bf make install}. En principe, aucun de vos fichiers .conf ou .sql ne sera
+\'ecras\'e.
+
+Pour plus d'informations sur les mises \`a jour, veuillez consulter la partie
+\ilink{Upgrading Bacula Versions}{upgrading} du chapitre Astuces de ce manuel
+
+\subsection*{Paquetage de D\'ependences}
\label{Dependency}
-\index[general]{Paquettage de D\'ependences }
-\addcontentsline{toc}{subsection}{Paquettage de D\'ependences}
+\index[general]{Paquetage de D\'ependences}
+\index[general]{Paquetage!D\'ependences}
+\addcontentsline{toc}{subsection}{Paquetage de D\'ependences}
Comme nous l'\'evoquions plus haut, nous avons combin\'e une s\'erie de
programmes dont Bacula peut avoir besoin dans les paquets {\bf depkgs} et {\bf
trouver. Pourtant, il faut noter que nous avons test\'e la compatibilit\'e des
paquets contenus dans les fichiers depkgs avec Bacula.
-Vous pouvez, bien sur, obtenir les dernieres versions de ces paquettages de
+Vous pouvez, bien sur, obtenir les dernieres versions de ces paquetages de
leurs auteurs. Les r\'ef\'erences n\'ecessaires figurent dans le README de
chaque paquet. Quoi qu'il en soit, soyez conscient du fait que nous avons
-test\'e la compatibilit\'e des paquettages des fichiers depkgs.
+test\'e la compatibilit\'e des paquetages des fichiers depkgs.
-Typiquement, un paquettage de d\'ependances sera nomm\'e {\bf
+Typiquement, un paquetage de d\'ependances sera nomm\'e {\bf
depkgs-ddMMMyy.tar.gz} et {\bf depkgs1-ddMMMyy.tar.gz} o\`u {\bf dd} est le
jour o\`u n'ous l'avons publi\'e, {\bf MMM} l'abbr\'eviation du mois et {\bf
yy} l'ann\'ee. Par exemple: {\bf depkgs-07Apr02.tar.gz}. Pour installer et
-construire ce paquettage (s'il est requis), vous devez:
+construire ce paquetage (s'il est requis), vous devez:
\begin{enumerate}
\item Cr\'eer un r\'epertoire {\bf bacula}, dans lequel vous placerez les
- sources de Bacula et le paquettage de d\'ependances.
+ sources de Bacula et le paquetage de d\'ependances.
\item D\'esarchiver le {\bf depkg} dans le r\'epertoire {\bf bacula}.
\item vous d\'eplacer dans le r\'epertoire obtenu: cd bacula/depkgs
\item ex\'ecuter make
\end{enumerate}
-La composition exacte des paquettages de d\'ependance est susceptible de
+La composition exacte des paquetages de d\'ependance est susceptible de
changer de temps en temps, voici sa composition actuelle :
\begin{longtable}{|l|l|l|l|}
\begin{enumerate}
\item Installez et construisez chaque {\bf depkgs} comme indiqu\'e plus haut.
+
\item Configurez et installez MySQL ou PostgreSQL (si vous le souhaitez):
\ilink{Installer et configurer MySQL Phase I}{_ChapterStart} ou
\ilink{Installer et configurer PostgreSQL Phase
compression gzip {\bf libz.a} ou {\bf libz.so}. Ces librairies sont dans le
paquet {\bf libz-devel}. Sur Debian, vous devrez charger le paquet {\bf
zlib1g-dev}. Si vous n'utilisez ni rpms, ni debs, il vous faudra trouver le
-paquettage adapt\'e \`a votre syst\`eme. Notez que si vous avez dej\`a MySQL
+paquetage adapt\'e \`a votre syst\`eme.
+
+Notez que si vous avez dej\`a MySQL
ou PostgreSQL sur votre syst\`eme vous pouvez sauter cette phase pourvu que
-vous ayez construit ``the thread safe libraries'' et que vous ayez d\'ej\`a
+vous ayez construit "the thread safe libraries'' et que vous ayez d\'ej\`a
install\'e les rpms additionnels sus-mentionn\'es.
+
\item En alternative \`a MySQL et PostgreSQL, configurez et installez SQLite,
- qui fait partie du paquettage {\bf depkgs}.
+ qui fait partie du paquetage {\bf depkgs}.
\ilink{Installer et configurer SQLite}{_ChapterStart33}.
+
\item D\'esarchivez les sources de Bacula, de pr\'ef\'erence dans le
r\'epertoire {\bf bacula} \'evoqu\'e ci-dessus.
+
\item D\'eplacez-vous dans ce r\'epertoire.
+
\item Ex\'ecutez ./configure (avec les options appropri\'ees comme d\'ecrit
ci-dessus)
+
\item Examinez tr\`es attentivement la sortie de ./configure,
particuli\`erement les r\'epertoires d'installation des binaires et des
fichiers de configuration. La sortie de ./configure est stock\'ee dans le
fichier {\bf config.out} et peut \^etre affich\'ee \`a volont\'e sans
relancer ./configure par la commande {\bf cat config.out}.
+
\item Vous pouvez relancer ./configure avec des options diff\'erentes apr\`es
une premi\`ere ex\'ecution, cela ne pose aucun probl\`eme, mais vous devriez
d'abord ex\'ecuter:
en cache une bonne partie des informations. {\bf make distclean} est aussi
recommand\'e si vous d\'eplacez vos fichiers source d'une machine \`a une
autre. Si {\bf make distclean} \'echoue, ignorez-le et continuez.
+
\item make
Si vous obtenez des erreurs durant le {\it linking} dans le r\'epertoire du
la librairie statique sur votre syst\`eme. J'ai remarqu\'e ce probl\`eme sur
un Solaris. Pour le corriger, assurez-vous de ne pas avoir ajout\'e l'option
{\bf \verb{--{enable-static-tools} \`a la commande {\bf ./configure}.
+
\item make install
+
\item Si vous \^etes un nouvel utilisateur de Bacula, nous vous recommandons
{\bf fortement} de sauter l'\'etape suivante et d'utiliser le fichier de
configuration par d\'efaut, puis d'ex\'ecuter le jeu d'exemples du prochain
chapitre avant de revenir modifier vos fichier de configuration pour qu'ils
satisfassent vos besoins.
+
\item Modifiez les fichiers de configuration de chacun des trois {\it daemons}
(Directory, File, Storage) et celui de la Console. Pour plus de d\'etails,
consultez le chapitre
passe qui sont g\'en\'er\'es al\'eatoirement, ainsi que les noms car ils
doivent s'accorder entre les fichiers de configuration pour des raisons de
s\'ecurit\'e.
+
\item Cr\'eez la base de donn\'ees Bacula MySQL et ses tables (si vous
utilisez MySQL)
\ilink{Installer et configurer MySQL Phase II}{mysql_phase2} ou
encore
\ilink{Installer et configurer SQLite Phase II}{phase2} (si vous
utilisez SQLite)
+
\item D\'emarrez Bacula ({\bf ./bacula start}) Notez: Le prochain chapitre
expose ces \'etapes en d\'etail.
+
\item Lancez la Console pour communiquer avec Bacula.
+
\item Pour les deux \'el\'ements pr\'ec\'edents, veuillez suivre les
instructions du chapitre
\ilink{Ex\'ecuter Bacula}{_ChapterStart1} o\`u vous ferez une
Si vous installez Bacula sur plusieurs syst\`emes identiques, vous pouvez
simplement transf\'erer le r\'epertoire des sources vers ces autres syst\`emes
-et faire un ``make install''. Cependant s'il y a des diff\'erences dans les
+et faire un "make install''. Cependant s'il y a des diff\'erences dans les
librairies, ou les versions de syst\`emes, ou si vous voulez installer sur un
syst\`eme diff\'erent, vous devriez recommencer \`a partir de l'archive tar
compress\'ee originale. Si vous transf\'erez un r\'epertoire de sources o\`u
l'outil GNU autoconf qui met la configuration en cache, de sorte que si vous
r\'eutilisez la configuration d'une machine Linux sur un Solaris, vous pouvez
\^etre certain que votre compilation \'echouera. Pour l'\'eviter, comme
-mentionn\'e plus haut, recommencez depuis l'archive tar, ou faites un ``make
+mentionn\'e plus haut, recommencez depuis l'archive tar, ou faites un "make
distclean''.
En g\'en\'eral, vous voudrez probablement sophistiquer votre {\bf configure}
Les m\^emes contraintes de librairies s'appliquent si vous souhaitez utiliser
les sous-programmes readlines pour l'\'edition des lignes de commande et
-l'historique.
+l'historique, ou si vous utilisez une librairie MySQL qui requiert le
+chiffrement. Dans ce dernier cas, vous pouvez exporter les librairies
+additionnelles comme indiqu\'e ci-dessus ou, alternativement, les inclure
+directement en param\`etres de la commande ./configure comme ci-dessous :
+
+ \footnotesize
+ \begin{verbatim}
+ LDFLAGS="-lssl -lcyrpto" \
+ ./configure \
+ <vos-options>
+ \end{verbatim}
+\normalsize
+
Veuillez noter que sur certains syst\`emes tels que Mandriva, readline tend
-\`a ``avaler'' l'invite de commandes, ce qui le rend totalement inutile. Si
-cela vous arrive, utilisez l'option ``disable'', ou si vous utilisez une
+\`a "avaler'' l'invite de commandes, ce qui le rend totalement inutile. Si
+cela vous arrive, utilisez l'option "disable'', ou si vous utilisez une
version post\'erieure \`a 1.33 essayez {\bf \verb{--{enable-conio} pour utiliser une
alternative \`a readline int\'egr\'ee. Il vous faudra tout de m\^eme termcap
-ou ncurses, mais il est peu probable que le paquettage {\bf conio} gobe vos
+ou ncurses, mais il est peu probable que le paquetage {\bf conio} gobe vos
invites de commandes.
Readline n'est plus support\'e depuis la version 1.34. Le code reste
sur votre machine, nous vous recommandons de d\'emarrer avec SQLite. Ceci vous
facilitera beaucoup l'installation car SQLite est compil\'e dans Bacula et ne
requiert aucune administration. SQLite fonctionne bien et sied bien aux
-petites et moyennes configurations (maximum 10-20 machines).
+petites et moyennes configurations (maximum 10-20 machines). Cependant, il nous
+faut signaler que plusieurs utilisateurs ont subi des corruptions inexpliqu\'ees
+de leur catalogue SQLite. C'est pourquoi nous recommandons de choisir MySQL
+ou PostgreSQL pour une utilisation en production.
Si vous souhaitez utiliser MySQL pour votre catalogue Bacula, consultez le
chapitre
tendant \`a \^etre un peu plus conforme \`a SQL92. PostgreSQL poss\`ede
beaucoup plus de fonctions avanc\'ees telles que les transactions, les
proc\'edures stock\'ees, etc. PostgreSQL requiert une certaine connaissance
-pour son installation et sa maintenance. Il y a d'importants probl\`emes de
-performances avec PostgreSQL et les versions de Bacula ant\'erieures \`a
-1.35.5.
+pour son installation et sa maintenance.
Si vous souhaitez utiliser SQLite pour votre catalogue Bacula, consultez le
chapitre
\ilink{Installer et Configurer SQLite}{_ChapterStart33} de ce manuel.
-
\subsection*{D\'emarrage rapide}
\index[general]{D\'emarrage rapide }
\index[general]{Rapide!D\'emarrage }
probl\`eme lors de la compilation de Bacula avec une configuration
simplifi\'ee comme celles montr\'ees plus haut.
+Si le processus ./configure ne parvient pas \`a trouver les librairies
+sp\'ecifiques (par exemple libintl), assurez vous que le paquetage appropri\'e
+est install\'e sur votre syst\`eme. S'il est install\'e dans un r\'epertoire non
+standard (au moins pour Bacula), il existe dans la plupart des cas une
+option parmi celles \'enum\'er\'ees ci-dessous (ou avec "./configure {-}{-}help")
+qui vous permettra de sp\'ecifier un r\'epertoire de recherche. D'autres options
+vous permettent de d\'esactiver certaines fonctionnalit\'es (par exemple
+{-}{-}disable-nls).
+
Si vous souhaitez vous jeter \`a l'eau, nous vous conseillons de passer
directement au chapitre suivant, et d'ex\'ecuter le jeu d'exemples. Il vous
apprendra beaucoup sur Bacula, et un Bacula de test peut \^etre install\'e
quelconque probl\`eme avec les exemples, ou lorsque vous voudrez effectuer une
installation r\'eelle.
+TAQUET MISE A JOUR
+
\subsection*{Options de la commande {\bf configure}}
\label{Options}
\index[general]{Options de la commande configure }
\index[dir]{{-}{-}sysconfdir }
D\'efinit l'emplacement des fichiers de configuration de Bacula.
+\item [ {-}{-}mandir=\lt{}path\gt{}]
+ \index[general]{{-}{-}mandir}
+ Par d\'efaut, Bacula installe une simple page de manuel dans
+ /usr/share/man. Si vous voulez qu'elle soit install\'ee ailleurs,
+ utilisez cette options pour sp\'ecifier le chemin voulu. Notez
+ que les principaux documents Bacula en HTML et PDF sont dans une
+ archive tar distincte des sources de distribution de Bacula.
+
+\item [ {-}{-}datadir=\lt{}path\gt{}]
+ \index[general]{{-}{-}datadir}
+ Si vous traduisez Bacula ou des parties de Bacula dans une autre
+ langue, vous pouvez sp\'ecifier l'emplacement des fichiers .po avec
+ l'option {\bf {-}{-}datadir}. Vous devez installer manuellement tout
+ fichier .po qui n'est pas (encore) install\'e automatiquement.
+
\item [{-}{-}enable-smartalloc ]
\index[dir]{{-}{-}enable-smartalloc }
Permet l'inclusion du code Smartalloc de d\'etection de tampons orphelins
Avec cette option, les utilitaires relatifs au Storage Daemon ({\bf bls},
{\bf bextract}, et {\bf bscan}) seront li\'es statiquement, ce qui vous permet
de les utiliser m\^eme si les librairies partag\'ees ne sont pas charg\'ees.
-Si vous avez des difficult\'es de type ``linking'' \`a la compilation du
+Si vous avez des difficult\'es de type "linking'' \`a la compilation du
r\'epertoire {\bf src/stored}, assurez-vous d'avoir d\'esactiv\'e cette
option, en ajoutant \'eventuellement {\bf \verb{--{disable-static-tools}.
du File Daemon standard. Cette version qui inclut les librairies statiquement
li\'ees est requise pour la reconstruction compl\`ete d'une machine apr\`es
un d\'esastre. Cette option est largement surpass\'ee par l'usage de {\bf
-make static-bacula-fd} du r\'epertoire {\bf src/filed}.
+make static-bacula-fd} du r\'epertoire {\bf src/filed}. L'option {\bf
+\verb:--:enable-client-only} d\'ecrite plus loin est aussi int\'eressante
+pour compiler un simple client sans les autres parties du programme.
+
+Pour lier un binaire statique, l'\'editeur de liens a besoin des versions
+statiques de toutes les librairies utilis\'ees, aussi les utilisateurs
+rencontrent fr\'equemment des erreurs d'\'edition de liens \`a l'utilisation
+de cette option. La premi\`ere chose \`a faire est de s'assurer d'avoir la
+librairie glibc statiquement li\'ee sur votre syst\`eme. Ensuite, il faut
+s'assurer de ne pas utiliser les options {\bf {-}{-}openssl} ou
+{\bf {-}{-}with-python} de la commande configure, car elle requierent des
+librairies suppl\'ementaires. Vous devriez pouvoir activer ces options, mais
+il vous faudra charger les librairies statiques additionnelles correspondantes.
\item [{-}{-}enable-static-sd]
\index[sd]{{-}{-}enable-static-sd }
statiquement li\'ees peut se r\'ev\'eler utile pour la reconstruction
compl\`ete d'une machine apr\`es un d\'esastre.
+Pour lier un binaire statique, l'\'editeur de liens a besoin des versions
+statiques de toutes les librairies utilis\'ees, aussi les utilisateurs
+rencontrent fr\'equemment des erreurs d'\'edition de liens \`a l'utilisation
+de cette option. La premi\`ere chose \`a faire est de s'assurer d'avoir la
+librairie glibc statiquement li\'ee sur votre syst\`eme. Ensuite, il faut
+s'assurer de ne pas utiliser les options {\bf {-}{-}openssl} ou
+{\bf {-}{-}with-python} de la commande configure, car elle requierent des
+librairies suppl\'ementaires. Vous devriez pouvoir activer ces options, mais
+il vous faudra charger les librairies statiques additionnelles correspondantes.
+
\item [{-}{-}enable-static-dir]
\index[dir]{{-}{-}enable-static-dir }
Avec cette option, la compilation produira un {\bf static-bacula-dir} en plus
statiquement li\'ees peut se r\'ev\'eler utile pour la reconstruction
compl\`ete d'une machine apr\`es un d\'esastre.
+Pour lier un binaire statique, l'\'editeur de liens a besoin des versions
+statiques de toutes les librairies utilis\'ees, aussi les utilisateurs
+rencontrent fr\'equemment des erreurs d'\'edition de liens \`a l'utilisation
+de cette option. La premi\`ere chose \`a faire est de s'assurer d'avoir la
+librairie glibc statiquement li\'ee sur votre syst\`eme. Ensuite, il faut
+s'assurer de ne pas utiliser les options {\bf {-}{-}openssl} ou
+{\bf {-}{-}with-python} de la commande configure, car elle requierent des
+librairies suppl\'ementaires. Vous devriez pouvoir activer ces options, mais
+il vous faudra charger les librairies statiques additionnelles correspondantes.
+
\item [{-}{-}enable-static-cons]
\index[dir]{{-}{-}enable-static-cons }
Avec cette option, la compilation produira une {\bf static-console} et une
version qui inclut les librairies statiquement li\'ees peut se r\'ev\'eler
utile pour la reconstruction compl\`ete d'une machine apr\`es un d\'esastre.
+Pour lier un binaire statique, l'\'editeur de liens a besoin des versions
+statiques de toutes les librairies utilis\'ees, aussi les utilisateurs
+rencontrent fr\'equemment des erreurs d'\'edition de liens \`a l'utilisation
+de cette option. La premi\`ere chose \`a faire est de s'assurer d'avoir la
+librairie glibc statiquement li\'ee sur votre syst\`eme. Ensuite, il faut
+s'assurer de ne pas utiliser les options {\bf {-}{-}openssl} ou
+{\bf {-}{-}with-python} de la commande configure, car elle requierent des
+librairies suppl\'ementaires. Vous devriez pouvoir activer ces options, mais
+il vous faudra charger les librairies statiques additionnelles correspondantes.
\item [{-}{-}enable-client-only]
\index[console]{{-}{-}enable-client-only }
daemons}, vous devez la d\'esactiver. Cette option facilite grandement la
compilation sur les simples clients.
+Pour lier un binaire statique, l'\'editeur de liens a besoin des versions
+statiques de toutes les librairies utilis\'ees, aussi les utilisateurs
+rencontrent fr\'equemment des erreurs d'\'edition de liens \`a l'utilisation
+de cette option. La premi\`ere chose \`a faire est de s'assurer d'avoir la
+librairie glibc statiquement li\'ee sur votre syst\`eme. Ensuite, il faut
+s'assurer de ne pas utiliser les options {\bf {-}{-}openssl} ou
+{\bf {-}{-}with-python} de la commande configure, car elle requierent des
+librairies suppl\'ementaires. Vous devriez pouvoir activer ces options, mais
+il vous faudra charger les librairies statiques additionnelles correspondantes.
+
\item [{-}{-}enable-largefile]
\index[console]{{-}{-}enable-largefile }
Cette option (activ\'ee par d\'efaut) provoque la compilation de Bacula avec
GBytes. Vous pouvez d\'esactiver cette option et revenir \`a un adressage de
fichiers 32 bits en utilisant {\bf \verb{--{disable-largefile}.
+\item [ {-}{-}disable-nls]
+ \index[general]{{-}{-}disable-nls}
+ Bacula utilise par d\'efaut les librairies {\it GNU Native Language Support} (NLS).
+ Sur certaines machines, ces librairies peuvent \^etre inexistante, ou ne pas
+ fonctionner correctement (particuli\`erement sur les impl\'ementations non Linux).
+ dans ce genre de situations, vous pouvez neutraliser l'utilisation de ces librairies
+ avec l'option {\bf {-}{-}disable-nls}. Dans ce cas, Bacula reviendra \`a l'usage de l'anglais.
+
\item [{-}{-}with-sqlite=\lt{}sqlite-path\gt{}]
\index[console]{{-}{-}with-sqlite }
- Cette option permet l'utilisation de la base de donn\'ees SQLite. Il n'est,
+ Cette option permet l'utilisation de la base de donn\'ees SQLite versions 2.8.x. Il n'est,
en principe, pas n\'ecessaire de sp\'ecifier le chemin {\bf sqlite-path} car
Bacula recherche les composants requis dans les r\'epertoires standards ({\bf
depkgs/sqlite}). voyez
\ilink{Installer et Configurer SQLite}{_ChapterStart33} pour plus de
d\'etails.
+Voyez aussi la note ci-dessous, apr\`es le paragraphe --with-postgreSQL
+
+\item [{-}{-}with-sqlite3=\lt{}sqlite3-path\gt{}]
+ \index[console]{{-}{-}with-sqlite3 }
+ Cette option permet l'utilisation de la base de donn\'ees SQLite versions 3.x. Il n'est,
+en principe, pas n\'ecessaire de sp\'ecifier le chemin {\bf sqlite3-path} car
+Bacula recherche les composants requis dans les r\'epertoires standards ({\bf
+depkgs/sqlite3}). voyez
+\ilink{Installer et Configurer SQLite}{_ChapterStart33} pour plus de
+d\'etails.
+
+Voyez aussi la note ci-dessous, apr\`es le paragraphe --with-postgreSQL
+
\item [{-}{-}with-mysql=\lt{}mysql-path\gt{}]
\index[console]{{-}{-}with-mysql }
Cette option permet la compilation des services de Catalogue de Bacula. Elle
\ilink{Installer and Configurer MySQL}{_ChapterStart}) avant de
proc\'eder \`a la configuration.
+Voyez aussi la note ci-dessous, apr\`es le paragraphe --with-postgreSQL
+
\item [{-}{-}with-postgresql=\lt{}postgresql-path\gt{}]
\index[console]{{-}{-}with-postgresql }
Cette option d\'eclare un chemin explicite pour les librairies PostgreSQL si
Bacula ne les trouve pas dans le r\'epertoire par d\'efaut.
+Notez que pour que Bacula soit configur\'e correctement, vous devez sp\'ecifier l'une des
+quatre options de bases de donn\'ees support\'ees : {-}{-}with-sqlite, {-}{-}with-sqlite3,
+{-}{-}with-mysql, ou {-}{-}with-postgresql, faute de quoi ./configure \'echouera.
+
+\item [ {-}{-}with-openssl=\lt{}path\gt{}]
+ Cette option est requise si vous souhaitez activer TLS (ssl) dans Bacula. Normalement,
+ la sp\'ecification du chemin {\bf path} n'est pas n\'ecessaire car le processus de
+ configuration recherche les librairies OpenSSL dans les emplacements standard du
+ syst\`eme. L'activation d'OpenSSL dans Bacula permet des communications s\'ecuris\'ees
+ entre les {\it daemons}. Pour plus d'informations sur l'usage de TLS, consultez le
+ chapitre \ilink{Bacula TLS}{_ChapterStart61} de ce manuel.
+
+
+\item [ {-}{-}with-python=\lt{}path\gt{}]
+ \index[general]{{-}{-}with-python }
+ Cette option active le support Python dans Bacula. Si le chemin n'est pas
+ sp\'ecifi\'e, le processus de configuration recherchera les librairies Python
+ dans leurs emplacements standard. S'il ne peut trouver les librairies , il vous faudra
+ fournir le chemin vers votre r\'epertoire de librairies Python. Voyez le
+ \ilink{chapitre Python}{_ChapterStart60} pour plus de d\'etails sur l'utilisation de
+ scripts Python.
+
+\item [ {-}{-}with-libintl-prefix=\lt{}DIR\gt{}]
+ \index[general]{{-}{-}with-libintl-prefix}
+ Cette option peut \^etre utilis\'ee pour indiquer \`a Bacula de rechercher dans DIR/include
+ et DIR/lib les fichiers d'en t\^ete libintl et les librairies requises pour
+ Native Language Support (NLS).
+
\item [{-}{-}enable-conio]
\index[console]{{-}{-}enable-conio }
Cette option permet la compilation d'une petite et l\'eg\`ere routine en
\item [{-}{-}enable-readline]
\index[console]{{-}{-}enable-readline }
Active le support readline. D\'esactiv\'e par d\'efaut en raison de nombreux
-probl\`emes de configuration, et parce que le paquettage semble devenir
+probl\`emes de configuration, et parce que le paquetage semble devenir
incompatible.
\item [{-}{-}with-tcp-wrappers=\lt{}path\gt{}]
\index[dir]{{-}{-}with-subsys-dir }
Cette option pr\'ecise le r\'epertoire de stockage des fichiers verrous du
sous-syst\`eme lors de l'ex\'ecution. Le r\'epertoire par d\'efaut est {\bf
-/var/run/subsys}.Veillez \`a ne pas sp\'ecifier le m\^eme r\'epertoire que
+/var/run/subsys}. Veillez \`a ne pas sp\'ecifier le m\^eme r\'epertoire que
pour l'option {\bf sbindir}. Ce r\'epertoire n'est utilis\'e que par les
scripts de d\'emarrage automatique. Le r\'epertoire sp\'ecifi\'e ici n'est
pas automatiquement cr\'e\'e par le processus d'installation, aussi vous devez
\normalsize
Si vous souhaitez installer Bacula dans un r\'epertoire d'installation
-plut\^ot que de l'ex\'ecuter depuis le r\'epertoire d'installation, (comme le
+plut\^ot que de l'ex\'ecuter depuis le r\'epertoire de compilation, (comme le
feront les d\'eveloppeurs la plupart du temps), vous devriez aussi inclure les
options \verb{--{sbindir et \verb{--{sysconfdir avec les chemins appropri\'es. Aucune n'est
-n\'ecessaire si vous ne vous servez pas de ``make install'', comme c'est le
+n\'ecessaire si vous ne vous servez pas de "make install'', comme c'est le
cas pour la plupart des travaux de d\'eveloppement. Le processus
d'installation va cr\'eer les r\'epertoires sbindir et sysconfdir s'ils
n'existent pas, mais il ne cr\'eera pas les r\'epertoires pid-dir, subsys-dir
/var/lock/subsys existent, ils ne seront pas cr\'ees par le processus
d'installation.
+D'autre part, avec gcc 4.0.1 20050727 (Red Hat 4.0.1-5) sur processeur AMD64
+et sous CentOS4 64 bits, un bug du compilateur g\'en\`ere du code erron\'e qui
+conduit Bacula \`a des erreurs de segmentation. Typiquement, vous le rencontrerez
+d'abord avec le Storage Daemon. La solution consiste \`a s'assurer que Bacula est
+compil\'e sans optimisation (normalement -O2)
+
\subsection*{Solaris}
\index[general]{Solaris }
\addcontentsline{toc}{subsection}{Solaris}
+Pour installer Bacula depuis les sources, il vous faudra les paquetages suivants
+sur votre syst\`eme (ils ne sont pas install\'es par d\'efaut) : libiconv, gcc 3.3.2, stdc++, libgcc
+( pour les librairies stdc++ and gcc\_s ), make 3.8 ou plus r\'ecent.
+
+Il vous faudra probablement aussi ajouter /usr/local/bin et /usr/css/bin \`a PATH pour ar.
+
\footnotesize
\begin{verbatim}
#!/bin/sh
pas les r\'epertoires pid-dir, subsys-dir ni working-dir, aussi assurez vous
qu'ils existent avant de lancer Bacula.
+Notez que vous pouvez aussi avoir besoin des paquetages suivants pour installer Bacula
+depuis les sources :
+\footnotesize
+\begin{verbatim}
+SUNWbinutils,
+SUNWarc,
+SUNWhea,
+SUNWGcc,
+SUNWGnutls
+SUNWGnutls-devel
+SUNWGmake
+SUNWgccruntime
+SUNWlibgcrypt
+SUNWzlib
+SUNWzlibs
+SUNWbinutilsS
+SUNWGmakeS
+SUNWlibm
+
+export
+PATH=/usr/bin::/usr/ccs/bin:/etc:/usr/openwin/bin:/usr/local/bin:/usr/sfw/bin:/opt/sfw/bin:/usr/ucb:/usr/sbin
+\end{verbatim}
+\normalsize
+
+
\subsection*{FreeBSD}
\index[general]{FreeBSD }
\addcontentsline{toc}{subsection}{FreeBSD}
\addcontentsline{toc}{subsection}{Le script Configure de Kern}
Voici le script que j'utilise pour compiler sur mes machines Linux de
-``production'':
+"production'':
\footnotesize
\begin{verbatim}
Si vous avez pr\'ec\'edemment install\'e Bacula, les anciens binaires seront
\'ecras\'es, mais les anciens fichiers de configuration resteront inchang\'es,
-et les ``nouveaux'' recevront l'extension {\bf .new}. G\'en\'eralement, si
+et les "nouveaux'' recevront l'extension {\bf .new}. G\'en\'eralement, si
vous avez d\'ej\`a install\'e et ex\'ecut\'e Bacula, vous pr\'ef\`ererez
supprimer ou ignorer les fichiers de configuration avec l'extension {\bf .new}
supporte le standard {\it systemtray} de FreeDesktop, et comment l'activer le
cas \'ech\'eant.
-\section*{Modifier les fichiers de configuration de Bacula}
+\subsection*{Modifier les fichiers de configuration de Bacula}
\index[general]{Modifier les fichiers de configuration de Bacula }
\index[general]{Bacula!Modifier les fichiers de configuration de }
\addcontentsline{toc}{section}{Modifier les fichiers de configuration de
Bacula}
Consultez le chapitre
-\ilink{Configuring Bacula}{_ChapterStart16} de ce manuel pour les
+\ilink{Configurer Bacula}{_ChapterStart16} de ce manuel pour les
instructions de configuration de Bacula.
install\'e {\bf Bacula}. Dans le cas contraire, nous vous invitons \`a le
faire avant de poursuivre.
-Prennez bonne note que la commande {\bf ./configure} utilis\'ee pour
+Notez bien que la commande {\bf ./configure} utilis\'ee pour
construire {\bf Bacula} n\'ecessite d'ajouter l'option {\bf
\verb{--{with-postgresql=repertoire\_de\_PostgreSQL}, o\`u {\bf
repertoire\_de\_PostgreSQL} sp\'ecifie le chemin de PostgreSQL indiqu\'e \`a
\item ./create\_bacula\_database
- Cr\'eer la base de donn\'ees PostgreSQL de {\bf Bacula}.
+ Ce script cr\'e\'e le catalogue {\bf bacula} PostgreSQL. S'il \'echoue,
+ c'est probablement que vous n'avez pas les droits requis sur la
+ base de donn\'ees. Sur la plupart des syst\`emes, le propri\'etaire de
+ la base de donn\'ees est {\bf pgsql}, et sur d'autres tels que RedHat ou
+ Fedora, c'est {\bf postgres}. Vous pouvez d\'eterminer lequel en examinant
+ le fichier /etc/passwd. Pour cr\'eer un nouvel utilisateur avec votre nom
+ ou le nom {\bf bacula}, vous pouvez faire ce qui suit :
+
+\begin{verbatim}
+ su
+ (entrez le mot de passe root)
+ password pgsql (ou postgres)
+ (entrez un mot de passe pour cet utilisateur)
+ exit
+ su pgsql (ou postgres)
+ (entrez le nouveau mot de passe)
+ createuser kern (or peut-\^etre bacula)
+ Shall the new user be allowed to create databases? (y/n) y
+ Shall the new user be allowed to create more new users? (y/n) (choisissez ce que vous voulez)
+ exit
+\end{verbatim}
+
+ A ce stade, vous devriez pouvoir ex\'ecuter la commande ./create\_bacula\_database
\item ./make\_bacula\_tables
\end{verbatim}
\normalsize
+J'ai rencontr\'e un probl\`eme de permissions avec le mot de passe. J'ai finalement
+du modifier mon fichier {\bf pg_hba.conf} (situ\'e dans /var/lib/pgsql/data sur ma
+machine) :
+
+\footnotesize
+\begin{verbatim}
+de
+ local all all ident sameuser
+vers
+ local all all trust sameuser
+\end{verbatim}
+\normalsize
+
+Ceci a r\'esolu le probl\`eme pour moi, mais ce n'est pas pas forc\'ement une bonne
+chose du point de vue de la s\'ecurit\'e, mais j'ai ainsi pu ex\'ecuter mes scripts de
+r\'egression sans mot de passe.
+
+Un moyen plus s\'ecuris\'e pour l'authentification aupr\`es de la base de donn\'ees
+consiste \`a utiliser le hachage MD5 des mots de passe. Pour cela, \'editez les
+fichier {\bf pg_hba.conf}, et ajoutez ajoutez ce qui suit juste avant les lignes
+"local" et "host" existantes :
+
+\footnotesize
+\begin{verbatim}
+ local bacula bacula md5
+\end{verbatim}
+\normalsize
+
+Puis red\'emarrez le {\it daemon} Postgres (la plupart du temps, avec
+ "/etc/init.d/postgresql restart") pour activer cette nouvelle r\`egle
+d'authentification.
+
+Ensuite, en tant qu'administrateur Postgres (connectez-vous en tant
+qu'utilisateur postgres ou en utilisant {\bf su} pour devenir root, puis
+ {\bf su postgres}), ajoutez un mot de passe \`a la base de donn\'ees bacula
+pour l'utilisateur bacula avec les commandes suivantes :
+
+\footnotesize
+\begin{verbatim}
+ \$ psql bacula
+ bacula=# alter user bacula with password 'secret';
+ ALTER USER
+ bacula=# \\q
+\end{verbatim}
+\normalsize
+
+Enfin, il vous faudra ajouter ce mot de passe en deux endroits du fichier
+bacula-dir.conf : au niveau de la ressource Catalog et au niveau de la
+directive RunBeforeJob de la ressource Job BackupCatalog. Avec les mots de
+passe en place, ces deux lignes devraient ressembler \`a ceci :
+
+\footnotesize
+\begin{verbatim}
+ dbname = bacula; user = bacula; password = "secret"
+ ... and ...
+ RunBeforeJob = "/etc/make_catalog_backup bacula bacula secret"
+\end{verbatim}
+\normalsize
+
+Naturellement, vous devriez choisir un meilleur mot de passe, et vous assurer
+que le fichier bacula-dir.conf qui contient ce mot de passe n'est lisible
+que par root.
+
+M\^eme avec ces restrictions, il reste un probl\`eme de s\'ecurit\'e avec cette approche :
+sur certaines plateformes, la variable d'environnement utilis\'ee pour soumettre le
+mot de passe \`a Postgres est in\'evitablement disponible pour tout utilisateur
+local du syst\`eme. Pour supprimer ce probl\`eme, l'\'equipe Postgres a d\'ecr\'et\'e
+obsol\`ete ce m\'ecanisme de passage de mot de passe par variable d'environnement et
+recommande d'utiliser un fichier .pgpass. Pour utiliser ce m\'ecanisme, cr\'eez un fichier
+nomm\'e .pgpass vcontenant une simple ligne :
+
+\footnotesize
+\begin{verbatim}
+ localhost:5432:bacula:bacula:secret
+\end{verbatim}
+\normalsize
+
+Ce fichier devrait \^etre copi\'e dans les r\'epertoires personnels (NDT : home directories)
+de tous les comptes susceptibles d'avoir besoin d'acc\'eder \`a la base de donn\'ees :
+typiquement, il s'agit de root, bacula et tout utilisateur de la console Bacula. Les fichiers
+doivent appartenir aux utilisateur et groupe correspondant : root:root pour la copie
+dans ~root, etc. Les permissions doivent \^etre positionn\'ees \`a 600 pour limiter
+l'acc\`es au propri\'etaire du fichier.
+
\subsection*{R\'einitialiser la base des catalogues (de sauvegardes)}
\index[general]{R\'einitialiser la base des catalogues (de sauvegardes) }
\index[general]{Sauvegardes!R\'einitialiser la base des catalogues de }
o\`u vous devrez remplacer {\bf /dev/nst0} par le chemin appropri\'e de votre
lecteur de sauvegarde.
+\subsection*{Installer PostgreSQL avec les RPMs}
+\index[general]{PostgreSQL!Installer avec les RPMs}
+\index[general]{Installer PostgreSQL avec les RPMs}
+\addcontentsline{toc}{subsection}{Installer PostgreSQL avec les RPMs}
+Si vous installez PostgreSQL avec les RPMs, il vous faut installer les
+binaires PostgreSQL ainsi que les librairies clientes. Ces derni\`eres font
+g\'en\'eralement partie de paquetages de d\'eveloppement, aussi vous devez installer :
+
+\footnotesize
+\begin{verbatim}
+ postgresql
+ postgresql-devel
+\end{verbatim}
+\normalsize
+
+Il en va de m\^eme avec la plupart des gestionnaires de paquetages.
+
\subsection*{Migrer de MySQL \`a PostgreSQL}
\index[general]{Migrer de MySQL \`a PostgreSQL }
\index[general]{PostgreSQL!Migrer de MySQL \`a }
\begin{itemize}
\item Linux Mandrake 10/Kernel 2.4.22-10 SMP
-\item Mysql Ver 12.21 Distrib 4.0.15, pour mandrake-linux-gnu (i586)
+\item MySQL Ver 12.21 Distrib 4.0.15, pour mandrake-linux-gnu (i586)
\item PostgreSQL 7.3.4
\item Bacula 1.34.5
\end{itemize}
\begin{enumerate}
\item Arr\^etez bacula (cd /etc/bacula;./bacula stop)
-\item Lancez la commande pour extraire les donn\'ees de votre base Mysql:
+\item Lancez la commande pour extraire les donn\'ees de votre base MySQL:
\footnotesize
\begin{verbatim}
\item Faites une sauvegarde de votre r\'epertoire /etc/bacula (mais laisser
l'original en place ).
\item Allez dans le r\'epertoire source de {\bf Bacula} et reconstruisez le en
- incluant le support PostgreSQL au lieu de celui de Mysql . V\'erifiez que le
+ incluant le support PostgreSQL au lieu de celui de MySQL . V\'erifiez que le
fichier config.log de votre configuration originale et remplacez enable-mysql
par enable-postgresql.
\item Recompilez Bacula avec la commande make et si tout se passe correctement
- lancez un ``make install''.
-\item Arr\^etez Mysql.
+ lancez un "make install".
+\item Arr\^etez MySQL.
\item Lancez PostgreSQL sur votre syst\`eme.
\item Cr\'eez un utilisateur {\bf Bacula} dans Postgres avec la commande
- ``createuser''. En fonction de votre installation, vous serez peut \^etre
- amen\'e \`a faire un ``su'' vers l'utilisateur ad\'equat (NDT: su postgres).
+ "createuser". En fonction de votre installation, vous serez peut \^etre
+ amen\'e \`a faire un "su" vers l'utilisateur ad\'equat (NDT: su postgres).
\item Verifiez que le fichier pg\_hba.conf (NdT sur Debian:
/etc/postgres/pg\_hba.conf) contient les permissions ad\'equates pour
permettre \`a {\bf Bacula} d'acc\'eder au serveur. Le mien contient les
\end{verbatim}
\normalsize
-\item Parvenu ici, lancez {\bf Bacula}, v\'erifiez votre banque de bandes et
+\item Parvenu ici, lancez {\bf Bacula}, v\'erifiez votre librairie et
faites un test pour valider que tout s'est bien d\'eroul\'e.
- \end{enumerate}
+\end{enumerate}
+
+\subsection*{Mettre \`a jour PostgreSQL}
+\index[general]{Mettre \`a jour PostgreSQL }
+\index[general]{Mettre \`a jour!PostgreSQL }
+\addcontentsline{toc}{subsection}{Mettre \`a jour PostgreSQL}
+Si vous mettez PosgreSQL \`a jour, vous devez reconfigurer, recompiler et
+r\'einstaller Bacula, faute de quoi vous constaterez probalement des
+erreurs \'etranges.
+Pour cela, il vous faut installer le RPM source, modifier le fichier bacula.spec
+pour l'accorder \`a votre version de PostgreSQL, reconstruire le RPM et l'installer.
+
+If you upgrade PostgreSQL, you must reconfigure, rebuild, and re-install
+Bacula otherwise you are likely to get bizarre failures. If you
+to modify the bacula.spec file to account for the new PostgreSQL version.
+You can do so by rebuilding from the source rpm. To do so, you may need
+install from rpms and you upgrade PostgreSQL, you must also rebuild Bacula.
+
\subsection*{Credits}
\index[general]{Credits }
%%
%%
-\section*{Caract\'eristiques syst\`eme g\'en\'erales indispensables \`a
-Bacula}
+\section*{Caract\'eristiques syst\`eme g\'en\'erales indispensables \`a Bacula}
\label{_ChapterStart51}
-\index[general]{Caract\'eristiques syst\`eme g\'en\'erales indispensables \`a
-Bacula }
-\index[general]{Bacula!Caract\'eristiques syst\`eme g\'en\'erales
-indispensables \`a }
-\addcontentsline{toc}{section}{Caract\'eristiques syst\`eme g\'en\'erales
-indispensables \`a Bacula}
+\index[general]{Caract\'eristiques syst\`eme g\'en\'erales indispensables \`a Bacula }
+\index[general]{Bacula!Caract\'eristiques syst\`eme g\'en\'erales indispensables \`a }
+\addcontentsline{toc}{section}{Caract\'eristiques syst\`eme g\'en\'erales indispensables \`a Bacula}
\label{SysReqs}
-\subsection*{Caract\'eristiques syst\`eme g\'en\'erales indispensables \`a
-Bacula}
-\index[general]{Caract\'eristiques syst\`eme g\'en\'erales indispensables \`a
-Bacula }
-\index[general]{Bacula!Caract\'eristiques syst\`eme g\'en\'erales
-indispensables \`a }
-\addcontentsline{toc}{subsection}{Caract\'eristiques syst\`eme g\'en\'erales
-indispensables \`a Bacula}
+\subsection*{Caract\'eristiques syst\`eme g\'en\'erales indispensables \`a Bacula}
+\index[general]{Caract\'eristiques syst\`eme g\'en\'erales indispensables \`a Bacula }
+\index[general]{Bacula!Caract\'eristiques syst\`eme g\'en\'erales indispensables \`a }
+\addcontentsline{toc}{subsection}{Caract\'eristiques syst\`eme g\'en\'erales indispensables \`a Bacula}
\begin{itemize}
\item {\bf Bacula} a \'et\'e compil\'e et ex\'ecut\'e sur les syst\`emes
s\'epar\'e (e.g. RPM) de GNU C, et vous devrez avoir les deux. Sur les
syst\`emes RedHat, le compilateur C++ fait partie du paquet RPM {\bf
gcc-c++}.
-\item Certains paquets tierce partie sont n\'ecessaires \`a {\bf Bacula}.
+\item Certains paquets tiers sont n\'ecessaires \`a {\bf Bacula}.
Except\'e pour MySQL et PostgreSQL, ils peuvent tous \^etre trouv\'es dans
les distributions {\bf depkgs} et {\bf depkgs1}.
\item Si vous voulez construire les binaires Win32, vous aurez besoin du
\item Si vous voulez permettre l'\'edition en ligne de commande et
l'historique, il vous faudra /usr/include/termcap.h et l'une des
biblioth\`eques termcap ou ncurses charg\'ee (libtermcap-devel ou
-ncurses-devel).
-\end{itemize}
-
-\subsection*{Syst\`emes d'exploitation support\'es}
-\label{SupportedOSes1}
-\index[general]{Syst\`emes d'exploitation support\'es }
-\addcontentsline{toc}{subsection}{Syst\`emes d'exploitation support\'es}
+ncurses-devel).
+\item Si vous voulez utiliser des DVD en guise de media de sauvegarde, vous devrez
+ télécharger les \elink{dvd+rw-tools 5.21.4.10.8}{http://fy.chalmers.se/~appro/linux/DVD+RW/},
+ appliquer le \elink{patch}{http://cvs.sourceforge.net/viewcvs.py/*checkout*/bacula/bacula/patches/dvd+rw-tools-5.21.4.10.8.bacula.patch}
+ pour rendre ces outils compatibles avec Bacula, puis les compiler et installer.
+ N'utilisez pas les dvd+rw-tools fournis par votre distribution, ils ne
+ fonctionneront pas avec Bacula.
-\begin{itemize}
-\item Syst\`emes Linux (compil\'e et test\'e sur RedHat Enterprise Linux
- 3.0).
-\item Si vous avez un syst\`eme Red Hat r\'ecent ex\'ecutant le noyau 2.4.x
- et si vous avez le r\'epertoire {\bf /lib/tls} install\'e sur votre
- syst\`eme (par d\'efaut normalement), {\bf Bacula ne fonctionnera pas
-correctement} Ceci est d\^u \`a la nouvelle biblioth\`eque pthreads qui est
-d\'efectueuse. Vous devez supprimer ce r\'epertoire avant d'ex\'ecuter
-Bacula, ou vous pouvez simplement le renommer en {\bf /lib/tls-broken} puis
-red\'emarrer votre machine (une des rares occasions o\`u; Linux doit \^etre
-red\'emarr\'e). Si vous ne souhaitez pas d\'eplacer/renommer /lib/tls, une
-autre alternative est de placer la variable d'environnement
-``LD\_ASSUME\_KERNEL=2.4.19'' avant d'ex\'ecuter Bacula. Pour cette option,
-vous n'avez pas besoin de red\'emarrer, et tous les programmes autres que
-{\bf Bacula} continueront d'utiliser {\bf /lib/tls}.
+\end{itemize}
-Les retours que nous avons des noyaux 2.6 indiquents que le probl\`eme
-subsiste. Cependant, sur les syst\`emes utilisant un noyau 2.6, nous
-recommanderions plut\^ot d'utiliser la variable d'environnement (the variable
-environment override) (LD\_ASSUME\_KERNEL=2.4.19) plut\^ot que la suppression
-de /lib/tls.
-\item La plupart des distributions Linux (Gentoo, SUSE, Mandriva, Debian,
- ...).
-\item Diff\'erentes versions de Solaris.
-\item FreeBSD (pilote de bande support\'e \`a partir de la version 1.30 --
- allez voir les consid\'erations {\bf importantes} dans la section
- \ilink{Configuration des lecteurs de bandes sur
-FreeBSD}{FreeBSDTapes} du chapitre Test des Bandes de ce
-manuel.)
-\item Windows (Win98/Me, WinNT/2K/XP) clients binaires ({\bf File Daemon}).
-\item MacOS X/Darwin (voir
- \elink{ http://fink.sourceforge.net/}{http://fink.sourceforge.net/} pour
- obtenir les paquets)
-\item OpenBSD Client ({\bf File Daemon}).
-\item Irix Client ({\bf File Daemon}).
-\item Tru64
-\item {\bf Bacula} est r\'eput\'e fonctionner sur d'autres syst\`emes (AIX,
- BSDI, HPUX, ...) mais nous ne les avons pas test\'es.
-\item Voir le chapitre de Portage de la Documentation Pour D\'eveloppeurs pour
- les informations concernant le portage sur d'autres syst\`emes.
- \end{itemize}
\addcontentsline{toc}{section}{Consid\'erations sur la s\'ecurit\'e de Bacula}
\begin{itemize}
+\item La s\'ecurit\'e, c'est de pouvoir restaurer vos fichiers, aussi, lisez
+ attentivement le chapitre \ilink{Critical Items Chapter}{Critical} de
+ ce manuel.
\item Le client ({\bf bacula-fd}) doit \^etre ex\'ecut\'e en tant que root
afin d'avoir l'acc\`es \`a tous les fichiers du syst\`eme.
\item Il n'est pas n\'ecessaire d'ex\'ecuter le Director en tant que root.
\item Il n'est pas n\'ecessaire d'ex\'ecuter le Storage Daemon en tant que
root, mais vous devez vous assurer qu'l peut utiliser le lecteur de bandes,
dont l'acc\`es est presque toujours r\'eserv\'e \`a root par d\'efaut.
-\item
+ De plus, si vous n'ex\'ecutez pas le Storage Daemon en tant que root, il sera
+ dans l'incapacit\'e de r\'egler automatiquement les param\`etres de votre lecteur
+ de bandes. En effet, ces fonctions requi\`erent les droits root sur la plupart
+ des syst\`emes d'exploitation.
\item Vous devriez restreindre l'acc\`es au fichiers de configuration de
Bacula, de sorte que les mots de passe ne soient pas lisibles par tous. Les
{\it daemons} {\bf Bacula} sont prot\'eg\'es par des mots de passe et CRAM-MD5
-(i.e. les mots de passe ne sont pas envoy\'es sur le r\'eseau). Ceci assur
+(i.e. les mots de passe ne sont pas envoy\'es sur le r\'eseau). Ceci assure
que tout le monde ne peut acc\'eder aux {\it daemons}. C'est une protection
-raisonnablement bonne, mais qui peut \^etre craqu\'e par un expert.
+raisonnablement bonne, mais qui peut \^etre craqu\'ee par un expert.
\item Si vous utilisez les ports recommand\'es 9101,9102 et 9103, vous voudrez
probablement prot\'eger ces ports des acc\`es externes \`a l'aide d'un
firewall et/ou en utilisant tcp wrappers ({\bf etc/hosts.allow}).
-\item Actuellement, toutes les donn\'es sont envoy\'ees sur le r\'eseau sans
- chiffrage. Par cons\'equent, \`a moins que vous n'utilisiez {\bf ssh} ou {\bf
- stunnel} pour la transmission de port (port forwarding), il n'est pas
+\item Actuellement, toutes les donn\'ees sont envoy\'ees sur le r\'eseau sans
+ chiffrement. Par cons\'equent, \`a moins que vous n'utilisiez {\bf ssh} ou {\bf
+ stunnel} pour la transmission de port (NDT: port forwarding), il n'est pas
recommand\'e de faire des sauvegardes \`a travers un r\'eseau non
s\'ecuris\'e (par exemple, Internet). Nous pr\'evoyons d'int\'egrer le
chiffrage {\bf ssl} dans une version future.
connectera en utilisant les enregistrements appropri\'es {\bf DirAddress},
{\bf FDAddress}, ou {\bf SDAddress} dans les fichiers de configurations
respectifs des {\it daemons}
+\item Soyez conscient que si vous sauvegardez votre catalogue avec le script
+ par d\'efaut, et si l'acc\`es \`a votre catalogue est prot\'eg\'e par un mot de passe,
+ ce dernier est transmis en tant qu'option de ligne de commande \`a ce script,
+ ce qui le rend visible \`a tout utilisateur du syst\`eme. Si vous voulez
+ s\'ecuriser ce point, vous devez le passer via une variable d'environnement
+ ou un fichier s\'ecuris\'e.
\end{itemize}
+\subsection*{Compatibilit\'e ascendante}
+\index[general]{Compatibilit\'e ascendante}
+\addcontentsline{toc}{subsection}{Compatibilit\'e ascendante}
+L'un des principaux objectifs de Bacula est de garantir que vous pouvez
+restaurer depuis des cartouches (ou depuis des volumes disque) \'ecrites des ann\'ees
+auparavant. Ceci implique que chaque nouvelle version de Bacula devrait \^etre
+capable de relire les anciens formats de cartouches. Le premier probl\`eme est de
+s'assurer que le mat\'eriel fonctionne encore malgr\'e les ann\'ees, et que les supports
+sont encore valides. Ensuite, votre syst\`eme d'exploitation doit \^etre capable
+de s'interfacer avec le p\'eriph\'erique et finalement, Bacula doit \^etre capable
+de reconna\^itre les anciens formats. De tous ces probl\`emes, nous ne pouvons
+prendre en charge que le dernier, pour les autres, vous devez vous pr\'eparer
+consciencieusement.
+
+Depuis les tous premiers stades de Bacula (janvier 2000) jusqu'\`a aujourd'hui
+(D\'ecembre 2005), Bacula a connu deux formats majeurs d'\'ecriture sur les
+cartouches. Le second format a \'et\'e introduit dans la version 1.27 en
+novembre 2002, et n'a pas chang\'e depuis. En principe, Bacula devrait encore pouvoir
+lire le format d'origine, mais j'avoue ne pas avoir essay\'e depuis longtemps...
+
+Bien que le format des cartouches soit fix\'e, les types de donn\'ees qui peuvent \^etre
+\'ecrites sur les cartouches sont extensibles, ce qui nous a permis d'ajouter de
+nouvelles fonctionnalit\'es telles que les ACLs, les donn\'ees Win32, les donn\'ees
+chiffr\'ees... Naturellement, une ancienne version de Bacula ne saurait lire des
+nouveaux flux de donn\'ees, mais chaque nouvelle version de Bacula est en principe
+capable de lire les anciens flux.
+
+Si vous voulez \^etre absolument certain de pouvoir lire vos vieilles cartouches,
+vous devriez :
+
+1. Essayer de lire les vieilles cartouches de temps en temps, une fois par an
+par exemple.
+
+2. Conserver une copie statiquement li\'ee de chaque version de Bacula que vous
+avez utilis\'ee en production. Ainsi, si pour quelque raison nous venions \`a
+abandonner la compatibilit\'e avec les anciens formats de cartouches, vous pourriez
+toujours remettre en service une vieille copie de Bacula...
+
+Le second point est probablement excessif, en toute rigueur, il pourrait vous
+sauver un jour.
+
\label{wrappers}
-\subsection*{Configurer et tester TCP Wrappers avec Bacula}
-\index[general]{Configurer et tester TCP Wrappers avec Bacula }
-\index[general]{Bacula!Configurer et tester TCP Wrappers avec }
-\addcontentsline{toc}{subsection}{Configurer et tester TCP Wrappers avec
-Bacula}
+\subsection*{Configurer et tester TCP Wrappers}
+\index[general]{Configurer et tester TCP Wrappers}
+\index[general]{Bacula!Configurer et tester TCP Wrappers}
+\addcontentsline{toc}{subsection}{Configurer et tester TCP Wrappers}
Les TCP Wrappers sont impl\'ement\'es si vous les activez lors de la
-configuration ({\bf ./configure \verb{--{with-libwrap}). Avec ce code activ\'e, vous
+configuration ({\bf ./configure \verb{:--:{with-tcp-wrappers}). Avec ce code activ\'e, vous
pourrez contr\^oler qui peut acc\'eder \`a vos {\it daemons}. Ce contr\^ole
est obtenu par la modification du fichier {\bf /etc/hosts.allow}. Le nom de
programme qu'utilise {\bf Bacula} pour appliquer ces restrictions est celui
Si vous lisez hosts\_options(5), vous verrez une option nomm\'ee twist. Cette
option remplace le processus courant par une instance de la commande shell
-sp\'ecifi\'ee. Ce qui suit est un exemple typique de son utilisation :
+sp\'ecifi\'ee. Voici un exemple typique de son utilisation :
\footnotesize
\begin{verbatim}
\normalsize
\label{question-1}
-{\bf question 1} Le code libwrap tente d'\'eviter {\bf twist} s'il est
-ex\'ecut\'e dans un processus r\'esident (i.e. , mais ce test ne prot\'egera
-pas le premier appel hosts\_access(). Il en r\'esulte que le processus (e.g.
+Le code libwrap tente d'\'eviter {\bf twist} s'il est
+ex\'ecut\'e dans un processus r\'esident. Il en r\'esulte que le processus (e.g.
bacula-fd, bacula-sd, bacula-dir) sera stopp\'e si la premi\`ere connection
\`a son port provoque l'invocation de l'option twist. Le risque est qu'une
-attaque provoque l'arr\^et des {\it daemons}.
-
-The libwrap code tries to avoid {\bf twist} if it runs in a resident process,
-but that test will not protect the first hosts\_access() call. This will
-result in the prcess (e.g. bacula-fd, bacula-sd, bacula-dir) being terminated
-if the first connection to their port results in the twist option being
-invoked. The potential, and I stree potential, exists for an attacker to
-prevent the daemons from running. Cette situation est \'evit\'ee si votre
+attaque provoque l'arr\^et des {\it daemons}. Cette situation est \'evit\'ee si votre
fichier /etc/hosts.allow contient un jeu de r\`egles appropri\'e. L'exemple
suivant est suffisant :
Storage Daemon est undef-sd, et le File Daemon est undef-fd. Ajustez pour
coller \`a votre configuration. L'exemple de r\`egles ci-dessus suppose que
SD, FD et DIR sont tous sur la m\^eme machine. Si vous avez un client FD
-distant, il vous suffira de placer le jeu de r\^egles suivant sur ce client :
+distant, il vous suffira de placer le jeu de r\`egles suivant sur ce client :
\footnotesize
\begin{verbatim}
\normalsize
O\`u director.example.org est l'h\^ote qui contactera le client (i.e. la
-machine sur laquelle le Bacula Director tourne). L'usage de ``ALL : deny''
+machine sur laquelle le Bacula Director tourne). L'usage de "ALL : deny"
assure que l'option twist (si pr\'esente) n'est pas invoqu\'ee. Pour tester
correctement votre configuration, d\'emarrez le(s) {\it daemon(s)}, puis
essayez de vous y connecter depuis une adresse IP qui devrait \^etre capable
\normalsize
Alors, twist a \'et\'e invoqu\'ee, et votre configuration est incorrecte. vous
-devez ajouter la directive ``deny''. Il est important de noter que vos tests
+devez ajouter la directive "deny". Il est important de noter que vos tests
doivent inclure le red\'emarrage des {\it daemons} apr\`es chaque tentative de
connexion. Vous pouvez aussi tcpdchk(8) et tcpdmatch(8) pour valider jeu de
r\`egles /etc/hosts.allow. Voici un test simple avec tcpdmatch :
Si vous ex\'ecutez Bacula en tant que {\it standalone daemon}, les
avertissements ci-dessus peuvent \^etre ignor\'es sans scrupules. Voici un
-exemple qui r\'ev\`ele que ``deny'' fait defaut \`a vos r\`egles, et que
+exemple qui r\'ev\`ele que "deny" fait defaut \`a vos r\`egles, et que
l'option twist a \'et\'e invoqu\'ee.
\footnotesize
\index[general]{Executer Bacula sans \^etre root }
\addcontentsline{toc}{subsection}{Executer Bacula sans \^etre root}
-Un conseil de s\'ecurit\'e de Dan Languille:
+Voici quelques recommandations de Dan Languille :
C'est une bonne id\'ee d'ex\'ecuter vos {\it daemons} avec des privil\`eges
aussi faibles que possible. En d'autres termes, si vous pouvez, n'ex\'ecutez
\addcontentsline{toc}{subsection}{Autochangers -- General}
Bacula provides autochanger support for reading and writing tapes. In
-order to work with an autochanger, Bacula requires three things, each of
+order to work with an autochanger, Bacula requires a number of things, each of
which is explained in more detail after this list:
\begin{itemize}
LabelMedia = no;
AutomaticMount = yes;
AlwaysOpen = yes;
- Mount Anonymous Volumes = no;
}
\end{verbatim}
\normalsize
LabelMedia = no;
AutomaticMount = yes;
AlwaysOpen = yes;
- Mount Anonymous Volumes = no;
}
Device {
LabelMedia = no;
AutomaticMount = yes;
AlwaysOpen = yes;
- Mount Anonymous Volumes = no;
}
\end{verbatim}
You may begin using Bacula with SQLite then later find that you want to switch
to MySQL for any of a number of reasons: SQLite tends to use more disk than
-MySQL, SQLite apparently does not handle database sizes greater than 2GBytes,
-... Several users have done so by first producing an ASCII "dump" of the
-SQLite database, then creating the MySQL tables with the {\bf
-create\_mysql\_tables} script that comes with Bacula, and finally feeding the
-SQLite dump into MySQL using the {\bf -f} command line option to continue past
-the errors that are generated by the DDL statements that SQLite's dump
-creates. Of course, you could edit the dump and remove the offending
-statements. Otherwise, MySQL accepts the SQL produced by SQLite.
+MySQL; when the database is corrupted it is often more catastrophic than
+with MySQL or PostgreSQL.
+Several users have succeeded in converting from SQLite to MySQL by
+exporting the MySQL data and then processing it with Perl scripts
+prior to putting it into MySQL. This is, however, not a simple
+process.
\label{BackingUpBacula}
\subsection*{Backing Up Your Bacula Database}
\section*{Bacula Console}
\label{_ConsoleChapter}
-\index[general]{Console!Bacula }
-\index[general]{Bacula Console }
-\index[console]{Console!Bacula }
-\index[console]{Bacula Console }
+\index[general]{Console!Bacula}
+\index[general]{Bacula Console}
+\index[console]{Console!Bacula}
+\index[console]{Bacula Console}
\addcontentsline{toc}{section}{Bacula Console}
\subsection*{General}
this document.
\subsection*{Running the Console Program}
-\index[general]{Running the Console Program }
-\index[general]{Program!Running the Console }
-\index[console]{Running the Console Program }
-\index[console]{Program!Running the Console }
+\index[general]{Running the Console Program}
+\index[general]{Program!Running the Console}
+\index[console]{Running the Console Program}
+\index[console]{Program!Running the Console}
\addcontentsline{toc}{subsection}{Running the Console Program}
After launching the Console program (bconsole), it will prompt you for the
will display all the Pool resource records.
\subsection*{Stopping the Console Program}
-\index[general]{Program!Stopping the Console }
-\index[general]{Stopping the Console Program }
-\index[console]{Program!Stopping the Console }
-\index[console]{Stopping the Console Program }
+\index[general]{Program!Stopping the Console}
+\index[general]{Stopping the Console Program}
+\index[console]{Program!Stopping the Console}
+\index[console]{Stopping the Console Program}
\addcontentsline{toc}{subsection}{Stopping the Console Program}
Normally, you simply enter {\bf quit} or {\bf exit} and the Console program
the case of nested prompts). In a few places such as where it is asking for a
Volume name, the period will be taken to be the Volume name. In that case, you
will most likely be able to cancel at the next prompt.
-\label{list}
+\label{keywords}
+\subsection*{Alphabetic List of Console Keywords}
+\index[general]{Keywords!Alphabetic List of Console}
+\index[general]{Alphabetic List of Console Keywords}
+\index[console]{Keywords!Alphabetic List of Console}
+\index[console]{Alphabetic List of Console Keywords}
+\addcontentsline{toc}{subsection}{Alphabetic List of Console Keywords}
+Unless otherwise specified, each of the following keywords
+takes an argument, which is specified after the keyword following
+an equal sign. For example:
+
+\begin{verbatim}
+jobid=536
+\end{verbatim}
+
+Please note, this list is incomplete as it is currently in
+the process of being created and is not currently totally in
+alphabetic
+order ...
+
+\begin{description}
+\item [restart]
+ Permitted on the python command, and causes the Python
+ interpreter to be restarted. Takes no argument.
+\item [all]
+ Permitted on the status and show commands to specify all components or
+ resources respectively.
+\item [before]
+ Used in the restore command.
+\item [bootstrap]
+ Used in the restore command.
+\item [catalog]
+ Allowed in the use command to specify the catalog name
+ to be used.
+\item [catalogs]
+ Used in the show command. Takes no arguments.
+\item [client | fd]
+\item [clients]
+ Used in the show, list, and llist commands. Takes no arguments.
+\item [counters]
+ Used in the show command. Takes no arguments.
+\item [current]
+ Used in the restore command. Takes no argument.
+\item [days]
+\item [devices]
+ Used in the show command. Takes no arguments.
+\item [dir | director]
+\item [directors]
+ Used in the show command. Takes no arguments.
+\item [directory]
+ Used in the restore command.
+\item [done]
+ Used in the restore command. Takes no argument.
+\item [file]
+ Used in the restore command.
+\item [files]
+ Used in the list and llist commands. Takes no arguments.
+\item [fileset]
+\item [filesets]
+ Used in the show command. Takes no arguments.
+\item [help]
+ Used in the show command. Takes no arguments.
+\item [jobs]
+ Used in the show, list and llist commands. Takes no arguments.
+\item [jobmedia]
+ Used in the list and llist commands. Takes no arguments.
+\item [jobtotals]
+ Used in the list and llist commands. Takes no arguments.
+\item [jobid]
+ The JobId is the numeric jobid that is printed in the Job
+ Report output. It is the index of the database record for the
+ given job. While it is unique for all the existing Job records
+ in the catalog database, the same JobId can be reused once a
+ Job is removed from the catalog. Probably you will refer
+ specific Jobs that ran using their numeric JobId.
+\item [job | jobname]
+ The Job or Jobname keyword refers to the name you specified
+ in the Job resource, and hence it refers to any number of
+ Jobs that ran. It is typically useful if you want to list
+ all jobs of a particular name.
+\item [level]
+\item [listing]
+ Permitted on the estimate command. Takes no argument.
+\item [limit]
+\item [messages]
+ Used in the show command. Takes no arguments.
+\item [media]
+ Used in the list and llist commands. Takes no arguments.
+\item [nextvol | nextvolume]
+ Used in the list and llist commands. Takes no arguments.
+\item [on]
+ Takes no keyword.
+\item [off]
+ Takes no keyword.
+\item [pool]
+\item [pools]
+ Used in the show, list, and llist commands. Takes no arguments.
+\item [select]
+ Used in the restore command. Takes no argument.
+\item [storages]
+ Used in the show command. Takes no arguments.
+\item [schedules]
+ Used in the show command. Takes no arguments.
+\item [sd | store | storage]
+\item [ujobid]
+ The ujobid is a unique job identification that is printed
+ in the Job Report output. At the current time, it consists
+ of the Job name (from the Name directive for the job) appended
+ with the date and time the job was run. This keyword is useful
+ if you want to completely identify the Job instance run.
+\item [volume]
+\item [volumes]
+ Used in the list and llist commands. Takes no arguments.
+\item [where]
+ Used in the restore command.
+\item [yes]
+ Used in the restore command. Takes no argument.
+\end{description}
+
+\label{list}
\subsection*{Alphabetic List of Console Commands}
-\index[general]{Commands!Alphabetic List of Console }
-\index[general]{Alphabetic List of Console Commands }
-\index[console]{Commands!Alphabetic List of Console }
-\index[console]{Alphabetic List of Console Commands }
+\index[general]{Commands!Alphabetic List of Console}
+\index[general]{Alphabetic List of Console Commands}
+\index[console]{Commands!Alphabetic List of Console}
+\index[console]{Alphabetic List of Console Commands}
\addcontentsline{toc}{subsection}{Alphabetic List of Console Commands}
The following commands are currently implemented:
off, you must explicitly {\bf mount} the tape after a label command to
use it.
-\item [{cancel [jobid=\lt{}number\gt{} job=\lt{}job-name\gt{}]}]
+\item [{cancel [jobid=\lt{}number\gt{} job=\lt{}job-name\gt{} ujobid=\lt{}unique-jobid\gt{}]}]
\index[console]{cancel jobid}
This command is used to cancel a job and accepts {\bf jobid=nnn} or {\bf
job=xxx} as an argument where nnn is replaced by the JobId and xxx is
database immediately, simply use this command to force it to be created.
\item [{ delete [volume=\lt{}vol-name\gt{} pool=\lt{}pool-name\gt{} job
- jobid=\lt{}id\gt{}] }]
+ jobid=\lt{}id\gt{}]}]
\index[console]{delete}
The delete command is used to delete a Volume, Pool or Job record from
the Catalog as well as all associated catalog Volume records that were
number. That is a "delete jobid" accepts lists and ranges of
jobids.
+\item [disable job\lt{}job-name\gt{}]
+ \index[console]{enable}
+ This command permits you to disable a Job for automatic scheduling.
+ The job may have been previously enabled with the Job resource
+ {\bf Enabled} directive or using the console {\bf enable} command.
+ The next time the Director is restarted or the conf file is reloaded,
+ the Enable/Disable state will be set to the value in the Job resource
+ (default enabled).
+
+\item [enable job\lt{}job-name\gt{}]
+ \index[console]{enable}
+ This command permits you to enable a Job for automatic scheduling.
+ The job may have been previously disabled with the Job resource
+ {\bf Enabled} directive or using the console {\bf disable} command.
+ The next time the Director is restarted or the conf file is reloaded,
+ the Enable/Disable state will be set to the value in the Job resource
+ (default enabled).
+
\label{estimate}
\item [estimate]
\index[console]{estimate}
Pool {
Name ...
Cleaning Prefix = "CLN"
- }
+ }
\end{verbatim}
\normalsize
\begin{verbatim}
list jobs
- list jobid=\lt{}id\gt{}
+ list jobid=<id> (list jobid id)
+
+ list ujobid<unique job name> (list job with unique name)
- list job=\lt{}job-name\gt{}
+ list job=<job-name> (list all jobs with "job-name")
+
+ list jobname=<job-name> (same as above)
+
+ In the above, you can add "limit=nn" to limit the output to
+ nn jobs.
list jobmedia
- list jobmedia jobid=\lt{}id\gt{}
+ list jobmedia jobid=<id>
- list jobmedia job=\lt{}job-name\gt{}
+ list jobmedia job=<job-name>
- list files jobid=\lt{}id\gt{}
+ list files jobid=<id>
- list files job=\lt{}job-name\gt{}
+ list files job=<job-name>
list pools
list volumes
- list volumes jobid=\lt{}id\gt{}
+ list volumes jobid=<id>
- list volumes pool=\lt{}pool-name\gt{}
+ list volumes pool=<pool-name>
- list volumes job=\lt{}job-name\gt{}
+ list volumes job=<job-name>
- list volume=\lt{}volume-name\gt{}
+ list volume=<volume-name>
- list nextvolume job=\lt{}job-name\gt{}
+ list nextvolume job=<job-name>
- list nextvol job=\lt{}job-name\gt{}
+ list nextvol job=<job-name>
- list nextvol job=\lt{}job-name\gt{} days=nnn
+ list nextvol job=<job-name> days=nnn
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[console]{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=\lt{}storage-name\gt{}
+unmount storage=<storage-name>
-unmount [ jobid=\lt{}id\gt{} | job=\lt{}job-name\gt{} ]
+unmount [ jobid=<id> | job=<job-name> ]
\end{verbatim}
\normalsize
\normalsize
\item [use]
- \index[console]{use }
+ \index[console]{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
\item [var]
\label{var}
- \index[console]{var name }
+ \index[console]{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
good idea of what is going to happen in the real case.
\item [version]
- \index[console]{version }
+ \index[console]{version}
The command prints the Director's version.
\item [quit]
- \index[console]{quit }
+ \index[console]{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
command (i.e. quit preceded by a period).
\item [query]
- \index[console]{query }
+ \index[console]{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
\normalsize
\item [exit]
- \index[console]{exit }
+ \index[console]{exit}
This command terminates the console program.
\item [wait]
- \index[console]{wait }
+ \index[console]{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
\label{dotcommands}
\subsection*{Special dot Commands}
-\index[general]{Commands!Special dot }
-\index[general]{Special dot Commands }
+\index[general]{Commands!Special dot}
+\index[general]{Special dot Commands}
\addcontentsline{toc}{subsection}{Special dot Commands}
There is a list of commands that are prefixed with a period (.). These
\label{atcommands}
\subsection*{Special At (@) Commands}
-\index[general]{Commands!Special At @ }
-\index[general]{Special At (@) Commands }
+\index[general]{Commands!Special At @}
+\index[general]{Special At (@) Commands}
\addcontentsline{toc}{subsection}{Special At (@) Commands}
Normally, all commands entered to the Console program are immediately
\begin{description}
\item [@input \lt{}filename\gt{}]
- \index[console]{@input \lt{}filename\gt{} }
+ \index[console]{@input \lt{}filename\gt{}}
Read and execute the commands contained in the file specified.
\item [@output \lt{}filename\gt{} w/a]
- \index[console]{@output \lt{}filename\gt{} w/a }
+ \index[console]{@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.
\normalsize
\item [@tee \lt{}filename\gt{} w/a]
- \index[console]{@tee \lt{}filename\gt{} w/a }
+ \index[console]{@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[console]{@sleep \lt{}seconds\gt{} }
+ \index[console]{@sleep \lt{}seconds\gt{}}
Sleep the specified number of seconds.
\item [@time]
- \index[console]{@time }
+ \index[console]{@time}
Print the current time and date.
\item [@version]
- \index[console]{@version }
+ \index[console]{@version}
Print the console's version.
\item [@quit]
- \index[console]{@quit }
+ \index[console]{@quit}
quit
\item [@exit]
- \index[console]{@exit }
+ \index[console]{@exit}
quit
\item [@\# anything]
- \index[console]{anything }
+ \index[console]{anything}
Comment
\end{description}
\label{scripting}
\subsection*{Running the Console Program from a Shell Script}
-\index[general]{Script!Running the Console Program from a Shell }
-\index[general]{Running the Console Program from a Shell Script }
+\index[general]{Script!Running the Console Program from a Shell}
+\index[general]{Running the Console Program from a Shell Script}
\addcontentsline{toc}{subsection}{Running the Console Program from a Shell
Script}
\normalsize
\subsection*{Adding Volumes to a Pool}
-\index[general]{Adding Volumes to a Pool }
-\index[general]{Pool!Adding Volumes to a }
+\index[general]{Adding Volumes to a Pool}
+\index[general]{Pool!Adding Volumes to a}
\addcontentsline{toc}{subsection}{Adding Volumes to a Pool}
If you have used the {\bf label} command to label a Volume, it will be
\item After installing and experimenting with Bacula, read and work carefully
through the examples in the
\ilink{Tutorial}{_ChapterStart1} chapter of this manual.
-\item Learn what each of the \ilink{Bacula Utility Programs}{_ChapterStart9}
+\item Learn what each of the \ilink{Bacula Utility Programs}{_UtilityChapter}
does.
\item Set up reasonable retention periods so that your catalog does not grow
to be too big. See the following three chapters:\\
supplied.
\item [Name = \lt{}name\gt{}]
- \index[dir]{Name }
+ \index[dir]{Name}
+ \index[dir]{Directive!Name}
The director name used by the system administrator. This directive is
required.
\item [Description = \lt{}text\gt{}]
- \index[dir]{Description }
+ \index[dir]{Description}
+ \index[dir]{Directive!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 }
+ \index[dir]{Password}
+ \index[dir]{Directive!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
blank and you must manually supply it.
\item [Messages = \lt{}Messages-resource-name\gt{}]
- \index[dir]{Messages }
+ \index[dir]{Messages}
+ \index[dir]{Directive!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,
directive is required.
\item [Working Directory = \lt{}Directory\gt{}]
- \index[dir]{Working Directory }
+ \index[dir]{Working Directory}
+ \index[dir]{Directive!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 done when the configuration file is read so that values such
as {\bf \$HOME} will be properly expanded. This directive is required.
+ If you have specified a Director user and/or a Director group on your
+ ./configure line with {\bf {-}{-}with-dir-user} and/or
+ {\bf {-}{-}with-dir-group} the Working Directory owner and group will
+ be set to those values.
+
\item [Pid Directory = \lt{}Directory\gt{}]
- \index[dir]{Pid Directory }
+ \index[dir]{Pid Directory}
+ \index[dir]{Directive!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.
Directory} as defined above. This directive is required.
\item [Scripts Directory = \lt{}Directory\gt{}]
- \index[dir]{Scripts Directory }
+ \index[dir]{Scripts Directory}
+ \index[dir]{Directive!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.
expanded.
\item [QueryFile = \lt{}Path\gt{}]
- \index[dir]{QueryFile }
+ \index[dir]{QueryFile}
+ \index[dir]{Directive!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
\label{DirMaxConJobs}
\item [Maximum Concurrent Jobs = \lt{}number\gt{}]
-\index[dir]{Maximum Concurrent Jobs }
+\index[dir]{Maximum Concurrent Jobs}
+\index[dir]{Directive!Maximum Concurrent Jobs}
\index[general]{Simultaneous Jobs}
\index[general]{Concurrent Jobs}
where \lt{}number\gt{} is the maximum number of total Director Jobs that
of this manual.
\item [FD Connect Timeout = \lt{}time\gt{}]
- \index[dir]{FD Connect Timeout }
+ \index[dir]{FD Connect Timeout}
+ \index[dir]{Directive!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 }
+ \index[dir]{SD Connect Timeout}
+ \index[dir]{Directive!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 }
+ \index[dir]{DirAddresses}
+ \index[dir]{Directive!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:
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
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.
+Please note that if you use the DirAddresses directive, you must
+not use either a DirPort or a DirAddress directive in the same
+resource.
+
\item [DIRport = \lt{}port-number\gt{}]
- \index[dir]{DIRport }
+ \index[dir]{DIRport}
+ \index[dir]{Directive!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
directive is not needed if you specify DirAddresses.
\item [DirAddress = \lt{}IP-Address\gt{}]
- \index[dir]{DirAddress }
+ \index[dir]{DirAddress}
+ \index[dir]{Directive!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
\item [Job]
\index[dir]{Job}
+ \index[dir]{Directive!Job}
Start of the Job resource. At least one Job resource is required.
\item [Name = \lt{}name\gt{}]
- \index[dir]{Name }
+ \index[dir]{Name}
+ \index[dir]{Directive!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
specify here followed by the date and time the job was scheduled for
execution. This directive is required.
+\item [Enabled = \lt{}yes|no\gt{}]
+ \index[dir]{Enable}
+ \index[dir]Directive!Enable}
+ This directive allows you to enable or disable automatic execution
+ via the scheduler of a Job.
+
\item [Type = \lt{}job-type\gt{}]
- \index[dir]{Type }
+ \index[dir]{Type}
+ \index[dir]{Directive!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
\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.
+\index[dir]{Level}
+\index[dir]{Directive!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.
+\index[dir]{Full}
+ When the Level is set to Full all files in the FileSet whether or not
+ they have changed will be backed up.
\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:
+ When the Level is set to Incremental 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, will be backed up. 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.
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}
+\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.
+ 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.
+
+ 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
+ When the Level is set to Differential
+ all files specified in the FileSet that have changed since the last
+ successful Full backup of the same Job will be backed up.
+ 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
\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.
-
+ 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 a Differential backup
+ effectively merges
+ 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 since the old backups could be used if the merged backup
+ cannot be read. 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}
\begin{description}
\item [InitCatalog]
- \index[dir]{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
the files.
\item [Catalog]
- \index[dir]{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
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.
+\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.
+\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.
+ \index[dir]{Verify Job}
+ \index[dir]{Directive!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.
+\index[dir]{JobDefs}
+\index[dir]{Directive!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.
+\index[dir]{Bootstrap}
+\index[dir]{Directive!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.
+\index[dir]{Write Bootstrap}
+\index[dir]{Directive!Write Bootstrap}
+ 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 }
+\index[dir]{Client}
+\index[dir]{Directive!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
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.
+\index[dir]{FileSet}
+\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.
+\index[dir]{Messages}
+\index[dir]{Directive!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.
+\index[dir]{Pool}
+\index[dir]{Directive!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.
+\index[dir]{Full Backup Pool}
+\index[dir]{Directive!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.
+\index[dir]{Differential Backup Pool}
+\index[dir]{Directive!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.
+\index[dir]{Incremental Backup Pool}
+\index[dir]{Directive!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 }
+\index[dir]{Schedule}
+\index[dir]{Directive!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.
\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
+\index[dir]{Storage}
+\index[dir]{Directive!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.
+ This directive is required.
\item [Max Start Delay = \lt{}time\gt{}]
- \index[dir]{Max Start Delay }
+\index[dir]{Max Start Delay}
+\index[dir]{Directive!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.
which indicates no limit.
\item [Max Run Time = \lt{}time\gt{}]
- \index[dir]{Max Run Time }
+\index[dir]{Max Run Time}
+\index[dir]{Directive!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 }
+\index[dir]{Max Wait Time}
+\index[dir]{Directive!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
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 }
+\index[dir]{Incremental Max Wait Time}
+\index[dir]{Directive!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
{\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 }
+\index[dir]{Differential Max Wait Time}
+\index[dir]{Directive!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
{\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}
+\index[dir]{Prefer Mounted Volumes}
+\index[dir]{Directive!Prefer Mounted Volumes}
If the Prefer Mounted Volumes directive is set to {\bf yes} (default
yes), the Storage daemon is requested to select either an Autochanger or
a drive with a valid Volume already mounted in preference to a drive
\item [Prune Jobs = \lt{}yes|no\gt{}]
- \index[dir]{Prune Jobs }
+\index[dir]{Prune Jobs}
+\index[dir]{Directive!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
\item [Prune Files = \lt{}yes|no\gt{}]
- \index[dir]{Prune Files }
+\index[dir]{Prune Files}
+\index[dir]{Directive!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
default is {\bf no}.
\item [Prune Volumes = \lt{}yes|no\gt{}]
- \index[dir]{Prune Volumes }
+\index[dir]{Prune Volumes}
+\index[dir]{Directive!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
resource. The default is {\bf no}.
\item [Run Before Job = \lt{}command\gt{}]
- \index[dir]{Run Before Job }
+\index[dir]{Run Before Job}
+\index[dir]{Directive!Run Before Job}
+\index[dir]{Directive!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
%% = %
%c = Client's name
%d = Director's name
- %i = JobId
%e = Job Exit Status
- %j = Unique Job name
+ %i = JobId
+ %j = Unique Job id
%l = Job Level
%n = Job name
- %t = Job type
+ %s = Since time
+ %t = Job type (Backup, ...)
%v = Volume name
\end{verbatim}
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.
+\index[dir]{Run After Job}
+\index[dir]{Directive!Run After Job}
+ The specified {\bf command} is run as an external program if the current
+ job terminates normally (without error or without being canceled). 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, Bacula will print a warning message. 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.
+ \ilink{Tips Chapter}{JobNotification} of this manual.
+ See the {\bf Run After Failed Job} if you
+ want to run a script after the job has terminated with any
+ non-normal status.
+
+\item [Run After Failed Job = \lt{}command\gt{}]
+\index[dir]{Run After Job}
+\index[dir]{Directive!Run After Job}
+ The specified {\bf command} is run as an external program after the current
+ job terminates with any error status. 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, Bacula will print a
+ warning message. Before submitting the specified command to the
+ operating system, Bacula performs character substitution as described above
+ for the {\bf Run Before Job} directive. Note, if you wish, you may
+ specify the same script as for {\bf Run After Job} so that your script
+ will run regardless of the exit status of the Job.
+
+ An example of the use of this directive is given in the
+ \ilink{Tips Chapter}{JobNotification} of this manual.
+
\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.
-
+\index[dir]{Client Run Before Job}
+\index[dir]{Directive!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}.
+
+ 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.
+
{\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)
+ 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.
- 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.)
+ 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}
\end{verbatim}
\normalsize
- The special characters \&()[]\{\}\^{}=;!'+,`\~{} will need to be quoted if
- they are part of a filename or argument.
+ 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.
+ 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:
+ 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 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:
\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.
+ \index[dir]{Client Run After Job}
+ \index[dir]{Directive!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.
+ \index[dir]{Rerun Failed Levels}
+ \index[dir]{Directive!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 }
+ \index[dir]{Spool Data}
+ \index[dir]{Directive!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.
+ 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 }
+ \index[dir]{Spool Attributes}
+ \index[dir]{Directive!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,
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.
+ \index[dir]{Where}
+ \index[dir]{Directive!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}:
+ \index[dir]{Replace}
+ \index[dir]{Directive!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.
+ 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.
+\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.
+ 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}
\item [Prefix Links=\lt{}yes|no\gt{}]
\index[dir]{Prefix Links}
+ \index[dir]{Directive!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
original locations, all files linked with absolute names will be broken.
\item [Maximum Concurrent Jobs = \lt{}number\gt{}]
- \index[dir]{Maximum Concurrent Jobs }
+ \index[dir]{Maximum Concurrent Jobs}
+ \index[dir]{Directive!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
Director's resource.
\item [Reschedule On Error = \lt{}yes|no\gt{}]
- \index[dir]{Reschedule On Error }
+ \index[dir]{Reschedule On Error}
+ \index[dir]{Directive!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
machines that are not always connected to the network or switched on.
\item [Reschedule Interval = \lt{}time-specification\gt{}]
- \index[dir]{Reschedule Interval }
+ \index[dir]{Reschedule Interval}
+ \index[dir]{Directive!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
rescheduled on error.
\item [Reschedule Times = \lt{}count\gt{}]
- \index[dir]{Reschedule Times }
+ \index[dir]{Reschedule Times}
+ \index[dir]{Directive!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]{Run}
+ \index[dir]{Directive!Run}
\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
\label{Priority}
\item [Priority = \lt{}number\gt{}]
- \index[dir]{Priority }
+ \index[dir]{Priority}
+ \index[dir]{Directive!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,
The default priority is 10.
- If you want to run concurrent jobs, which is not recommended, you should
-keep
- these points in mind:
+ 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.
+\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
\label{WritePartAfterJob}
\item [Write Part After Job = \lt{}yes|no\gt{}]
- \index[dir]{Write Part After Job }
+\index[dir]{Write Part After Job}
+\index[dir]{Directive!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.
\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.
+\index[dir]{Schedule}
+\index[dir]{Directive!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 }
+ \index[dir]{Name}
+ \index[dir]{Directive!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:
+ \index[dir]{Run}
+ \index[dir]{Directive!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}
+ \index[dir]{Directive!Level}
is all files in the FileSet whether or not they have changed.
\item [Level=Incremental]
\index[dir]{Level}
+ \index[dir]{Directive!Level}
is all files that have changed since the last backup.
\item [Pool=Weekly]
\index[dir]{Pool}
+ \index[dir]{Directive!Pool}
specifies to use the Pool named {\bf Weekly}.
\item [Storage=DLT\_Drive]
\index[dir]{Storage}
+ \index[dir]{Directive!Storage}
specifies to use {\bf DLT\_Drive} for the storage device.
\item [Messages=Verbose]
\index[dir]{Messages}
+ \index[dir]{Directive!Messages}
specifies to use the {\bf Verbose} message resource for the Job.
\item [FullPool=Full]
\index[dir]{FullPool}
+ \index[dir]{Directive!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}
+ \index[dir]{Directive!DifferentialPool}
specifies to use the Pool named {\bf Differential} if the job is a
differential backup.
\item [IncrementalPool=Incremental]
\index[dir]{IncrementalPool}
+ \index[dir]{Directive!IncrementalPool}
specifies to use the Pool named {\bf Incremental} if the job is an
incremental backup.
\item [SpoolData=yes|no]
\index[dir]{SpoolData}
+ \index[dir]{Directive!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}
+ \index[dir]{Directive!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
\item [Client (or FileDaemon)]
\index[dir]{Client (or FileDaemon)}
+ \index[dir]{Directive!Client (or FileDaemon)}
Start of the Client directives.
\item [Name = \lt{}name\gt{}]
- \index[dir]{Name }
+ \index[dir]{Name}
+ \index[dir]{Directive!Name}
The client name which will be used in the Job resource directive or in the
console run command. This directive is required.
\item [Address = \lt{}address\gt{}]
- \index[dir]{Address }
+ \index[dir]{Address}
+ \index[dir]{Directive!Address}
Where the address is a host name, a fully qualified domain name, or a
network
address in dotted quad notation for a Bacula File server daemon. This
directive is required.
\item [FD Port = \lt{}port-number\gt{}]
- \index[dir]{FD Port }
+ \index[dir]{FD Port}
+ \index[dir]{Directive!FD Port}
Where the port is a port number at which the Bacula File server daemon can
be
contacted. The default is 9102.
\item [Catalog = \lt{}Catalog-resource-name\gt{}]
- \index[dir]{Catalog }
+ \index[dir]{Catalog}
+ \index[dir]{Directive!Catalog}
This specifies the name of the catalog resource to be used for this Client.
This directive is required.
\item [Password = \lt{}password\gt{}]
- \index[dir]{Password }
+ \index[dir]{Password}
+ \index[dir]{Directive!Password}
This is the password to be used when establishing a connection with the File
services, so the Client configuration file on the machine to be backed up
must have the same password defined for this Director. This directive is
\label{FileRetention}
\item [File Retention = \lt{}time-period-specification\gt{}]
- \index[dir]{File Retention }
+ \index[dir]{File Retention}
+ \index[dir]{Directive!File Retention}
The File Retention directive defines the length of time that Bacula will
keep
File records in the Catalog database. When this time period expires, and if
\label{JobRetention}
\item [Job Retention = \lt{}time-period-specification\gt{}]
- \index[dir]{Job Retention }
+ \index[dir]{Job Retention}
+ \index[dir]{Directive!Job Retention}
The Job Retention directive defines the length of time that Bacula will keep
Job records in the Catalog database. When this time period expires, and if
{\bf AutoPrune} is set to {\bf yes} Bacula will prune (remove) Job records
\label{AutoPrune}
\item [AutoPrune = \lt{}yes|no\gt{}]
- \index[dir]{AutoPrune }
+ \index[dir]{AutoPrune}
+ \index[dir]{Directive!AutoPrune}
If AutoPrune is set to {\bf yes} (default), Bacula (version 1.20 or greater)
will automatically apply the File retention period and the Job retention
period for the Client at the end of the Job. If you set {\bf AutoPrune = no},
stored in the backup archives (on Volumes).
\item [Maximum Concurrent Jobs = \lt{}number\gt{}]
- \index[dir]{Maximum Concurrent Jobs }
+ \index[dir]{Maximum Concurrent Jobs}
+ \index[dir]{Directive!Maximum Concurrent Jobs}
where \lt{}number\gt{} is the maximum number of Jobs with the current Client
that can run concurrently. Note, this directive limits only Jobs for Clients
with the same name as the resource in which it appears. Any other
\ilink{ Maximum Concurrent Jobs}{DirMaxConJobs} in the Director's
resource.
-\item [*Priority = \lt{}number\gt{}]
- \index[dir]{*Priority }
+\item [Priority = \lt{}number\gt{}]
+ \index[dir]{Priority}
+ \index[dir]{Directive!Priority}
The number specifies the priority of this client relative to other clients
-that the Director is processing simultaneously. The priority can range from
-1 to 1000. The clients are ordered such that the smaller number priorities
-are performed first (not currently implemented).
+ that the Director is processing simultaneously. The priority can range from
+ 1 to 1000. The clients are ordered such that the smaller number priorities
+ are performed first (not currently implemented).
\end{description}
The following is an example of a valid Client resource definition:
\item [Storage]
\index[dir]{Storage}
+ \index[dir]{Directive!Storage}
Start of the Storage resources. At least one storage resource must be
specified.
\item [Name = \lt{}name\gt{}]
- \index[dir]{Name }
+ \index[dir]{Name}
+ \index[dir]{Directive!Name}
The name of the storage resource. This name appears on the Storage directive
specified in the Job resource and is required.
\item [Address = \lt{}address\gt{}]
- \index[dir]{Address }
+ \index[dir]{Address}
+ \index[dir]{Directive!Address}
Where the address is a host name, a {\bf fully qualified domain name}, or an
{\bf IP address}. Please note that the \lt{}address\gt{} as specified here
will be transmitted to the File daemon who will then use it to contact the
directive is required.
\item [SD Port = \lt{}port\gt{}]
- \index[dir]{SD Port }
+ \index[dir]{SD Port}
+ \index[dir]{Directive!SD Port}
Where port is the port to use to contact the storage daemon for information
and to start jobs. This same port number must appear in the Storage resource
of the Storage daemon's configuration file. The default is 9103.
\item [Password = \lt{}password\gt{}]
\index[dir]{Password}
+ \index[dir]{Directive!Password}
This is the password to be used when establishing a connection with the
Storage services. This same password also must appear in the Director
resource of the Storage daemon's configuration file. This directive is
\item [Device = \lt{}device-name\gt{}]
\index[dir]{Device}
- This directive specifies the name of the device to be used for the
- storage. This name is not the physical device name, but the logical
- device name as defined on the {\bf Name} directive contained in the {\bf
- Device} resource definition of the {\bf Storage daemon} configuration
- file or if the device is an Autochanger, you must put the name as
- defined on the {\bf Name} directive contained in the {\bf Autochanger}
- resource definition of the {\bf Storage daemon}. You can specify any
- name you would like (even the device name if you prefer) up to a maximum
- of 127 characters in length. The physical device name associated with
- this device is specified in the {\bf Storage daemon} configuration file
- (as {\bf Archive Device}). Please take care not to define two different
- Storage resource directives in the Director that point to the same
- Device in the Storage daemon. Doing so may cause the Storage daemon to
- block (or hang) attempting to open the same device that is already open.
+ \index[dir]{Directive!Device}
+ This directive specifies the Storage daemon's name of the device resource
+ to be used for the storage. This name is not the physical device name, but
+ the logical device name as defined on the {\bf Name} directive contained in
+ the {\bf Device} resource definition of the {\bf Storage daemon}
+ configuration file or if the device is an Autochanger, you must put the
+ name as defined on the {\bf Name} directive contained in the {\bf
+ Autochanger} resource definition of the {\bf Storage daemon}. You can
+ specify any name you would like (even the device name if you prefer) up to
+ a maximum of 127 characters in length. The physical device name associated
+ with this device is specified in the {\bf Storage daemon} configuration
+ file (as {\bf Archive Device}). Please take care not to define two
+ different Storage resource directives in the Director that point to the
+ same Device in the Storage daemon. Doing so may cause the Storage daemon
+ to block (or hang) attempting to open the same device that is already open.
This directive is required.
\label{MediaType}
\item [Media Type = \lt{}MediaType\gt{}]
\index[dir]{Media Type}
+ \index[dir]{Directive!Media Type}
This directive specifies the Media Type to be used to store the data.
This is an arbitrary string of characters up to 127 maximum that you
define. It can be anything you want. However, it is best to make it
associated with the Job, Bacula can decide to use any Storage daemon
that supports Media Type {\bf DDS-4} and on any drive that supports it.
+ Currently Bacula permits only a single Media Type. Consequently, if
+ you have a drive that supports more than one Media Type, you can
+ give a unique string to Volumes with different intrinsic Media
+ Type (Media Type = DDS-3-4 for DDS-3 and DDS-4 types), but then
+ those volumes will only be mounted on drives indicated with the
+ dual type (DDS-3-4).
+
If you want to tie Bacula to using a single Storage daemon or drive, you
must specify a unique Media Type for that drive. This is an important
point that should be carefully understood. Note, this applies equally
\label{Autochanger1}
\item [Autochanger = \lt{}yes|no\gt{}]
- \index[dir]{Autochanger }
+ \index[dir]{Autochanger}
+ \index[dir]{Directive!Autochanger}
If you specify {\bf yes} for this command (the default is {\bf no}), when
you use the {\bf label} command or the {\bf add} command to create a new
Volume, {\bf Bacula} will also request the Autochanger Slot number.
using autochangers.
\item [Maximum Concurrent Jobs = \lt{}number\gt{}]
- \index[dir]{Maximum Concurrent Jobs }
+ \index[dir]{Maximum Concurrent Jobs}
+ \index[dir]{Directive!Maximum Concurrent Jobs}
where \lt{}number\gt{} is the maximum number of Jobs with the current
Storage
resource that can run concurrently. Note, this directive limits only Jobs
\item [Pool]
\index[dir]{Pool}
+ \index[dir]{Directive!Pool}
Start of the Pool resource. There must be at least one Pool resource
defined.
\item [Name = \lt{}name\gt{}]
- \index[dir]{Name }
+ \index[dir]{Name}
+ \index[dir]{Directive!Name}
The name of the pool. For most applications, you will use the default
pool name {\bf Default}. This directive is required.
\label{MaxVolumes}
\item [Maximum Volumes = \lt{}number\gt{}]
- \index[dir]{Maximum Volumes }
+ \index[dir]{Maximum Volumes}
+ \index[dir]{Directive!Maximum Volumes}
This directive specifies the maximum number of volumes (tapes or files)
contained in the pool. This directive is optional, if omitted or set to
zero, any number of volumes will be permitted. In general, this
made to disk files do not become too numerous or consume too much space.
\item [Pool Type = \lt{}type\gt{}]
- \index[dir]{Pool Type }
+ \index[dir]{Pool Type}
+ \index[dir]{Directive!Pool Type}
This directive defines the pool type, which corresponds to the type of
Job being run. It is required and may be one of the following:
\end{itemize}
\item [Use Volume Once = \lt{}yes|no\gt{}]
- \index[dir]{Use Volume Once }
+ \index[dir]{Use Volume Once}
+ \index[dir]{Directive!Use Volume Once}
This directive if set to {\bf yes} specifies that each volume is to be
used only once. This is most useful when the Media is a file and you
want a new file for each backup that is done. The default is {\bf no}
Volume you must use the {\bf update} command in the Console.
\item [Maximum Volume Jobs = \lt{}positive-integer\gt{}]
- \index[dir]{Maximum Volume Jobs }
+ \index[dir]{Maximum Volume Jobs}
+ \index[dir]{Directive!Maximum Volume Jobs}
This directive specifies the maximum number of Jobs that can be written
to the Volume. If you specify zero (the default), there is no limit.
Otherwise, when the number of Jobs backed up to the Volume equals {\bf
must use the {\bf update} command in the Console.
\item [Maximum Volume Files = \lt{}positive-integer\gt{}]
- \index[dir]{Maximum Volume Files }
+ \index[dir]{Maximum Volume Files}
+ \index[dir]{Directive!Maximum Volume Files}
This directive specifies the maximum number of files that can be written
to the Volume. If you specify zero (the default), there is no limit.
Otherwise, when the number of files written to the Volume equals {\bf
Volume you must use the {\bf update} command in the Console.
\item [Maximum Volume Bytes = \lt{}size\gt{}]
- \index[dir]{Maximum Volume Bytes }
+ \index[dir]{Maximum Volume Bytes}
+ \index[dir]{Directive!Maximum Volume Bytes}
This directive specifies the maximum number of bytes that can be written
to the Volume. If you specify zero (the default), there is no limit
except the physical size of the Volume. Otherwise, when the number of
Volume you must use the {\bf update} command in the Console.
\item [Volume Use Duration = \lt{}time-period-specification\gt{}]
- \index[dir]{Volume Use Duration }
+ \index[dir]{Volume Use Duration}
+ \index[dir]{Directive!Volume Use Duration}
The Volume Use Duration directive defines the time period that the
Volume can be written beginning from the time of first data write to the
Volume. If the time-period specified is zero (the default), the Volume
\ilink{\bf update volume}{UpdateCommand} command in the Console.
\item [Catalog Files = \lt{}yes|no\gt{}]
- \index[dir]{Catalog Files }
+ \index[dir]{Catalog Files}
+ \index[dir]{Directive!Catalog Files}
This directive defines whether or not you want the names of the files
that were saved to be put into the catalog. The default is {\bf yes}.
The advantage of specifying {\bf Catalog Files = No} is that you will
\label{PoolAutoPrune}
\item [AutoPrune = \lt{}yes|no\gt{}]
- \index[dir]{AutoPrune }
+ \index[dir]{AutoPrune}
+ \index[dir]{Directive!AutoPrune}
If AutoPrune is set to {\bf yes} (default), Bacula (version 1.20 or greater)
will automatically apply the Volume Retention period when new Volume is
needed and no appendable Volumes exist in the Pool. Volume pruning causes
\label{VolRetention}
\item [Volume Retention = \lt{}time-period-specification\gt{}]
- \index[dir]{Volume Retention }
+ \index[dir]{Volume Retention}
+ \index[dir]{Directive!Volume Retention}
The Volume Retention directive defines the length of time that {\bf
Bacula} will keep Job records associated with the Volume in the Catalog
database. When this time period expires, and if {\bf AutoPrune} is set
\label{PoolRecycle}
\item [Recycle = \lt{}yes|no\gt{}]
- \index[dir]{Recycle }
+ \index[dir]{Recycle}
+ \index[dir]{Directive!Recycle}
This directive specifies whether or not Purged Volumes may be recycled.
If it is set to {\bf yes} (default) and Bacula needs a volume but finds
none that are appendable, it will search for and recycle (reuse) Purged
\label{RecycleOldest}
\item [Recycle Oldest Volume = \lt{}yes|no\gt{}]
- \index[dir]{Recycle Oldest Volume }
+ \index[dir]{Recycle Oldest Volume}
+ \index[dir]{Directive!Recycle Oldest Volume}
This directive instructs the Director to search for the oldest used
Volume in the Pool when another Volume is requested by the Storage
daemon and none are available. The catalog is then {\bf pruned}
\label{RecycleCurrent}
\item [Recycle Current Volume = \lt{}yes|no\gt{}]
- \index[dir]{Recycle Current Volume }
+ \index[dir]{Recycle Current Volume}
+ \index[dir]{Directive!Recycle Current Volume}
If Bacula needs a new Volume, this directive instructs Bacula to Prune
the volume respecting the Job and File retention periods. If all Jobs
are pruned (i.e. the volume is Purged), then the Volume is recycled and
\label{PurgeOldest}
\item [Purge Oldest Volume = \lt{}yes|no\gt{}]
- \index[dir]{Purge Oldest Volume }
+ \index[dir]{Purge Oldest Volume}
+ \index[dir]{Directive!Purge Oldest Volume}
This directive instructs the Director to search for the oldest used
Volume in the Pool when another Volume is requested by the Storage
daemon and none are available. The catalog is then {\bf purged}
data. The default is {\bf no}.
\item [Cleaning Prefix = \lt{}string\gt{}]
- \index[dir]{Cleaning Prefix }
+ \index[dir]{Cleaning Prefix}
+ \index[dir]{Directive!Cleaning Prefix}
This directive defines a prefix string, which if it matches the
beginning of a Volume name during labeling of a Volume, the Volume will
be defined with the VolStatus set to {\bf Cleaning} and thus Bacula will
\label{Label}
\item [Label Format = \lt{}format\gt{}]
- \index[dir]{Label Format }
+ \index[dir]{Label Format}
+ \index[dir]{Directive!Label Format}
This directive specifies the format of the labels contained in this
pool. The format directive is used as a sort of template to create new
Volume names during automatic Volume labeling.
\item [Catalog]
\index[dir]{Catalog}
+ \index[dir]{Directive!Catalog}
Start of the Catalog resource. At least one Catalog resource must be
defined.
\item [Name = \lt{}name\gt{}]
- \index[dir]{Name }
+ \index[dir]{Name}
+ \index[dir]{Directive!Name}
The name of the Catalog. No necessary relation to the database server
name. This name will be specified in the Client resource directive
indicating that all catalog data for that Client is maintained in this
Catalog. This directive is required.
\item [password = \lt{}password\gt{}]
- \index[dir]{password }
+ \index[dir]{password}
+ \index[dir]{Directive!password}
This specifies the password to use when logging into the database. This
directive is required.
\item [DB Name = \lt{}name\gt{}]
- \index[dir]{DB Name }
+ \index[dir]{DB Name}
+ \index[dir]{Directive!DB Name}
This specifies the name of the database. If you use multiple catalogs
(databases), you specify which one here. If you are using an external
database server rather than the internal one, you must specify a name
tables using this name. This directive is required.
\item [user = \lt{}user\gt{}]
- \index[dir]{user }
+ \index[dir]{user}
+ \index[dir]{Directive!user}
This specifies what user name to use to log into the database. This
directive is required.
\item [DB Socket = \lt{}socket-name\gt{}]
- \index[dir]{DB Socket }
+ \index[dir]{DB Socket}
+ \index[dir]{Directive!DB Socket}
This is the name of a socket to use on the local host to connect to the
database. This directive is used only by MySQL and is ignored by SQLite.
Normally, if neither {\bf DB Socket} or {\bf DB Address} are specified, MySQL
will use the default socket.
\item [DB Address = \lt{}address\gt{}]
- \index[dir]{DB Address }
+ \index[dir]{DB Address}
+ \index[dir]{Directive!DB Address}
This is the host address of the database server. Normally, you would specify
this instead of {\bf DB Socket} if the database server is on another machine.
In that case, you will also specify {\bf DB Port}. This directive is used
optional.
\item [DB Port = \lt{}port\gt{}]
- \index[dir]{DB Port }
+ \index[dir]{DB Port}
+ \index[dir]{Directive!DB Port}
This defines the port to be used in conjunction with {\bf DB Address} to
access the database if it is on another machine. This directive is used only
by MySQL and is ignored by SQLite if provided. This directive is optional.
%% \item [Multiple Connections = \lt{}yes|no\gt{}]
-%% \index[dir]{Multiple Connections }
+%% \index[dir]{Multiple Connections}
+%% \index[dir]{Directive!Multiple Connections}
%% By default, this directive is set to no. In that case, each job that uses
the
%% same Catalog will use a single connection to the catalog. It will be shared,
\begin{description}
\item [Name = \lt{}name\gt{}]
- \index[dir]{Name }
+ \index[dir]{Name}
+ \index[dir]{Directive!Name}
The name of the console. This name must match the name specified in the
Console's configuration resource (much as is the case with Client
definitions).
\item [Password = \lt{}password\gt{}]
- \index[dir]{Password }
+ \index[dir]{Password}
+ \index[dir]{Directive!Password}
Specifies the password that must be supplied for a named Bacula Console
to be authorized. The same password must appear in the {\bf Console}
resource of the Console configuration file. For added security, the
process, otherwise it will be left blank.
\item [JobACL = \lt{}name-list\gt{}]
- \index[dir]{JobACL }
+ \index[dir]{JobACL}
+ \index[dir]{Directive!JobACL}
This directive is used to specify a list of Job resource names that can
be accessed by the console. Without this directive, the console cannot
access any of the Director's Job resources. Multiple Job resource names
for the four jobs named on the JobACL directives, but for no others.
\item [ClientACL = \lt{}name-list\gt{}]
- \index[dir]{ClientACL }
+ \index[dir]{ClientACL}
+ \index[dir]{Directive!ClientACL}
This directive is used to specify a list of Client resource names that can
be
accessed by the console.
\item [StorageACL = \lt{}name-list\gt{}]
- \index[dir]{StorageACL }
+ \index[dir]{StorageACL}
+ \index[dir]{Directive!StorageACL}
This directive is used to specify a list of Storage resource names that can
be accessed by the console.
\item [ScheduleACL = \lt{}name-list\gt{}]
- \index[dir]{ScheduleACL }
+ \index[dir]{ScheduleACL}
+ \index[dir]{Directive!ScheduleACL}
This directive is used to specify a list of Schedule resource names that can
be accessed by the console.
\item [PoolACL = \lt{}name-list\gt{}]
- \index[dir]{PoolACL }
+ \index[dir]{PoolACL}
+ \index[dir]{Directive!PoolACL}
This directive is used to specify a list of Pool resource names that can be
accessed by the console.
\item [FileSetACL = \lt{}name-list\gt{}]
- \index[dir]{FileSetACL }
+ \index[dir]{FileSetACL}
+ \index[dir]{Directive!FileSetACL}
This directive is used to specify a list of FileSet resource names that can
be accessed by the console.
\item [CatalogACL = \lt{}name-list\gt{}]
- \index[dir]{CatalogACL }
+ \index[dir]{CatalogACL}
+ \index[dir]{Directive!CatalogACL}
This directive is used to specify a list of Catalog resource names that can
be accessed by the console.
\item [CommandACL = \lt{}name-list\gt{}]
- \index[dir]{CommandACL }
+ \index[dir]{CommandACL}
+ \index[dir]{Directive!CommandACL}
This directive is used to specify a list of of console commands that can be
executed by the console.
\end{description}
\item [Counter]
\index[dir]{Counter}
+ \index[dir]{Directive!Counter}
Start of the Counter resource. Counter directives are optional.
\item [Name = \lt{}name\gt{}]
- \index[dir]{Name }
+ \index[dir]{Name}
+ \index[dir]{Directive!Name}
The name of the Counter. This is the name you will use in the variable
expansion to reference the counter value.
\item [Minimum = \lt{}integer\gt{}]
- \index[dir]{Minimum }
+ \index[dir]{Minimum}
+ \index[dir]{Directive!Minimum}
This specifies the minimum value that the counter can have. It also becomes
the default. If not supplied, zero is assumed.
\item [Maximum = \lt{}integer\gt{}]
- \index[dir]{Maximum }
+ \index[dir]{Maximum}
+ \index[dir]{Directive!Maximum}
+ \index[dir]{Directive!Maximum}
This is the maximum value value that the counter can have. If not specified
or set to zero, the counter can have a maximum value of 2,147,483,648 (2 to
the 31 power). When the counter is incremented past this value, it is reset
to the Minimum.
\item [*WrapCounter = \lt{}counter-name\gt{}]
- \index[dir]{*WrapCounter }
+ \index[dir]{*WrapCounter}
+ \index[dir]{Directive!*WrapCounter}
If this value is specified, when the counter is incremented past the
maximum
and thus reset to the minimum, the counter specified on the {\bf WrapCounter}
is incremented. (This is not currently implemented).
\item [Catalog = \lt{}catalog-name\gt{}]
- \index[dir]{Catalog }
+ \index[dir]{Catalog}
+ \index[dir]{Directive!Catalog}
If this directive is specified, the counter and its values will be saved in
the specified catalog. If this directive is not present, the counter will be
redefined each time that Bacula is started.
FileSet {
Name = "Full Set"
Include {
- Options { signature=SHA1 }
+ Options { signature=SHA1}
#
# Put your list of files here, one per line or include an
# external list with:
#
# Note: / backs up everything
File = /
- }
+}
Exclude {}
}
# When to do the backups
\subsection*{Does Bacula support Windows?}
\item [Does Bacula support Windows?]
- \index[general]{Does Bacula support Windows? }
- Yes, Bacula compiles and runs on Windows machines (Win98, WinMe, WinXP,
- WinNT, and Win2000). We provide a binary version of the Client (bacula-fd),
- but have not tested the Director nor the Storage daemon. Note, Win95 is no
- longer supported because it doesn't have the GetFileAttributesExA API call.
+\index[general]{Does Bacula support Windows? }
+ Yes, Bacula compiles and runs on Windows machines (Win98, WinMe, WinXP,
+ WinNT, Win2003, and Win2000). We provide a binary version of the Client
+ (bacula-fd), but have not tested the Director nor the Storage daemon.
+ Note, Win95 is no longer supported because it doesn't have the
+ GetFileAttributesExA API call.
\label{lang}
\subsection*{What language is Bacula written in?}
\item [What language is Bacula written in?]
- \index[general]{What language is Bacula written in? }
+\index[general]{What language is Bacula written in? }
It is written in C++, but it is mostly C code using only a limited set of
the C++ extensions over C. Thus Bacula is completely compiled using the
C++ compiler. There are several modules, including the Win32 interface, that
\subsection*{On what machines does Bacula run?}
\item [On what machines does Bacula run? ]
\index[general]{On what machines does Bacula run? }
- {\bf Bacula} builds and executes on RedHat Linux (versions RH7.1-RHEL 3.0,
- SuSE, Gentoo, Debian, Mandriva, ...), FreeBSD, Solaris, Alpha, SGI (client),
- NetBSD, OpenBSD, Mac OS X (client), and Win32 (client).
-
- Bacula has been my only backup tool for over four years backing up 5
- machines nightly (3 Linux boxes running RedHat, a WinXP machine, and a WinNT
- machine).
+ {\bf Bacula} builds and executes on RedHat Linux (versions RH7.1-RHEL
+ 4.0, Fedora, SuSE, Gentoo, Debian, Mandriva, ...), FreeBSD, Solaris,
+ Alpha, SGI (client), NetBSD, OpenBSD, Mac OS X (client), and Win32
+ (client).
+
+ Bacula has been my only backup tool for over five years backing up 7
+ machines nightly (5 Linux boxes running Fedora Core, previously
+ RedHat, a WinXP machine, and a WinNT machine).
\label{stable}
\subsection*{Is Bacula Stable?}
\item [Is Bacula Stable? ]
- \index[general]{Is Bacula Stable? }
- Yes, it is remarkably stable, but remember, there are still a lot of
- unimplemented or partially implemented features. With a program of this size
- (100,000+ lines of C++ code not including the SQL programs) there are bound
- to be bugs. The current test environment (a twisted pair local network and a
- HP DLT backup tape) is not exactly ideal, so additional testing on other
-sites is
- necessary. The File daemon has never crashed -- running months at a time
-with
- no intervention. The Storage daemon is remarkably stable with most of the
- problems arising during labeling or switching tapes. Storage daemon crashes
- are rare. The Director, given the multitude of functions it fulfills is
-also
- relatively stable. In a production environment, it rarely if ever crashes. Of
- the three daemons, the Director is the most prone to having problems. Still,
-it
- frequently runs several months with no problems.
+\index[general]{Is Bacula Stable? }
+ Yes, it is remarkably stable, but remember, there are still a lot of
+ unimplemented or partially implemented features. With a program of this
+ size (140,000+ lines of C++ code not including the SQL programs) there
+ are bound to be bugs. The current test environment (a twisted pair
+ local network and a HP DLT backup tape) is not exactly ideal, so
+ additional testing on other sites is necessary. The File daemon has
+ never crashed -- running months at a time with no intervention. The
+ Storage daemon is remarkably stable with most of the problems arising
+ during labeling or switching tapes. Storage daemon crashes are rare.
+ The Director, given the multitude of functions it fulfills is also
+ relatively stable. In a production environment, it rarely if ever
+ crashes. Of the three daemons, the Director is the most prone to having
+ problems. Still, it frequently runs several months with no problems.
There are a number of reasons for this stability.
\item All memory leaks (orphaned buffers) are reported each time the
program terminates.\\
\item Any signal (segmentation fault, ...) generates a
- traceback that is emailed to the developer. This permits quick resolution
-of
- bugs even if they only show up rarely in a production system.\\
+ traceback that is emailed to the developer. This permits quick
+ resolution of bugs even if they only show up rarely in a production
+ system.\\
\item There is a reasonably comprehensive set of regression tests
that avoids re-creating the most common errors in new versions of
Bacula.
\label{restorehang}
\subsection*{I Run a Restore Job and Bacula Hangs. What do I do?}
\item [I Run a Restore Job and Bacula Hangs. What do I do?]
- \index[general]{I Run a Restore Job and Bacula Hangs. What do I do? }
- On Bacula version 1.25 and prior, it expects you to have the correct tape
- mounted prior to a restore. On Bacula version 1.26 and higher, it will ask
- you for the tape, and if the wrong one is mounted, it will inform you.
+\index[general]{I Run a Restore Job and Bacula Hangs. What do I do? }
+ On Bacula version 1.25 and prior, it expects you to have the correct
+ tape mounted prior to a restore. On Bacula version 1.26 and higher, it
+ will ask you for the tape, and if the wrong one is mounted, it will
+ inform you.
- If you have previously done an {\bf unmount} command, all Storage daemon
- sessions (jobs) will be completely blocked from using the drive unmounted,
-so
- be sure to do a {\bf mount} after your unmount. If in doubt, do a second
- {\bf mount}, it won't cause any harm.
+ If you have previously done an {\bf unmount} command, all Storage daemon
+ sessions (jobs) will be completely blocked from using the drive
+ unmounted, so be sure to do a {\bf mount} after your unmount. If in
+ doubt, do a second {\bf mount}, it won't cause any harm.
\label{windowstart}
\subsection*{I Cannot Get My Windows Client to Start Automatically? }
\item [I Cannot Get My Windows Client to Start Automatically? ]
- \index[general]{I Cannot Get My Windows Client to Start Automatically? }
- You are probably having one of two problems: either the Client is dying due
- to an incorrect configuration file, or you didn't do the Installation
- commands necessary to install it as a Windows Service.
+\index[general]{Windows Auto Start}
+ You are probably having one of two problems: either the Client is dying
+ due to an incorrect configuration file, or you didn't do the
+ Installation commands necessary to install it as a Windows Service.
- For the first problem, see the next FAQ question. For the second problem,
- please review the
- \ilink{ Windows Installation instructions}{_ChapterStart7} in this
- manual.
+ For the first problem, see the next FAQ question. For the second
+ problem, please review the \ilink{ Windows Installation
+ instructions}{_ChapterStart7} in this manual.
\label{windowsdie}
\subsection*{My Windows Client Immediately Dies When I Start It}
-\item [My Windows Client Immediately Dies When I Start It ]
-\index[general]{My Windows Client Immediately Dies When I Start It }
-The most common problem is either that the configuration file is not where it
-expects it to be, or that there is an error in the configuration file. You
-must have the configuration file in {\bf
-c:\textbackslash{}bacula\textbackslash{}bin\textbackslash{}bacula-fd.conf}.
+\item [My Windows Client Immediately Dies When I Start It]
+\index[general]{Windows Client Dies}
+The most common problem is either that the configuration file is not where
+it expects it to be, or that there is an error in the configuration file.
+You must have the configuration file in {\bf
+c:\textbackslash{}bacula\textbackslash{}bin\textbackslash{}bacula-fd.conf}.
To {\bf see} what is going on when the File daemon starts on Windows, do the
following:
\label{scroll}
\item [When I Start the Console, the Error Messages Fly By. How can I see
them? ]
- \index[general]{When I Start the Console, the Error Messages Fly By. How can
-I see them? }
- Either use a shell window with a scroll bar, or use the gnome-console. In
-any
- case, you probably should be logging all output to a file, and then you can
- simply view the file using an editor or the {\bf less} program. To log all
- output, I have the following in my Director's Message resource definition:
+\index[general]{Error Messages}
+ Either use a shell window with a scroll bar, or use the gnome-console.
+ In any case, you probably should be logging all output to a file, and
+ then you can simply view the file using an editor or the {\bf less}
+ program. To log all output, I have the following in my Director's
+ Message resource definition:
\footnotesize
\begin{verbatim}
\label{nobackup}
\subsection*{My backups are not working on my Windows
Client. What should I do?}
-
\item [I didn't realize that the backups were not working on my Windows
Client. What should I do? ]
-\index[general]{I didn't realize that the backups were not working on my Windows
-Client. What should I do? }
+\index[general]{Backups Failing}
You should be sending yourself an email message for each job. This will avoid
the possibility of not knowing about a failed backup. To do so put something
like:
\end{verbatim}
\normalsize
-in your Director's message resource. You should then receive one email for
-each Job that ran. When you are comfortable with what is going on (it took me
-9 months), you might change that to:
+in your Director's message resource. You should then receive one email for
+each Job that ran. When you are comfortable with what is going on (it took
+me 9 months), you might change that to:
\footnotesize
\begin{verbatim}
\item [All my Jobs are scheduled for the same time. Will this cause
problems? ]
\index[general]{Schedule problems}
- No, not at all. Bacula will schedule all the Jobs at the same time, but will
- run them one after another unless you have increased the number of
- simultaneous jobs in the configuration files for the Director, the File
- daemon, and the Storage daemon. The appropriate configuration record is {\bf
- Maximum Concurrent Jobs = nn}. At the current time, we recommend that you
- leave this set to {\bf 1} for the Director.
+ No, not at all. Bacula will schedule all the Jobs at the same time, but
+ will run them one after another unless you have increased the number of
+ simultaneous jobs in the configuration files for the Director, the File
+ daemon, and the Storage daemon. The appropriate configuration record is
+ {\bf Maximum Concurrent Jobs = nn}. At the current time, we recommend
+ that you leave this set to {\bf 1} for the Director.
\label{disk}
\subsection*{Can Bacula Backup My System To Files instead of Tape?}
\item [Can Bacula Backup My System To Files instead of Tape? ]
- \index[general]{Can Bacula Backup My System To Files instead of Tape? }
- Yes, in principle, Bacula can backup to any storage medium as long as you
- have correctly defined that medium in the Storage daemon's Device resource.
- For an example of how to backup to files, please see the
- \ilink{Pruning Example}{PruningExample} in the Recycling
- chapter of this manual. Also, there is a whole chapter devoted to
- \ilink{Basic Volume Management}{_ChapterStart39}. This chapter was
- originally written to explain how to write to disk, but was expanded
- to include volume management. It is, however, still quite a good
- chapter to read.
+\index[general]{Backup to Disk}
+ Yes, in principle, Bacula can backup to any storage medium as long as
+ you have correctly defined that medium in the Storage daemon's Device
+ resource. For an example of how to backup to files, please see the
+ \ilink{Pruning Example}{PruningExample} in the Recycling chapter of this
+ manual. Also, there is a whole chapter devoted to \ilink{Basic Volume
+ Management}{_ChapterStart39}. This chapter was originally written to
+ explain how to write to disk, but was expanded to include volume
+ management. It is, however, still quite a good chapter to read.
\label{bigfiles}
\subsection*{Can Bacula Backup and Restore Files Greater than 2 Gigabytes?}
\item [Can Bacula Backup and Restore Files Greater than 2 Gigabytes in
Size? ]
\index[general]{Large file support}
-If your operating system permits it, and you are running Bacula version 1.26
-or later, the answer is yes. To the best of our knowledge all client system
-supported by Bacula can handle files larger than 2 Gigabytes.
+If your operating system permits it, and you are running Bacula version
+1.26 or later, the answer is yes. To the best of our knowledge all client
+system supported by Bacula can handle files larger than 2 Gigabytes.
\label{cancel}
\subsection*{I want to stop a job. Is
\item [I Started A Job then Decided I Really Did Not Want to Run It. Is
there a better way than {\bf ./bacula stop} to stop it?]
\index[general]{Cancelling jobs}
- Yes,
- you normally should use the Console command {\bf cancel} to cancel a Job
- that is either scheduled or running. If the Job is scheduled, it will
- be marked for cancellation and will be canceled when it is scheduled to
- start. If it is running, it will normally terminate after a few
- minutes. If the Job is waiting on a tape mount, you may need to do a
- {\bf mount} command before it will be canceled.
+ Yes, you normally should use the Console command {\bf cancel} to cancel
+ a Job that is either scheduled or running. If the Job is scheduled, it
+ will be marked for cancellation and will be canceled when it is
+ scheduled to start. If it is running, it will normally terminate after
+ a few minutes. If the Job is waiting on a tape mount, you may need to
+ do a {\bf mount} command before it will be canceled.
\label{trademark}
\subsection*{Why have You Trademarked the Name
\label{sure}
\subsection*{Does Bacula really save and restore all files?}
\item [How Can I Be Sure that Bacula Really Saves and Restores All Files? ]
- \index[general]{How Can I Be Sure that Bacula Really Saves and Restores
- All Files? } It is really quite simple, but took me a while to figure
+\index[general]{Checking Restores}
+ It is really quite simple, but took me a while to figure
out how to "prove" it. First make a Bacula Rescue disk, see the
\ilink{Disaster Recovery Using Bacula}{_ChapterRescue} chapter
of this manual.
\subsection*{I want an Incremental but Bacula runs it as a Full backup. Why?}
\item [I did a Full backup last week, but now in running an Incremental,
Bacula says it did not find a FULL backup, so it did a FULL backup. Why?]
- \index[general]{I did a Full backup last week, but now in running an
- Incremental, Bacula says it did not find a FULL backup, so it did a
- FULL backup. Why? } Before doing an Incremental or a Differential
+\index[general]{FULL backup not found}
+ Before doing an Incremental or a Differential
backup, Bacula checks to see if there was a prior Full backup of the
same Job that terminated successfully. If so, it uses the date that
full backup started as the time for comparing if files have changed. If
\subsection*{Do you really handle unlimited path lengths?}
\item [How Can You Claim to Handle Unlimited Path and Filename Lengths
when All Other Programs Have Fixed Limits?]
- \index[general]{How Can You Claim to Handle Unlimited Path and Filename
- Lengths when All Other Programs Have Fixed Limits? } Most of those
- other programs have been around for a long time, in fact since the
- beginning of Unix, which means that they were designed for rather small
- fixed length path and filename lengths. Over the years, these
- restrictions have been relaxed allowing longer names. Bacula on the
- other hand was designed in 2000, and so from the start, Path and
+\index[general]{Path and Filename Lengths}
+ Most of those other programs have been around for a long time, in fact
+ since the beginning of Unix, which means that they were designed for
+ rather small fixed length path and filename lengths. Over the years,
+ these restrictions have been relaxed allowing longer names. Bacula on
+ the other hand was designed in 2000, and so from the start, Path and
Filenames have been kept in buffers that start at 256 bytes in length,
but can grow as needed to handle any length. Most of the work is
carried out by lower level routines making the coding rather easy.
\label{unique}
\subsection*{What Is the Really Unique Feature of Bacula?}
\item [What Is the Really Unique Feature of Bacula?]
- \index[general]{What Is the Really Unique Feature of Bacula? } Well, it
- is hard to come up with unique features when backup programs for Unix
- machines have been around since the 1960s. That said, I believe that
- Bacula is the first and only program to use a standard SQL interface to
- catalog its database. Although this adds a bit of complexity and
- possibly overhead, it provides an amazingly rich set of features that
- are easy to program and enhance. The current code has barely scratched
- the surface in this regard (version 1.31).
+\index[general]{Unique Feature of Bacula}
+ Well, it is hard to come up with unique features when backup programs
+ for Unix machines have been around since the 1960s. That said, I
+ believe that Bacula is the first and only program to use a standard SQL
+ interface to catalog its database. Although this adds a bit of
+ complexity and possibly overhead, it provides an amazingly rich set of
+ features that are easy to program and enhance. The current code has
+ barely scratched the surface in this regard (version 1.38).
The second feature, which gives a lot of power and flexibility to Bacula
is the Bootstrap record definition.
\subsection*{How can I force one job to run after another?}
\item [If I Run Multiple Simultaneous Jobs, How Can I Force One
Particular Job to Run After Another Job? ]
-\index[general]{If I Run Multiple Simultaneous Jobs, How Can I Force One
-Particular Job to Run After Another Job? }
+\index[general]{Multiple Simultaneous Jobs}
Yes, you can set Priorities on your jobs so that they run in the order you
specify. Please see:
\ilink{the Priority record}{Priority} in the Job resource.
\label{nomail}
\subsection*{I Am Not Getting Email Notification, What Can I Do? }
\item [I Am Not Getting Email Notification, What Can I Do? ]
-
-\index[general]{I Am Not Getting Email Notification, What Can I Do? }
-The most common problem is that you have not specified a fully qualified
-email address and your bsmtp server is rejecting the mail. The next most
-common problem is that your bsmtp server doesn't like the syntax on the From
-part of the message. For more details on this and other problems, please see
-the
-\ilink{ Getting Email Notification to Work}{email} section of the
-Tips chapter of this manual. The section
-\ilink{ Getting Notified of Job Completion}{notification} of the Tips
-chapter may also be useful. For more information on the {\bf bsmtp} mail
-program, please see
-\ilink{bsmtp in the Volume Utility Tools chapter}{bsmtp} of this
-manual.
+\index[general]{No Email Notification}
+ The most common problem is that you have not specified a fully qualified
+ email address and your bsmtp server is rejecting the mail. The next
+ most common problem is that your bsmtp server doesn't like the syntax on
+ the From part of the message. For more details on this and other
+ problems, please see the \ilink{ Getting Email Notification to
+ Work}{email} section of the Tips chapter of this manual. The section
+ \ilink{ Getting Notified of Job Completion}{notification} of the Tips
+ chapter may also be useful. For more information on the {\bf bsmtp}
+ mail program, please see \ilink{bsmtp in the Volume Utility Tools
+ chapter}{bsmtp} of this manual.
\label{periods}
\subsection*{My retention periods don't work}
the tape drive hardware, and you either enable or disable it with system
tools such as {\bf mt}. This compression works independently of Bacula.
- Bacula also has compression code, which is normally used only when backing
-up
- to file Volumes. There are two conditions for this "software" to become
- enabled.
+ Bacula also has compression code, which is normally used only when
+ backing up to file Volumes. There are two conditions for this
+ "software" to become enabled.
\begin{enumerate}
\item You must have the zip development libraries loaded on your system when
\subsection*{Incremental backups are not working}
\item [Bacula is Not Doing the Right Thing When I Request an Incremental
Backup. Why?]
- \index[general]{Incremental backups}
- As explained in one of the previous questions, Bacula will automatically
- upgrade an Incremental or Differential job to a Full backup if it cannot
-find
- a prior Full backup or a suitable Full backup. For the gory details on
- how/when Bacula decides to upgrade levels please see the
- \ilink{Level record}{Level} in the Director's configuration
- chapter of this manual.
+\index[general]{Incremental backups}
+ As explained in one of the previous questions, Bacula will automatically
+ upgrade an Incremental or Differential job to a Full backup if it cannot
+ find a prior Full backup or a suitable Full backup. For the gory
+ details on how/when Bacula decides to upgrade levels please see the
+ \ilink{Level record}{Level} in the Director's configuration chapter of
+ this manual.
If after reading the above mentioned section, you believe that Bacula is not
correctly handling the level (Differential/Incremental), please send us the
\subsection*{I am waiting forever for a backup of an offsite machine}
\item [I am Backing Up an Offsite Machine with an Unreliable Connection.
The Director Waits Forever for the Client to Contact the SD. What Can I
-Do?]
- \index[general]{I am Backing Up an Offsite Machine with an Unreliable
-Connection.
- The Director Waits Forever for the Client to Contact the SD. What Can I Do?}
- Bacula was written on the assumption that it will have a good TCP/IP
- connection between all the daemons. As a consequence, the current Bacula
- doesn't deal with faulty connections very well. This situation is slowly
-being
- corrected over time.
+ Do?]
+\index[general]{Backing Up Offsite Machines}
+ Bacula was written on the assumption that it will have a good TCP/IP
+ connection between all the daemons. As a consequence, the current
+ Bacula doesn't deal with faulty connections very well. This situation
+ is slowly being corrected over time.
There are several things you can do to improve the situation.
\subsection*{SSH hangs forever after starting Bacula}
\item [When I ssh into a machine and start Bacula then attempt to exit,
ssh hangs forever.]
- \index[general]{When I ssh into a machine and start Bacula then attempt to
-exit,
- ssh hangs forever. }
- This happens because Bacula leaves stdin, stdout, and stderr open for debug
- purposes. To avoid it, the simplest thing to do is to redirect the output of
- those files to {\bf /dev/null} or another file in your startup script (the
- RedHat autostart scripts do this automatically). For example, you start the
- Director with:
+\index[general]{ssh hangs}
+ This happens because Bacula leaves stdin, stdout, and stderr open for
+ debug purposes. To avoid it, the simplest thing to do is to redirect
+ the output of those files to {\bf /dev/null} or another file in your
+ startup script (the RedHat autostart scripts do this automatically).
+ For example, you start the Director with:
\footnotesize
\begin{verbatim}
\subsection*{I'm confused by retention periods}
\item [I'm confused by the different Retention periods: File Retention,
Job Retention, Volume Retention. Why are there so many?]
- \index[general]{I'm confused by the different Retention periods: File
-Retention,
- Job Retention, Volume Retention. Why are there so many? }
- Yes, this certainly can be confusing. The basic reason for so many is to
- allow flexibility. The File records take quite a lot of space in the
-catalog,
- so they are typically records you want to remove rather quickly. The Job
- records, take very little space, and they can be useful even without the
-File
- records to see what Jobs actually ran and when. One must understand that if
- the File records are removed from the catalog, you cannot use the {\bf
- restore} command to restore an individual file since Bacula no longer knows
- where it is. However, as long as the Volume Retention period has not
-expired,
- the data will still be on the tape, and can be recovered from the tape.
+\index[general]{Retention Periods}
+ Yes, this certainly can be confusing. The basic reason for so many is
+ to allow flexibility. The File records take quite a lot of space in the
+ catalog, so they are typically records you want to remove rather
+ quickly. The Job records, take very little space, and they can be
+ useful even without the File records to see what Jobs actually ran and
+ when. One must understand that if the File records are removed from the
+ catalog, you cannot use the {\bf restore} command to restore an
+ individual file since Bacula no longer knows where it is. However, as
+ long as the Volume Retention period has not expired, the data will still
+ be on the tape, and can be recovered from the tape.
- For example, I keep a 30 day retention period for my Files to keep my
-catalog
- from getting too big, but I keep my tapes for a minimum of one year, just in
- case.
+ For example, I keep a 30 day retention period for my Files to keep my
+ catalog from getting too big, but I keep my tapes for a minimum of one
+ year, just in case.
\label{MaxVolumeSize}
\subsection*{MaxVolumeSize is ignored}
\item [Why Does Bacula Ignore the MaxVolumeSize Set in my Pool?]
- \index[general]{Why Does Bacula Ignore the MaxVolumeSize Set in my Pool? }
- The MaxVolumeSize that Bacula uses comes from the Media record, so most
- likely you changed your Pool, which is used as the default for creating
-Media
- records, {\bf after} you created your Volume. Check what is in the Media
- record by doing:
+\index[general]{MaxVolumeSize}
+ The MaxVolumeSize that Bacula uses comes from the Media record, so most
+ likely you changed your Pool, which is used as the default for creating
+ Media records, {\bf after} you created your Volume. Check what is in
+ the Media record by doing:
\footnotesize
\begin{verbatim}
\subsection*{I get a Connection refused when connecting to my Client}
\item [In connecting to my Client, I get "ERR:Connection Refused. Packet
Size too big from File daemon:192.168.1.4:9102" Why?]
- \index[general]{In connecting to my Client, I get "ERR:Connection
-Refused.
- Packet Size too big from File daemon:192.168.1.4:9102" Why? }
+\index[general]{ERR:Connection Refused}
This is typically a communications error resulting from one of the
-following:
+ following:
\begin{itemize}
\subsection*{Long running jobs die with Pipe Error}
\item [During long running jobs my File daemon dies with Pipe Error, or
some other communications error. Why?]
- \index[general]{Communications Errors}
- \index[general]{Pipe Errors}
+\index[general]{Communications Errors}
+\index[general]{Pipe Errors}
There are a number of reasons why a connection might break.
Most often, it is a router between your two computers that times out
inactive lines (not respecting the keepalive feature that Bacula uses).
\begin{description}
\item [Client (or FileDaemon)]
- \index[fd]{Client (or FileDaemon) }
+ \index[fd]{Client (or FileDaemon)}
+ \index[fd]{Directive!Client (or FileDaemon)}
Start of the Client records. There must be one and only one Client resource
in the configuration file, since it defines the properties of the current
client program.
\item [Name = \lt{}name\gt{}]
- \index[fd]{Name }
+ \index[fd]{Name}
+ \index[fd]{Directive!Name}
The client name that must be used by the Director when connecting. Generally,
it is a good idea to use a name related to the machine so that error messages
can be easily identified if you have multiple Clients. This directive is
required.
\item [Working Directory = \lt{}Directory\gt{}]
- \index[fd]{Working Directory }
+ \index[fd]{Working Directory}
+ \index[fd]{Directive!Working Directory}
This directive is mandatory and specifies a directory in which the File
daemon may put its status files. This directory should be used only by {\bf
Bacula}, but may be shared by other Bacula daemons provided the daemon
to the Storage daemon).
\item [Pid Directory = \lt{}Directory\gt{}]
- \index[fd]{Pid Directory }
+ \index[fd]{Pid Directory}
+ \index[fd]{Directive!Pid Directory}
This directive is mandatory and specifies a directory in which the Director
-may put its process Id file files. The process Id file is used to shutdown
-Bacula and to prevent multiple copies of Bacula from running simultaneously.
-This record is required. 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.
+ may put its process Id file files. The process Id file is used to shutdown
+ Bacula and to prevent multiple copies of Bacula from running simultaneously.
+ This record is required. 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.
+ 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.
\item [Heartbeat Interval = \lt{}time-interval\gt{}]
- \index[fd]{Heartbeat Interval }
+ \index[fd]{Heartbeat Interval}
+ \index[fd]{Directive!Heartbeat Interval}
\index[general]{Heartbeat Interval}
\index[general]{Broken pipe}
This record defines an interval of time. For each heartbeat that the
\item [Maximum Concurrent Jobs = \lt{}number\gt{}]
- \index[fd]{Maximum Concurrent Jobs }
+ \index[fd]{Maximum Concurrent Jobs}
+ \index[fd]{Directive!Maximum Concurrent Jobs}
where \lt{}number\gt{} is the maximum number of Jobs that should run
concurrently. The default is set to 2, but you may set it to a larger
number. Each contact from the Director (e.g. status request, job start
will need to set this value greater than 1.
\item [FDAddresses = \lt{}IP-address-specification\gt{}]
- \index[console]{FDAddresses }
+ \index[fd]{FDAddresses}
+ \index[fd]{Directive!FDAddresses}
Specify the ports and addresses on which the Director daemon will listen
for Bacula Console connections. Probably the simplest way to explain is
to show an example:
only IPv4 resolutions will be permitted, and likewise with ip6.
\item [FDPort = \lt{}port-number\gt{}]
- \index[console]{FDPort }
+ \index[fd]{FDPort}
+ \index[fd]{Directive!FDPort}
This specifies the port number on which the Client listens for Director
connections. It must agree with the FDPort specified in the Client resource
of the Director's configuration file. The default is 9102.
\item [FDAddress = \lt{}IP-Address\gt{}]
- \index[console]{FDAddress }
+ \index[fd]{FDAddress}
+ \index[fd]{Directive!FDAddress}
This record is optional, and if it is specified, it will cause the File
daemon server (for Director connections) to bind to the specified {\bf
IP-Address}, which is either a domain name or an IP address specified as a
to any available address (the default).
\item [SDConnectTimeout = \lt{}time-interval\gt{}]
- \index[console]{SDConnectTimeout }
+ \index[fd]{SDConnectTimeout}
+ \index[fd]{Directive!SDConnectTimeout}
This record defines an interval of time that the File daemon will try to
connect to the Storage daemon. The default is 30 minutes. If no connection
is made in the specified time interval, the File daemon cancels the Job.
\item [Maximum Network Buffer Size = \lt{}bytes\gt{}]
- \index[console]{Maximum Network Buffer Size }
+ \index[fd]{Maximum Network Buffer Size}
+ \index[fd]{Directive!Maximum Network Buffer Size}
where \lt{}bytes\gt{} specifies the initial network buffer size to use with
the File daemon. This size will be adjusted down if it is too large until it
is accepted by the OS. Please use care in setting this value since if it is
\begin{description}
\item [Director]
- \index[fd]{Director }
+ \index[fd]{Director}
+ \index[fd]{Directive!Director}
Start of the Director records. There may be any number of Director resources
in the Client configuration file. Each one specifies a Director that is
allowed to connect to this Client.
\item [Name = \lt{}name\gt{}]
- \index[fd]{Name }
+ \index[fd]{Name}
+ \index[fd]{Directive!Name}
The name of the Director that may contact this Client. This name must be the
same as the name specified on the Director resource in the Director's
configuration file. This record is required.
\item [Password = \lt{}password\gt{}]
- \index[fd]{Password }
+ \index[fd]{Password}
+ \index[fd]{Directive!Password}
Specifies the password that must be supplied for a Director to be authorized.
This password must be the same as the password specified in the Client
resource in the Director's configuration file. This record is required.
\item [Monitor = \lt{}yes|no\gt{}]
- \index[fd]{Monitor }
+ \index[fd]{Monitor}
+ \index[fd]{Directive!Monitor}
If Monitor is set to {\bf no} (default), this director will have full access
to this Client. If Monitor is set to {\bf yes}, this director will only be
able to fetch the current status of this Client.
-%%
+-%
%%
\subsection*{The FileSet Resource}
\label{FileSetResource}
-\index[general]{Resource!FileSet }
-\index[general]{FileSet Resource }
+\index[general]{Resource!FileSet}
+\index[general]{FileSet Resource}
\addcontentsline{toc}{subsection}{FileSet Resource}
The FileSet resource defines what files are to be included or excluded in a
\item [FileSet]
\index[dir]{FileSet}
+\index[dir]{Directive!FileSet}
Start of the FileSet resource. One {\bf FileSet} resource must be
defined for each Backup job.
\item [Name = \lt{}name\gt{}]
\index[dir]{Name}
+\index[dir]{Directive!Name}
The name of the FileSet resource. This directive is required.
\item [Ignore FileSet Changes = \lt{}yes|no\gt{}]
\index[dir]{Ignore FileSet Changes}
- If this directive is set to {\bf yes}, any changes you make to the FileSet
- Include or Exclude lists will be ignored and not cause Bacula to immediately
- perform a Full backup. The default is {\bf no}, in which case, if you change
- the Include or Exclude, Bacula will force a Full backup to ensure that
- everything is properly backed up. It is not recommended to set this directive
- to yes. This directive is available in Bacula version 1.35.4 or later.
+\index[dir]{Directive!Ignore FileSet Changes}
+ Normally, if you modify the FileSet Include or Exclude lists,
+ the next backup will be forced to a Full so that Bacula can
+ guarantee that any additions or deletions are properly backed
+ up.
+ If this directive is set to {\bf yes}, any changes you make to the
+ FileSet Include or Exclude lists will be ignored and not cause Bacula to
+ immediately perform a Full backup. The default is {\bf no}, in which
+ case, if you change the Include or Exclude, Bacula will force a Full
+ backup to ensure that everything is properly backed up. It is not
+ recommended to set this directive to yes.
\item [Enable VSS = \lt{}yes|no\gt{}]
\index[dir]{Enable VSS}
+\index[dir]{Directive!Enable VSS}
If this directive is set to {\bf yes} the File daemon will be notified
that the user wants to use a Volume Shadow Copy Service (VSS) backup
for this job. The default is {\bf no}. This directive is effective
\lt{}file-list\gt{} \} ]
\index[dir]{Include \{ [ Options \{\lt{}file-options\gt{}\} ...]
\lt{}file-list\gt{} \} }
+\index[dir]{Directive!Include}
\item [Options \{ \lt{}file-options\gt{} \} ]
\index[dir]{Options \{ \lt{}file-options\gt{} \} }
\item [Exclude \{ \lt{}file-list\gt{} \}]
\index[dir]{Exclude \{ \lt{}file-list\gt{} \} }
+\index[dir]{Directive!Exclude}
\end{description}
Note, see below for the definition of \lt{}file-list\gt{}.
The Include resource may also contain one or more Options resources that
specify options such as compression to be applied to all or any subset of
-the files found when processing the file-list for backup.
+the files found when processing the file-list for backup. Please see
+below for more details concerning Options resources.
There can be any number of {\bf Include} resources within the FileSet, each
having its own list of directories or files to be backed up and the backup
Multiple Options resources may be specified one after another. As the
files are found in the specified directories, the Options will applied to
the filenames to determine if and how the file should be backed up. The
-Options resources are applied in the order they are specified in the
-FileSet until the first one that matches.
+wildcard and regular expression pattern matching parts of the
+Options resources are checked in the order they are specified in the
+FileSet until the first one that matches. Once one matches, the
+compression and other flags within the Options specification will
+apply to the pattern matched.
A key point is that in the absence of an Option or no other Option is
matched, every file is accepted for backing up. This means that if
resources that may be present. This means that any wild cards must appear
before an Options resource without wild cards.
-If for some reason, Bacula applies all the Options resources to a file
-under consideration for backup, but there are no matches (generally because
-of wild cards that don't match), Bacula as a default will then backup the
-file. This is quite logical if you consider the case of no Options, where
-you want everything to be backed up, and it is important to keep in
-mind when excluding as mentioned above.
+If for some reason, Bacula checks all the Options resources to a file under
+consideration for backup, but there are no matches (generally because of wild
+cards that don't match), Bacula as a default will then backup the file. This
+is quite logical if you consider the case of no Options clause is specified,
+where you want everything to be backed up, and it is important to keep in mind
+when excluding as mentioned above.
-However, one additional point is that
-in the case that no match was found, Bacula will use the options found in
-the last Options resource. As a consequence, if you want a particular set
-of "default" options, you should put them in an Options resource after
-any other Options.
+However, one additional point is that in the case that no match was found,
+Bacula will use the options found in the last Options resource. As a
+consequence, if you want a particular set of "default" options, you should put
+them in an Options resource after any other Options.
It is a good idea to put all your wild-card and regex expressions inside
double quotes to prevent conf file scanning problems.
\begin{description}
\item [compression=GZIP]
-\index[fd]{compression }
- All files saved will be software compressed using the GNU ZIP compression
- format. The compression is done on a file by file basis by the File daemon.
- If there is a problem reading the tape in a single record of a file, it will
- at most affect that file and none of the other files on the tape. Normally
- this option is {\bf not} needed if you have a modern tape drive as the drive
- will do its own compression. In fact, if you specify software compression at
- the same time you have hardware compression turned on, your files may
- actually take more space on the volume.
-
- Software compression is very important if you are writing your Volumes to a
- file, and it can also be helpful if you have a fast computer but a slow
- network, otherwise it is generally better to rely your tape drive's hardware
- compression. As noted above, it is not generally a good idea to do both software
- and hardware compression.
-
- Specifying {\bf GZIP} uses the default compression level six (i.e. {\bf GZIP}
- is identical to {\bf GZIP6}). If you want a different compression level (1
- through 9), you can specify it by appending the level number with no
- intervening spaces to {\bf GZIP}. Thus {\bf compression=GZIP1} would give
- minimum compression but the fastest algorithm, and {\bf compression=GZIP9}
- would give the highest level of compression, but requires more computation.
- According to the GZIP documentation, compression levels greater than 6
- generally give very little extra compression and are rather CPU intensive.
+\index[dir]{compression}
+\index[dir]{Directive!compression}
+ All files saved will be software compressed using the GNU ZIP
+ compression format. The compression is done on a file by file basis by
+ the File daemon. If there is a problem reading the tape in a single
+ record of a file, it will at most affect that file and none of the other
+ files on the tape. Normally this option is {\bf not} needed if you have
+ a modern tape drive as the drive will do its own compression. In fact,
+ if you specify software compression at the same time you have hardware
+ compression turned on, your files may actually take more space on the
+ volume.
+
+ Software compression is very important if you are writing your Volumes
+ to a file, and it can also be helpful if you have a fast computer but a
+ slow network, otherwise it is generally better to rely your tape drive's
+ hardware compression. As noted above, it is not generally a good idea
+ to do both software and hardware compression.
+
+ Specifying {\bf GZIP} uses the default compression level six (i.e. {\bf
+ GZIP} is identical to {\bf GZIP6}). If you want a different compression
+ level (1 through 9), you can specify it by appending the level number
+ with no intervening spaces to {\bf GZIP}. Thus {\bf compression=GZIP1}
+ would give minimum compression but the fastest algorithm, and {\bf
+ compression=GZIP9} would give the highest level of compression, but
+ requires more computation. According to the GZIP documentation,
+ compression levels greater than 6 generally give very little extra
+ compression and are rather CPU intensive.
\item [signature=SHA1]
-\index[fd]{signature }
- An SHA1 signature will be computed for all The SHA1 algorithm is purported to
- be some what slower than the MD5 algorithm, but at the same time is
- significantly better from a cryptographic point of view (i.e. much fewer
- collisions, much lower probability of being hacked.) It adds four more bytes
- than the MD5 signature. We strongly recommend that either this option or MD5
- be specified as a default for all files. Note, only one of the two options
- MD5 or SHA1 can be computed for any file.
+\index[dir]{signature}
+\index[dir]{SHA1}
+\index[dir]{Directive!signature}
+ An SHA1 signature will be computed for all The SHA1 algorithm is
+ purported to be some what slower than the MD5 algorithm, but at the same
+ time is significantly better from a cryptographic point of view (i.e.
+ much fewer collisions, much lower probability of being hacked.) It adds
+ four more bytes than the MD5 signature. We strongly recommend that
+ either this option or MD5 be specified as a default for all files.
+ Note, only one of the two options MD5 or SHA1 can be computed for any
+ file.
\item [signature=MD5]
- \index[fd]{signature }
- An MD5 signature will be computed for all files saved. Adding this option
- generates about 5\% extra overhead for each file saved. In addition to the
- additional CPU time, the MD5 signature adds 16 more bytes per file to your
- catalog. We strongly recommend that this option or the SHA1 option be
- specified as a default for all files.
+\index[dir]{signature}
+\index[dir]{MD5}
+\index[dir]{Directive!signature}
+ An MD5 signature will be computed for all files saved. Adding this
+ option generates about 5\% extra overhead for each file saved. In
+ addition to the additional CPU time, the MD5 signature adds 16 more
+ bytes per file to your catalog. We strongly recommend that this option
+ or the SHA1 option be specified as a default for all files.
\item [verify=\lt{}options\gt{}]
-\index[fd]{verify }
+\index[dir]{verify}
+\index[dir]{Directive!verify}
The options letters specified are used when running a {\bf Verify
Level=Catalog} as well as the {\bf DiskToCatalog} level job. The options
letters may be any combination of the following:
inodes, number of links, size, and MD5 changes.
\item [onefs=yes|no]
-\index[fd]{onefs}
- If set to {\bf yes} (the default), {\bf Bacula} will remain on a single file
- system. That is it will not backup file systems that are mounted on a
- subdirectory. If you are using a *nix system, you may not even be aware
- that there are several different filesystems as they are often
- automatically mounted by the OS (e.g. /dev, /net, /sys, /proc, ...).
- With Bacula 1.38.0 or later, it will inform you when it decides not
- to traverse into another filesystem. This can be very useful if you
- forgot to backup a particular partition. An example of the
- informational message in the job report is:
+\index[dir]{onefs}
+\index[dir]{Directive!onefs}
+ If set to {\bf yes} (the default), {\bf Bacula} will remain on a single
+ file system. That is it will not backup file systems that are mounted
+ on a subdirectory. If you are using a *nix system, you may not even be
+ aware that there are several different filesystems as they are often
+ automatically mounted by the OS (e.g. /dev, /net, /sys, /proc, ...).
+ With Bacula 1.38.0 or later, it will inform you when it decides not to
+ traverse into another filesystem. This can be very useful if you forgot
+ to backup a particular partition. An example of the informational
+ message in the job report is:
\footnotesize
\begin{verbatim}
also be backed up. Normally, it is preferable to set {\bf onefs=yes} and to
explicitly name each filesystem you want backed up. Explicitly naming the
filesystems you want backed up avoids the possibility of getting into a
- infinite loop recursing filesystems. Another possiblity is to
+ infinite loop recursing filesystems. Another possibility is to
use {\bf onefs=no} and to set {\bs fstype=ext2, ...}.
See the example below for more details.
\label{portable}
\item [portable=yes|no]
-\index[dir]{portable }
- If set to {\bf yes} (default is {\bf no}), the Bacula File daemon will backup
- Win32 files in a portable format, but not all Win32 file attributes will be
- saved and restored. By default, this option is set to {\bf no}, which means
- that on Win32 systems, the data will be backed up using Windows API calls and
- on WinNT/2K/XP, all the security and ownership attributes will be properly
- backed up (and restored). However this format is not portable to other
- systems -- e.g. Unix, Win95/98/Me. When backing up Unix systems, this option
- is ignored, and unless you have a specific need to have portable backups, we
- recommend accept the default ({\bf no}) so that the maximum information
- concerning your files is saved.
+\index[dir]{portable}
+\index[dir]{Directive!portable}
+ If set to {\bf yes} (default is {\bf no}), the Bacula File daemon will
+ backup Win32 files in a portable format, but not all Win32 file
+ attributes will be saved and restored. By default, this option is set
+ to {\bf no}, which means that on Win32 systems, the data will be backed
+ up using Windows API calls and on WinNT/2K/XP, all the security and
+ ownership attributes will be properly backed up (and restored). However
+ this format is not portable to other systems -- e.g. Unix, Win95/98/Me.
+ When backing up Unix systems, this option is ignored, and unless you
+ have a specific need to have portable backups, we recommend accept the
+ default ({\bf no}) so that the maximum information concerning your files
+ is saved.
\item [recurse=yes|no]
-\index[fd]{recurse }
- If set to {\bf yes} (the default), Bacula will recurse (or descend) into all
- subdirectories found unless the directory is explicitly excluded using an
- {\bf exclude} definition. If you set {\bf recurse=no}, Bacula will save the
- subdirectory entries, but not descend into the subdirectories, and thus will
- not save the files or directories contained in the subdirectories. Normally,
- you will want the default ({\bf yes}).
+\index[dir]{recurse}
+\index[dir]{Directive!recurse}
+ If set to {\bf yes} (the default), Bacula will recurse (or descend) into
+ all subdirectories found unless the directory is explicitly excluded
+ using an {\bf exclude} definition. If you set {\bf recurse=no}, Bacula
+ will save the subdirectory entries, but not descend into the
+ subdirectories, and thus will not save the files or directories
+ contained in the subdirectories. Normally, you will want the default
+ ({\bf yes}).
\item [sparse=yes|no]
-\index[dir]{sparse }
+\index[dir]{sparse}
+\index[dir]{Directive!sparse}
Enable special code that checks for sparse files such as created by
ndbm. The default is {\bf no}, so no checks are made for sparse files.
You may specify {\bf sparse=yes} even on files that are not sparse file.
\label{readfifo}
\item [readfifo=yes|no]
-\index[fd]{readfifo }
+\index[dir]{readfifo}
+\index[dir]{Directive!readfifo}
If enabled, tells the Client to read the data on a backup and write the
data on a restore to any FIFO (pipe) that is explicitly mentioned in the
FileSet. In this case, you must have a program already running that
\item [mtimeonly=yes|no]
-\index[dir]{mtimeonly }
+\index[dir]{mtimeonly}
+\index[dir]{Directive!mtimeonly}
If enabled, tells the Client that the selection of files during
Incremental and Differential backups should based only on the st\_mtime
value in the stat() packet. The default is {\bf no} which means that
to use this option.
\item [keepatime=yes|no]
-\index[dir]{keepatime }
+\index[dir]{keepatime}
+\index[dir]{Directive!keepatime}
The default is {\bf no}. When enabled, Bacula will reset the st\_atime
(access time) field of files that it backs up to their value prior to
the backup. This option is not generally recommended as there are very
\item [hardlinks=yes|no]
\index[dir]{hardlinks}
+\index[dir]{Directive!hardlinks}
When enabled (default), this directive will cause hard inks to be
backed up. However, the File daemon keeps track of hard linked files and
will backup the data only once. The process of keeping track of the
system will not be restored identically to the original.
\item [wild=\lt{}string\gt{}]
-\index[dir]{wild }
+\index[dir]{wild}
+\index[dir]{Directive!wild}
Specifies a wild-card string to be applied to the filenames and
directory names. Note, if {\bf Exclude} is not enabled, the wild-card
will select which files are to be included. If {\bf Exclude=yes} is
Multiple wild-card directives may be specified, and they will be applied
in turn until the first one that matches. Note, if you exclude a
directory, no files or directories below it will be matched.
- It is recommended to enclose the string in double quotes.
-\item [wildfile=\lt{}string\gt{}]
-\index[dir]{wildfile }
- Specifies a wild-card string to be applied to filenames only. No
- directories will be matched by this directive. Note, if {\bf Exclude}
- is not enabled, the wild-card will select which files are to be
- included. If {\bf Exclude=yes} is specified, the wild-card will select
- which files are to be excluded. Multiple wild-card directives may be
- specified, and they will be applied in turn until the first one that
- matches.
+ You may want to test your expressions prior to running your
+ backup by using the bwild program. Please see the
+ \ilink{UtilitiesChapter}{Utilities} chapter of this manual for
+ more. You can also test your full FileSet definition by using
+ the \ilink{estimate}{Estimate} command in the Console
+ chapter of this manual.
It is recommended to enclose the string in double quotes.
- An example of excluding with the WildFile option on Win32 machines is
- presented below.
\item [wilddir=\lt{}string\gt{}]
-\index[dir]{wilddir }
+\index[dir]{wilddir}
+\index[dir]{Directive!wilddir}
Specifies a wild-card string to be applied to directory names only. No
filenames will be matched by this directive. Note, if {\bf Exclude} is
not enabled, the wild-card will select directories files are to be
specified, and they will be applied in turn until the first one that
matches. Note, if you exclude a directory, no files or directories
below it will be matched.
+
It is recommended to enclose the string in double quotes.
+
+ You may want to test your expressions prior to running your
+ backup by using the bwild program. Please see the
+ \ilink{UtilitiesChapter}{Utilities} chapter of this manual for
+ more. You can also test your full FileSet definition by using
+ the \ilink{estimate}{Estimate} command in the Console
+ chapter of this manual.
An example of excluding with the WildDir option on Win32 machines is
presented below.
+\item [wildfile=\lt{}string\gt{}]
+\index[dir]{wildfile}
+\index[dir]{Directive!wildfile}
+ Specifies a wild-card string to be applied to non-directories. That
+ is no directory entries will be matched by this directive.
+ However, note that the match is done against the full path and filename,
+ so your wild-card string must take into account that filenames
+ are preceded by the full path.
+ If {\bf Exclude}
+ is not enabled, the wild-card will select which files are to be
+ included. If {\bf Exclude=yes} is specified, the wild-card will select
+ which files are to be excluded. Multiple wild-card directives may be
+ specified, and they will be applied in turn until the first one that
+ matches.
+
+ It is recommended to enclose the string in double quotes.
+
+ You may want to test your expressions prior to running your
+ backup by using the bwild program. Please see the
+ \ilink{UtilitiesChapter}{Utilities} chapter of this manual for
+ more. You can also test your full FileSet definition by using
+ the \ilink{estimate}{Estimate} command in the Console
+ chapter of this manual.
+ An example of excluding with the WildFile option on Win32 machines is
+ presented below.
+
\item [regex=\lt{}string\gt{}]
-\index[dir]{regex }
+\index[dir]{regex}
+\index[dir]{Directive!regex}
Specifies a POSIX extended regular expression to be applied to the
- filenames and directory names.
- This directive is available in version 1.35 and later. If {\bf
+ filenames and directory names, which include the full path. If {\bf
Exclude} is not enabled, the regex will select which files are to be
included. If {\bf Exclude=yes} is specified, the regex will select
which files are to be excluded. Multiple regex directives may be
specified within an Options resource, and they will be applied in turn
- until the first one that matches. Note, if you exclude a
- directory, no files or directories below it will be matched.
+ until the first one that matches. Note, if you exclude a directory, no
+ files or directories below it will be matched.
+
It is recommended to enclose the string in double quotes.
+ The regex libraries differ from one operating system to
+ another, and in addition, regular expressions are complicated,
+ so you may want to test your expressions prior to running your
+ backup by using the bregex program. Please see the
+ \ilink{UtilitiesChapter}{Utilities} chapter of this manual for
+ more. You can also test your full FileSet definition by using
+ the \ilink{estimate}{Estimate} command in the Console
+ chapter of this manual.
+
+
\item [regexfile=\lt{}string\gt{}]
-\index[dir]{regexfile }
- Specifies a POSIX extended regular expression to be applied to filenames
- only. No directories will be matched by this directive. Note, if {\bf
- Exclude} is not enabled, the regex will select which files are to be
- included. If {\bf Exclude=yes} is specified, the regex will select
- which files are to be excluded. Multiple regex directives may be
+\index[dir]{regexfile}
+\index[dir]{Directive!regexfile}
+ Specifies a POSIX extended regular expression to be applied to
+ non-directories. No directories will be matched by this directive.
+ However, note that the match is done against the full path and
+ filename, so your regex string must take into account that filenames
+ are preceded by the full path.
+ If {\bf Exclude} is not enabled, the regex will select which files are
+ to be included. If {\bf Exclude=yes} is specified, the regex will
+ select which files are to be excluded. Multiple regex directives may be
specified, and they will be applied in turn until the first one that
matches.
+
It is recommended to enclose the string in double quotes.
+ The regex libraries differ from one operating system to
+ another, and in addition, regular expressions are complicated,
+ so you may want to test your expressions prior to running your
+ backup by using the bregex program. Please see the
+ \ilink{UtilitiesChapter}{Utilities} chapter of this manual for
+ more.
+
+
\item [regexdir=\lt{}string\gt{}]
-\index[dir]{regexdir }
+\index[dir]{regexdir}
+\index[dir]{Directive!regexdir}
Specifies a POSIX extended regular expression to be applied to directory
names only. No filenames will be matched by this directive. Note, if
{\bf Exclude} is not enabled, the regex will select directories
regex directives may be specified, and they will be applied in turn
until the first one that matches. Note, if you exclude a directory, no
files or directories below it will be matched.
+
It is recommended to enclose the string in double quotes.
+ The regex libraries differ from one operating system to
+ another, and in addition, regular expressions are complicated,
+ so you may want to test your expressions prior to running your
+ backup by using the bregex program. Please see the
+ \ilink{UtilitiesChapter}{Utilities} chapter of this manual for
+ more.
+
+
\item [exclude=yes|no]
-\index[dir]{exclude }
- The default is {\bf no}. When enabled, any files matched within the Options
- will be excluded from the backup.
+\index[dir]{exclude}
+\index[dir]{Directive!exclude}
+ The default is {\bf no}. When enabled, any files matched within the
+ Options will be excluded from the backup.
\label{ACLSupport}
\item [aclsupport=yes|no]
-\index[dir]{aclsupport }
+\index[dir]{aclsupport}
+\index[dir]{Directive!aclsupport}
The default is {\bf no}. If this option is set to yes, and you have the
POSIX {\bf libacl} installed on your system, Bacula will backup the file
and directory UNIX Access Control Lists (ACL) as defined in IEEE Std
(perhaps reiserfs) that does not have ACLs, the ACLs will be ignored.
\item [ignore case=yes|no]
-\index[dir]{ignore case }
- The default is {\bf no}, except on Windows systems where the default
- is {\bf yes}. When this directive is set to {\bf yes} all the case
- of character will be ignored in wild-card and regex comparisons.
- That is an uppercase A will match a lowercase a.
+\index[dir]{ignore case}
+\index[dir]{Directive!ignore case}
+ The default is {\bf no}. On Windows systems, you will almost surely
+ want to set this to {\bf yes}. When this directive is set to {\bf yes}
+ all the case of character will be ignored in wild-card and regex
+ comparisons. That is an uppercase A will match a lowercase a.
\item [fstype=filesystem-type]
-\index[dir]{fstype }
+\index[dir]{fstype}
+\index[dir]{Directive!fstype}
This option allows you to select files and directories by the
filesystem type. The permitted filesystem-type names are:
\item [hfsplussupport=yes|no]
-\index[dir]{hfsplussupport }
+\index[dir]{hfsplussupport}
+\index[dir]{Directive!hfsplussupport}
This option allows you to turn on support for Mac OSX HFS plus
finder information.
{\bf \lt{}file-list\gt{}} is a list of directory and/or filename names
specified with a {\bf File =} directive. To include names containing spaces,
-enclose the name between double-quotes.
+enclose the name between double-quotes. Wild-cards are not interpreted
+in file-lists. They can only be specified in Options resources.
There are a number of special cases when specifying directories and files in a
{\bf file-list}. They are:
you must ensure that there is a reader program or Bacula will block, and
after one minute, Bacula will time out the write to the fifo and move on
to the next file.
+
+\item A file-list may not contain wild-cards. Use directives in the
+ Options resource if you wish to specify wild-cards or regular expression
+ matching.
\end{itemize}
\subsubsection*{FileSet Examples}
Options {
wilddir = /proc
wilddir = /tmp
- wildfile = ".journal"
- wildfile = ".autofsck"
+ wildfile = "/.journal"
+ wildfile = "/.autofsck"
exclude = yes
}
File = /
be backed up too (i.e. that is the default rule).
To accomplish what we want, we must explicitly exclude all other files.
-We do this with the fillowing:
+We do this with the following:
\footnotesize
\begin{verbatim}
}
Options {
Exclude = yes
- RegexFile = "^.?*$"
+ RegexFile = ".*"
}
File = /myfile
}
The problem is that the above will include everything in /home. To get
things to work correctly, you need to start with the idea of exclusion
instead of inclusion. So, you could simply exclude all directories
-except the two you want using:
+except the two you want to use:
\footnotesize
\begin{verbatim}
FileSet {
wilddir = "/home/b*"
}
Options {
- RegexDir = "^.?*$"
+ RegexDir = ".*"
exclude = yes
}
File = /home
\end{verbatim}
\normalsize
-I haven't actually tried the above two examples, so you may need to
-tweak them to get them to work right.
-
-
\subsubsection*{Backing up Raw Partitions}
\index[general]{Backing up!Partitions }
\index[general]{Backing up Raw Partitions }
\normalsize
\label{win32}
-
\subsubsection*{Windows FileSets}
\index[general]{Windows FileSets }
\index[general]{FileSets!Windows }
\begin{itemize}
\item Filenames are case sensitive, so you must use the correct case.
-\item To exclude a directory, you must not have a trailing slash on the
+\item To 2~exclude a directory, you must not have a trailing slash on the
directory name.
-\item If you have spaces in your filename, you must enclose the entire name
+\item I2~f you have spaces in your filename, you must enclose the entire name
in double-quote characters ("). Trying to use a backslash before the space
will not work.
-\item If you are using the old Exclude syntax (noted below), you may not
- specify a drive letter in the exclude. The new syntax noted above should work
- fine including driver letters.
+\item If you are using the old Exclude syntax (noted below), you may not
+ specify a drive letter in the exclude. The new syntax noted above
+ should work fine including driver letters.
\end{itemize}
Thanks to Thiago Lima for summarizing the above items for us. If you are
exclusion rules will work correctly, you can test it by using the {\bf
estimate} command in the Console program. See the
\ilink{estimate command}{estimate} in the Console chapter of this
-manual.
+manual.
+
+As an example, suppose you add the following test FileSet:
+
+\footnotesize
+\begin{verbatim}
+FileSet {
+ Name = Test
+ Include {
+ File = /home/xxx/test
+ Options {
+ regex = ".*\.c$"
+ }
+ }
+}
+\end{verbatim}
+\normalsize
+
+You could then add some test files to the directory {\bf /home/xxx/test}
+and use the following command in the console:
+
+\footnotesize
+\begin{verbatim}
+estimate job=<any-job-name> listing client=<desired-client> fileset=Test
+\end{verbatim}
+\normalsize
+
+to give you a listing of all files that match.
continue on.
\item make
+\begin{verbatim}
+
+\end{verbatim}
If you get errors while linking in the Storage daemon directory
(src/stored), it is probably because you have not loaded the static
libraries on your system. I noticed this problem on a Solaris system.
To correct it, make sure that you have not added {\bf
{-}{-}enable-static-tools} to the {\bf ./configure} command.
+ If you skip this step ({\bf make}) and proceed immediately to the {\bf
+ make install} you are making two serious errors: 1. your install will
+ fail because Bacula requires a {\bf make} before a {\bf make install}.
+ 2. you are depriving yourself of the chance to make sure there are no
+ errors before beginning to write files to your system directories.
+
+
\item make install
+
\item If you are new to Bacula, we {\bf strongly} recommend that you skip
the next step and use the default configuration files, then run the
can be done after you have Bacula up and running. Please take care when
modifying passwords, which were randomly generated, and the {\bf Name}s
as the passwords and names must agree between the configuration files
- for security reasons. \item Create the Bacula MySQL database and tables
+ for security reasons.
+
+\item Create the Bacula MySQL database and tables
(if using MySQL)
\ilink{Installing and Configuring MySQL Phase II}{mysql_phase2} or
create the Bacula PostgreSQL database and tables
heavy modifications to the configuration files so that you are sure that
Bacula works and are familiar with it. After that changing the conf files
will be easier.
+
\item If after installing Bacula, you decide to "move it", that is to
install it in a different set of directories, proceed as follows:
\item [ {-}{-}with-dir-user=\lt{}User\gt{} ]
\index[general]{{-}{-}with-dir-user }
- This option allows you to specify the Userid used to run the Director. The
- Director must be started as root, but doesn't need to run as root, and after
- doing preliminary initializations, it can "drop" to the UserId specified on
- this option.
+ This option allows you to specify the Userid used to run the Director. The
+ Director must be started as root, but doesn't need to run as root, and
+ after doing preliminary initializations, it can "drop" to the UserId
+ specified on this option.
+ If you specify this option, you must
+ create the User prior to running {\bf make install}, because the
+ working directory owner will be set to {\bf User}.
+
\item [ {-}{-}with-dir-group=\lt{}Group\gt{} ]
\index[general]{{-}{-}with-dir-group }
Director must be started as root, but doesn't need to run as root, and after
doing preliminary initializations, it can "drop" to the GroupId specified
on this option.
+ If you specify this option, you must
+ create the Group prior to running {\bf make install}, because the
+ working directory group will be set to {\bf Group}.
\item [ {-}{-}with-sd-user=\lt{}User\gt{} ]
\index[general]{{-}{-}with-sd-user }
\normalsize
Also, I had an authorization problem with the password. In the end,
-I had to modify my {\bf pg_hba.conf} file (in /var/lib/pgsql on my machine)
+I had to modify my {\bf pg_hba.conf} file (in /var/lib/pgsql/data on my machine)
from:
\footnotesize
\begin{verbatim}
- local all all ident
+ local all all ident sameuser
to
- local all all trust
+ local all all trust sameuser
\end{verbatim}
\normalsize
\footnotesize
\begin{verbatim}
- mysqldump -f -t -n >bacula-backup.dmp>
+ mysqldump -f -t -n >bacula-backup.dmp
\end{verbatim}
\normalsize
%%
\section*{Volume Utility Tools}
-\label{_ChapterStart9}
-\index[general]{Volume Utility Tools }
-\index[general]{Tools!Volume Utility }
+\label{_UtilityChapter}
+\index[general]{Volume Utility Tools}
+\index[general]{Tools!Volume Utility}
\addcontentsline{toc}{section}{Volume Utility Tools}
This document describes the utility programs written to aid Bacula users and
developers in dealing with Volumes external to Bacula.
\subsection*{Specifying the Configuration File}
-\index[general]{Specifying the Configuration File }
+\index[general]{Specifying the Configuration File}
\addcontentsline{toc}{subsection}{Specifying the Configuration File}
Starting with version 1.27, each of the following programs requires a valid
\subsection*{Specifying a Device Name For a Tape}
-\index[general]{Tape!Specifying a Device Name For a }
-\index[general]{Specifying a Device Name For a Tape }
+\index[general]{Tape!Specifying a Device Name For a}
+\index[general]{Specifying a Device Name For a Tape}
\addcontentsline{toc}{subsection}{Specifying a Device Name For a Tape}
Each of these programs require a {\bf device-name} where the Volume can be
\subsection*{Specifying a Device Name For a File}
-\index[general]{File!Specifying a Device Name For a }
-\index[general]{Specifying a Device Name For a File }
+\index[general]{File!Specifying a Device Name For a}
+\index[general]{Specifying a Device Name For a File}
\addcontentsline{toc}{subsection}{Specifying a Device Name For a File}
If you are attempting to read or write an archive file rather than a tape, the
\subsection*{Specifying Volumes}
-\index[general]{Volumes!Specifying }
-\index[general]{Specifying Volumes }
+\index[general]{Volumes!Specifying}
+\index[general]{Specifying Volumes}
\addcontentsline{toc}{subsection}{Specifying Volumes}
In general, you must specify the Volume name to each of the programs below
\subsection*{bls}
\label{bls}
-\index[general]{bls }
+\index[general]{bls}
+\index[general]{program!bls}
\addcontentsline{toc}{subsection}{bls}
{\bf bls} can be used to do an {\bf ls} type listing of a {\bf Bacula} tape or
\normalsize
\subsubsection*{Listing Jobs}
-\index[general]{Listing Jobs with bls }
-\index[general]{bls!Listing Jobs }
+\index[general]{Listing Jobs with bls}
+\index[general]{bls!Listing Jobs}
\addcontentsline{toc}{subsubsection}{bls Listing Jobs}
If you are listing a Volume to determine what Jobs to restore, normally the
available for each record:
\subsubsection*{Listing Blocks}
-\index[general]{Listing Blocks with bls }
-\index[general]{bls!Listing Blocks }
+\index[general]{Listing Blocks with bls}
+\index[general]{bls!Listing Blocks}
\addcontentsline{toc}{subsubsection}{bls Listing Blocks}
Normally, except for debugging purposes, you will not need to list Bacula
\subsection*{bextract}
\label{bextract}
-\index[general]{Bextract }
+\index[general]{Bextract}
+\index[general]{program!bextract}
\addcontentsline{toc}{subsection}{bextract}
Normally, you will restore files by running a {\bf Restore} Job from the {\bf
drive.
\subsubsection*{Extracting with Include or Exclude Lists}
-\index[general]{Lists!Extracting with Include or Exclude }
-\index[general]{Extracting with Include or Exclude Lists }
+\index[general]{Lists!Extracting with Include or Exclude}
+\index[general]{Extracting with Include or Exclude Lists}
\addcontentsline{toc}{subsubsection}{Extracting with Include or Exclude Lists}
Using the {\bf -e} option, you can specify a file containing a list of files
/tmp/usr/local/bin/...).
\subsubsection*{Extracting With a Bootstrap File}
-\index[general]{File!Extracting With a Bootstrap }
-\index[general]{Extracting With a Bootstrap File }
+\index[general]{File!Extracting With a Bootstrap}
+\index[general]{Extracting With a Bootstrap File}
\addcontentsline{toc}{subsubsection}{Extracting With a Bootstrap File}
The {\bf -b} option is used to specify a {\bf bootstrap} file containing the
exclude lists.
\subsubsection*{Extracting From Multiple Volumes}
-\index[general]{Volumes!Extracting From Multiple }
-\index[general]{Extracting From Multiple Volumes }
+\index[general]{Volumes!Extracting From Multiple}
+\index[general]{Extracting From Multiple Volumes}
\addcontentsline{toc}{subsubsection}{Extracting From Multiple Volumes}
If you wish to extract files that span several Volumes, you can specify the
\subsection*{bscan}
\label{bscan}
-\index[general]{bscan }
+\index[general]{bscan}
+\index[general]{program!bscan}
\addcontentsline{toc}{subsection}{bscan}
The {\bf bscan} program can be used to re-create a database (catalog) from the
normal Bacula console commands.
\subsubsection*{Using bscan to Compare a Volume to an existing Catalog}
-\index[general]{Catalog!Using bscan to Compare a Volume to an existing }
-\index[general]{Using bscan to Compare a Volume to an existing Catalog }
+\index[general]{Catalog!Using bscan to Compare a Volume to an existing}
+\index[general]{Using bscan to Compare a Volume to an existing Catalog}
\addcontentsline{toc}{subsubsection}{Using bscan to Compare a Volume to an
existing Catalog}
testing.
\subsubsection*{Using bscan to Recreate a Catalog from a Volume}
-\index[general]{Volume!Using bscan to Recreate a Catalog from a }
-\index[general]{Using bscan to Recreate a Catalog from a Volume }
+\index[general]{Volume!Using bscan to Recreate a Catalog from a}
+\index[general]{Using bscan to Recreate a Catalog from a Volume}
\addcontentsline{toc}{subsubsection}{Using bscan to Recreate a Catalog from a
Volume}
If there is more than one volume, simply append it to the first one separating
it with a vertical bar. You may need to precede the vertical bar with a
forward slash escape the shell -- e.g. {\bf
-TestVolume1\textbackslash{}|TestVolume2 }. The {\bf -v} option was added for
+TestVolume1\textbackslash{}|TestVolume2}. The {\bf -v} option was added for
verbose output (this can be omitted if desired). The {\bf -s} option that
tells {\bf bscan} to store information in the database. The physical device
name {\bf /dev/nst0} is specified after all the options.
-{\bf } For example, after having done a full backup of a directory, then two
+{\bf} For example, after having done a full backup of a directory, then two
incrementals, I reinitialized the SQLite database as described above, and
using the bootstrap.bsr file noted above, I entered the following command:
against it and get valid results.
\subsubsection*{Using bscan to Correct the Volume File Count}
-\index[general]{Using bscan to Correct the Volume File Count }
-\index[general]{Count!Using bscan to Correct the Volume File }
+\index[general]{Using bscan to Correct the Volume File Count}
+\index[general]{Count!Using bscan to Correct the Volume File}
\addcontentsline{toc}{subsubsection}{Using bscan to Correct the Volume File
Count}
update only the final Media record for the Volumes read.
\subsubsection*{After bscan}
-\index[general]{After bscan }
-\index[general]{Bscan!After }
+\index[general]{After bscan}
+\index[general]{Bscan!After}
\addcontentsline{toc}{subsubsection}{After bscan}
If you use {\bf bscan} to enter the contents of the Volume into an existing
\subsection*{bcopy}
\label{bcopy}
-\index[general]{Bcopy }
+\index[general]{Bcopy}
+\index[general]{program!bcopy}
\addcontentsline{toc}{subsection}{bcopy}
The {\bf bcopy} program can be used to copy one {\bf Bacula} archive file to
command, for example, you must first bscan the new Volume into the catalog.
\subsubsection*{bcopy Command Options}
-\index[general]{Options!bcopy Command }
-\index[general]{Bcopy Command Options }
+\index[general]{Options!bcopy Command}
+\index[general]{Bcopy Command Options}
\addcontentsline{toc}{subsubsection}{bcopy Command Options}
\footnotesize
\subsection*{btape}
\label{btape}
-\index[general]{Btape }
+\index[general]{Btape}
+\index[general]{program!btape}
\addcontentsline{toc}{subsection}{btape}
This program permits a number of elementary tape operations via a tty command
\footnotesize
\begin{verbatim}
-Usage: btape [-c config_file] [-d debug_level] [device_name]
+Usage: btape <options> <device_name>
+ -b <file> specify bootstrap file
-c <file> set configuration file to file
- -dnn set debug level to nn
+ -d <nn> set debug level to nn
+ -p proceed inspite of I/O errors
-s turn off signals
- -t open the default tape device
+ -v be verbose
-? print this message.
\end{verbatim}
\normalsize
\subsubsection*{Using btape to Verify your Tape Drive}
-\index[general]{Using btape to Verify your Tape Drive }
-\index[general]{Drive!Using btape to Verify your Tape }
+\index[general]{Using btape to Verify your Tape Drive}
+\index[general]{Drive!Using btape to Verify your Tape}
\addcontentsline{toc}{subsubsection}{Using btape to Verify your Tape Drive}
An important reason for this program is to ensure that a Storage daemon
the details.
\subsubsection*{btape Commands}
-\index[general]{Btape Commands }
-\index[general]{Commands!btape }
+\index[general]{Btape Commands}
+\index[general]{Commands!btape}
\addcontentsline{toc}{subsubsection}{btape Commands}
The full list of commands are:
\begin{verbatim}
Command Description
======= ===========
+ autochanger test autochanger
bsf backspace file
bsr backspace record
+ bfill fill tape using Bacula writes
cap list device capabilities
clear clear tape errors
eod go to end of Bacula data for append
- test General test Bacula tape functions
eom go to the physical end of medium
fill fill tape, write onto second volume
unfill read filled tape
label write a Bacula label to the tape
load load a tape
quit quit btape
- rd read tape
+ rawfill use write() to fill tape
readlabel read and print the Bacula tape label
rectest test record handling functions
rewind rewind the tape
- scan read tape block by block to EOT and report
+ scan read() tape block by block to EOT and report
+ scanblocks Bacula read block by block to EOT and report
status print tape status
- test test a tape for compatibility with Bacula
+ test General test Bacula tape functions
weof write an EOF on the tape
- wr write a single record of 2048 bytes
+ wr write a single Bacula block
+ rr read a single record
+ qfill quick fill command
\end{verbatim}
\normalsize
the {\bf Console} program since it will never overwrite a valid Bacula tape.
\subsection*{Other Programs}
-\index[general]{Programs!Other }
-\index[general]{Other Programs }
+\index[general]{Programs!Other}
+\index[general]{Other Programs}
\addcontentsline{toc}{subsection}{Other Programs}
The following programs are general utility programs and in general do not need
\subsection*{bsmtp}
\label{bsmtp}
-\index[general]{Bsmtp }
+\index[general]{Bsmtp}
+\index[general]{program!bsmtp}
\addcontentsline{toc}{subsection}{bsmtp}
{\bf bsmtp} is a simple mail transport program that permits more flexibility
When running {\bf bsmtp} by hand, you will need to terminate the message by
entering a ctl-d in column 1 of the last line.
+If you are getting incorrect dates (e.g. 1970) and you are
+running with a non-English language setting, you might try adding
+a LANG="en_US" immediately before the bsmtp call.
+
\subsection*{dbcheck}
\label{dbcheck}
-\index[general]{Dbcheck }
+\index[general]{Dbcheck}
+\index[general]{program!dbcheck}
\addcontentsline{toc}{subsection}{dbcheck}
{\bf dbcheck} is a simple program that will search for logical
recommendations given above, which are given so that users don't
waste their time running dbcheck too often.
+\subsection*{bregex}
+\label{regex}
+\index[general]{bregex}
+\index[general]{program!bregex}
+\addcontentsline{toc}{subsection}{bregex}
+
+{\bf bregex} is a simple program that will allow you to test
+regular expressions against a file of data. This can be useful
+because the regex libraries on most systems differ, and in
+addition, regex expressions can be complicated.
+
+{\bf bregex} is found in the src/tools directory and it is
+normally installed with your system binaries. To run it, use:
+
+\begin{verbatim}
+Usage: bregex [-d debug_level] -f <data-file>
+ -f specify file of data to be matched
+ -l suppress line numbers
+ -n print lines that do not match
+ -? print this message.
+\end{verbatim}
+
+The \lt{}data-file\gt{} is a filename that contains lines
+of data to be matched (or not) against one or more patterns.
+When the program is run, it will prompt you for a regular
+expression pattern, then apply it one line at a time against
+the data in the file. Each line that matches will be printed
+preceded by its line number. You will then be prompted again
+for another pattern.
+
+Enter an empty line for a pattern to terminate the program. You
+can print only lines that do not match by using the -n option,
+and you can suppress printing of line numbers with the -l option.
+
+This program can be useful for testing regex expressions to be
+applied against a list of filenames.
+
+\subsection*{bwild}
+\label{wild}
+\index[general]{bwild}
+\index[general]{program!bwild}
+\addcontentsline{toc}{subsection}{bwild}
+
+{\bf bwild} is a simple program that will allow you to test
+wild-card expressions against a file of data.
+
+{\bf bwild} is found in the src/tools directory and it is
+normally installed with your system binaries. To run it, use:
+
+\begin{verbatim}
+Usage: bwild [-d debug_level] -f <data-file>
+ -f specify file of data to be matched
+ -l suppress line numbers
+ -n print lines that do not match
+ -? print this message.
+\end{verbatim}
+
+The \lt{}data-file\gt{} is a filename that contains lines
+of data to be matched (or not) against one or more patterns.
+When the program is run, it will prompt you for a wild-card
+pattern, then apply it one line at a time against
+the data in the file. Each line that matches will be printed
+preceded by its line number. You will then be prompted again
+for another pattern.
+
+Enter an empty line for a pattern to terminate the program. You
+can print only lines that do not match by using the -n option,
+and you can suppress printing of line numbers with the -l option.
+
+This program can be useful for testing wild expressions to be
+applied against a list of filenames.
+
\subsection*{testfind}
\label{testfind}
-\index[general]{Testfind }
+\index[general]{Testfind}
+\index[general]{program!testfind}
\addcontentsline{toc}{subsection}{testfind}
{\bf testfind} permits listing of files using the same search engine that is
a number of methods (subroutines) that can be called. They
are:
\begin{description}
-\item [set\_events] The set\_events takes a single
+\item [set\_events] The set\_events method takes a single
argument, which is the instantation of the Job Events class
that contains the methods that you want called. The method
names that will be called must correspond to the Bacula
started, or -1 if there was an error.
\item [write] The write method is used to be able to send
print output to the Job Report. This will be described later.
-\item [DoesVolumeExist] The DoesVolumeExist takes a single
+\item[cancel] The cancel method takes a single integer argument,
+ which is a JobId. If JobId is found, it will be canceled.
+\item [DoesVolumeExist] The DoesVolumeExist method takes a single
string argument, which is the Volume name, and returns
1 if the volume exists in the Catalog and 0 if the volume
does not exist.
\begin{description}
\item [Priority] Read or set the Job priority.
-Note, that setting a Job Priority is effective only before
-the Job actually starts. (not functional yet)
+ Note, that setting a Job Priority is effective only before
+ the Job actually starts.
+\item [Level] This attribute contains a string representing the Job
+ level, e.g. Full, Differential, Incremental, ... if read.
+ The level can also be set.
\end{description}
The following read-only attributes are available within the Director
\begin{description}
-\item [Level] This attribute contains a string representing the Job
- level, e.g. Full, Differential, Incremental, ...
\item [Type] This attribute contains a string representing the Job
type, e.g. Backup, Restore, Verify, ...
\item [JobId] This attribute contains an integer representing the
\index[general]{Algorithm!New Volume}
\begin{itemize}
+\item If the request is for an Autochanger device, look only
+ for Volumes in the Autochanger (i.e. with InChanger set and that have
+ the correct Storage device).
\item Search the Pool for a Volume with VolStatus=Append (if there is more
than one, the Volume with the oldest date last written is chosen. If
two have the same date then the one with the lowest MediaId is chosen).
-\item If the current device is an Autochanger, search the Scratch
- Pool for a Volume that is in the Autochanger. If found, move
- it to the correct Pool.
\item Search the Pool for a Volume with VolStatus=Recycle and the InChanger
flag is set true (if there is more than one, the Volume with the oldest
date last written is chosen. If two have the same date then the one
\item Prune volumes applying Volume retention period (Volumes with VolStatus
Full, Used, or Append are pruned).
\item Search the Pool for a Volume with VolStatus=Purged
-\item If InChanger was set, go back to the first step above, but
- this second time, ignore the InChanger flag in step 2.
\item If a Pool named "Scratch" exists, search for a Volume and if found
- move it to the current Pool for the Job and use it.
+ move it to the current Pool for the Job and use it. Note, when
+ the Scratch Volume is moved into the current Pool, the basic
+ Pool defaults are applied as if it is a newly labeled Volume
+ (equivalent to an {\bf update volume from pool} command).
+\item If we were looking for Volumes in the Autochanger, go back to
+ step 2 above, but this time, look for any Volume whether or not
+ it is in the Autochanger.
\item Attempt to create a new Volume if automatic labeling enabled
- If Python is enabled, a Python NewVolume even is generated before
- the Label Format check is used.
+ If Python is enabled, a Python NewVolume event is generated before
+ the Label Format directve is used.
\item Prune the oldest Volume if RecycleOldestVolume=yes (the Volume with the
oldest LastWritten date and VolStatus equal to Full, Recycle, Purged, Used,
or Append is chosen). This record ensures that all retention periods are
In this case, {\bf File0001} will never be automatically recycled. The same
effect can be achieved by setting the Volume Status to Read-Only.
+As you have noted, the Volume Status (VolStatus) colume in the
+catalog database contains the current status of the Volume, which
+is normally maintained automatically by Bacula. To give you an
+idea of some of the values it can take during the life cycle of
+a Volume, here is a picture created by Arno Lehmann:
+
+\footnotesize
+\begin{verbatim}
+A typical volume life cycle is like this:
+
+ because job count or size limit exceeded
+ Append ----------------------------------------> Used
+ ^ |
+ | First Job writes to Retention time passed |
+ | the volume and recycling takes |
+ | place |
+ | v
+ Recycled <-------------------------------------- Purged
+ Volume is selected for reuse
+
+\end{verbatim}
+\normalsize
+
+
\subsection*{Making Bacula Use a Single Tape}
\label{singletape}
\index[general]{Tape!Making Bacula Use a Single}
The spec file currently supports building on the following platforms:
\footnotesize
\begin{verbatim}
-# RedHat builds
+RedHat builds
--define "build_rh7 1"
--define "build_rh8 1"
--define "build_rh9 1"
-# Fedora Core build
+Fedora Core build
--define "build_fc1 1"
--define "build_fc3 1"
--define "build_fc4 1"
-# Whitebox Enterprise build
+Whitebox Enterprise build
--define "build_wb3 1"
-# RedHat Enterprise builds
+RedHat Enterprise builds
--define "build_rhel3 1"
--define "build_rhel4 1"
-# CentOS build
+CentOS build
--define "build_centos3 1"
--define "build_centos4 1"
-# SuSE build
+SuSE build
--define "build_su9 1"
--define "build_su10 1"
-# Mandrake build
+Mandrake 10.x build
--define "build_mdk 1"
-MySQL support:
+Mandriva build
+--define "build_mdv 1"
-# for mysql 3.23.x support define this
+MySQL support:
+for mysql 3.23.x support define this
--define "build_mysql 1"
-# if using mysql 4.x define this
-# currently: Mandrake 10.x, SuSE 9.x & 10.x, FC4 & RHEL4
+if using mysql 4.x define this,
+currently: Mandrake 10.x, SuSE 9.x & 10.x, FC4 & RHEL4
--define "build_mysql4 1"
PostgreSQL support:
Sqlite support:
--define "build_sqlite 1"
+X86-64 support:
+--define "build_x86_64 1"
+
+Supress build of gnome console:
+--define "nobuild_gconsole 1"
+
+Build the WXWindows console:
+requires wxGTK >= 2.6
+--define "build_wxconsole 1"
+
\end{verbatim}
\normalsize
+
+\subsection*{RPM Install Problems}
+\index[general]{RPM Install Problems}
+\addcontentsline{toc}{subsection}{RPM Install Options}
+In general the RPMs, once properly built should install correctly.
+However, when attempting to run the daemons, a number of problems
+can occur:
+\begin{itemize}
+\item [Wrong /var/bacula Permissions]
+ By default, the Director and Storage daemon do not run with
+ root permission. If the /var/bacula is owned by root, then it
+ is possible that the Director and the Storage daemon will not
+ be able to access this directory, which is used as the Working
+ Directory. To fix this, the easiest thing to do is:
+\begin{verbatim}
+ chown bacula:bacula /var/bacula
+\end{verbatim}
+ Note: as of 1.38.8 /var/bacula is installed root:bacula with
+ permissions 770.
+\item [The Storage daemon cannot Access the Tape drive]
+ This can happen in some older RPM releases where the Storage
+ daemon ran under userid bacula, group bacula. There are two
+ ways of fixing this: the best is to modify the /etc/init.d/bacula-sd
+ file so that it starts the Storage daemon with group "disk".
+ The second way to fix the problem is to change the permissions
+ of your tape drive (usually /dev/nst0) so that Bacula can access it.
+ You will probably need to change the permissions of the SCSI control
+ device as well, which is usually /dev/sg0. The exact names depend
+ on your configuration, please see the Tape Testing chapter for
+ more information on devices.
+\end{itemize}
+
+
\begin{description}
\item [Name = \lt{}Storage-Daemon-Name\gt{}]
- \index[sd]{Name }
+ \index[sd]{Name}
+ \index[sd]{Directive!Name}
Specifies the Name of the Storage daemon. This directive is required.
\item [Working Directory = \lt{}Directory\gt{}]
- \index[sd]{Working Directory }
+ \index[sd]{Working Directory}
+ \index[sd]{Directive!Working Directory}
This directive is mandatory and specifies a directory in which the Storage
daemon may put its status files. This directory should be used only by {\bf
Bacula}, but may be shared by other Bacula daemons provided the names
required
\item [Pid Directory = \lt{}Directory\gt{}]
- \index[sd]{Pid Directory }
+ \index[sd]{Pid Directory}
+ \index[sd]{Directive!Pid Directory}
This directive is mandatory and specifies a directory in which the Director
may put its process Id file files. The process Id file is used to shutdown
Bacula and to prevent multiple copies of Bacula from running simultaneously.
Directory} as defined above.
\item [Heartbeat Interval = \lt{}time-interval\gt{}]
- \index[sd]{Heartbeat Interval }
+ \index[sd]{Heartbeat Interval}
+ \index[sd]{Directive!Heartbeat Interval}
\index[general]{Heartbeat Interval}
\index[general]{Broken pipe}
This directive defines an interval of time. When the Storage daemon is
\item [Maximum Concurrent Jobs = \lt{}number\gt{}]
\index[sd]{Maximum Concurrent Jobs}
+ \index[sd]{Directive!Maximum Concurrent Jobs}
where \lt{}number\gt{} is the maximum number of Jobs that should run
concurrently. The default is set to 10, but you may set it to a larger
number. Each contact from the Director (e.g. status request, job start
\item [SDAddresses = \lt{}IP-address-specification\gt{}]
\index[sd]{SDAddresses}
+ \index[sd]{Directive!SDAddresses}
Specify the ports and addresses on which the Storage daemon will listen
for Director connections. Normally, the default is sufficient and you
do not need to specify this directive. Probably the simplest way to
directives shown below.
\item [SDPort = \lt{}port-number\gt{}]
- \index[sd]{SDPort }
+ \index[sd]{SDPort}
+ \index[sd]{Directive!SDPort}
Specifies port number on which the Storage daemon listens for Director
connections. The default is 9103.
\item [SDAddress = \lt{}IP-Address\gt{}]
- \index[sd]{SDAddress }
- This directive is optional, and if it is specified, it will cause the Storage
- daemon server (for Director and File daemon connections) to bind to the
- specified {\bf IP-Address}, which is either a domain name or an IP address
- specified as a dotted quadruple. If this directive is not specified, the
- Storage daemon will bind to any available address (the default).
+ \index[sd]{SDAddress}
+ \index[sd]{Directive!SDAddress}
+ This directive is optional, and if it is specified, it will cause the
+ Storage daemon server (for Director and File daemon connections) to bind
+ to the specified {\bf IP-Address}, which is either a domain name or an
+ IP address specified as a dotted quadruple. If this directive is not
+ specified, the Storage daemon will bind to any available address (the
+ default).
\end{description}
\begin{description}
\item [Name = \lt{}Director-Name\gt{}]
- \index[sd]{Name }
+ \index[sd]{Name}
+ \index[sd]{Directive!Name}
Specifies the Name of the Director allowed to connect to the Storage daemon.
This directive is required.
\item [Password = \lt{}Director-password\gt{}]
- \index[sd]{Password }
+ \index[sd]{Password}
+ \index[sd]{Directive!Password}
Specifies the password that must be supplied by the above named Director.
This directive is required.
\item [Monitor = \lt{}yes|no\gt{}]
- \index[sd]{Monitor }
+ \index[sd]{Monitor}
+ \index[sd]{Directive!Monitor}
If Monitor is set to {\bf no} (default), this director will have full
access to this Storage daemon. If Monitor is set to {\bf yes}, this
director will only be able to fetch the current status of this Storage
\begin{description}
\item [Name = {\it Device-Name}]
- \index[sd]{Name }
+ \index[sd]{Name}
+ \index[sd]{Directive!Name}
Specifies the Name that the Director will use when asking to backup or
restore to or from to this device. This is the logical Device name, and may
be any string up to 127 characters in length. It is generally a good idea to
resource.
\item [Archive Device = {\it name-string}]
- \index[sd]{Archive Device }
+ \index[sd]{Archive Device}
+ \index[sd]{Directive!Archive Device}
The specified {\bf name-string} gives the system file name of the storage
device managed by this storage daemon. This will usually be the device file
name of a removable storage device (tape drive), for example "{\bf
\item [Device Type = {\it type-specification}]
\index[sd]{Device Type}
+ \index[sd]{Directive!Device Type}
The Device Type specification allows you to explicitly tell Bacula
what kind of device you are defining. It the {\it type-specification}
may be one of the following:
If the Device Type is not explicitly specified, then the mount point
must exist when the Storage daemon starts.
- This directive was implemented in Bacula version 1.39.5.
+ This directive was implemented in Bacula version 1.38.6.
\item [Media Type = {\it name-string}]
- \index[sd]{Media Type }
+ \index[sd]{Media Type}
+ \index[sd]{Directive!Media Type}
The specified {\bf name-string} names the type of media supported by this
device, for example, "DLT7000". Media type names are arbitrary in that you
set them to anything you want, but they must be known to the volume
\label{Autochanger}
\item [Autochanger = {\it Yes|No}]
\index[sd]{Autochanger}
+ \index[sd]{Directive!Autochanger}
If {\bf Yes}, this device belongs to an automatic tape changer, and you should also
specify a {\bf Changer Device} as well as a {\bf Changer Command}. If {\bf
No} (default), the volume must be manually changed. You should also
configuration file so that when labeling tapes you are prompted for the slot.
\item [Changer Device = {\it name-string}]
- \index[sd]{Changer Device }
+ \index[sd]{Changer Device}
+ \index[sd]{Directive!Changer Device}
The specified {\bf name-string} must be the {\bf generic SCSI} device
name of the autochanger that corresponds to the normal read/write
{\bf Archive Device} specified in the Device resource. This
autochanger directives.
\item [Changer Command = {\it name-string}]
- \index[sd]{Changer Command }
+ \index[sd]{Changer Command}
+ \index[sd]{Directive!Changer Command}
The {\bf name-string} specifies an external program to be called that will
automatically change volumes as required by {\bf Bacula}. Most frequently,
you will specify the Bacula supplied {\bf mtx-changer} script as follows:
scripts in {\bf examples/autochangers}.
\item [Alert Command = {\it name-string}]
- \index[sd]{Alert Command }
+ \index[sd]{Alert Command}
The {\bf name-string} specifies an external program to be called at the
+ \index[sd]{Directive!Changer Command}
completion of each Job after the device is released. The purpose of this
command is to check for Tape Alerts, which are present when something is
wrong with your tape drive (at least for most modern tape drives). The same
\item [Drive Index = {\it number}]
\index[sd]{Drive Index}
+ \index[sd]{Directive!Drive Index}
The {\bf Drive Index} that you specify is passed to the {\bf mtx-changer}
script and is thus passed to the {\bf mtx} program. By default, the Drive
Index is zero, so if you have only one drive in your autochanger, everything
\item [Autoselect = {\it Yes|No}]
\index[sd]{Autoselect}
+ \index[sd]{Directive!Autoselect}
If this directive is set to {\bf yes} (default), and the Device
belongs to an autochanger, then when the Autochanger is referenced
by the Director, this device can automatically be selected. If this
for reserving a drive for something special such as a high priority
backup or restore operations.
-\item [Maximum Changer Wait = {\it seconds}]
+\item [Maximum Changer Wait = {\it time}]
\index[sd]{Maximum Changer Wait}
+ \index[sd]{Directive!Maximum Changer Wait}
This directive specifies the maximum time in seconds for Bacula to wait
for an autochanger to change the volume. If this time is exceeded,
Bacula will invalidate the Volume slot number stored in the catalog and
try again. If no additional changer volumes exist, Bacula will ask the
operator to intervene. The default is 5 minutes.
- Please note that if you want to set your changer wait time to
- 10 minutes, you must specify:
-
-\begin{verbatim}
-Maximum Changer Wait = 600
-\end{verbatim}
-
- This directive will not accept qualifiers (such as "minutes").
-
-\item [Maximum Rewind Wait = {\it seconds}]
+\item [Maximum Rewind Wait = {\it time}]
\index[sd]{Maximum Rewind Wait}
+ \index[sd]{Directive!Maximum Rewind Wait}
This directive specifies the maximum time in seconds for Bacula to wait
for a rewind before timing out. If this time is exceeded,
Bacula will cancel the job. The default is 5 minutes.
-\item [Maximum Open Wait = {\it seconds}]
+\item [Maximum Open Wait = {\it time}]
\index[sd]{Maximum Open Wait}
+ \index[sd]{Directive!Maximum Open Wait}
This directive specifies the maximum time in seconds for Bacula to wait
for a open before timing out. If this time is exceeded,
Bacula will cancel the job. The default is 5 minutes.
\item [Always Open = {\it Yes|No}]
- \index[sd]{Always Open }
+ \index[sd]{Always Open}
+ \index[sd]{Directive!Always Open}
If {\bf Yes} (default), Bacula will always keep the device open unless
specifically {\bf unmounted} by the Console program. This permits
Bacula to ensure that the tape drive is always available. If you set
operation.
\item [Volume Poll Interval = {\it time}]
- \index[sd]{Volume Poll Interval }
+ \index[sd]{Volume Poll Interval}
+ \index[sd]{Directive!Volume Poll Interval}
If the time specified on this directive is non-zero, after asking the
operator to mount a new volume Bacula will periodically poll (or read) the
drive at the specified interval to see if a new volume has been mounted. If
\item [Close on Poll= {\it Yes|No}]
\index[sd]{Close on Poll}
+ \index[sd]{Directive!Close on Poll}
If {\bf Yes}, Bacula close the device (equivalent to an unmount except no
mount is required) and reopen it at each poll. Normally this is not too
useful unless you have the {\bf Offline on Unmount} directive set, in which
the drive on the next poll and automatically continue with the backup.
Please see above more more details.
-\item [Maximum Open Wait = {\it seconds}]
- \index[sd]{Maximum Open Wait }
+\item [Maximum Open Wait = {\it time}]
+ \index[sd]{Maximum Open Wait}
+ \index[sd]{Directive!Maximum Open Wait}
This directive specifies the maximum amount of time in seconds that
Bacula will wait for a device that is busy. The default is 5 minutes.
If the device cannot be obtained, the current Job will be terminated in
starts that needs the the drive.
\item [Removable media = {\it Yes|No}]
- \index[sd]{Removable media }
- If {\bf Yes}, this device supports removable media (for example, tapes or
- CDs). If {\bf No}, media cannot be removed (for example, an intermediate
- backup area on a hard disk).
+ \index[sd]{Removable media}
+ \index[sd]{Directive!Removable media}
+ If {\bf Yes}, this device supports removable media (for example, tapes
+ or CDs). If {\bf No}, media cannot be removed (for example, an
+ intermediate backup area on a hard disk).
\item [Random access = {\it Yes|No}]
- \index[sd]{Random access }
- If {\bf Yes}, the archive device is assumed to be a random access medium
- which supports the {\bf lseek} (or {\bf lseek64} if Largefile is enabled
- during configuration) facility.
+ \index[sd]{Random access}
+ \index[sd]{Directive!Random access}
+ If {\bf Yes}, the archive device is assumed to be a random access medium
+ which supports the {\bf lseek} (or {\bf lseek64} if Largefile is enabled
+ during configuration) facility.
\item [Minimum block size = {\it size-in-bytes}]
- \index[sd]{Minimum block size }
+ \index[sd]{Minimum block size}
+ \index[sd]{Directive!Minimum block size}
On most modern tape drives, you will not need or wamt to specify this
directive, and if you do so, it will be to make Bacula use fixed block
sizes. This statement applies only to non-random access devices (e.g.
\normalsize
\item [Maximum block size = {\it size-in-bytes}]
- \index[sd]{Maximum block size }
+ \index[sd]{Maximum block size}
+ \index[sd]{Directive!Maximum block size}
On most modern tape drives, you will not need to specify this directive.
If you do so, it will most likely be to use fixed block sizes (see
Minimum block size above). The Storage daemon will aways attempt to
use a default block size of 64,512 bytes (126 * 512).
\item [Hardware End of Medium = {\it Yes|No}]
- \index[sd]{Hardware End of Medium }
+ \index[sd]{Hardware End of Medium}
+ \index[sd]{Directive!Hardware End of Medium}
If {\bf No}, the archive device is not required to support end of medium
ioctl request, and the storage daemon will use the forward space file
function to find the end of the recorded data. If {\bf Yes}, the archive
feature.
\item [Fast Forward Space File = {\it Yes|No}]
- \index[sd]{Fast Forward Space File }
+ \index[sd]{Fast Forward Space File}
+ \index[sd]{Directive!Fast Forward Space File}
If {\bf No}, the archive device is not required to support keeping track of
the file number ({\bf MTIOCGET} ioctl) during forward space file. If {\bf
Yes}, the archive device must support the {\tt ioctl} {\tt MTFSF} call, which
Default setting for Fast Forward Space File is {\bf Yes}.
\item [Use MTIOCGET = {\it Yes|No}]
- \index[sd]{Fast Forward Space File }
+ \index[sd]{Fast Forward Space File}
+ \index[sd]{Directive!Fast Forward Space File}
If {\bf No}, the operating system is not required to support keeping track of
the file number and reporting it in the ({\bf MTIOCGET} ioctl). The default
is {\bf Yes}. If you must set this to No, Bacula will do the proper file
Solaris, Linux and FreeBSD.
\item [BSF at EOM = {\it Yes|No}]
- \index[sd]{BSF at EOM }
+ \index[sd]{BSF at EOM}
+ \index[sd]{Directive!BSF at EOM}
If {\bf No}, the default, no special action is taken by Bacula with the End
of Medium (end of tape) is reached because the tape will be positioned after
the last EOF tape mark, and Bacula can append to the tape as desired.
is done using the {\bf test} command in the {\bf btape} program.
\item [TWO EOF = {\it Yes|No}]
- \index[sd]{TWO EOF }
+ \index[sd]{TWO EOF}
+ \index[sd]{Directive!TWO EOF}
If {\bf Yes}, Bacula will write two end of file marks when terminating a tape
-- i.e. after the last job or at the end of the medium. If {\bf No}, the
default, Bacula will only write one end of file to terminate the tape.
\item [Backward Space Record = {\it Yes|No}]
\index[sd]{Backward Space Record}
+ \index[sd]{Directive!Backward Space Record}
If {\it Yes}, the archive device supports the {\tt MTBSR ioctl} to backspace
records. If {\it No}, this call is not used and the device must be rewound
and advanced forward to the desired position. Default is {\bf Yes} for non
precautionary rather than required.
\item [Backward Space File = {\it Yes|No}]
- \index[sd]{Backward Space File }
+ \index[sd]{Backward Space File}
+ \index[sd]{Directive!Backward Space File}
If {\it Yes}, the archive device supports the {\bf MTBSF} and {\bf MTBSF
ioctl}s to backspace over an end of file mark and to the start of a file. If
{\it No}, these calls are not used and the device must be rewound and
random-access devices.
\item [Forward Space Record = {\it Yes|No}]
- \index[sd]{Forward Space Record }
+ \index[sd]{Forward Space Record}
+ \index[sd]{Directive!Forward Space Record}
If {\it Yes}, the archive device must support the {\bf MTFSR ioctl} to
forward space over records. If {\bf No}, data must be read in order to
advance the position on the device. Default is {\bf Yes} for non
random-access devices.
\item [Forward Space File = {\it Yes|No}]
- \index[sd]{Forward Space File }
+ \index[sd]{Forward Space File}
+ \index[sd]{Directive!Forward Space File}
If {\bf Yes}, the archive device must support the {\tt MTFSF ioctl} to
forward space by file marks. If {\it No}, data must be read to advance the
position on the device. Default is {\bf Yes} for non random-access devices.
\item [Offline On Unmount = {\it Yes|No}]
- \index[sd]{Offline On Unmount }
+ \index[sd]{Offline On Unmount}
+ \index[sd]{Directive!Offline On Unmount}
The default for this directive is {\bf No}. If {\bf Yes} the archive device
must support the {\tt MTOFFL ioctl} to rewind and take the volume offline. In
this case, Bacula will issue the offline (eject) request before closing the
\item [Maximum Volume Size = {\it size}]
- \index[sd]{Maximum Volume Size }
+ \index[sd]{Maximum Volume Size}
+ \index[sd]{Directive!Maximum Volume Size}
No more than {\bf size} bytes will be written onto a given volume on the
archive device. This directive is used mainly in testing Bacula to
simulate a small Volume. It can also be useful if you wish to limit the
Volume Bytes} defined in the Director's configuration file.
\item [Maximum File Size = {\it size}]
- \index[sd]{Maximum File Size }
+ \index[sd]{Maximum File Size}
+ \index[sd]{Directive!Maximum File Size}
No more than {\bf size} bytes will be written into a given logical file
on the volume. Once this size is reached, an end of file mark is
written on the volume and subsequent data are written into the next
Gigabyte.
\item [Block Positioning = {\it yes|no}]
- \index[sd]{Block Positioning }
+ \index[sd]{Block Positioning}
+ \index[sd]{Directive!Block Positioning}
This directive is not normally used (and has not yet been tested). It will
tell Bacula not to use block positioning when it is reading tapes. This can
cause Bacula to be {\bf extremely} slow when restoring files. You might use
hope, Bacula will be able to re-read your tapes.
\item [Maximum Network Buffer Size = {\it bytes}]
- \index[sd]{Maximum Network Buffer Size }
+ \index[sd]{Maximum Network Buffer Size}
+ \index[sd]{Directive!Maximum Network Buffer Size}
where {\it bytes} specifies the initial network buffer size to use with the
File daemon. This size will be adjusted down if it is too large until
it is accepted by the OS. Please use care in setting this value since if
\item [Maximum Spool Size = {\it bytes}]
- \index[sd]{Maximum Spool Size }
+ \index[sd]{Maximum Spool Size}
+ \index[sd]{Directive!Maximum Spool Size}
where the bytes specify the maximum spool size for all jobs that are running.
The default is no limit.
\item [Maximum Job Spool Size = {\it bytes}]
- \index[sd]{Maximum Job Spool Size }
+ \index[sd]{Maximum Job Spool Size}
+ \index[sd]{Directive!Maximum Job Spool Size}
where the bytes specify the maximum spool size for any one job that is
running. The default is no limit.
This directive is implemented only in version 1.37 and later.
\item [Spool Directory = {\it directory}]
- \index[sd]{Spool Directory }
+ \index[sd]{Spool Directory}
+ \index[sd]{Directive!Spool Directory}
specifies the name of the directory to be used to store the spool files for
this device. This directory is also used to store temporary part files when
writing to a device that requires mount (DVD). The default is to use the
working directory.
\item [Maximum Part Size = {\it bytes}]
- \index[sd]{Maximum Part Size }
+ \index[sd]{Maximum Part Size}
+ \index[sd]{Directive!Maximum Part Size}
This is the maximum size of a volume part file. The default is no limit.
This directive is implemented only in version 1.37 and later.
\addcontentsline{toc}{subsection}{Devices that require a mount (DVD)}
All the directives in this section are implemented only in
-Bacula version 1.37 and later. As of version 1.39.5, the directives
+Bacula version 1.37 and later and hence are available in version 1.38.6.
+
+As of version 1.39.5, the directives
"Requires Mount", "Mount Point", "Mount Command", and "Unmount Command"
apply to removable filesystems such as USB in addition to DVD.
\begin{description}
\item [Requires Mount = {\it Yes|No}]
- \index[sd]{Requires Mount }
+ \index[sd]{Requires Mount}
+ \index[sd]{Directive!Requires Mount}
You must set this directive to {\bf yes} for DVD-writers, and to {\bf no} for
all other devices (tapes/files). This directive indicates if the device
requires to be mounted to be read, and if it must be written in a special way.
{\bf Write Part Command} directives must also be defined.
\item [Mount Point = {\it directory}]
- \index[sd]{Mount Point }
+ \index[sd]{Mount Point}
+ \index[sd]{Directive!Mount Point}
Directory where the device can be mounted.
\item [Mount Command = {\it name-string}]
- \index[sd]{Mount Command }
+ \index[sd]{Mount Command}
+ \index[sd]{Directive!Mount Command}
Command that must be executed to mount the device. Before the command is
executed, \%a is replaced with the Archive Device, and \%m with the Mount
Point.
\normalsize
\item [Unmount Command = {\it name-string}]
- \index[sd]{Unmount Command }
+ \index[sd]{Unmount Command}
+ \index[sd]{Directive!Unmount Command}
Command that must be executed to unmount the device. Before the command is
executed, \%a is replaced with the Archive Device, and \%m with the Mount
Point.
\normalsize
\item [Write Part Command = {\it name-string}]
- \index[sd]{Write Part Command }
+ \index[sd]{Write Part Command}
+ \index[sd]{Directive!Write Part Command}
Command that must be executed to write a part to the device. Before the
command is executed, \%a is replaced with the Archive Device, \%m with the
Mount Point, \%e is replaced with 1 if we are writing the first part,
\item [Free Space Command = {\it name-string}]
- \index[sd]{Free Space Command }
+ \index[sd]{Free Space Command}
+ \index[sd]{Directive!Free Space Command}
Command that must be executed to check how much free space is left on the
device. Before the command is executed,\%a is replaced with the Archive
Device, \%m with the Mount Point, \%e is replaced with 1 if we are writing
\begin{description}
\item [Label media = {\it Yes|No}]
- \index[sd]{Label media }
- If {\bf Yes}, permits this device to automatically label blank media without
- an explicit operator command. It does so by using an internal algorithm as
- defined on the
- \ilink{Label Format}{Label} record in each Pool resource. If
- this is {\bf No} as by default, Bacula will label tapes only by specific
- operator command ({\bf label} in the Console) or when the tape has been
- recycled. The automatic labeling feature is most useful when writing to disk
- rather than tape volumes.
+ \index[sd]{Label media}
+ \index[sd]{Directive!Label media}
+ If {\bf Yes}, permits this device to automatically label blank media
+ without an explicit operator command. It does so by using an internal
+ algorithm as defined on the \ilink{Label Format}{Label} record in each
+ Pool resource. If this is {\bf No} as by default, Bacula will label
+ tapes only by specific operator command ({\bf label} in the Console) or
+ when the tape has been recycled. The automatic labeling feature is most
+ useful when writing to disk rather than tape volumes.
\item [Automatic mount = {\it Yes|No}]
- \index[sd]{Automatic mount }
+ \index[sd]{Automatic mount}
+ \index[sd]{Directive!Automatic mount}
If {\bf Yes} (the default), permits the daemon to examine the device to
determine if it contains a Bacula labeled volume. This is done
initially when the daemon is started, and then at the beginning of each
\hline {Linux } & {Adic } & {LTO-1/2, SDLT 320 } & {Adic Scalar 24 } & {24} & {100GB } \\
\hline {Linux } & {Adic } & {LTO-2 } & {Adic FastStor 2, Sun Storedge L8 } & {8} & {200GB } \\
\hline {- } & {CA-VM } & {?? } & {Tape } & {??} & {?? } \\
- \hline {Linux Gentoo} & {Dell} & {DLT VI,LTO-2} & {PowerVault 122T/132T/136T } & {-} & {100GB } \\
+ \hline {Linux } & {Dell} & {DLT VI,LTO-2,LTO3} & {PowerVault 122T/132T/136T } & {-} & {100GB } \\
+ \hline {Linux } & {Dell} & {LTO-2} & {PowerVault 124T } & {-} & {200GB } \\
\hline {- } & {DFSMS } & {?? } & {VM RMM} & {-} & {?? } \\
- \hline {z/VM } & {IBM } & {?? } & {IBM Tape Manager } & {-} & {?? } \\
- \hline {z/VM } & {IBM } & {?? } & {native tape } & {-} & {?? } \\
\hline {Linux } & {Exabyte } & {VXA2 } & {VXA PacketLoader 1x10 2U } & {10} & {80/160GB } \\
\hline {- } & {Exabyte } & {LTO } & {Magnum 1x7 LTO Tape Auotloader } & {7} & {200/400GB } \\
- \hline {Linux Gentoo 1.4 } & {Exabyte } & {AIT-2 } & {215A } & {15 (2 drives)} & {50GB } \\
+ \hline {Linux } & {Exabyte } & {AIT-2 } & {215A } & {15 (2 drives)} & {50GB } \\
\hline {Linux } & {HP } & {DDS-4 } & {SureStore DAT-40X6 } & {6 } & {40GB } \\
\hline {Linux } & {HP } & {Ultrium-2/LTO } & {MSL 6000/ 60030/ 5052 } & {28 } & {200/400GB } \\
\hline {- } & {HP } & {DLT } & {A4853 DLT } & {30} & {40/70GB } \\
\hline {Linux } & {HP (Compaq) } & {DLT VI } & {Compaq TL-895 } & {96+4 import export} & {35/70GB } \\
- \hline {SuSE 9.0 } & {IBM } & {LTO } & {IBM 3581 Ultrium Tape Loader } & {7} & {200/400GB } \\
+ \hline {z/VM } & {IBM } & {?? } & {IBM Tape Manager } & {-} & {?? } \\
+ \hline {z/VM } & {IBM } & {?? } & {native tape } & {-} & {?? } \\
+ \hline {Linux } & {IBM } & {LTO } & {IBM 3581 Ultrium Tape Loader } & {7} & {200/400GB } \\
\hline {FreeBSD 5.4} & {IBM } & {DLT} & {IBM 3502-R14 -- rebranded ATL L-500} & {14} & {35/70GB } \\
\hline {Debian} & {Overland } & {LTO } & {Overland LoaderXpress LTO/DLT8000 } & {10-19} & {40-100GB } \\
\hline {Fedora} & {Overland } & {LTO } & {Overland PowerLoader LTO-2 } & {10-19} & {200/400GB } \\
will automatically use it. If you do not have it configured, you can manually
issue the appopriate {\bf mtx} command, or press the autochanger buttons to
change the tape when requested to do so.
-\item FreeBSD users, run the {\bf tapetest} program, and make sure your
- system is patched if necessary. See below for more details.
+\item FreeBSD users, if you have a pre-5.0 system run the {\bf tapetest}
+ program, and make sure your system is patched if necessary. The tapetest
+ program can be found in the platform/freebsd directory. The instructions
+ for its use are at the top of the file.
\item Run Bacula, and backup a reasonably small directory, say 60 Megabytes.
Do three successive backups of this directory.
\item Stop Bacula, then restart it. Do another full backup of the same
which will give you more time to mount the next tape before the job is
failed.
-
-
\subsubsection*{Specifying the Configuration File}
\index[general]{File!Specifying the Configuration}
\index[general]{Specifying the Configuration File}
directive. For the program to work, it must find the identical name in the
Device resource of the configuration file. If the name is not found in the
list of phsical names, the utility program will compare the name you entered
-to the Device names (rather than the Archive device names). See below for
-specifying Volume names.
+to the Device names (rather than the Archive device names).
+
+When specifying a tape device, it is preferable that the "non-rewind"
+variant of the device file name be given. In addition, on systems such as
+Sun, which have multiple tape access methods, you must be sure to specify
+to use Berkeley I/O conventions with the device. The
+{\bf b} in the Solaris (Sun) archive specification {\bf /dev/rmt/0mbn} is
+what is needed in this case. Bacula does not support SysV tape drive
+behavior.
+
+See below for specifying Volume names.
\subsubsection*{Specifying a Device Name For a File}
\index[general]{File!Specifying a Device Name For a}
\normalsize
then almost certainly, you are running your drive in fixed block mode rather
-than variable block mode. Please see below for help on resolving that.
+than variable block mode. See below for more help of resolving fix
+versus variable block problems.
+
+It is also possible that you have your drive
+set in SysV tape drive mode. The drive must use BSD tape conventions.
+See the section above on setting your {\bf Archive device} correctly.
For FreeBSD users, please see the notes below for doing further testing of
your tape drive.
\item The first and best is to always ensure that your drive is in variable
block mode. Note, it can switch back to fixed block mode on a reboot or if
another program uses the drive. So on such systems you need to modify the
-Bacula startup files to explicitly set:
+ Bacula startup files to explicitly set:
\footnotesize
\begin{verbatim}
\end{itemize}
\label{IncorrectBlocks}
-
\subsubsection*{Incorrect Number of Blocks or Positioning Errors during btape
Testing}
\index[general]{Testing!Incorrect Number of Blocks or Positioning Errors
man pages or documentation to figure out how to do the same thing. This should
not really be necessary though -- for example, on both Linux and Solaris
systems, the default tape driver options are compatible with Bacula.
+On Solaris systems, you must take care to specify the correct device
+name on the {\bf Archive device} directive. See above for more details.
You may also want to ensure that no prior program has set the default block
size, as happened to one user, by explicitly turning it off with:
work in such a situation because it will normally attempt to write blocks of
64,512 bytes, except the last block of the job which will generally be
shorter. The first thing to try is setting the default block size to zero
-using the {\bf mt \ -f \ /dev/nst0 \ defblksize \ 0} command as shown above.
-On FreeBSD, this would be something like: {\bf mt \ -f \ /dev/nsa0 \ blocksize
-\ 0}.
+using the {\bf mt -f /dev/nst0 defblksize 0} command as shown above.
+On FreeBSD, this would be something like: {\bf mt -f /dev/nsa0 blocksize 0}.
On some operating systems with some tape drives, the amount of data that
can be written to the tape and whether or not compression is enabled is
-determined by the density usually the {\bf mt \ -f \ /dev/nst0 setdensity xxx} command.
-Often {\bf mt \ -f \ /dev/nst0 \ status} will print out the current
+determined by the density usually the {\bf mt -f /dev/nst0 setdensity xxx} command.
+Often {\bf mt -f /dev/nst0 status} will print out the current
density code that is used with the drive. Most systems, but unfortunately
not all, set the density to the maximum by default. On some systems, you
can also get a list of all available density codes with:
-{\bf mt \ -f \ /dev/nst0 \ densities} or a similar {\bf mt} command.
+{\bf mt -f /dev/nst0 densities} or a similar {\bf mt} command.
Note, for DLT and SDLT devices, no-compression versus compression is very
often controlled by the density code. On FreeBSD systems, the compression
-mode is set using {\bf mt \ -f \ /dev/nsa0 \ comp xxx} where xxx is the
+mode is set using {\bf mt -f /dev/nsa0 comp xxx} where xxx is the
mode you want. In general, see {\bf man mt} for the options available on
your system.
-
+Note, some of the above {\bf mt} commands may not be persistent depending
+on your system configuration. That is they may be reset if a program
+other than Bacula uses the drive or, as is frequently the case, on reboot
+of your system.
+
If your tape drive requires fixed block sizes (very unusual), you can use the
following records:
\footnotesize
\begin{verbatim}
-mt \ -f \ /dev/nsa0 \ seteotmodel \ 2
-mt \ -f \ /dev/nsa0 \ blocksize \ 0
-mt \ -f \ /dev/nsa0 \ comp \ enable
+mt -f /dev/nsa0 seteotmodel 2
+mt -f /dev/nsa0 blocksize 0
+mt -f /dev/nsa0 comp enable
\end{verbatim}
\normalsize
You might want to put those commands in a startup script to make sure your
-tape driver is properly initialized before running Bacula.
+tape driver is properly initialized before running Bacula, because
+depending on your system configuration, these modes may be reset if a
+program other than Bacula uses the drive or when your system is rebooted.
Then according to what the {\bf btape test} command returns, you will probably
need to set the following (see below for an alternative):
\footnotesize
\begin{verbatim}
-mt \ -f \ /dev/nsa0 \ seteotmodel \ 1
-mt \ -f \ /dev/nsa0 \ blocksize \ 0
-mt \ -f \ /dev/nsa0 \ comp \ enable
+mt -f /dev/nsa0 seteotmodel 1
+mt -f /dev/nsa0 blocksize 0
+mt -f /dev/nsa0 comp enable
\end{verbatim}
\normalsize
\normalsize
-\subsubsection*{Determining What Tape Drives and Autochangers You Have on
-FreeBSD}
-\index[general]{FreeBSD!Determining What Tape Drives and Autochangers You Have
-}
-\index[general]{Determining What Tape Drives and Autochangers You Have on
-FreeBSD}
-\addcontentsline{toc}{subsubsection}{Determining What Tape Drives and
-Autochangers You Have on FreeBSD}
+\subsubsection*{Finding your Tape Drives and Autochangers on FreeBSD}
+\index[general]{FreeBSD!Finding your Tape Drives and Autochangers}
+\index[general]{Finding your Tape Drives and Autochangers on FreeBSD}
+\addcontentsline{toc}{subsubsection}{Finding your Tape Drives and
+Autochangers on FreeBSD}
On FreeBSD, you can do a {\bf camcontrol devlist} as root to determine what
drives and autochangers you have. For example,
skipped. File number is always tracked for MTEOM.
Linux does support both SCSI SPACE Filemarks and End-of-data: When MTEOM
- is called in MT_ST_FAST_MTEOM mode, SCSI SPACE Filemarks with count =
- 8388607 is used. In the other case, SCSI SPACE End-of-data is used.
+ is called in MT_ST_FAST_MTEOM mode, SCSI SPACE End-of-data is used.
+ In the other case, SCSI SPACE Filemarks with count =
+ 8388607 is used.
There is no real slow mode like in Solaris - I just expect, that for
older tape drives Filemarks may be slower than End-of-data, but not so
much as in Solaris slow mode. File number is tracked for MTEOM just
FreeBSD does support both SCSI SPACE Filemarks and End-of-data, but when
MTEOD (MTEOM) is called, SCSI SPACE End-of-data is always used. FreeBSD
never use SCSI SPACE Filemarks for MTEOD. File number is never tracked
- for MTOED.
+ for MTEOD.
\item[Bacula level]
When {\bf Hardware End of Medium = Yes} is used, MTEOM is called, but it
If I use No, an action depends on Fast Forward Space File.
- Considering {\bf Hardware End of Medium = no}
+ When I set {\bf Hardware End of Medium = no}
and {\bf Fast Forward Space File = no}
- When I set the two to no, file positioning was very slow
- on my LTO-3:
-\begin{verbatim}
- HEOM = no, FFSF = no: ~ 10 - 100 minutes
-\end{verbatime}
+ file positioning was very slow
+ on my LTO-3 (about 10 to 100 minutes), but
-while even with {\bf Hardware End of Medium = no} but
+ with {\bf Hardware End of Medium = no} and
{\bf Fast Forward Space File = yes}, the time is 10 to
-100 times faster.
-\begin{verbatim}
- HEOM = no, FFSF = yes: ~ 1 minute
-\end{verbatim}
+100 times faster (about 1 to 2 minutes).
\end{description}
all access to the proper control device, and if you don't have any
SCSI disk drives (including SATA drives), you might want to change
the permissions on /dev/sg*.
+
+\subsection*{Syslog Errors}
+\index[general]{Errors!Syslog}
+\index[general]{Syslog Errors}
+\addcontentsline{toc}{subsection}{Syslog Errors}
+
+If you are getting errors such as:
+
+\footnotesize
+\begin{verbatim}
+: kernel: st0: MTSETDRVBUFFER only allowed for root
+\end{verbatim}
+\normalsize
+
+you are most likely running your Storage daemon as non-root, and
+Bacula is attempting to set the correct OS buffering to correspond
+to your Device resource. Most OSes allow only root to issue this
+ioctl command. In general, the message can be ignored providing
+you are sure that your OS parameters are properly configured as
+described earlier in this manual. If you are running your Storage daemon
+as root, you should not be getting these system log messages, and if
+you are, something is probably wrong.
+
Director { # define myself
Name = backup1-dir
...
+ TLS Enable = yes
TLS Require = yes
TLS Verify Peer = yes
TLS Allowed CN = "bacula@backup1.example.com"
Director {
Name = backup1-dir
...
+ TLS Enable = yes
TLS Require = yes
TLS Verify Peer = yes
# Allow only the Director to connect
# These TLS configuration options are used for incoming
# file daemon connections. Director TLS settings are handled
# below.
+ TLS Enable = yes
TLS Require = yes
# Peer certificate is not required/requested -- peer validity
# is verified by the storage connection cookie provided to the
Director {
Name = backup1-dir
...
+ TLS Enable = yes
TLS Require = yes
# Require the connecting director to provide a certificate
# with the matching CN.
# latex2html has used as the source to create the imgxx.png filename.
# The filename extension is taken from the file
sub read_transfile {
- my ($trans,$direction) = @_;
-
- if (!open IN,"<$path$TRANSFILE") {
- print "WARNING: Cannot open image translation file $path$TRANSFILE for reading\n";
- print " Image filename translation aborted\n\n";
- exit 0;
- }
-
- while (<IN>) {
- chomp;
- my ($new,$old) = split(/\001/);
-
- # Old filenames will usually have a leading ./ which we don't need.
- $old =~ s/^\.\///;
-
- # The filename extension of the old filename must be made to match
- # the new filename because it indicates the encoding format of the image.
- my ($ext) = $new =~ /(\.[^\.]*)$/;
- $old =~ s/\.[^\.]*$/$ext/;
- if ($direction == 0) {
- $trans->{$new} = $old;
- } else {
- $trans->{$old} = $new;
- }
- }
- close IN;
+ my ($trans,$direction) = @_;
+
+ if (!open IN,"<$path$TRANSFILE") {
+ print "WARNING: Cannot open image translation file $path$TRANSFILE for reading\n";
+ print " Image filename translation aborted\n\n";
+ exit 0;
+ }
+
+ while (<IN>) {
+ chomp;
+ my ($new,$old) = split(/\001/);
+
+ # Old filenames will usually have a leading ./ which we don't need.
+ $old =~ s/^\.\///;
+
+ # The filename extension of the old filename must be made to match
+ # the new filename because it indicates the encoding format of the image.
+ my ($ext) = $new =~ /(\.[^\.]*)$/;
+ $old =~ s/\.[^\.]*$/$ext/;
+ if ($direction == 0) {
+ $trans->{$new} = $old;
+ } else {
+ $trans->{$old} = $new;
+ }
+ }
+ close IN;
}
-
+
# Translates the image names in the file given as the first argument, according to
# the translations in the hash that is given as the second argument.
# The file contents are read in entirely into a string, the string is processed, and
# Links to other files are added to the %filelist for processing. That way,
# all linked files will be processed (assuming they are local).
sub translate_html {
- my ($filename,$trans,$filelist) = @_;
- my ($contents,$out,$this,$img,$dest);
- my $cnt = 0;
-
- # If the filename is an external link ignore it. And drop any file:// from
- # the filename.
- $filename =~ /^(http|ftp|mailto)\:/ and return 0;
- $filename =~ s/^file\:\/\///;
- # Load the contents of the html file.
- if (!open IF,"<$path$filename") {
- print "WARNING: Cannot open $path$filename for reading\n";
- print " Image Filename Translation aborted\n\n";
- exit 0;
- }
-
- while (<IF>) {
- $contents .= $_;
- }
- close IF;
-
- # Now do the translation...
- # First, search for an image filename.
- while ($contents =~ /\<\s*IMG[^\>]*SRC=\"/si) {
- $contents = $';
- $out .= $` . $&;
-
- # The next thing is an image name. Get it and translate it.
- $contents =~ /^(.*?)\"/s;
- $contents = $';
- $this = $&;
- $img = $1;
- # If the image is in our list of ones to be translated, do it
- # and feed the result to the output.
- $cnt += $this =~ s/$img/$trans->{$img}/ if (defined($trans->{$img}));
- $out .= $this;
- }
- $out .= $contents;
-
- # Now send the translated text to the html file, overwriting what's there.
- open OF,">$path$filename" or die "Cannot open $path$filename for writing\n";
- print OF $out;
- close OF;
-
- # Now look for any links to other files and add them to the list of files to do.
- while ($out =~ /\<\s*A[^\>]*HREF=\"(.*?)\"/si) {
- $out = $';
- $dest = $1;
- # Drop an # and anything after it.
- $dest =~ s/\#.*//;
- $filelist->{$dest} = '' if $dest;
- }
- return $cnt;
+ my ($filename,$trans,$filelist) = @_;
+ my ($contents,$out,$this,$img,$dest);
+ my $cnt = 0;
+
+ # If the filename is an external link ignore it. And drop any file:// from
+ # the filename.
+ $filename =~ /^(http|ftp|mailto)\:/ and return 0;
+ $filename =~ s/^file\:\/\///;
+ # Load the contents of the html file.
+ if (!open IF,"<$path$filename") {
+ print "WARNING: Cannot open $path$filename for reading\n";
+ print " Image Filename Translation aborted\n\n";
+ exit 0;
+ }
+
+ while (<IF>) {
+ $contents .= $_;
+ }
+ close IF;
+
+ # Now do the translation...
+ # First, search for an image filename.
+ while ($contents =~ /\<\s*IMG[^\>]*SRC=\"/si) {
+ $contents = $';
+ $out .= $` . $&;
+
+ # The next thing is an image name. Get it and translate it.
+ $contents =~ /^(.*?)\"/s;
+ $contents = $';
+ $this = $&;
+ $img = $1;
+ # If the image is in our list of ones to be translated, do it
+ # and feed the result to the output.
+ $cnt += $this =~ s/$img/$trans->{$img}/ if (defined($trans->{$img}));
+ $out .= $this;
+ }
+ $out .= $contents;
+
+ # Now send the translated text to the html file, overwriting what's there.
+ open OF,">$path$filename" or die "Cannot open $path$filename for writing\n";
+ print OF $out;
+ close OF;
+
+ # Now look for any links to other files and add them to the list of files to do.
+ while ($out =~ /\<\s*A[^\>]*HREF=\"(.*?)\"/si) {
+ $out = $';
+ $dest = $1;
+ # Drop an # and anything after it.
+ $dest =~ s/\#.*//;
+ $filelist->{$dest} = '' if $dest;
+ }
+ return $cnt;
}
-
+
# REnames the image files spefified in the %translate hash.
sub rename_images {
- my $translate = shift;
- my ($response);
-
- foreach (keys(%$translate)) {
- if (! $translate->{$_}) {
- print " WARNING: No destination Filename for $_\n";
- } else {
- $response = `mv -f $path$_ $path$translate->{$_} 2>&1`;
- $response and print "ERROR from system $response\n";
- }
- }
+ my $translate = shift;
+ my ($response);
+
+ foreach (keys(%$translate)) {
+ if (! $translate->{$_}) {
+ print " WARNING: No destination Filename for $_\n";
+ } else {
+ $response = `mv -f $path$_ $path$translate->{$_} 2>&1`;
+ $response and print "ERROR from system $response\n";
+ }
+ }
}
#################################################
my $arg0 = shift(@ARGV);
$arg0 =~ /^(--to_meaningful_names|--from_meaningful_names)$/ or
- die "ERROR: First argument must be either \'--to_meaningful_names\' or \'--from_meaningful_names\'\n";
+ die "ERROR: First argument must be either \'--to_meaningful_names\' or \'--from_meaningful_names\'\n";
$direction = ($arg0 eq '--to_meaningful_names') ? 0 : 1;
read_transfile(\%translate,$direction);
foreach (@ARGV) {
- # Strip the path from the filename, and use it later on.
- if (s/(.*\/)//) {
- $path = $1;
- } else {
- $path = '';
- }
- $filelist{$_} = '';
-
- while ($thisfile = (keys(%filelist))[0]) {
- $cnt += translate_html($thisfile,\%translate,\%filelist) if (!exists($completed{$thisfile}));
- delete($filelist{$thisfile});
- $completed{$thisfile} = '';
- }
- print "translate_images.pl: $cnt image filenames translated ",($direction)?"from":"to"," meaningful names\n";
+ # Strip the path from the filename, and use it later on.
+ if (s/(.*\/)//) {
+ $path = $1;
+ } else {
+ $path = '';
+ }
+ $filelist{$_} = '';
+
+ while ($thisfile = (keys(%filelist))[0]) {
+ $cnt += translate_html($thisfile,\%translate,\%filelist) if (!exists($completed{$thisfile}));
+ delete($filelist{$thisfile});
+ $completed{$thisfile} = '';
+ }
+ print "translate_images.pl: $cnt image filenames translated ",($direction)?"from":"to"," meaningful names\n";
}
rename_images(\%translate);
The second change was to add a new Client resource that defines {\bf matou-fd}
and has the correct address {\bf matou}, but in real life, you may need a
-fully qualified machine address or an IP address. I also kept the password the
+fully qualified domain name or an IP address. I also kept the password the
same (shown as xxxxx for the example).
At this point, if you stop Bacula and restart it, and start the Client on the
If you are having difficulties getting one or more of your File daemons to
connect to the Storage daemon, it is most likely because you have not used a
-fully qualified Internet address on the {\bf Address} directive in the
+fully qualified domain name on the {\bf Address} directive in the
Director's Storage resource. That is the resolver on the File daemon's machine
(not on the Director's) must be able to resolve the name you supply into an IP
address. An example of an address that is guaranteed not to work: {\bf
-1.39.5 (20 February 2006)
+1.38.9 (02 May 2006)
below, we are referring to the File daemon only.
The Windows version of the Bacula File daemon has been tested on Win98, WinMe,
-WinNT, and Win2000 systems. We have coded to support Win95, but no longer have
-a system for testing. The Windows version of Bacula is a native Win32 port,
-but there are very few source code changes to the Unix code, which means that the Windows
-version is for the most part running code that has long proved stable on Unix
-systems. When running, it is perfectly integrated with Windows and displays
-its icon in the system icon tray, and provides a system tray menu to obtain
-additional information on how Bacula is running (status and events dialog
-boxes). If so desired, it can also be stopped by using the system tray menu,
-though this should normally never be necessary.
+WinNT, WinXP, Win2000, and Windwos 2003 systems. We have coded to support
+Win95, but no longer have a system for testing. The Windows version of
+Bacula is a native Win32 port, but there are very few source code changes
+to the Unix code, which means that the Windows version is for the most part
+running code that has long proved stable on Unix systems. When running, it
+is perfectly integrated with Windows and displays its icon in the system
+icon tray, and provides a system tray menu to obtain additional information
+on how Bacula is running (status and events dialog boxes). If so desired,
+it can also be stopped by using the system tray menu, though this should
+normally never be necessary.
Once installed Bacula normally runs as a system service. This means that it is
immediately started by the operating system when the system is booted, and
NSIS Free Software installer, so if you have already installed Windows
software, it should be very familiar to you.
-If you have a previous version Cygwin of Bacula (1.32 or lower) installed,
-you should stop the service, uninstall it, and remove the Bacula
-installation directory possibly saving your bacula-fd.conf file for use
-with the new version you will install. The new native version of Bacula
-has far fewer files than the old Cygwin version, so it is better to start
-with a clean directory.
+If you have a previous version Cygwin of Bacula (1.32 or lower)
+installed, you should stop the service, uninstall it, and remove
+the Bacula installation directory possibly saving your
+bacula-fd.conf file for use with the new version you will
+install. Current versions of Bacula do not use Cygwin and has
+far fewer files than the old Cygwin version, so it is better to
+start with a clean directory.
Finally, proceed with the installation.
\item Next you will be asked to select an installation directory.
- \addcontentsline{lof}{figure}{Win32 Directory Selection Dialog}
+\addcontentsline{lof}{figure}{Win32 Directory Selection Dialog}
\includegraphics{./win32-location.eps}
\item If you are installing for the first time, you will be asked if you want
projects / bacula / docs / commitdiff