The following people or organizations have made
donations or supplied finacial development support
-to the Bacula project:
+to the Bacula project and have specifically requested
+that their names appear here:
$50 TightPoker.com (Hans)
</td>
</tr>
<tr>
- <td class="content">
+ <td class="content">
Below, you will find excerpts from email that users have sent us.
The purpose is to give you some idea of what kinds of
sites are running Bacula and how they are using it.
These testimonials are used with permission of the author.
- </td>
+ </td>
</tr>
<tr>
- <td class="content">
+ <td class="content">
<h3 style="padding: 5px; border-bottom: 1px dotted #002244"> Norm Dressler - 2004/06/15 </h3>
Bacula has been awesome for us. We used to use Ar**** but I
have always hated the interface. And the cost was outrageous.
Whenever someone asks me about what to use, I point them at
Bacula.
<p> Norm Dressler, Senior Network Architect</p>
- </td>
+ </td>
</tr>
<tr>
- <td class="content">
+ <td class="content">
<h3 style="padding: 5px; border-bottom: 1px dotted #002244"> Michael Scherer - 2005/02/09 </h3>
Our former backup-system was ARGHserve running on NT4.
Due to the fact that we replaced most of our servers with
<br>
<p> Michael Scherer, some admin </p>
- </td>
+ </td>
</tr>
<tr>
- <td class="content">
+ <td class="content">
<h3 style="padding: 5px; border-bottom: 1px dotted #002244"> Ludovicz Strappazon - 2005/03/05</h3>
- I had previously used Veritas Netbackup, but it was really too expensive
- for our University. Bacula permitted us to buy a library. Now, we use
- Bacula since 10/2002 with an ADIC Scalar 24 library and LTO ultrium,
- without any problems. I think it can do anything Netbackup could do with our
- configuration. We backup seven Linux servers, one NT server, four
- Windows 2003 servers and a few XP workstations. Some of these servers
- are backed up across a firewall using ssh; some others are on a private
- network. We tried succesfully the disaster recovery procedure on Linux
- and had some good results in restoring Windows "from bare metal". What do I
- like in Bacula ? It is very flexible and reliable. With its light
- interface console, I can manage the backups from everywhere. A few words
- about the support : it is free but efficient. I don't have to cross a
- level 1, level 2 helpdesk to have some help, I never felt alone, and the
- bacula-users mailing list is a mix of courtesy and honest speech. At
- last, you don't need to be a big company to have your features requests
- heard.<br>
- Thanks to Kern Sibbald and the others who give so much work and time
- for this project.<br>
- <br>
- Ludovic Strappazon<br>
- University Marc Bloch de Strasbourg.<br>
- </td>
+ I had previously used Veritas Netbackup, but it was really too expensive
+ for our University. Bacula permitted us to buy a library. Now, we use
+ Bacula since 10/2002 with an ADIC Scalar 24 library and LTO ultrium,
+ without any problems. I think it can do anything Netbackup could do with our
+ configuration. We backup seven Linux servers, one NT server, four
+ Windows 2003 servers and a few XP workstations. Some of these servers
+ are backed up across a firewall using ssh; some others are on a private
+ network. We tried succesfully the disaster recovery procedure on Linux
+ and had some good results in restoring Windows "from bare metal". What do I
+ like in Bacula ? It is very flexible and reliable. With its light
+ interface console, I can manage the backups from everywhere. A few words
+ about the support : it is free but efficient. I don't have to cross a
+ level 1, level 2 helpdesk to have some help, I never felt alone, and the
+ bacula-users mailing list is a mix of courtesy and honest speech. At
+ last, you don't need to be a big company to have your features requests
+ heard.<br>
+ Thanks to Kern Sibbald and the others who give so much work and time
+ for this project.<br>
+ <br>
+ Ludovic Strappazon<br>
+ University Marc Bloch de Strasbourg.<br>
+ </td>
</tr>
+
+<tr>
+ <td class="content">
+ <h3 style="padding: 5px; border-bottom: 1px dotted #002244"> Jeff Richards - 2006/08/26</h3>
+ I used Bacula at my previous employer to backup: Linux, OpenBSD, Windows 2000,XP,2003, and AIX 5.1
+ <br> <br>
+ Bacula provided a solution when I had no budget for backup
+ software. The Linux systems (about 30) acted as Tivoli (TMF)
+ gateways. The Linux systems were commodity PCs, so when the IDE
+ HDs failed it took hours (usually at least 4) to clean up the
+ Tivoli environment and rebuild the failed gateway. Using Bacula
+ and mkCDrec I cut that time down to under an hour, and most of
+ that time was not spent doing anything except waiting for the
+ restore to finish. I recovered 2 failed Linux systems with
+ Bacula.
+ <br>
+ I would like to thank you and the entire Bacula team for an
+ excellent piece of software.
+ <br> <br>
+ Jeff Richards<br>
+ Consultant<br>
+ </td>
+</tr>
+
</table>
<? require_once("inc/footer.php"); ?>
lower case characters and spaces.
Each resource definition MUST contain a Name directive, and may optionally
-contain a Description directive (or record). The Name directive is used to
+contain a Description directive. The Name directive is used to
uniquely identify the resource. The Description directive is (will be) used
during display of the Resource to provide easier human recognition. For
example:
\$HOME/bacula/bin/working. In general, if you want spaces in a name to the
right of the first equal sign (=), you must enclose that name within double
quotes. Otherwise quotes are not generally necessary because once defined,
-quoted strings and unquoted strings are all equal.
-\label{Comments}
+quoted strings and unquoted strings are all equal.
+\label{Comments}
\subsubsection*{Comments}
-\index[general]{Comments }
+\index[general]{Comments}
\addcontentsline{toc}{subsubsection}{Comments}
When reading the configuration file, blank lines are ignored and everything
\label{Case1}
\subsubsection*{Upper and Lower Case and Spaces}
-\index[general]{Spaces!Upper and Lower Case and }
-\index[general]{Upper and Lower Case and Spaces }
+\index[general]{Spaces!Upper/Lower Case}
+\index[general]{Upper and Lower Case and Spaces}
\addcontentsline{toc}{subsubsection}{Upper and Lower Case and Spaces}
Case (upper/lower) and spaces are totally ignored in the resource directive
be accepted. Names may contain up to 127 characters. Currently, a name may
contain any ASCII character. Within a quoted string, any character following a
backslash (\textbackslash{}) is taken as itself (handy for inserting
-blackslashes and double quotes (").
+blackslashes and double quotes (").
Please note, however, that Bacula resource names as well as certain other
-names (e.g. Volume names) will in the future be severely limited to permit
-only letters (including ISO accented letters), numbers, and a few special
-characters (space, underscore, ...). All other characters and punctuation will
-be illegal.
-\label{Includes}
+names (e.g. Volume names) must contain only letters (including ISO accented
+letters), numbers, and a few special characters (space, underscore, ...).
+All other characters and punctuation are illegal.
+\label{Includes}
\subsubsection*{Including other Configuration Files}
\index[general]{Including other Configuration Files }
\index[general]{Files!Including other Configuration }
If you wish to break your configuration file into smaller pieces, you can do
so by including other files using the syntax @{\bf filename} where {\bf
filename} is the full path and filename of another file. The @filename
-specification can be given anywhere a primitive token would appear.
-\label{DataTypes}
+specification can be given anywhere a primitive token would appear.
+\label{DataTypes}
\subsubsection*{Recognized Primitive Data Types}
\index[general]{Types!Recognized Primitive Data }
\index[general]{Recognized Primitive Data Types }
be quoted.
\item [name-string]
- \index[fd]{name-string }
+ \index[fd]{name-string}
A name-string is similar to a name, except that the name may be quoted and
can thus contain additional characters including spaces. Name strings are
limited to 127 characters in length. Name strings are typically used on the
\item [string]
- \index[fd]{string }
+ \index[fd]{string}
A quoted string containing virtually any character including spaces, or a
non-quoted string. A string may be of any length. Strings are typically
values that correspond to filenames, directories, or system command names. A
backslash. Likewise to include a backslash.
\item [directory]
- \index[dir]{directory }
+ \index[dir]{directory}
A directory is either a quoted or non-quoted string. A directory will be
passed to your standard shell for expansion when it is scanned. Thus
constructs such as {\bf \$HOME} are interpreted to be their correct values.
\item [password]
- \index[dir]{password }
- This is a Bacula password and it is stored internally in MD5 hashed format.
+ \index[dir]{password}
+ This is a Bacula password and it is stored internally in MD5 hashed format.
\item [integer]
- \index[dir]{integer }
- A 32 bit integer value. It may be positive or negative.
+ \index[dir]{integer}
+ A 32 bit integer value. It may be positive or negative.
\item [positive integer]
\index[dir]{positive integer }
A 32 bit positive integer value.
\item [long integer]
- \index[dir]{long integer }
+ \index[dir]{long integer}
A 64 bit integer value. Typically these are values such as bytes that can
exceed 4 billion and thus require a 64 bit value.
\label{Size1}
\item [size]
-\index[dir]{size }
+\index[dir]{size}
A size specified as bytes. Typically, this is a floating point scientific
input format followed by an optional modifier. The floating point input is
stored as a 64 bit integer value. If a modifier is present, it must
\begin{description}
\item [seconds]
- \index[dir]{seconds }
- seconds
+ \index[dir]{seconds}
+ seconds
\item [minutes]
- \index[dir]{minutes }
+ \index[dir]{minutes}
minutes (60 seconds)
\item [hours]
hours (3600 seconds)
\item [days]
- \index[dir]{days }
+ \index[dir]{days}
days (3600*24 seconds)
\item [weeks]
- \index[dir]{weeks }
- weeks (3600*24*7 seconds)
+ \index[dir]{weeks}
+ weeks (3600*24*7 seconds)
\item [months]
\index[dir]{months }
In addition, there is a wx-console built with wxWidgets that allows a graphic
restore of files. As of version 1.34.1 it is in an early stage of development,
-but it already is quite useful.
+but it already is quite useful. Unfortunately, it has not been enhanced for
+some time now.
Since the Console program interacts with the Director through the network, your
Console and Director programs do not necessarily need to run on the same
Used in the restore command. Its argument specifies the directory
to be restored.
\item [enabled]
- This keyword can appear on the {\bf update volume} command, and can
+ This keyword can appear on the {\bf update volume} as well
+ as the {\bf update slots} commands, and can
allows one of the following arguments: yes, true, no, false, archived,
0, 1, 2. Where 0 corresponds to no or false, 1 corresponds to yes or true, and
2 corresponds to archived. Archived volumes will not be used, nor will
\index[console]{mount}
The mount command is used to get Bacula to read a volume on a physical
device. It is a way to tell Bacula that you have mounted a tape and
- that Bacula should examine the tape. This command is used only after
- there was no Volume in a drive and Bacula requests you to mount a new
+ that Bacula should examine the tape. This command is normally
+ used only after there was no Volume in a drive and Bacula requests you to mount a new
Volume or when you have specifically unmounted a Volume with the {\bf
unmount} console command, which causes Bacula to close the drive. If
you have an autoloader, the mount command will not cause Bacula to
- operate the autoloader. The various forms of the mount command are:
+ operate the autoloader unless you specify a {\bf slot} and possibly a
+ {\bf drive}. The various forms of the mount command are:
-mount storage=\lt{}storage-name\gt{}
+mount storage=\lt{}storage-name\gt{} [ slot=\lt{}num\gt{} ] [
+ drive=\lt{}num\gt{} ]
mount [ jobid=\lt{}id\gt{} | job=\lt{}job-name\gt{} ]
specified device. The forms of the command are the same as the mount command:
\footnotesize
\begin{verbatim}
-unmount storage=<storage-name>
+unmount storage=<storage-name> [ drive=\lt{}num\gt{} ]
unmount [ jobid=<id> | job=<job-name> ]
\end{verbatim}
\normalsize
+ Once you unmount a storage device, Bacula will no longer be able to use
+ it until you issue a mount command for that device. If Bacula needs to
+ access that device, it will block and issue mount requests periodically
+ to the operator.
+
+ If the device you are unmounting is an autochanger, it will unload
+ the drive you have specified on the command line. If no drive is
+ specified, it will assume drive 1.
+
\label{UpdateCommand}
\item [update]
\index[console]{update}
simply contains the information necessary to contact the Director or
Directors.
-For a general discussion of configuration file and resources including the
-data types recognized by {\bf Bacula}, please see the
-\ilink{Configuration}{_ChapterStart16} chapter of this manual.
+For a general discussion of the syntax of configuration files and their
+resources including the data types recognized by {\bf Bacula}, please see
+the \ilink{Configuration}{_ChapterStart16} chapter of this manual.
The following Console Resource definition must be defined:
choose one when you start the {\bf Console} program.
\begin{description}
-
\item [Director]
\index[console]{Director}
Start of the Director directives.
\item [Password = \lt{}password\gt{}]
\index[dir]{Password}
Where the password is the password needed for the Director to accept the
-Console connection. This password must be identical to the {\bf Password}
-specified in the {\bf Director} resource of the
-\ilink{Director's configuration}{_ChapterStart40} file. This
-directive is required.
+ Console connection. This password must be identical to the {\bf Password}
+ specified in the {\bf Director} resource of the
+ \ilink{Director's configuration}{_ChapterStart40} file. This
+ directive is required.
\end{description}
An actual example might be:
\begin{verbatim}
ConsoleFont {
Name = Default
-Font = "Monospace 10"
+ Font = "Monospace 10"
}
\end{verbatim}
\normalsize
\item The first console type is an {\bf anonymous} or {\bf default} console,
which has full privileges. There is no console resource necessary for this
type since the password is specified in the Director resource. This is the
-kind of console that was initially implemented in versions prior to 1.33 and
-remains valid. Typically you would use it only for administrators.
-\item The second type of console, and new to version 1.33 and higher is a
- "named" console defined within a Console resource in both the Director's
- configuration file and in the Console's configuration file. Both the names
-and the passwords in these two entries must match much as is the case for
-Client programs.
-
-This second type of console begins with absolutely no privileges except those
-explicitly specified in the Director's Console resource. Thus you can have
-multiple Consoles with different names and passwords, sort of like multiple
-users, each with different privileges. As a default, these consoles can do
-absolutely nothing -- no commands what so ever. You give them privileges or
-rather access to commands and resources by specifying access control lists in
-the Director's Console resource. Note, if you are specifying such a console,
-you will want to put a null password in the Director resource.
-\item The third type of console is similar to the above mentioned one in that
- it requires a Console resource definition in both the Director and the
- Console. In addition, if the console name, provided on the {\bf Name =}
-directive, is the same as a Client name, the user of that console is
-permitted to use the {\bf SetIP} command to change the Address directive in
-the Director's client resource to the IP address of the Console. This permits
-portables or other machines using DHCP (non-fixed IP addresses) to
-"notify" the Director of their current IP address.
+ kind of console that was initially implemented in versions prior to 1.33 and
+ remains valid. Typically you would use it only for administrators.
+
+\item The second type of console, and new to version 1.33 and higher is a
+ "named" or "restricted" console defined within a Console resource in
+ both the Director's configuration file and in the Console's
+ configuration file. Both the names and the passwords in these two
+ entries must match much as is the case for Client programs.
+
+ This second type of console begins with absolutely no privileges except
+ those explicitly specified in the Director's Console resource. Note,
+ the definition of what these restricted consoles can do is determined
+ by the Director's conf file.
+
+ Thus you may define within the Director's conf file multiple Consoles
+ with different names and passwords, sort of like multiple users, each
+ with different privileges. As a default, these consoles can do
+ absolutely nothing -- no commands what so ever. You give them
+ privileges or rather access to commands and resources by specifying
+ access control lists in the Director's Console resource. This gives the
+ administrator fine grained control over what particular consoles (or
+ users) can do.
+
+\item The third type of console is similar to the above mentioned
+ restricted console in that it requires a Console resource definition in
+ both the Director and the Console. In addition, if the console name,
+ provided on the {\bf Name =} directive, is the same as a Client name,
+ the user of that console is permitted to use the {\bf SetIP} command to
+ change the Address directive in the Director's client resource to the IP
+ address of the Console. This permits portables or other machines using
+ DHCP (non-fixed IP addresses) to "notify" the Director of their current
+ IP address.
\end{itemize}
The Console resource is optional and need not be specified. However, if it is
configuration file to restrict the particular console (or user) to see only
information pertaining to his jobs or client machine.
+You may specify as many Console resources in the console's conf file. If
+you do so, generally the first Console resource will be used. However, if
+you have multiple Director resources (i.e. you want to connect to different
+directors), you can bind one of your Console resources to a particular
+Director resource, and thus when you choose a particular Director, the
+appropriate Console configuration resource will be used. See the "Director"
+directive in the Console resource described below for more information.
+
+Note, the Console resource is optional, but can be useful for
+restricted consoles as noted above.
+
+\begin{description}
+\item [Console]
+ \index[console]{Console}
+ Start of the Console resource.
+
+\item [Name = \lt{}name\gt{}]
+ \index[console]{Name}
+ The Console name used to allow a restricted console to change
+ its IP address using the SetIP command. The SetIP command must
+ also be defined in the Director's conf CommandACL list.
+
+
+\item [Password = \lt{}password\gt{}]
+ \index[dir]{Password}
+ If this password is supplied, then the password specified in the
+ Director resource of you Console conf will be ignored. See below
+ for more details.
+
+\item [Director = \lt{}director-resource-name\gt{}]
+ If this directive is specified, this Console resource will be
+ used by bconsole when that particular director is selected
+ when first starting bconsole. I.e. it binds a particular console
+ resource with its name and password to a particular director.
+\end{description}
+
+
The following configuration files were supplied by Phil Stracchino. For
example, if we define the following in the user's bconsole.conf file (or
perhaps the wx-console.conf file):
\footnotesize
\begin{verbatim}
- Director {
+Director {
Name = MyDirector
DIRport = 9101
Address = myserver
Password = "XXXXXXXXXXX" # no, really. this is not obfuscation.
}
+
- Console {
+Console {
Name = restricted-user
Password = "UntrustedUser"
}
run} command. In other words, this user is rather limited in what he can see
and do with Bacula.
+The following is an example of a bconsole conf file that can access
+several Directors and has different Consoles depending on the director:
+
+Director {
+ Name = MyDirector
+ DIRport = 9101
+ Address = myserver
+ Password = "XXXXXXXXXXX" # no, really. this is not obfuscation.
+}
+
+Director {
+ Name = SecondDirector
+ DIRport = 9101
+ Address = secondserver
+ Password = "XXXXXXXXXXX" # no, really. this is not obfuscation.
+}
+
+Console {
+ Name = restricted-user
+ Password = "UntrustedUser"
+ Director = MyDirector
+}
+
+Console {
+ Name = restricted-user
+ Password = "A different UntrustedUser"
+ Director = SecondDirector
+}
+\end{verbatim}
+\normalsize
+
+The second Director referenced at "secondserver" might look
+like the following:
+
+\footnotesize
+\begin{verbatim}
+Console {
+ Name = restricted-user
+ Password = "A different UntrustedUser"
+ JobACL = "Restricted Client Save"
+ ClientACL = restricted-client
+ StorageACL = second-storage
+ ScheduleACL = *all*
+ PoolACL = *all*
+ FileSetACL = "Restricted Client's FileSet"
+ CatalogACL = RestrictedCatalog
+ CommandACL = run, restore
+ WhereACL = "/"
+}
+\end{verbatim}
+\normalsize
+
+
+
\subsection*{Console Commands}
\index[general]{Console Commands}
\index[general]{Commands!Console}
it will pipe the bootstrap record. It could for example be a shell
script that emails you the bootstrap record.
- On versions 1.40 or greater, before openning the file or execute the
+ On versions 1.39.22 or greater, before openning the file or execute the
specified command, Bacula performs
\ilink{character substitution}{character substitution} like in RunScript
directive. To manage automatically yours bootstrap files, you can use
is {\bf yes}, it will override the value specified in the Client
resource. The default is {\bf no}.
-\item [RunScript \{...\}]
+\item [RunScript \{\lt{}body-of-runscript\gt{}\}]
\index[dir]{RunScript}
\index[dir]{Directive!Run Script}
- This directive is only implemented in version 1.40 and later.
- The specified {\bf command} is run as an external program prior or after the
- current Job. This is optional.
+ This directive is only implemented in version 1.39.22 and later.
+ The RunScript directive behaves more like a resource in that it
+ requires opening and closing braces around a number of directives
+ that make up the body of the runscript.
- You can use following options:\\
+ The specified {\bf Command} (see below for details) is run as an
+ external program prior or after the current Job. This is optional.
+
+ You can use following options may be specified in the body
+ of the runscript:\\
\begin{tabular}{|c|c|c|l}
-Options & Value & Default & Informations \\
+Options & Value & Default & Information \\
\hline
\hline
Runs On Success & Yes/No & {\it Yes} & Run command if JobStatus is successful\\
\hline
Runs When & Before|After|Always & {\it Never} & When run commands\\
\hline
-Abort Job On Error & Yes/No & {\it Yes} & Abort job if script return
+Abort Job On Error & Yes/No & {\it Yes} & Abort job if script returns
something different from 0 \\
\hline
Command & & & Path to your script\\
Client Run After Failed Job & No & Yes & & Yes & After \\
\end{tabular}
-Example :
+Examples:
\begin{verbatim}
RunScript {
RunsWhen = Before
}
\end{verbatim}
- Lutz Kittler has pointed out that using the RunBeforJob directive can be a
+ Lutz Kittler has pointed out that using the RunBeforeJob directive can be a
simple way to modify your schedules during a holiday. For example, suppose
that you normally do Full backups on Fridays, but Thursday and Friday are
holidays. To avoid having to change tapes between Thursday and Friday when
\index[dir]{FD Port}
\index[dir]{Directive!FD Port}
Where the port is a port number at which the Bacula File server daemon can
-be
-contacted. The default is 9102.
+ be contacted. The default is 9102.
\item [Catalog = \lt{}Catalog-resource-name\gt{}]
\index[dir]{Catalog}
\index[dir]{Directive!Catalog}
This specifies the name of the catalog resource to be used for this Client.
-This directive is required.
+ This directive is required.
\item [Password = \lt{}password\gt{}]
\index[dir]{Password}
\index[dir]{Directive!Password}
This is the password to be used when establishing a connection with the File
-services, so the Client configuration file on the machine to be backed up
-must have the same password defined for this Director. This directive is
-required. If you have either {\bf /dev/random} {\bf bc} on your machine,
-Bacula will generate a random password during the configuration process,
-otherwise it will be left blank.
-\label{FileRetention}
+ services, so the Client configuration file on the machine to be backed up
+ must have the same password defined for this Director. This directive is
+ required. If you have either {\bf /dev/random} {\bf bc} on your machine,
+ Bacula will generate a random password during the configuration process,
+ otherwise it will be left blank.
+\label{FileRetention}
\item [File Retention = \lt{}time-period-specification\gt{}]
\index[dir]{File Retention}
\index[dir]{Directive!File Retention}
The File Retention directive defines the length of time that Bacula will
-keep
-File records in the Catalog database. When this time period expires, and if
-{\bf AutoPrune} is set to {\bf yes} Bacula will prune (remove) File records
-that are older than the specified File Retention period. Note, this affects
-only records in the catalog database. It does not affect your archive
-backups.
-
-File records may actually be retained for a shorter period than you specify
-on this directive if you specify either a shorter {\bf Job Retention} or a
-shorter {\bf Volume Retention} period. The shortest retention period of the
-three takes precedence. The time may be expressed in seconds, minutes,
-hours, days, weeks, months, quarters, or years. See the
-\ilink{ Configuration chapter}{Time} of this manual for
-additional details of time specification.
-
-The default is 60 days.
+ keep File records in the Catalog database after the End time of the
+ Job corresponding to the File records.
+ When this time period expires, and if
+ {\bf AutoPrune} is set to {\bf yes} Bacula will prune (remove) File records
+ that are older than the specified File Retention period. Note, this affects
+ only records in the catalog database. It does not affect your archive
+ backups.
+
+ File records may actually be retained for a shorter period than you specify
+ on this directive if you specify either a shorter {\bf Job Retention} or a
+ shorter {\bf Volume Retention} period. The shortest retention period of the
+ three takes precedence. The time may be expressed in seconds, minutes,
+ hours, days, weeks, months, quarters, or years. See the
+ \ilink{ Configuration chapter}{Time} of this manual for
+ additional details of time specification.
+
+ The default is 60 days.
\label{JobRetention}
\item [Job Retention = \lt{}time-period-specification\gt{}]
\index[dir]{Job Retention}
\index[dir]{Directive!Job Retention}
The Job Retention directive defines the length of time that Bacula will keep
- Job records in the Catalog database. When this time period expires, and if
- {\bf AutoPrune} is set to {\bf yes} Bacula will prune (remove) Job records
- that are older than the specified File Retention period. As with the other
- retention periods, this affects only records in the catalog and not data in
- your archive backup.
-
-If a Job record is selected for pruning, all associated File and JobMedia
-records will also be pruned regardless of the File Retention period set.
-As a consequence, you normally will set the File retention period to be
-less than the Job retention period. The Job retention period can actually
-be less than the value you specify here if you set the {\bf Volume
-Retention} directive in the Pool resource to a smaller duration. This is
-because the Job retention period and the Volume retention period are
-independently applied, so the smaller of the two takes precedence.
-
-The Job retention period is specified as seconds, minutes, hours, days,
-weeks, months, quarters, or years. See the
-\ilink{ Configuration chapter}{Time} of this manual for
-additional details of time specification.
-
-The default is 180 days.
-\label{AutoPrune}
+ Job records in the Catalog database after the Job End time. When
+ this time period expires, and if {\bf AutoPrune} is set to {\bf yes}
+ Bacula will prune (remove) Job records that are older than the specified
+ File Retention period. As with the other retention periods, this
+ affects only records in the catalog and not data in your archive backup.
+
+ If a Job record is selected for pruning, all associated File and JobMedia
+ records will also be pruned regardless of the File Retention period set.
+ As a consequence, you normally will set the File retention period to be
+ less than the Job retention period. The Job retention period can actually
+ be less than the value you specify here if you set the {\bf Volume
+ Retention} directive in the Pool resource to a smaller duration. This is
+ because the Job retention period and the Volume retention period are
+ independently applied, so the smaller of the two takes precedence.
+
+ The Job retention period is specified as seconds, minutes, hours, days,
+ weeks, months, quarters, or years. See the
+ \ilink{ Configuration chapter}{Time} of this manual for
+ additional details of time specification.
+
+ The default is 180 days.
+\label{AutoPrune}
\item [AutoPrune = \lt{}yes|no\gt{}]
\index[dir]{AutoPrune}
\index[dir]{Directive!AutoPrune}
are performed first (not currently implemented).
\end{description}
-The following is an example of a valid Client resource definition:
+ The following is an example of a valid Client resource definition:
\footnotesize
\begin{verbatim}
\index[dir]{Name}
\index[dir]{Directive!Name}
The name of the storage resource. This name appears on the Storage directive
-specified in the Job resource and is required.
+ specified in the Job resource and is required.
\item [Address = \lt{}address\gt{}]
\index[dir]{Address}
\index[dir]{Directive!SD Address}
\index[dir]{Storage daemon Address}
Where the address is a host name, a {\bf fully qualified domain name}, or an
-{\bf IP address}. Please note that the \lt{}address\gt{} as specified here
-will be transmitted to the File daemon who will then use it to contact the
-Storage daemon. Hence, it is {\bf not}, a good idea to use {\bf localhost} as
-the name but rather a fully qualified machine name or an IP address. This
-directive is required.
+ {\bf IP address}. Please note that the \lt{}address\gt{} as specified here
+ will be transmitted to the File daemon who will then use it to contact the
+ Storage daemon. Hence, it is {\bf not}, a good idea to use {\bf localhost} as
+ the name but rather a fully qualified machine name or an IP address. This
+ directive is required.
\item [SD Port = \lt{}port\gt{}]
\index[dir]{SD Port}
\index[dir]{Directive!SD Port}
Where port is the port to use to contact the storage daemon for information
-and to start jobs. This same port number must appear in the Storage resource
-of the Storage daemon's configuration file. The default is 9103.
+ and to start jobs. This same port number must appear in the Storage resource
+ of the Storage daemon's configuration file. The default is 9103.
\item [Password = \lt{}password\gt{}]
\index[dir]{Password}
\index[dir]{Directive!Password}
This is the password to be used when establishing a connection with the
-Storage services. This same password also must appear in the Director
-resource of the Storage daemon's configuration file. This directive is
-required. If you have either {\bf /dev/random} {\bf bc} on your machine,
-Bacula will generate a random password during the configuration process,
-otherwise it will be left blank.
+ Storage services. This same password also must appear in the Director
+ resource of the Storage daemon's configuration file. This directive is
+ required. If you have either {\bf /dev/random} {\bf bc} on your machine,
+ Bacula will generate a random password during the configuration process,
+ otherwise it will be left blank.
\item [Device = \lt{}device-name\gt{}]
\index[dir]{Device}
\item [AutoPrune = \lt{}yes|no\gt{}]
\index[dir]{AutoPrune}
\index[dir]{Directive!AutoPrune}
- If AutoPrune is set to {\bf yes} (default), Bacula (version 1.20 or greater)
- will automatically apply the Volume Retention period when new Volume is
- needed and no appendable Volumes exist in the Pool. Volume pruning causes
- expired Jobs (older than the {\bf Volume Retention} period) to be deleted
- from the Catalog and permits possible recycling of the Volume.
+ If AutoPrune is set to {\bf yes} (default), Bacula (version 1.20 or
+ greater) will automatically apply the Volume Retention period when new
+ Volume is needed and no appendable Volumes exist in the Pool. Volume
+ pruning causes expired Jobs (older than the {\bf Volume Retention}
+ period) to be deleted from the Catalog and permits possible recycling of
+ the Volume.
\label{VolRetention}
\item [Volume Retention = \lt{}time-period-specification\gt{}]
\index[dir]{Volume Retention}
\index[dir]{Directive!Volume Retention}
The Volume Retention directive defines the length of time that {\bf
- Bacula} will keep Job records associated with the Volume in the Catalog
- database. When this time period expires, and if {\bf AutoPrune} is set
- to {\bf yes} Bacula may prune (remove) Job records that are older than
- the specified Volume Retention period if it is necessary to free up a
+ Bacula} will keep Job and Files records associated with the Volume in
+ the Catalog database after the End time of each Job written to the
+ Volume. When this time period expires, and if {\bf AutoPrune} is set to
+ {\bf yes} Bacula may prune (remove) Job records that are older than the
+ specified Volume Retention period if it is necessary to free up a
Volume. Recycling will not occur until it is absolutely necessary to
free up a volume. All File records associated with pruned Jobs are also
pruned. The time may be specified as seconds, minutes, hours, days,
the retentions periods are applied in turn and that the shorter period
is the one that effectively takes precedence. Note, that when the {\bf
Volume Retention} period has been reached, and it is necessary to obtain
- a new volume, Bacula will prune both the Job and the File records.
- This pruning could also occur during a {\bf status dir}
- command because it uses similar algorithms for finding the
- next available Volume.
+ a new volume, Bacula will prune both the Job and the File records. This
+ pruning could also occur during a {\bf status dir} command because it
+ uses similar algorithms for finding the next available Volume.
It is important to know that when the Volume Retention period expires,
Bacula does not automatically recycle a Volume. It attempts to keep the
for an existing Volume you must use the {\bf update} command in the
Console.
+ When all Job and File records have been pruned or purged from the
+ catalog for a particular Volume, if that Volume is marked as
+ Append, Full, Used, or Error, it will then be marked as Purged. Only
+ Volumes marked as Purged will be considered to be converted to the
+ Recycled state if the {\bf Recycle} directive is set to {\bf yes}.
+
+
\label{RecycleOldest}
\item [Recycle Oldest Volume = \lt{}yes|no\gt{}]
\index[dir]{Recycle Oldest Volume}
\index[dir]{ScheduleACL}
\index[dir]{Directive!ScheduleACL}
This directive is used to specify a list of Schedule resource names that can
-be accessed by the console.
+ be accessed by the console.
\item [PoolACL = \lt{}name-list\gt{}]
\index[dir]{PoolACL}
\index[dir]{Directive!PoolACL}
This directive is used to specify a list of Pool resource names that can be
-accessed by the console.
+ accessed by the console.
\item [FileSetACL = \lt{}name-list\gt{}]
\index[dir]{FileSetACL}
\index[dir]{Directive!FileSetACL}
- This directive is used to specify a list of FileSet resource names that can
-be accessed by the console.
+ This directive is used to specify a list of FileSet resource names that
+ can be accessed by the console.
\item [CatalogACL = \lt{}name-list\gt{}]
\index[dir]{CatalogACL}
\index[dir]{Directive!CatalogACL}
- This directive is used to specify a list of Catalog resource names that can
-be accessed by the console.
+ This directive is used to specify a list of Catalog resource names that
+ can be accessed by the console.
\item [CommandACL = \lt{}name-list\gt{}]
\index[dir]{CommandACL}
\index[dir]{Directive!CommandACL}
- This directive is used to specify a list of of console commands that can be
-executed by the console.
+ This directive is used to specify a list of of console commands that can
+ be executed by the console.
+
+\item [WhereACL = \lt{}string\gt{}]
+ \index[dir]{WhereACL}
+ \index[dir]{Directive!WhereACL}
+ This directive permits you to specify where a restricted console
+ can restore files. If this directive is not specified, only the
+ default restore location is permitted (normally {\bf
+ /tmp/bacula-restores}. If {\bf *all*} is specified any path the
+ user enters will be accepted (not very secure), any other
+ value specified (there may be multiple WhereACL directives) will
+ restrict the user to use that path. For example, on a Unix system,
+ if you specify "/", the file will be restored to the original
+ location. This directive is untested.
+
\end{description}
Aside from Director resource names and console command names, the special
and you must do both the {\bf make} and {\bf make install} commands, a
{\bf make install} without the preceding {\bf make} will not work.
-
For additional information on upgrading, please see the \ilink{Upgrading Bacula
Versions}{upgrading} in the Tips chapter of this manual.
+\subsection*{Releases Numbering}
+\index[general]{Release Numbering}
+\index[general]{Version Numbering}
+\addcontentsline{toc}{subsection}{Release Numbering}
+Every Bacula release whether beta or production has a different number
+as well as the date of the release build. The numbering system follows
+traditional Open Source conventions in that it is of the form.
+
+\begin{verbatim}
+major.minor.release
+\end{verbatim}
+
+For example:
+\begin{verbatim}
+1.38.11
+\end{verbatim}
+
+where each component (major, minor, patch) is a number.
+The major number is currently 1 and normally does not change
+very frequently. The minor number starts at 0 and increases
+each for each production release by 2 (i.e. it is always an
+even number for a production release), and the patch number is
+starts at zero each time the minor number changes. The patch
+number is increased each time a bug fix (or fixes) is released
+to production.
+
+So, as of this date (10 September 2006), the current production Bacula
+release is version 1.38.11. If there are bug fixes, the next release
+will be 1.38.12 (i.e. the patch number has increased by one).
+
+For all patch releases where the minor version number does not change,
+the database and all the daemons will be compatible. That means that
+you can safely run a 1.38.0 Director with a 1.38.11 Client. Of course,
+in this case, the Director may have bugs that are not fixed. Generally,
+within a minor release (some minor releases are not so minor), all
+patch numbers are officially released to production. This means that while
+the current Bacula version is 1.38.11, versions 1.38.0, 1.38.1, ... 1.38.10
+have all been previously released.
+
+When the minor number is odd, it indicates that the package is under
+development and thus may not be stable. For example, while the current
+production release of Bacula is currently 1.38.11, the current development
+version is 1.39.22. All patch versions of the development code are
+available in the CVS (source repository). However, not all patch versions
+of the development code (odd minor version) are officially released. When
+they are released, they are released as beta versions (see below for a
+definition of what beta means for Bacula releases).
+
+In general when the minor number increases from one production release
+to the next (i.e. 1.38.x to 1.40.0), the catalog database must be upgraded,
+the Director and Storage daemon must always be on the same minor release
+number, and often (not always), the Clients must also be on the same minor
+release. As often as possible, we attempt to make new releases that are
+downwards compatible with prior clients, but this is not always possible.
+You must check the release notes. In general, you will have fewer problems
+if you always run all the components on the same minor version number (i.e.
+all either 1.38.x or 1.40.x but not mixed).
+
+
\subsection*{Beta Releases}
\index[general]{Beta Releases}
\addcontentsline{toc}{subsection}{Beta Releases}
Towards the end of the development cycle, which typically runs
one year from a major release to another, there will be several beta
-releases of the development code prior to a production release. The
-purpose of the beta releases is to allow users to test the new code.
-Beta releases are made with the following considerations:
+releases of the development code prior to a production release.
+As noted above, beta versions always have odd minor version numbers
+(e.g 1.37.x or 1.39.x).
+The purpose of the beta releases is to allow early adopter users to test
+the new code. Beta releases are made with the following considerations:
+
\begin{itemize}
\item The code passes the regression testing on Linux,
FreeBSD, and Solaris machines. Including tape drive testing
on Linux and FreeBSD (not currently on Solaris).
-\item There are no known major bugs.
-\item Some of the new code/features will not yet be tested.
+\item There are no known major bugs, or on the rare occassion that
+ there are, they will be documented.
+\item Some of the new code/features may not yet be tested.
\item Bugs are expected to be found, especially in the new
code before the final production release.
-\item The code will be in production in at least one small
+\item The code will have been run in production in at least one small
site (mine).
\item The Win32 client will have been run in production at least
one night at that small site.
-\item The documentation is unlikely to be complete especially
+\item The documentation in the manual is unlikely to be complete especially
for the new features, and the Release Notes may not be fully
organized.
\item Beta code is not generally recommended for everyone, but
\end{itemize}
-
-
\subsection*{Dependency Packages}
\label{Dependency}
-\index[general]{Dependency Packages }
-\index[general]{Packages!Dependency }
+\index[general]{Dependency Packages}
+\index[general]{Packages!Dependency}
\addcontentsline{toc}{subsection}{Dependency Packages}
As discussed above, we have combined a number of third party packages that
-Bacula might need into the {\bf depkgs} and {\bf depkgs1} releases. You can,
-of course, get the latest packages from the original authors. The locations of
+Bacula might need into the {\bf depkgs} release. You can,
+of course, get the latest packages from the original authors or
+from your operating system supplier. The locations of
where we obtained the packages are in the README file in each package.
However, be aware that the packages in the depkgs files have been tested by us
for compatibility with Bacula.
-Typically, a dependency package will be named {\bf depkgs-ddMMMyy.tar.gz} and
-{\bf depkgs1-ddMMyy.tar.gz} where {\bf dd} is the day we release it, {\bf MMM}
+Typically, a dependency package will be named {\bf depkgs-ddMMMyy.tar.gz}
+where {\bf dd} is the day we release it, {\bf MMM}
is the abbreviated month (e.g. Jan), and {\bf yy} is the year. An actual
example is: {\bf depkgs-07Apr02.tar.gz}. To install and build this package (if
needed), you do the following:
to time, the current makeup is the following:
\addcontentsline{lot}{table}{Dependency Packages}
-\begin{longtable}{|l|l|l|}
+\begin{longtable}{|l|l|}
\hline
\multicolumn{1}{|c| }{\bf 3rd Party Package } & \multicolumn{1}{c| }{\bf
-depkgs } & \multicolumn{1}{c| }{\bf depkgs1 } \\
- \hline {SQLite } & \multicolumn{1}{c| }{X } & \multicolumn{1}{c| }{- } \\
- \hline {SQLite3 } & \multicolumn{1}{c| }{X } & \multicolumn{1}{c| }{- } \\
- \hline {mtx } & \multicolumn{1}{c| }{X } & \multicolumn{1}{c| }{- } \\
- \hline {readline } & \multicolumn{1}{c| }{- } & \multicolumn{1}{c| }{X } \\
- \hline {pthreads } & \multicolumn{1}{c| }{- } & \multicolumn{1}{c| }{- } \\
- \hline {zlib } & \multicolumn{1}{c| }{- } & \multicolumn{1}{c| }{- } \\
- \hline {wxWidgets } & \multicolumn{1}{c| }{- } & \multicolumn{1}{c| }{- } \\
+depkgs } & \multicolumn{1} \\
+ \hline {SQLite } & \multicolumn{1}{c| }{X } & \multicolumn{1} \\
+ \hline {SQLite3 } & \multicolumn{1}{c| }{X } & \multicolumn{1} \\
+ \hline {mtx } & \multicolumn{1}{c| }{X } & \multicolumn{1} \\
\hline
\end{longtable}
will configure and build only the SQLite package.
-You should build the packages that you will require in {\bf depkgs} and/or
-{\bf depkgs1} prior to configuring and building Bacula, since Bacula will need
+You should build the packages that you will require in {\bf depkgs} a
+prior to configuring and building Bacula, since Bacula will need
them during the build process.
Even if you do not use SQLite, you might find it worthwhile to build {\bf mtx}
because the {\bf tapeinfo} program that comes with it can often provide you
with valuable information about your SCSI tape drive (e.g. compression,
-min/max block sizes, ...).
+min/max block sizes, ...). Note, most distros provide {\bf mtx} as part of
+their release.
+
+The {\bf depkgs1} package is depreciated and previously contained
+readline, which should be available on all operating systems.
The {\bf depkgs-win32} package is deprecated and no longer used in
Bacula version 1.39.x and later. It was previously used to build
-1.39.22 (08 September 2006)
+1.39.23 (10 September 2006)
\footnotesize
\begin{verbatim}
Start a DOS shell Window.
- cd c:\bacula\bin
- bacula-fd -t >out
+ c:\Program Files\bacula\bin\bacula-fd -t >out
type out
\end{verbatim}
\normalsize
+The precise path to bacula-fd depends on where it is installed. The
+example above is the default used in 1.39.22 and later.
The {\bf -t} option will cause Bacula to read the configuration file, print
any error messages and then exit. the {\bf \gt{}} redirects the output to the
file named {\bf out}, which you can list with the {\bf type} command.
\footnotesize
\begin{verbatim}
- bacula-fd -d 100 >out
+ c:\Program Files\bacula\bin\bacula-fd -d 100 >out
\end{verbatim}
\normalsize
\normalsize
then run the job, and once you have terminated the File daemon, you will find
-the debug output in the {\bf bacula.trace} file.
+the debug output in the {\bf bacula.trace} file, which will probably be
+located in the same directory as bacula-fd.exe.
In addition, you should look in the System Applications log on the Control
Panel to find any Windows errors that Bacula got during the startup process.