\section*{Bacula Developer Notes}
\label{_ChapterStart10}
-\index{Bacula Developer Notes }
-\index{Notes!Bacula Developer }
+\index{Bacula Developer Notes}
+\index{Notes!Bacula Developer}
\addcontentsline{toc}{section}{Bacula Developer Notes}
\subsection*{General}
-\index{General }
+\index{General}
\addcontentsline{toc}{subsection}{General}
This document is intended mostly for developers and describes the the general
framework of making Bacula source changes.
\subsubsection*{Contributions}
-\index{Contributions }
+\index{Contributions}
\addcontentsline{toc}{subsubsection}{Contributions}
Contributions from programmers are broken into two groups. The first are
requirements for such code.
\subsubsection*{Patches}
-\index{Patches }
+\index{Patches}
\addcontentsline{toc}{subsubsection}{Patches}
Subject to the copyright assignment described below, your patches should be
out the source with CVS, you can get a diff using:
\begin{verbatim}
-cvs diff -u
+cvs diff -u \lt{}change.patch
\end{verbatim}
If you plan on doing
will need a userid on Source Forge.
\subsubsection*{Copyrights}
-\index{Copyrights }
+\index{Copyrights}
\addcontentsline{toc}{subsubsection}{Copyrights}
To avoid future problems concerning changing licensing or copyrights, all code
enhancements, or bug fixes of 5-10 lines of code, and documentation.
\subsubsection*{Copyright Assignment}
-\index{Copyright Assignment }
-\index{Assignment!Copyright }
+\index{Copyright Assignment}
+\index{Assignment!Copyright}
\addcontentsline{toc}{subsubsection}{Copyright Assignment}
Since this is not a commercial enterprise, and I prefer to believe in
misunderstandings between the employee, the company, and the Bacula project.
\subsubsection*{Corporate Assignment Statement}
-\index{Statement!Corporate Assignment }
-\index{Corporate Assignment Statement }
+\index{Statement!Corporate Assignment}
+\index{Corporate Assignment Statement}
\addcontentsline{toc}{subsubsection}{Corporate Assignment Statement}
The following statement must be filled out by the employer, signed, and mailed
\index{CVS}
\addcontentsline{toc}{subsection}{Basic CVS Usage}
-
The Bacula CVS is kept at Source Forge. If you are not a developer,
you only be able to access the public CVS, which runs about 6 hours behind
the developer's CVS. If you are a developer, then you will have immediate
long as you are careful only to change files that you want changed,
you have little to worry about.
+\subsection*{The Development Cycle}
+\index{Developement Cycle}
+\index{Cycle!Developement}
+\addcontentsline{toc}{subsubsection}{Development Cycle}
+
+As I noted in the 1.38 ReleaseNotes, version 1.38 was different from prior
+versions because it had a lot more contributions. I expect that this trend
+will continue. As a consequence, I am going to modify how I normally do
+development, and instead of making a list of all the features that I will
+implement in the next version, I will personally sign up for one (maybe
+two) projects at a time, and when they are complete, I will release a new
+version.
+
+The difference is that I will have more time to review the new code that is
+being contributed, and will be able to devote more time to a smaller number
+of projects (1.38 had too many new features for me to handle correctly).
+
+I expect that future release schedules will be much the same, and the
+number of new features will also be much the same providing that the
+contributions continue to come -- and they show no signs of let up :-)
+
+\bf{Feature Requests:} \\
+In addition, I would like to "formalize" the feature requests a bit.
+
+Instead of me maintaining an informal list of everything I run into
+(kernstodo), I would like to maintain a "formal" list of projects. This
+means that all new feature requests, including those recently discussed on
+the email lists, must be formally submitted and approved.
+
+Formal submission of feature requests will take two forms: \\
+1. non-mandatory, but highly recommended is to discuss proposed new features
+on the mailing list.\\
+2. Formal submission of an Feature Request in a special format.
+I'll give an example of this below, but you can also find it on the web
+site under "Support -\gt{} Feature Requests". Since it takes a bit of time to
+properly fill out a Feature Request form, you probably should check on the email list
+first.
+
+Once I receive the Feature Request, I will either accept it, send it back
+asking for clarification, send it to the email list asking for opinions, or
+reject it.
+
+If it is accepted, it will go in the "projects" file (a simple ASCII file)
+maintained in the main Bacula source directory.
+
+\bf{Implementation of Feature Requests:}\\
+Any qualified developer can sign up for a project. The project must have
+an entry in the projects file, and the developer's name will appear in the
+Status field.
+
+\bf{How Feature Requests are accepted:}\\
+Acceptance of Feature Requests depends on several things: \\
+1. feedback from users. If it is negative, the Feature Request will probably not be
+accepted. \\
+2. the difficulty of the project. A project that is so
+difficult that I cannot imagine finding someone to implement probably won't
+be accepted. \\
+ 3. whether or not the Feature Request fits within the
+current stategy of Bacula (for example an Feature Request that requests changing the
+tape to tar format would not be accepted, ...)
+
+\bf{How Feature Requests are prioritized:}\\
+Once an Feature Request is accepted, it needs to be implemented. If you
+can find a developer for it, or one signs up for implementing it, then the
+Feature Request becomes top priority (at least for that developer).
+
+Between releases of Bacula, I will generally solicit Feature Request input
+for the next version, and by way of this email, I suggest that you send
+discuss and send in your Feature Requests for the next release. Please
+verify that the Feature Request is not in the current list (attached to this email).
+
+Once users have had several weeks to submit Feature Requests, I will
+organize them, and request users to vote on them. This will allow fixing
+prioritizing the Feature Requests. Having a priority is one thing, but
+getting it implement is another thing -- I am hoping that the Bacula
+community will take more responsibility for assuring the implementation of
+accepted Feature Requests.
+
+Feature Request format:
+\begin{verbatim}
+============= Empty Feature Request form ===========
+Item n: One line summary ...
+ Date: Date submitted
+ Origin: Name and email of originator.
+ Status:
+
+ What: More detailed explanation ...
+
+ Why: Why it is important ...
+
+ Notes: Additional notes or features (omit if not used)
+============== End Feature Request form ==============
+\end{verbatim}
+
+\begin{verbatim}
+============= Example Completed Feature Request form ===========
+Item 1: Implement a Migration job type that will move the job
+ data from one device to another.
+ Origin: Sponsored by Riege Sofware International GmbH. Contact:
+ Daniel Holtkamp <holtkamp at riege dot com>
+ Date: 28 October 2005
+ Status: Partially coded in 1.37 -- much more to do. Assigned to
+ Kern.
+
+ What: The ability to copy, move, or archive data that is on a
+ device to another device is very important.
+
+ Why: An ISP might want to backup to disk, but after 30 days
+ migrate the data to tape backup and delete it from
+ disk. Bacula should be able to handle this
+ automatically. It needs to know what was put where,
+ and when, and what to migrate -- it is a bit like
+ retention periods. Doing so would allow space to be
+ freed up for current backups while maintaining older
+ data on tape drives.
+
+ Notes: Migration could be triggered by:
+ Number of Jobs
+ Number of Volumes
+ Age of Jobs
+ Highwater size (keep total size)
+ Lowwater mark
+=================================================
+\end{verbatim}
+
\subsection*{Developing Bacula}
-\index{Developing Bacula }
-\index{Bacula!Developing }
+\index{Developing Bacula}
+\index{Bacula!Developing}
\addcontentsline{toc}{subsubsection}{Developing Bacula}
Typically the simplest way to develop Bacula is to open one xterm window
./stopit then repeat the process.
\subsubsection*{Debugging}
-\index{Debugging }
+\index{Debugging}
\addcontentsline{toc}{subsubsection}{Debugging}
Probably the first thing to do is to turn on debug output.
just about everything a level of 200.
\subsubsection*{Using a Debugger}
-\index{Using a Debugger }
-\index{Debugger!Using a }
+\index{Using a Debugger}
+\index{Debugger!Using a}
\addcontentsline{toc}{subsubsection}{Using a Debugger}
If you have a serious problem such as a segmentation fault, it can usually be
manual entitled ``What To Do When Bacula Crashes (Kaboom)''.
\subsubsection*{Memory Leaks}
-\index{Leaks!Memory }
-\index{Memory Leaks }
+\index{Leaks!Memory}
+\index{Memory Leaks}
\addcontentsline{toc}{subsubsection}{Memory Leaks}
Because Bacula runs routinely and unattended on client and server machines, it
daemons.
\subsubsection*{Special Files}
-\index{Files!Special }
-\index{Special Files }
+\index{Files!Special}
+\index{Special Files}
\addcontentsline{toc}{subsubsection}{Special Files}
Kern uses files named 1, 2, ... 9 with any extension as scratch files. Thus
any files with these names are subject to being rudely deleted at any time.
\subsubsection*{When Implementing Incomplete Code}
-\index{Code!When Implementing Incomplete }
-\index{When Implementing Incomplete Code }
+\index{Code!When Implementing Incomplete}
+\index{When Implementing Incomplete Code}
\addcontentsline{toc}{subsubsection}{When Implementing Incomplete Code}
Please identify all incomplete code with a comment that contains {\bf
new programmers to easily recognize where things are partially implemented.
\subsubsection*{Bacula Source File Structure}
-\index{Structure!Bacula Source File }
-\index{Bacula Source File Structure }
+\index{Structure!Bacula Source File}
+\index{Bacula Source File Structure}
\addcontentsline{toc}{subsubsection}{Bacula Source File Structure}
The distribution generally comes as a tar file of the form {\bf
\normalsize
\subsubsection*{Header Files}
-\index{Header Files }
-\index{Files!Header }
+\index{Header Files}
+\index{Files!Header}
\addcontentsline{toc}{subsubsection}{Header Files}
Please carefully follow the scheme defined below as it permits in general only
protos.h} is always included by the main directory dependent include file.
\subsubsection*{Programming Standards}
-\index{Standards!Programming }
-\index{Programming Standards }
+\index{Standards!Programming}
+\index{Programming Standards}
\addcontentsline{toc}{subsubsection}{Programming Standards}
For the most part, all code should be written in C unless there is a burning
so be conservative in your use of C++ features.
\subsubsection*{Do Not Use}
-\index{Use!Do Not }
-\index{Do Not Use }
+\index{Use!Do Not}
+\index{Do Not Use}
\addcontentsline{toc}{subsubsection}{Do Not Use}
\begin{itemize}
\end{itemize}
\subsubsection*{Avoid if Possible}
-\index{Possible!Avoid if }
-\index{Avoid if Possible }
+\index{Possible!Avoid if}
+\index{Avoid if Possible}
\addcontentsline{toc}{subsubsection}{Avoid if Possible}
\begin{itemize}
\end{itemize}
\subsubsection*{Do Use Whenever Possible}
-\index{Possible!Do Use Whenever }
-\index{Do Use Whenever Possible }
+\index{Possible!Do Use Whenever}
+\index{Do Use Whenever Possible}
\addcontentsline{toc}{subsubsection}{Do Use Whenever Possible}
\begin{itemize}
\end{itemize}
\subsubsection*{Indenting Standards}
-\index{Standards!Indenting }
-\index{Indenting Standards }
+\index{Standards!Indenting}
+\index{Indenting Standards}
\addcontentsline{toc}{subsubsection}{Indenting Standards}
I cannot stand code indented 8 columns at a time. This makes the code
\begin{verbatim}
if (abc) {
some_code;
- }
+ }
\end{verbatim}
\normalsize
break;
default:
break;
- }
+ }
\end{verbatim}
\normalsize
a = 1;
if (b >= 2) {
cleanup();
- }
+ }
\end{verbatim}
\normalsize
if (ua->verbose \&& del.num_del != 0) {
bsendmsg(ua, _("Pruned %d %s on Volume %s from catalog.\n"), del.num_del,
del.num_del == 1 ? "Job" : "Jobs", mr->VolumeName);
- }
+ }
\end{verbatim}
\normalsize
to 3.
\subsubsection*{Tabbing}
-\index{Tabbing }
+\index{Tabbing}
\addcontentsline{toc}{subsubsection}{Tabbing}
Tabbing (inserting the tab character in place of spaces) is as normal on all
characters) with indenting (visual alignment of the code).
\subsubsection*{Don'ts}
-\index{Don'ts }
+\index{Don'ts}
\addcontentsline{toc}{subsubsection}{Don'ts}
Please don't use:
Also please don't use the STL or Templates or any complicated C++ code.
\subsubsection*{Message Classes}
-\index{Classes!Message }
-\index{Message Classes }
+\index{Classes!Message}
+\index{Message Classes}
\addcontentsline{toc}{subsubsection}{Message Classes}
Currently, there are five classes of messages: Debug, Error, Job, Memory,
and Queued.
\subsubsection*{Debug Messages}
-\index{Messages!Debug }
-\index{Debug Messages }
+\index{Messages!Debug}
+\index{Debug Messages}
\addcontentsline{toc}{subsubsection}{Debug Messages}
Debug messages are designed to be turned on at a specified debug level and are
Dmsg1(9, ``Created client \%s record\textbackslash{}n'', client->hdr.name);
\subsubsection*{Error Messages}
-\index{Messages!Error }
-\index{Error Messages }
+\index{Messages!Error}
+\index{Error Messages}
\addcontentsline{toc}{subsubsection}{Error Messages}
Error messages are messages that are related to the daemon as a whole rather
\addcontentsline{lot}{table}{Message Error Code Classes}
\begin{longtable}{lp{3in}}
-{{\bf M\_ABORT} } & {Causes the daemon to immediately abort. This should be
-used only in extreme cases. It attempts to produce a traceback. } \\
-{{\bf M\_ERROR\_TERM} } & {Causes the daemon to immediately terminate. This
-should be used only in extreme cases. It does not produce a traceback. } \\
-{{\bf M\_FATAL} } & {Causes the daemon to terminate the current job, but the
-daemon keeps running } \\
-{{\bf M\_ERROR} } & {Reports the error. The daemon and the job continue
-running } \\
-{{\bf M\_WARNING} } & {Reports an warning message. The daemon and the job
-continue running } \\
-{{\bf M\_INFO} } & {Reports an informational message. }
+{{\bf M\_ABORT} } & {Causes the daemon to immediately abort. This should be
+used only in extreme cases. It attempts to produce a traceback. } \\
+{{\bf M\_ERROR\_TERM} } & {Causes the daemon to immediately terminate. This
+should be used only in extreme cases. It does not produce a traceback. } \\
+{{\bf M\_FATAL} } & {Causes the daemon to terminate the current job, but the
+daemon keeps running } \\
+{{\bf M\_ERROR} } & {Reports the error. The daemon and the job continue
+running } \\
+{{\bf M\_WARNING} } & {Reports an warning message. The daemon and the job
+continue running } \\
+{{\bf M\_INFO} } & {Reports an informational message.}
\end{longtable}
\%d \%s\textbackslash{}n'', cmd, n, strerror(errno));
\subsubsection*{Job Messages}
-\index{Job Messages }
-\index{Messages!Job }
+\index{Job Messages}
+\index{Messages!Job}
\addcontentsline{toc}{subsubsection}{Job Messages}
Job messages are messages that pertain to a particular job such as a file that
from user's output.
\subsubsection*{Queued Job Messages}
-\index{Queued Job Messages }
-\index{Messages!Job }
+\index{Queued Job Messages}
+\index{Messages!Job}
\addcontentsline{toc}{subsubsection}{Queued Job Messages}
Queued Job messages are similar to Jmsg()s except that the message is
Queued rather than immediately dispatched. This is necessary within the
\subsubsection*{Memory Messages}
-\index{Messages!Memory }
-\index{Memory Messages }
+\index{Messages!Memory}
+\index{Memory Messages}
\addcontentsline{toc}{subsubsection}{Memory Messages}
Memory messages are messages that are edited into a memory buffer. Generally
<li class="menuItem"> <a href="<? echo $spath ?>/?page=maillists"> Email Lists </a> </li>
<li class="menuItem"> <a href="<? echo $spath ?>/?page=bugs"> Bug Reports </a> </li>
<li class="menuItem"> <a href="<? echo $spath ?>/?page=professional"> Professional </a></li>
- <li class="menuItem"> <a href="<? echo $spath ?>/?page=rfc"> Feature Requests </a></li>
+ <li class="menuItem"> <a href="<? echo $spath ?>/?page=feature-requests"> Feature Requests </a></li>
</ul>
</div>
--- /dev/null
+<? require_once("inc/header.php"); ?>
+<table>
+<tr>
+ <td class="contentTopic"> Feature Requests </td>
+</tr>
+<tr>
+ <td class="content">
+
+In the past, users informally submitted feature requests by email, and
+I collected them, then once a version was released, I would publish the
+list for users to vote on.
+
+Now that Bacula has become a bigger project, I would like to formalize
+the process a bit more. The main change will be to require users
+to carefully think about their feature, and submit it on a feature
+request form. A mostly empty form is shown below along with an
+exaple of an actual filled in form.
+
+Once I receive and approve the Feature Request, possibly requesting
+some modifications, I'll add it to the projects file, which contains
+a list of all open Feature Requests.
+
+<h3>Feature Request Form</h3>
+<pre>
+Item n: One line summary ...
+ Origin: Name and email of originator.
+ Date: Date submitted (e.g. 28 October 2005)
+ Status:
+
+ What: More detailed explanation ...
+
+ Why: Why it is important ...
+
+ Notes: Additional notes or features ...
+
+</pre>
+
+<h3>An Example Feature Request</h3>
+<pre>
+Item 1: Implement a Migration job type that will move the job
+ data from one device to another.
+ Date: 28 October 2005
+ Origin: Sponsored by Riege Sofware International GmbH. Contact:
+ Daniel Holtkamp <holtkamp at riege dot com>
+ Status: Partially coded in 1.37 -- much more to do. Assigned to
+ Kern.
+
+ What: The ability to copy, move, or archive data that is on a
+ device to another device is very important.
+
+ Why: An ISP might want to backup to disk, but after 30 days
+ migrate the data to tape backup and delete it from
+ disk. Bacula should be able to handle this
+ automatically. It needs to know what was put where,
+ and when, and what to migrate -- it is a bit like
+ retention periods. Doing so would allow space to be
+ freed up for current backups while maintaining older
+ data on tape drives.
+
+ Notes: Migration could be triggered by:
+ Number of Jobs
+ Number of Volumes
+ Age of Jobs
+ Highwater size (keep total size)
+ Lowwater mark
+
+</pre>
+
+</td>
+</tr>
+
+</table>
+<? require_once("inc/footer.php"); ?>
+++ /dev/null
-<? require_once("inc/header.php"); ?>
-<table>
-<tr>
- <td class="contentTopic"> Feature Requests </td>
-</tr>
-<tr>
- <td class="content">
-
-In the past, users informally submitted feature requests by email, and
-I collected them, then once a version was released, I would publish the
-list for users to vote on.
-
-Now that Bacula has become a bigger project, I would like to formalize
-the process a bit more. The main change will be to require users
-to carefully think about their feature, and submit it on a feature
-request form. A mostly empty form is shown below along with an
-exaple of an actual filled in form.
-
-Once I receive and approve the Feature Request, possibly requesting
-some modifications, I'll add it to the projects file, which contains
-a list of all open Feature Requests.
-
-<h3>Feature Request Form</h3>
-<pre>
-Item n: One line summary ...
- Origin: Name and email of originator.
- Date: Date submitted (e.g. 28 October 2005)
- Status:
-
- What: More detailed explanation ...
-
- Why: Why it is important ...
-
- Notes: Additional notes or features ...
-
-</pre>
-
-<h3>An Example Feature Request</h3>
-<pre>
-Item 1: Implement a Migration job type that will move the job
- data from one device to another.
- Date: 28 October 2005
- Origin: Sponsored by Riege Sofware International GmbH. Contact:
- Daniel Holtkamp <holtkamp at riege dot com>
- Status: Partially coded in 1.37 -- much more to do. Assigned to
- Kern.
-
- What: The ability to copy, move, or archive data that is on a
- device to another device is very important.
-
- Why: An ISP might want to backup to disk, but after 30 days
- migrate the data to tape backup and delete it from
- disk. Bacula should be able to handle this
- automatically. It needs to know what was put where,
- and when, and what to migrate -- it is a bit like
- retention periods. Doing so would allow space to be
- freed up for current backups while maintaining older
- data on tape drives.
-
- Notes: Migration could be triggered by:
- Number of Jobs
- Number of Volumes
- Age of Jobs
- Highwater size (keep total size)
- Lowwater mark
-
-</pre>
-
-</td>
-</tr>
-
-</table>
-<? require_once("inc/footer.php"); ?>
The label command can fail for a number of reasons:
- \begin{enumerate}
- \item The Volume name you specify is already in the Volume database.
- \item The Storage daemon has a tape already mounted on the device, in which
- case you must {\bf unmount} the device, insert a blank tape, then do the
- {\bf label} command.
- \item The tape in the device is already a Bacula labeled tape. (Bacula will
- never relabel a Bacula labeled tape unless it is recycled and you use the
- {\bf relabel} command).
- \item There is no tape in the drive.
- \end{enumerate}
+\begin{enumerate}
+\item The Volume name you specify is already in the Volume database.
+\item The Storage daemon has a tape already mounted on the device, in which
+case you must {\bf unmount} the device, insert a blank tape, then do the
+{\bf label} command.
+\item The tape in the device is already a Bacula labeled tape. (Bacula will
+never relabel a Bacula labeled tape unless it is recycled and you use the
+{\bf relabel} command).
+\item There is no tape in the drive.
+\end{enumerate}
There are two ways to relabel a volume that already has a Bacula label. The
brute force method is to write an end of file mark on the tape using the
\begin{verbatim}
mt -f /dev/st0 rewind
mt -f /dev/st0 weof
-
\end{verbatim}
\normalsize
\item The Media Type as specified in the Storage Resource in the Director's
configuration file (e.g. "DLT8000")
\item The number and names of the Volumes you wish to create.
- \end{enumerate}
+\end{enumerate}
For example, to add media to a Pool, you would issue the following commands to
the console program:
\index[dir]{Run directive}
\index[dir]{Clone a Job}
The Run directive (not to be confused with the Run option in a
- Schedule) allows you to clone jobs and thus, if you want backup
+ Schedule) allows you to start other jobs or to clone jobs. By using the
+ cloning keywords (see below), you can backup
the same data (or almost the same data) to two or more drives
at the same time. The {\bf job-name} is normally the same name
as the current Job resource (thus creating a clone). However, it
of the Storage daemon's configuration file. The default is 9103.
\item [Password = \lt{}password\gt{}]
- \index[dir]{Password }
+ \index[dir]{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
otherwise it will be left blank.
\item [Device = \lt{}device-name\gt{}]
- \index[dir]{Device }
- This directive specifies the name of the device to be used for the
-storage. This name is not the physical device name, but the logical device
-name as defined on the {\bf Name} directive contained in the {\bf Device}
-resource definition of the {\bf Storage daemon} configuration file or if
-the device is an Autochanger, you must put the name as defined on the {\bf Name}
-directive contained in the {\bf Autochanger resource definition of the {\bf
-Storage daemon}. You can specify any name you would like (even the device name
-if you prefer) up to a
-maximum of 127 characters in length. The physical device name associated with
-this device is specified in the {\bf Storage daemon} configuration file (as
-{\bf Archive Device}). Please take care not to define two different Storage
-resource directives in the Director that point to the same Device in the
-Storage daemon. Doing so may cause the Storage daemon to block (or hang)
-attempting to open the same device that is already open. This directive is
-required.
-
+ \index[dir]{Device}
+ This directive specifies the name of the device to be used for the
+ storage. This name is not the physical device name, but the logical
+ device name as defined on the {\bf Name} directive contained in the {\bf
+ Device} resource definition of the {\bf Storage daemon} configuration
+ file or if the device is an Autochanger, you must put the name as
+ defined on the {\bf Name} directive contained in the {\bf Autochanger
+ resource definition of the {\bf Storage daemon}. You can specify any
+ name you would like (even the device name if you prefer) up to a maximum
+ of 127 characters in length. The physical device name associated with
+ this device is specified in the {\bf Storage daemon} configuration file
+ (as {\bf Archive Device}). Please take care not to define two different
+ Storage resource directives in the Director that point to the same
+ Device in the Storage daemon. Doing so may cause the Storage daemon to
+ block (or hang) attempting to open the same device that is already open.
+ This directive is required.
+
+\label{MediaType}
\item [Media Type = \lt{}MediaType\gt{}]
- \index[dir]{Media Type }
- This directive specifies the Media Type to be used to store the data. This
-is
-an arbitrary string of characters up to 127 maximum that you define. It can
-be anything you want. However, it is best to make it descriptive of the
-storage media (e.g. File, DAT, "HP DLT8000", 8mm, ...). In addition, it is
-essential that you make the {\bf Media Type} specification unique for each
-storage media type. If you have two DDS-4 drives that have incompatible
-formats, or if you have a DDS-4 drive and a DDS-4 autochanger, you almost
-certainly should specify different {\bf Media Types}. During a restore,
-assuming a {\bf DDS-4} Media Type is associated with the Job, Bacula can
-decide to use any Storage daemon that support Media Type {\bf DDS-4} and on
-any drive that supports it. If you want to tie Bacula to using a single Storage
-daemon or drive, you must specify a unique Media Type for that drive. This is
-an important point that should be carefully understood. You can find more on
-this subject in the
-\ilink{Basic Volume Management}{_ChapterStart39} chapter of this
-manual.
-
-The {\bf MediaType} specified here, {\bf must} correspond to the {\bf Media
-Type} specified in the {\bf Device} resource of the {\bf Storage daemon}
-configuration file. This directive is required, and it is used by the
-Director and the Storage daemon to ensure that a Volume automatically
-selected from the Pool corresponds to the physical device. If a Storage
-daemon handles multiple devices (e.g. will write to various file Volumes on
-different partitions), this directive allows you to specify exactly which
-device.
-
-As mentioned above, the value specified in the Director's Storage resource
-must agree with the value specified in the Device resource in the {\bf
-Storage daemon's} configuration file. It is also an additional check so that
-you don't try to write data for a DLT onto an 8mm device.
+ \index[dir]{Media Type}
+ This directive specifies the Media Type to be used to store the data.
+ This is an arbitrary string of characters up to 127 maximum that you
+ define. It can be anything you want. However, it is best to make it
+ descriptive of the storage media (e.g. File, DAT, "HP DLT8000", 8mm,
+ ...). In addition, it is essential that you make the {\bf Media Type}
+ specification unique for each storage media type. If you have two DDS-4
+ drives that have incompatible formats, or if you have a DDS-4 drive and
+ a DDS-4 autochanger, you almost certainly should specify different {\bf
+ Media Types}. During a restore, assuming a {\bf DDS-4} Media Type is
+ associated with the Job, Bacula can decide to use any Storage daemon
+ that supports Media Type {\bf DDS-4} and on any drive that supports it.
+
+ If you want to tie Bacula to using a single Storage daemon or drive, you
+ must specify a unique Media Type for that drive. This is an important
+ point that should be carefully understood. Note, this applies equally
+ to Disk Volumes. If you define more than one disk Device resource in
+ your Storage daemon's conf file, the Volumes on thoes two devices are in
+ fact incompatible because one can not be mounted on the other device
+ since they are found in different directories. For this reason, you
+ probably should use two different Media Types for your two disk Devices
+ (even though you might think of them as both being File types). You can
+ find more on this subject in the \ilink{Basic Volume
+ Management}{_ChapterStart39} chapter of this manual.
+
+ The {\bf MediaType} specified here, {\bf must} correspond to the {\bf
+ Media Type} specified in the {\bf Device} resource of the {\bf Storage
+ daemon} configuration file. This directive is required, and it is used
+ by the Director and the Storage daemon to ensure that a Volume
+ automatically selected from the Pool corresponds to the physical device.
+ If a Storage daemon handles multiple devices (e.g. will write to
+ various file Volumes on different partitions), this directive allows you
+ to specify exactly which device.
+
+ As mentioned above, the value specified in the Director's Storage resource
+ must agree with the value specified in the Device resource in the {\bf
+ Storage daemon's} configuration file. It is also an additional check so that
+ you don't try to write data for a DLT onto an 8mm device.
\label{Autochanger1}
\item [Autochanger = \lt{}yes|no\gt{}]
\index[dir]{Autochanger }
If you specify {\bf yes} for this command (the default is {\bf no}), when
-you
-use the {\bf label} command or the {\bf add} command to create a new Volume,
-{\bf Bacula} will also request the Autochanger Slot number. This simplifies
-creating database entries for Volumes in an autochanger. If you forget to
-specify the Slot, the autochanger will not be used. However, you may modify
-the Slot associated with a Volume at any time by using the {\bf update
-volume} command in the console program. When {\bf autochanger} is enabled,
-the algorithm used by Bacula to search for available volumes will be modified
-to consider only Volumes that are known to be in the autochanger's magazine.
-If no {\bf in changer} volume is found, Bacula will attempt recycling,
-pruning, ..., and if still no volume is found, Bacula will search for any
-volume whether or not in the magazine. By privileging in changer volumes,
-this procedure minimizes operator intervention. The default is {\bf no}.
-
-For the autochanger to be used, you must also specify {\bf Autochanger = yes}
-in the
-\ilink{Device Resource}{Autochanger} in the Storage daemon's
-configuration file as well as other important Storage daemon configuration
-information. Please consult the
-\ilink{Using Autochangers}{_ChapterStart18} manual of this
-chapter for the details of using autochangers.
+ you use the {\bf label} command or the {\bf add} command to create a new
+ Volume, {\bf Bacula} will also request the Autochanger Slot number.
+ This simplifies creating database entries for Volumes in an autochanger.
+ If you forget to specify the Slot, the autochanger will not be used.
+ However, you may modify the Slot associated with a Volume at any time by
+ using the {\bf update volume} command in the console program. When {\bf
+ autochanger} is enabled, the algorithm used by Bacula to search for
+ available volumes will be modified to consider only Volumes that are
+ known to be in the autochanger's magazine. If no {\bf in changer}
+ volume is found, Bacula will attempt recycling, pruning, ..., and if
+ still no volume is found, Bacula will search for any volume whether or
+ not in the magazine. By privileging in changer volumes, this procedure
+ minimizes operator intervention. The default is {\bf no}.
+
+ For the autochanger to be used, you must also specify {\bf Autochanger =
+ yes} in the \ilink{Device Resource}{Autochanger} in the Storage daemon's
+ configuration file as well as other important Storage daemon
+ configuration information. Please consult the \ilink{Using
+ Autochangers}{_ChapterStart18} manual of this chapter for the details of
+ using autochangers.
\item [Maximum Concurrent Jobs = \lt{}number\gt{}]
\index[dir]{Maximum Concurrent Jobs }
backup to disk Volumes rather than tape Volumes. This chapter is intended to
give you some of the options that are available to you so that you can manage
either disk or tape volumes.
-\label{Concepts}
+\label{Concepts}
\subsection*{Key Concepts and Resource Records}
\index[general]{Key Concepts and Resource Records }
\index[general]{Records!Key Concepts and Resource }
\ilink{Python Scripting}{_ChapterStart60} chapter of this manual for more
details.
-Please note that automatic Volume labeling can also be used with tapes, but it is not
-nearly so practical since the tapes must be pre-mounted. This requires some
-user interaction. Automatic labeling from templates does NOT work with
-autochangers since Bacula will not access unknown slots. There are several
-methods of labeling all volumes in an autochanger magazine. For more
-information on this, please see the
-\ilink{ Autochanger}{_ChapterStart18} chapter of this manual.
+Please note that automatic Volume labeling can also be used with tapes, but
+it is not nearly so practical since the tapes must be pre-mounted. This
+requires some user interaction. Automatic labeling from templates does NOT
+work with autochangers since Bacula will not access unknown slots. There
+are several methods of labeling all volumes in an autochanger magazine.
+For more information on this, please see the \ilink{
+Autochanger}{_ChapterStart18} chapter of this manual.
Automatic Volume labeling is enabled by making a change to both the Pool
resource (Director) and to the Device resource (Storage daemon) shown above.
Bacula can, of course, use multiple disks, but in general, each disk must be a
separate Device specification in the Storage daemon's conf file, and you must
-then select what clients to backup to each disk.
+then select what clients to backup to each disk. You will also want to
+give each Device specification a different Media Type so that during
+a restore, Bacula will be able to find the appropriate drive.
-The situation is a bit more complicated if you want to treat two disk drives
-logically as a single drive, which Bacula does not directly support. However,
-it is possible to back up your data to multiple disks as if they were a single
-drive by linking the Volumes from the first disk to the second disk.
+The situation is a bit more complicated if you want to treat two different
+physical disk drives (or partitions) logically as a single drive, which
+Bacula does not directly support. However, it is possible to back up your
+data to multiple disks as if they were a single drive by linking the
+Volumes from the first disk to the second disk.
For example, assume that you have two disks named {\bf /disk1} and {\bf
/disk2>}. If you then create a standard Storage daemon Device resource for
method is that you must explicitly name the disks and cannot use automatic
labeling unless you arrange to have the labels exactly match the links you
have created.
-\label{MultipleClients}
+An important thing to know is that Bacula treats disks like tape drives
+as much as it can. This means that you can only have a single Volume
+mounted at one time on a disk as defined in your Device resource in
+the Storage daemon's conf file. You can have multiple concurrent
+jobs running that all write to the one Volume that is being used, but
+if you want to have multiple concurrent jobs that are writting to
+separate disks drives (or partitions), you will need to define
+separate Device resources for each one, exactly as you would do for
+two different tape drives. There is one fundamental difference, however.
+The Volumes that you creat on the two drives cannot be easily exchanged
+as they can for a tape drive, because they are physically resident (already
+mounted in a sense) on the particular drive. As a consequence, you will
+probably want to give them different Media Types so that Bacula can
+distinguish what Device resource to use during a restore.
+An example would be the following:
+
+\footnotesize
+\begin{verbatim}
+Device {
+ Name = Disk1
+ Media Type = File1
+ Archive Device = /disk1
+ LabelMedia = yes;
+ Random Access = Yes;
+ AutomaticMount = yes;
+ RemovableMedia = no;
+ AlwaysOpen = no;
+}
+
+Device {
+ Name = Disk2
+ Media Type = File2
+ Archive Device = /disk2
+ LabelMedia = yes;
+ Random Access = Yes;
+ AutomaticMount = yes;
+ RemovableMedia = no;
+ AlwaysOpen = no;
+}
+\end{verbatim}
+\normalsize
+
+With the above device definitions, you can run two concurrent
+jobs each writing at the same time, one to \bf{/disk2} and the
+other to \bf{/disk2}. The fact that you have given them different
+Media Types will allow Bacula to quickly choose the correct
+Storage resource in the Director when doing a restore.
+
+\label{MultipleClients}
\subsection*{Considerations for Multiple Clients}
\index[general]{Clients!Considerations for Multiple }
\index[general]{Considerations for Multiple Clients }
Options { This
wildfile = "*.Z" example
wildfile = "*.gz" doesn't
- Include = yes work
+ work
} !!!!!!!!!!!!
File = /myfile
}
Options {
wildfile = "*.Z"
wildfile = "*.gz"
- Include = yes
}
Options {
Exclude = yes
For 64 bit support add '--define "build_x86_64 1"'
\end{verbatim}
\normalsize
+
+\subsection*{Build Options}
+\index[general]{Build Options}
+\addcontentsline{toc}{subsection}{Build Options}
+The spec file currently supports building on the following platforms:
+\footnotesize
+\begin{verbatim}
+# RedHat builds
+--define "build_rh8 1"
+--define "build_rh9 1"
+
+# Fedora Core build
+--define "build_fc1 1"
+--define "build_fc3 1"
+
+# Whitebox Enterprise build
+--define "build_wb3 1"
+
+# RedHat Enterprise builds
+--define "build_rhel3 1"
+--define "build_rhel4 1"
+
+# CentOS build
+--define "build_centos4 1"
+
+# SuSE build
+--define "build_su9 1"
+
+# Mandrake build
+--define "build_mdk 1"
+
+MySQL support:
+
+--define "build_mysql 1"
+# if using mysql 4.x define this and mysql above
+# currently: Mandrake 10.x, SuSE 9.x, RHEL4
+--define "build_mysql4 1"
+
+PostgreSQL support:
+--define "build_postgresql 1"
+
+Sqlite support:
+--define "build_sqlite 1"
+
+\end{verbatim}
+\normalsize
+
+
-1.38.0 (28 October 2005)
+ ()
The label command can fail for a number of reasons:
- \begin{enumerate}
- \item The Volume name you specify is already in the Volume database.
- \item The Storage daemon has a tape already mounted on the device, in which
- case you must {\bf unmount} the device, insert a blank tape, then do the
- {\bf label} command.
- \item The tape in the device is already a Bacula labeled tape. (Bacula will
- never relabel a Bacula labeled tape unless it is recycled and you use the
- {\bf relabel} command).
- \item There is no tape in the drive.
- \end{enumerate}
+\begin{enumerate}
+\item The Volume name you specify is already in the Volume database.
+\item The Storage daemon has a tape already mounted on the device, in which
+case you must {\bf unmount} the device, insert a blank tape, then do the
+{\bf label} command.
+\item The tape in the device is already a Bacula labeled tape. (Bacula will
+never relabel a Bacula labeled tape unless it is recycled and you use the
+{\bf relabel} command).
+\item There is no tape in the drive.
+\end{enumerate}
There are two ways to relabel a volume that already has a Bacula label. The
brute force method is to write an end of file mark on the tape using the
\begin{verbatim}
mt -f /dev/st0 rewind
mt -f /dev/st0 weof
-
\end{verbatim}
\normalsize
\item The Media Type as specified in the Storage Resource in the Director's
configuration file (e.g. "DLT8000")
\item The number and names of the Volumes you wish to create.
- \end{enumerate}
+\end{enumerate}
For example, to add media to a Pool, you would issue the following commands to
the console program:
of the Storage daemon's configuration file. The default is 9103.
\item [Password = \lt{}password\gt{}]
- \index[dir]{Password }
+ \index[dir]{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
otherwise it will be left blank.
\item [Device = \lt{}device-name\gt{}]
- \index[dir]{Device }
- This directive specifies the name of the device to be used for the
-storage. This name is not the physical device name, but the logical device
-name as defined on the {\bf Name} directive contained in the {\bf Device}
-resource definition of the {\bf Storage daemon} configuration file or if
-the device is an Autochanger, you must put the name as defined on the {\bf Name}
-directive contained in the {\bf Autochanger resource definition of the {\bf
-Storage daemon}. You can specify any name you would like (even the device name
-if you prefer) up to a
-maximum of 127 characters in length. The physical device name associated with
-this device is specified in the {\bf Storage daemon} configuration file (as
-{\bf Archive Device}). Please take care not to define two different Storage
-resource directives in the Director that point to the same Device in the
-Storage daemon. Doing so may cause the Storage daemon to block (or hang)
-attempting to open the same device that is already open. This directive is
-required.
-
+ \index[dir]{Device}
+ This directive specifies the name of the device to be used for the
+ storage. This name is not the physical device name, but the logical
+ device name as defined on the {\bf Name} directive contained in the {\bf
+ Device} resource definition of the {\bf Storage daemon} configuration
+ file or if the device is an Autochanger, you must put the name as
+ defined on the {\bf Name} directive contained in the {\bf Autochanger
+ resource definition of the {\bf Storage daemon}. You can specify any
+ name you would like (even the device name if you prefer) up to a maximum
+ of 127 characters in length. The physical device name associated with
+ this device is specified in the {\bf Storage daemon} configuration file
+ (as {\bf Archive Device}). Please take care not to define two different
+ Storage resource directives in the Director that point to the same
+ Device in the Storage daemon. Doing so may cause the Storage daemon to
+ block (or hang) attempting to open the same device that is already open.
+ This directive is required.
+
+\label{MediaType}
\item [Media Type = \lt{}MediaType\gt{}]
- \index[dir]{Media Type }
- This directive specifies the Media Type to be used to store the data. This
-is
-an arbitrary string of characters up to 127 maximum that you define. It can
-be anything you want. However, it is best to make it descriptive of the
-storage media (e.g. File, DAT, "HP DLT8000", 8mm, ...). In addition, it is
-essential that you make the {\bf Media Type} specification unique for each
-storage media type. If you have two DDS-4 drives that have incompatible
-formats, or if you have a DDS-4 drive and a DDS-4 autochanger, you almost
-certainly should specify different {\bf Media Types}. During a restore,
-assuming a {\bf DDS-4} Media Type is associated with the Job, Bacula can
-decide to use any Storage daemon that support Media Type {\bf DDS-4} and on
-any drive that supports it. If you want to tie Bacula to using a single Storage
-daemon or drive, you must specify a unique Media Type for that drive. This is
-an important point that should be carefully understood. You can find more on
-this subject in the
-\ilink{Basic Volume Management}{_ChapterStart39} chapter of this
-manual.
-
-The {\bf MediaType} specified here, {\bf must} correspond to the {\bf Media
-Type} specified in the {\bf Device} resource of the {\bf Storage daemon}
-configuration file. This directive is required, and it is used by the
-Director and the Storage daemon to ensure that a Volume automatically
-selected from the Pool corresponds to the physical device. If a Storage
-daemon handles multiple devices (e.g. will write to various file Volumes on
-different partitions), this directive allows you to specify exactly which
-device.
-
-As mentioned above, the value specified in the Director's Storage resource
-must agree with the value specified in the Device resource in the {\bf
-Storage daemon's} configuration file. It is also an additional check so that
-you don't try to write data for a DLT onto an 8mm device.
+ \index[dir]{Media Type}
+ This directive specifies the Media Type to be used to store the data.
+ This is an arbitrary string of characters up to 127 maximum that you
+ define. It can be anything you want. However, it is best to make it
+ descriptive of the storage media (e.g. File, DAT, "HP DLT8000", 8mm,
+ ...). In addition, it is essential that you make the {\bf Media Type}
+ specification unique for each storage media type. If you have two DDS-4
+ drives that have incompatible formats, or if you have a DDS-4 drive and
+ a DDS-4 autochanger, you almost certainly should specify different {\bf
+ Media Types}. During a restore, assuming a {\bf DDS-4} Media Type is
+ associated with the Job, Bacula can decide to use any Storage daemon
+ that supports Media Type {\bf DDS-4} and on any drive that supports it.
+
+ If you want to tie Bacula to using a single Storage daemon or drive, you
+ must specify a unique Media Type for that drive. This is an important
+ point that should be carefully understood. Note, this applies equally
+ to Disk Volumes. If you define more than one disk Device resource in
+ your Storage daemon's conf file, the Volumes on thoes two devices are in
+ fact incompatible because one can not be mounted on the other device
+ since they are found in different directories. For this reason, you
+ probably should use two different Media Types for your two disk Devices
+ (even though you might think of them as both being File types). You can
+ find more on this subject in the \ilink{Basic Volume
+ Management}{_ChapterStart39} chapter of this manual.
+
+ The {\bf MediaType} specified here, {\bf must} correspond to the {\bf
+ Media Type} specified in the {\bf Device} resource of the {\bf Storage
+ daemon} configuration file. This directive is required, and it is used
+ by the Director and the Storage daemon to ensure that a Volume
+ automatically selected from the Pool corresponds to the physical device.
+ If a Storage daemon handles multiple devices (e.g. will write to
+ various file Volumes on different partitions), this directive allows you
+ to specify exactly which device.
+
+ As mentioned above, the value specified in the Director's Storage resource
+ must agree with the value specified in the Device resource in the {\bf
+ Storage daemon's} configuration file. It is also an additional check so that
+ you don't try to write data for a DLT onto an 8mm device.
\label{Autochanger1}
\item [Autochanger = \lt{}yes|no\gt{}]
\index[dir]{Autochanger }
If you specify {\bf yes} for this command (the default is {\bf no}), when
-you
-use the {\bf label} command or the {\bf add} command to create a new Volume,
-{\bf Bacula} will also request the Autochanger Slot number. This simplifies
-creating database entries for Volumes in an autochanger. If you forget to
-specify the Slot, the autochanger will not be used. However, you may modify
-the Slot associated with a Volume at any time by using the {\bf update
-volume} command in the console program. When {\bf autochanger} is enabled,
-the algorithm used by Bacula to search for available volumes will be modified
-to consider only Volumes that are known to be in the autochanger's magazine.
-If no {\bf in changer} volume is found, Bacula will attempt recycling,
-pruning, ..., and if still no volume is found, Bacula will search for any
-volume whether or not in the magazine. By privileging in changer volumes,
-this procedure minimizes operator intervention. The default is {\bf no}.
-
-For the autochanger to be used, you must also specify {\bf Autochanger = yes}
-in the
-\ilink{Device Resource}{Autochanger} in the Storage daemon's
-configuration file as well as other important Storage daemon configuration
-information. Please consult the
-\ilink{Using Autochangers}{_ChapterStart18} manual of this
-chapter for the details of using autochangers.
+ you use the {\bf label} command or the {\bf add} command to create a new
+ Volume, {\bf Bacula} will also request the Autochanger Slot number.
+ This simplifies creating database entries for Volumes in an autochanger.
+ If you forget to specify the Slot, the autochanger will not be used.
+ However, you may modify the Slot associated with a Volume at any time by
+ using the {\bf update volume} command in the console program. When {\bf
+ autochanger} is enabled, the algorithm used by Bacula to search for
+ available volumes will be modified to consider only Volumes that are
+ known to be in the autochanger's magazine. If no {\bf in changer}
+ volume is found, Bacula will attempt recycling, pruning, ..., and if
+ still no volume is found, Bacula will search for any volume whether or
+ not in the magazine. By privileging in changer volumes, this procedure
+ minimizes operator intervention. The default is {\bf no}.
+
+ For the autochanger to be used, you must also specify {\bf Autochanger =
+ yes} in the \ilink{Device Resource}{Autochanger} in the Storage daemon's
+ configuration file as well as other important Storage daemon
+ configuration information. Please consult the \ilink{Using
+ Autochangers}{_ChapterStart18} manual of this chapter for the details of
+ using autochangers.
\item [Maximum Concurrent Jobs = \lt{}number\gt{}]
\index[dir]{Maximum Concurrent Jobs }
backup to disk Volumes rather than tape Volumes. This chapter is intended to
give you some of the options that are available to you so that you can manage
either disk or tape volumes.
-\label{Concepts}
+\label{Concepts}
\subsection*{Key Concepts and Resource Records}
\index[general]{Key Concepts and Resource Records }
\index[general]{Records!Key Concepts and Resource }
\ilink{Python Scripting}{_ChapterStart60} chapter of this manual for more
details.
-Please note that automatic Volume labeling can also be used with tapes, but it is not
-nearly so practical since the tapes must be pre-mounted. This requires some
-user interaction. Automatic labeling from templates does NOT work with
-autochangers since Bacula will not access unknown slots. There are several
-methods of labeling all volumes in an autochanger magazine. For more
-information on this, please see the
-\ilink{ Autochanger}{_ChapterStart18} chapter of this manual.
+Please note that automatic Volume labeling can also be used with tapes, but
+it is not nearly so practical since the tapes must be pre-mounted. This
+requires some user interaction. Automatic labeling from templates does NOT
+work with autochangers since Bacula will not access unknown slots. There
+are several methods of labeling all volumes in an autochanger magazine.
+For more information on this, please see the \ilink{
+Autochanger}{_ChapterStart18} chapter of this manual.
Automatic Volume labeling is enabled by making a change to both the Pool
resource (Director) and to the Device resource (Storage daemon) shown above.
Bacula can, of course, use multiple disks, but in general, each disk must be a
separate Device specification in the Storage daemon's conf file, and you must
-then select what clients to backup to each disk.
+then select what clients to backup to each disk. You will also want to
+give each Device specification a different Media Type so that during
+a restore, Bacula will be able to find the appropriate drive.
-The situation is a bit more complicated if you want to treat two disk drives
-logically as a single drive, which Bacula does not directly support. However,
-it is possible to back up your data to multiple disks as if they were a single
-drive by linking the Volumes from the first disk to the second disk.
+The situation is a bit more complicated if you want to treat two different
+physical disk drives (or partitions) logically as a single drive, which
+Bacula does not directly support. However, it is possible to back up your
+data to multiple disks as if they were a single drive by linking the
+Volumes from the first disk to the second disk.
For example, assume that you have two disks named {\bf /disk1} and {\bf
/disk2>}. If you then create a standard Storage daemon Device resource for
method is that you must explicitly name the disks and cannot use automatic
labeling unless you arrange to have the labels exactly match the links you
have created.
-\label{MultipleClients}
+An important thing to know is that Bacula treats disks like tape drives
+as much as it can. This means that you can only have a single Volume
+mounted at one time on a disk as defined in your Device resource in
+the Storage daemon's conf file. You can have multiple concurrent
+jobs running that all write to the one Volume that is being used, but
+if you want to have multiple concurrent jobs that are writting to
+separate disks drives (or partitions), you will need to define
+separate Device resources for each one, exactly as you would do for
+two different tape drives. There is one fundamental difference, however.
+The Volumes that you creat on the two drives cannot be easily exchanged
+as they can for a tape drive, because they are physically resident (already
+mounted in a sense) on the particular drive. As a consequence, you will
+probably want to give them different Media Types so that Bacula can
+distinguish what Device resource to use during a restore.
+An example would be the following:
+
+\footnotesize
+\begin{verbatim}
+Device {
+ Name = Disk1
+ Media Type = File1
+ Archive Device = /disk1
+ LabelMedia = yes;
+ Random Access = Yes;
+ AutomaticMount = yes;
+ RemovableMedia = no;
+ AlwaysOpen = no;
+}
+
+Device {
+ Name = Disk2
+ Media Type = File2
+ Archive Device = /disk2
+ LabelMedia = yes;
+ Random Access = Yes;
+ AutomaticMount = yes;
+ RemovableMedia = no;
+ AlwaysOpen = no;
+}
+\end{verbatim}
+\normalsize
+
+With the above device definitions, you can run two concurrent
+jobs each writing at the same time, one to \bf{/disk2} and the
+other to \bf{/disk2}. The fact that you have given them different
+Media Types will allow Bacula to quickly choose the correct
+Storage resource in the Director when doing a restore.
+
+\label{MultipleClients}
\subsection*{Considerations for Multiple Clients}
\index[general]{Clients!Considerations for Multiple }
\index[general]{Considerations for Multiple Clients }
-1.39.0 (05 November 2005)
+ ()
projects / bacula / docs / commitdiff