From 4181ff6d61d737490aa67b81ca93ed9060ff206f Mon Sep 17 00:00:00 2001 From: aussenwasser Date: Mon, 27 Mar 2006 19:40:55 +0000 Subject: [PATCH] I finally made it! TODO (among other): - find a consistent typo for terms, commands and other - ... 2006-3-27 Bernd Frick --- docs/manual-de/general.tex | 474 +++++++++---------- docs/manual-de/install.tex | 727 ++++++++++------------------- docs/manual-de/quickstart.tex | 141 ++---- docs/manual-de/requirements.tex | 21 +- docs/manual-de/state.tex | 36 +- docs/manual-de/supporteddrives.tex | 55 +-- docs/manual-de/supportedoses.tex | 2 +- 7 files changed, 553 insertions(+), 903 deletions(-) diff --git a/docs/manual-de/general.tex b/docs/manual-de/general.tex index 5decaaf8..1d2c0ed7 100644 --- a/docs/manual-de/general.tex +++ b/docs/manual-de/general.tex @@ -9,11 +9,7 @@ {\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 +across a network of computers of different kinds. 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 @@ -37,7 +33,7 @@ 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 +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. @@ -65,97 +61,97 @@ Bacula is made up of the following five major components or services: \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). + {\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 Guild. The Director runs as a daemon or a service (i.e. in the +background). \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}. + {\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 for the moment (23 November 2003) 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}{_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} 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 all currently known Windows versions (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). + {\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). \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. + {\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 +efficicient restoration and Volume management. Bacula currently supports +three different databases, MySQL, PostgreSQL, and SQLite, one of which must +be chosen when building {\bf Bacula}. There also exists an Internal database, +but it is no longer supported. + +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 more details see the +\ilink{Catalog Services Design Document}{_ChapterStart30}. + +The RPMs for MySQL and PostgreSQL ship as part of the Linux RedHat +and several other releases, or 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. \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} + {\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. +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 } @@ -223,41 +219,39 @@ definitions of the terminology that we use. \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. + 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. \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}. + 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. 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}. \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 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. \item [Console] \index[fd]{Console } The program that interfaces to the Director allowing the user or system - administrator to control Bacula. +administrator to control Bacula. \item [Daemon] \index[fd]{Daemon } @@ -268,134 +262,134 @@ systems, daemons are called {\bf Services}. \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. +Resource in a configuration file that defines one specific thing. For +example, the {\bf Name} directive defines the name of the 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. +operations. Occasionally, we refer to the Director as 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. +Note, other backup programs may define this differently. \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 +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. \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. +referred to as the File services, and sometimes as the Client services or the +FD. -\label{FileSetDef} -\item [FileSet] +\item [ + \label{FileSetDef} + 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. +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. \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. +or Incremental backup started. It is normally specified on the {\bf Level} +directive within the Job resource definition, or in a Schedule resource. -\label{JobDef} -\item [Job] +\item [ + \label{JobDef} + 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. +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. \item [Monitor] \index[fd]{Monitor } - The program that interfaces to all the daemons allowing the user or - system administrator to monitor Bacula status. + The program that interfaces to the all the daemons allowing the user or +system administrator to monitor Bacula status. \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, ... + 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 configuation statements). For example, the {\bf Job} resource +defines all the properties of a specific Job: name, schedule, Volume pool, +backup type, backup level, ... \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. + A restore is a configuration resource that describes the operation of +recovering a file (lost or damaged) 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. \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. + 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. \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. +frequently used in Unix environments as well. \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. + 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. \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). + 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). \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). + 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). \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. + 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. \item [*Archive] \index[fd]{*Archive } @@ -412,66 +406,64 @@ NOT YET IMPLEMENTED. \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. + 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. \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. + 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. \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). + 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). \end{description} \subsection*{What Bacula is Not} -\index[general]{What Bacula is Not} +\index[general]{Not!What Bacula is } +\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 @@ -484,7 +476,7 @@ 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. +``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 @@ -492,8 +484,8 @@ 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} +\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 diff --git a/docs/manual-de/install.tex b/docs/manual-de/install.tex index 481fabeb..f7c39d6a 100644 --- a/docs/manual-de/install.tex +++ b/docs/manual-de/install.tex @@ -13,51 +13,14 @@ 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} +Bacula needs certain third party packages (such as {\bf SQLite}, {\bf MySQL} 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. - -\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: - -\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. - -\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. - -\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. - -\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. - -\end{description} - \label{upgrading1} + \subsection*{Upgrading Bacula} \index[general]{Bacula!Upgrading } \index[general]{Upgrading Bacula } @@ -68,22 +31,13 @@ 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: - -\begin{verbatim} -cd (default /etc/bacula) -./update_bacula_tables -\end{verbatim} - -This update script can also be find in the Bacula source src/cats -directory. - -If there are several database upgrades between your version and the +it. 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. +if any, will be in the {\bf src/cats} directory as described in the +ReleaseNotes. 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 @@ -95,9 +49,6 @@ they will note if all daemons must be upgraded at the same time. 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. - For additional information on upgrading, please see the \ilink{Upgrading Bacula Versions}{upgrading} in the Tips chapter of this manual. @@ -127,12 +78,12 @@ needed), you do the following: \item Detar the {\bf depkg} into the {\bf bacula} directory. \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: -\addcontentsline{lot}{table}{Dependency Packages} +\addcontentsline{lot}{table}{Depedency Packages} \begin{longtable}{|l|l|l|l|} \hline \multicolumn{1}{|c| }{\bf 3rd Party Package } & \multicolumn{1}{c| }{\bf @@ -148,7 +99,7 @@ depkgs-win32 } \\ \multicolumn{1}{c| }{X } \\ \hline {zlib } & \multicolumn{1}{c| }{- } & \multicolumn{1}{c| }{- } & \multicolumn{1}{c| }{X } \\ - \hline {wxWidgets } & \multicolumn{1}{c| }{- } & \multicolumn{1}{c| }{- } & + \hline {wxWidgits } & \multicolumn{1}{c| }{- } & \multicolumn{1}{c| }{- } & \multicolumn{1}{c| }{X } \\ \hline @@ -179,9 +130,9 @@ 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, ...). -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. +The {\bf depkgs-win32} package contains the source code for the pthreads and +zlib libraries used by the native Win32 client program. It will only be needed +if you intend to build the Win32 client from source. \subsection*{Supported Operating Systems} \label{Systems} @@ -214,28 +165,21 @@ The basic installation is rather simple. 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 + \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, + binaries and Install config files 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: @@ -243,59 +187,54 @@ The basic installation is rather simple. \footnotesize \begin{verbatim} make distclean + \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 +make distclean} is also critical if you move the source file from one machine to another. If the {\bf make distclean} fails, just ignore it and continue on. - \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. + 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 \verb{--{enable-static-tools} to the {\bf ./configure} +command. \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 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}. - + (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 +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: \footnotesize @@ -318,8 +257,8 @@ reported to work with the Client only as long as readline support is disabled. 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, +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: @@ -333,7 +272,7 @@ make distclean 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". +mentioned above, either start from the tar file, or do a ``make distclean''. 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 @@ -365,7 +304,7 @@ 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. -The {\bf \verb:--:enable-conio} or {\bf \verb:--:enable-readline} options are useful because +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, @@ -408,7 +347,7 @@ LDFLAGS="-lssl -lcyrpto" \ 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 +\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. @@ -425,14 +364,11 @@ differences between systems, I can no longer afford to support it. \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 +PostgreSQL. If you are not already running MySQL or PostgreSQL, we recommend +that you start by using 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. +10-20 machines). If you wish to use MySQL as the Bacula catalog, please see the \ilink{Installing and Configuring MySQL}{_ChapterStart} chapter of @@ -449,7 +385,8 @@ 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. +requires a certain knowledge to install and maintain. There are some important +performance problems with PostgreSQL in Bacula versions prior to 1.35.5. If you wish to use SQLite as the Bacula catalog, please see \ilink{Installing and Configuring SQLite}{_ChapterStart33} chapter of @@ -463,15 +400,6 @@ this manual. 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 @@ -489,293 +417,165 @@ The following command line options are available for {\bf configure} to customize your installation. \begin{description} -\item [ {-}{-}sysbindir=\lt{}binary-path\gt{}] - \index[general]{{-}{-}sysbindir } + +\item [ \verb?--?sysbindir=\lt{}binary-path\gt{}] + \index[dir]{\verb{--{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 [ {-}{-}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. - -\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. - +\item [ \verb?--?sysconfdir=\lt{}config-path\gt{}] + \index[dir]{\verb{--{sysconfdir } + Defines where the Bacula configuration files should be placed during a {\bf + make install} command. + +\item [ \verb?--?enable-smartalloc ] + \index[dir]{\verb{--{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 [ \verb?--?enable-gnome ] + \index[dir]{\verb{--{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 [ \verb?--?enable-wx-console ] + \index[console]{\verb{--{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 [ \verb?--?enable-tray-monitor ] + \index[dir]{\verb{--{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 [ \verb?--?enable-static-tools] + \index[dir]{\verb{--{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 [ \verb?--?enable-static-fd] + \index[fd]{\verb{--{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. + +\item [ \verb?--?enable-static-sd] + \index[sd]{\verb{--{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. -\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 } +\item [ \verb?--?enable-static-dir] + \index[dir]{\verb{--{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. + + +\item [ \verb?--?enable-static-cons] + \index[dir]{\verb{--{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. + +\item [ \verb?--?enable-client-only] + \index[console]{\verb{--{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. + +\item [ \verb?--?enable-largefile] + \index[console]{\verb{--{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 [ {-}{-}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 + revert to 32 bit file addresses by using {\bf \verb{--{disable-largefile}. + +\item [ \verb?--?with-sqlite=\lt{}sqlite-path\gt{}] + \index[fd]{\verb{--{with-sqlite } + This enables use of the SQLite 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{}] - \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. - -\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-python=\lt{}path\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. - -\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. - -\item [ {-}{-}enable-readline] - \index[general]{{-}{-}enable-readline } +\item [ \verb?--?with-mysql=\lt{}mysql-path\gt{}] + \index[fd]{\verb{--{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. If this option is not present, the build will + automatically include the internal Bacula database code. We recommend that + you use this option if possible. 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. + +\item [ \verb?--?with-postgresql=\lt{}path\gt{}] + \index[fd]{\verb{--{with-postgresql } + This provides an explicit path to the PostgreSQL libraries if Bacula cannot + find it by default. + +\item [ \verb?--?enable-conio] + \index[fd]{\verb{--{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 [ \verb?--?with-readline=\lt{}readline-path\gt{}] + \index[fd]{\verb{--{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 + \verb{--{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. + +\item [ \verb?--?enable-readline] + \index[fd]{\verb{--{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 } +\item [ \verb?--?with-tcp-wrappers=\lt{}path\gt{}] + \index[fd]{\verb{--{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. + be terminated. 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 } +\item [ \verb?--?with-working-dir=\lt{}working-directory-path\gt{} ] + \index[dir]{\verb{--{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 @@ -784,11 +584,11 @@ customize your installation. 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 } +\item [ \verb?--?with-base-port=\lt{}port=number\gt{}] + \index[dir]{\verb{--{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 + \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 @@ -797,20 +597,20 @@ customize your installation. 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 } +\item [ \verb?--?with-dump-email=\lt{}email-address\gt{}] + \index[dir]{\verb{--{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 } +\item [ \verb?--?with-pid-dir=\lt{}PATH\gt{} ] + \index[dir]{\verb{--{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 } +\item [ \verb?--?with-subsys-dir=\lt{}PATH\gt{}] + \index[dir]{\verb{--{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} @@ -818,73 +618,73 @@ customize your installation. 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 } +\item [ \verb?--?with-dir-password=\lt{}Password\gt{}] + \index[dir]{\verb{--{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 } +\item [ \verb?--?with-fd-password=\lt{}Password\gt{} ] + \index[fd]{\verb{--{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 } +\item [ \verb?--?with-sd-password=\lt{}Password\gt{} ] + \index[sd]{\verb{--{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 } +\item [ \verb?--?with-dir-user=\lt{}User\gt{} ] + \index[dir]{\verb{--{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 + doing preliminary initializations, it can ``drop'' to the UserId specified on this option. -\item [ {-}{-}with-dir-group=\lt{}Group\gt{} ] - \index[general]{{-}{-}with-dir-group } +\item [ \verb?--?with-dir-group=\lt{}Group\gt{} ] + \index[dir]{\verb{--{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 + 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 } +\item [ \verb?--?with-sd-user=\lt{}User\gt{} ] + \index[sd]{\verb{--{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 + 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 } +\item [ \verb?--?with-sd-group=\lt{}Group\gt{} ] + \index[sd]{\verb{--{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 + 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 } +\item [ \verb?--?with-fd-user=\lt{}User\gt{} ] + \index[fd]{\verb{--{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 + preliminary initializations, it can ``drop'' to the UserId specified on this option. -\item [ {-}{-}with-fd-group=\lt{}Group\gt{} ] - \index[general]{{-}{-}with-fd-group } +\item [ \verb?--?with-fd-group=\lt{}Group\gt{} ] + \index[fd]{\verb{--{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 + root, however, after doing preliminary initializations, it can ``drop'' to the GroupId specified on this option. \end{description} -Note, many other options are presented when you do a {\bf ./configure -\verb:--:help}, but they are not implemented. +Note, many other options are presented when you do a {\bf ./configure \verb{--{help}, +but they are not implemented. \subsection*{Recommended Options for most Systems} \index[general]{Systems!Recommended Options for most } @@ -908,8 +708,8 @@ For most systems, we recommend starting with the following options: 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 +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 @@ -978,12 +778,6 @@ CFLAGS="-g -Wall" ./configure \ 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). - \subsection*{Solaris} \index[general]{Solaris } \addcontentsline{toc}{subsection}{Solaris} @@ -1014,30 +808,6 @@ 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. -Note, you may need to install the following packages to build Bacula -from source: -\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} @@ -1070,11 +840,11 @@ To install the binary Win32 version of the File daemon please see the \addcontentsline{toc}{subsection}{Windows Systems with CYGWIN Installed} 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. +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 6.0 or greater. In Bacula +prior to version 1.33, CYGWIN was used. Details for building it are in the +README file of the src/win32 directory. Note, although most parts of Bacula build on Windows systems, the only part that we have tested and used is the File daemon. @@ -1087,7 +857,7 @@ Finally, you should follow the installation instructions in the \index[general]{Kern's Configure Script } \addcontentsline{toc}{subsection}{Kern's Configure Script} -The script that I use for building on my "production" Linux machines is: +The script that I use for building on my ``production'' Linux machines is: \footnotesize \begin{verbatim} @@ -1116,7 +886,7 @@ port 9101 for the Director console, port 9102 for the File daemons, and port 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. +default if you do not specify a {\bf \verb{--{with-baseport} option. 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 @@ -1145,7 +915,7 @@ make install \normalsize If you have previously installed Bacula, the old binaries will be overwritten, -but the old configuration files will remain unchanged, and the "new" +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}. @@ -1169,15 +939,14 @@ File daemon on the Client machine. To do so, you can use the same {\bf 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. - +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. \label{autostart} + \subsection*{Auto Starting the Daemons} \index[general]{Daemons!Auto Starting the } \index[general]{Auto Starting the Daemons } @@ -1196,15 +965,15 @@ make install-autostart \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. +Please note, that the auto-start feature is implemented only on systems that +we officially support (currently, FreeBSD, RedHat Linux, and Solaris), and has +only been fully tested on RedHat Linux. -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. +The {\bf make install-autostart} will cause the appropriate startup scripts to +be installed with the necessary symbolic links. On RedHat 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. If you only wish to install the File daemon, you may do so with: @@ -1313,7 +1082,7 @@ drop_mysql_tables fd gnome-console gnome-console.conf -make_bacula_tables +lymake_bacula_tables make_catalog_backup make_mysql_tables mtx-changer @@ -1334,7 +1103,7 @@ wx-console.conf \addcontentsline{toc}{subsection}{Installing Tray Monitor} The Tray Monitor is already installed if you used the {\bf -\verb:--:enable-tray-monitor} configure option and ran {\bf make install}. +\verb{--{enable-tray-monitor} configure option and ran {\bf make install}. 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 diff --git a/docs/manual-de/quickstart.tex b/docs/manual-de/quickstart.tex index 267b4616..2e751c53 100644 --- a/docs/manual-de/quickstart.tex +++ b/docs/manual-de/quickstart.tex @@ -18,39 +18,8 @@ want to first look at the \ilink{System Requirements}{SysReqs} then at the \ilink{Compiling and Installing Bacula}{_ChapterStart17} chapter of this manual. - -\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. - \label{PoolsVolsLabels} + \subsection*{Understanding Pools, Volumes and Labels} \index[general]{Labels!Understanding Pools Volumes and } \index[general]{Understanding Pools, Volumes and Labels } @@ -84,8 +53,8 @@ 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 +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 @@ -102,17 +71,15 @@ subject later. \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. +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 @@ -131,25 +98,22 @@ 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. 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 +\verb{--{sysconfdir} option that you specified on the {\bf ./configure} command and by default is named {\bf console.conf}. -If you choose to build the GNOME console with the {\bf \verb:--:enable-gnome} -option, +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}. 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 +\verb{--{enable-wx-console} option, and the name of the default configuration file is, in this case, {\bf wx-console.conf}. Normally, for first time users, no change is needed to these files. Reasonable defaults are set. \subsubsection*{ -\ilink{Configuring the Monitor Program}{_MonitorChapter}} +\ilink{Configuring the Monitor Program}{_ChapterStart35}} \index[general]{Program!Configuring the Monitor } \index[general]{Configuring the Monitor Program } \addcontentsline{toc}{subsubsection}{Configuring the Monitor Program} @@ -168,8 +132,7 @@ 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 +\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 @@ -187,9 +150,9 @@ 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 +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 @@ -206,8 +169,8 @@ 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}. +{\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 @@ -227,13 +190,8 @@ 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}, +the name {\bf foobaz-fd}. For the Director, you might 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. \subsubsection*{ \ilink{Configuring the Storage daemon}{_ChapterStart31}} @@ -246,7 +204,7 @@ 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} +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 @@ -297,19 +255,20 @@ conf file name). \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} +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 } @@ -319,14 +278,12 @@ compatibility of Bacula and your system. \label{notls} 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 +running, Bacula will either block for long periods or deadlock entirely. The +feedback that we have concerning 2.6 kernels is the same. However, on 2.6 +systems, 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. - \label{Running1} \subsection*{Running Bacula} @@ -348,6 +305,7 @@ you will get detailed instructions on how to run Bacula. \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 @@ -355,17 +313,6 @@ 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. -\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. - \subsection*{Disaster Recovery} \index[general]{Recovery!Disaster } diff --git a/docs/manual-de/requirements.tex b/docs/manual-de/requirements.tex index 7d2e0744..6eae1088 100644 --- a/docs/manual-de/requirements.tex +++ b/docs/manual-de/requirements.tex @@ -38,22 +38,19 @@ need them both loaded. On RedHat systems, the C++ compiler is part of the 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. + stable ANSI (not Unicode) version of + \elink{wxWidgets}{http://www.wxwidgets.org/} (2.6.0). 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}. +\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 If you want to use DVD as backup medium, you will need to download and + install the + \elink{dvd+rw-tools}{http://fy.chalmers.se/~appro/linux/DVD+RW/}. \end{itemize} diff --git a/docs/manual-de/state.tex b/docs/manual-de/state.tex index 8bdedd89..39634318 100644 --- a/docs/manual-de/state.tex +++ b/docs/manual-de/state.tex @@ -9,8 +9,8 @@ In other words, what is and what is not currently implemented and functional. \subsection*{What is Implemented} -\index[general]{Implemented!What} -\index[general]{What is Implemented} +\index[general]{Implemented!What is } +\index[general]{What is Implemented } \addcontentsline{toc}{subsection}{What is Implemented} \begin{itemize} @@ -71,29 +71,26 @@ In other words, what is and what is not currently implemented and functional. \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 Saves and restores POSIX ACLs 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 + 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 Support for Unicode filenames (e.g. Chinese) on Win32 machines. + \end{itemize} \subsection*{Advantages of Bacula Over Other Backup Programs} @@ -162,27 +159,29 @@ In other words, what is and what is not currently implemented and functional. \addcontentsline{toc}{subsection}{Current Implementation Restrictions} \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 Typical of Microsoft, not all files can always be saved on WinNT, Win2K + and WinXP when they are in use by another program. Anyone knowing the magic + incantations, please step forward. The files that are skipped seem to be in + exclusive use by some other process, and don't appear to be too important. \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 Event handlers are not yet implemented (e.g. when Job terminates do + this, ...) \item File System Modules (configurable routines for saving/restoring special - files) are not yet implemented. + files). \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 There is no concept of a Pool of backup devices (i.e. if device + /dev/nst0 is busy, use /dev/nst1, ...). + \end{itemize} \subsection*{Design Limitations or Restrictions} \index[general]{Restrictions!Design Limitations or } @@ -194,7 +193,4 @@ In other words, what is and what is not currently implemented and functional. 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. \end{itemize} diff --git a/docs/manual-de/supporteddrives.tex b/docs/manual-de/supporteddrives.tex index 676e9fc2..bfb73edd 100644 --- a/docs/manual-de/supporteddrives.tex +++ b/docs/manual-de/supporteddrives.tex @@ -35,9 +35,7 @@ unknown: \multicolumn{1}{c| }{\bf Capacity } \\ \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 {- } & {HP } & {Travan 4 } & {Colorado T4000S } & {- } \\ @@ -48,7 +46,6 @@ unknown: \hline {- } & {Overland } & {LTO } & {LoaderXpress LTO } & {- } \\ \hline {- } & {Overland } & {- } & {Neo2000 } & {- } \\ \hline {- } & {OnStream } & {- } & {OnStream drives (see below) } & {- } \\ - \hline {FreeBSD 4.11-Release} & {Quantum } & {SDLT } & {SDLT320 } & {160/320GB } \\ \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 } \\ @@ -85,10 +82,10 @@ with Bacula. \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 +Unless you have patched the pthreads library on most FreeBSD 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 +near. 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. @@ -101,51 +98,3 @@ compatibility with Bacula. For information on supported autochangers, please see the \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} diff --git a/docs/manual-de/supportedoses.tex b/docs/manual-de/supportedoses.tex index c24d4bca..97bf1aab 100644 --- a/docs/manual-de/supportedoses.tex +++ b/docs/manual-de/supportedoses.tex @@ -22,7 +22,7 @@ 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 +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. -- 2.39.5