From 98a94b02a6339f6149d3d9250ddb0809b70dd789 Mon Sep 17 00:00:00 2001 From: Kern Sibbald Date: Thu, 10 Nov 2005 10:04:04 +0000 Subject: [PATCH] Update --- docs/developers/generaldevel.tex | 256 +++++++++++++----- docs/home-page/inc/header.php | 2 +- .../pages/{rfc.php => feature-request.php} | 0 docs/manual-de/console.tex | 23 +- docs/manual-de/dirdconf.tex | 151 ++++++----- docs/manual-de/disk.tex | 79 +++++- docs/manual-de/fileset.tex | 3 +- docs/manual-de/rpm-faq.tex | 48 ++++ docs/manual-de/version.tex | 2 +- docs/manual/console.tex | 23 +- docs/manual/dirdconf.tex | 148 +++++----- docs/manual/disk.tex | 79 +++++- docs/manual/version.tex | 2 +- 13 files changed, 550 insertions(+), 266 deletions(-) rename docs/home-page/pages/{rfc.php => feature-request.php} (100%) diff --git a/docs/developers/generaldevel.tex b/docs/developers/generaldevel.tex index 3d2b4e8f..fce20d9f 100644 --- a/docs/developers/generaldevel.tex +++ b/docs/developers/generaldevel.tex @@ -3,19 +3,19 @@ \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 @@ -29,7 +29,7 @@ dealing with copyright issues. The following text describes some of the 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 @@ -38,7 +38,7 @@ Forge CVS, which is the easiest for me to understand. If you have checked out the source with CVS, you can get a diff using: \begin{verbatim} -cvs diff -u +cvs diff -u \lt{}change.patch \end{verbatim} If you plan on doing @@ -48,7 +48,7 @@ that you can commit your changes directly to the CVS repository. To do so, you will need a userid on Source Forge. \subsubsection*{Copyrights} -\index{Copyrights } +\index{Copyrights} \addcontentsline{toc}{subsubsection}{Copyrights} To avoid future problems concerning changing licensing or copyrights, all code @@ -88,8 +88,8 @@ Items not needing a copyright assignment are: most small changes, 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 @@ -101,8 +101,8 @@ company must get a copyright assignment from his employer. This is to avoid 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 @@ -140,7 +140,6 @@ Address-to-be-given \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 @@ -315,10 +314,135 @@ doing your commits, your commit will effect only that directory. As 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 + 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 @@ -351,7 +475,7 @@ top source directory, stop the daemons by entering: ./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. @@ -363,8 +487,8 @@ want. If you really need more info, a debug level of 60 is not bad, and for 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 @@ -390,8 +514,8 @@ developer. For more details on this, please see the chapter in the main Bacula 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 @@ -407,16 +531,16 @@ correct any and all memory leaks that are printed at the termination of the 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 @@ -425,8 +549,8 @@ FIXME (in capitals) and no intervening spaces. This is important as it allows 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 @@ -520,8 +644,8 @@ Project gui: \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 @@ -548,8 +672,8 @@ the prototypes for subroutines exported by files in that directory. {\bf 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 @@ -568,8 +692,8 @@ Remember this is a C program that is migrating to a {\bf tiny} subset of C++, 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} @@ -577,8 +701,8 @@ so be conservative in your use of C++ features. \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} @@ -595,8 +719,8 @@ so be conservative in your use of C++ features. \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} @@ -606,8 +730,8 @@ so be conservative in your use of C++ features. \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 @@ -639,7 +763,7 @@ avoid generating too many lines, the first brace appears on the first line \begin{verbatim} if (abc) { some_code; - } + } \end{verbatim} \normalsize @@ -657,7 +781,7 @@ under a switch(), but now I prefer non-indented cases. break; default: break; - } + } \end{verbatim} \normalsize @@ -687,7 +811,7 @@ Always put space around assignment and comparison operators. a = 1; if (b >= 2) { cleanup(); - } + } \end{verbatim} \normalsize @@ -708,7 +832,7 @@ print statement, e.g.: 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 @@ -726,7 +850,7 @@ If you are using {\bf vim}, simply set your tabstop to 8 and your shiftwidth 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 @@ -737,7 +861,7 @@ them with spaces if you wish. Please don't confuse tabbing (use of tab 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: @@ -791,16 +915,16 @@ the appropriate string to be concatenated to the ``\%''. 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 @@ -826,8 +950,8 @@ Dmsg2(20, ``MD5len=\%d MD5=\%s\textbackslash{}n'', strlen(buf), buf); 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 @@ -841,17 +965,17 @@ indicates the severity or class of error, and it may be one of the following: \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} @@ -870,8 +994,8 @@ Emsg3(M\_FATAL, 0, ``bdird\lt{}filed: bad response from Filed to \%s command: \%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 @@ -891,8 +1015,8 @@ line number will be prefixed to the message. This permits a sort of debug 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 @@ -902,8 +1026,8 @@ event of a network error. \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 diff --git a/docs/home-page/inc/header.php b/docs/home-page/inc/header.php index 3907d46c..5a079f84 100644 --- a/docs/home-page/inc/header.php +++ b/docs/home-page/inc/header.php @@ -120,7 +120,7 @@
  • Email Lists
  • Bug Reports
  • Professional
    • -
  • Feature Requests
    • +
  • Feature Requests
    • diff --git a/docs/home-page/pages/rfc.php b/docs/home-page/pages/feature-request.php similarity index 100% rename from docs/home-page/pages/rfc.php rename to docs/home-page/pages/feature-request.php diff --git a/docs/manual-de/console.tex b/docs/manual-de/console.tex index 7b2ef78b..68cd5be9 100644 --- a/docs/manual-de/console.tex +++ b/docs/manual-de/console.tex @@ -298,16 +298,16 @@ attempting to label it: 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 @@ -317,7 +317,6 @@ system {\bf mt} program, something like the following: \begin{verbatim} mt -f /dev/st0 rewind mt -f /dev/st0 weof - \end{verbatim} \normalsize @@ -1155,7 +1154,7 @@ Before adding a volume, you must know the following information: \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: diff --git a/docs/manual-de/dirdconf.tex b/docs/manual-de/dirdconf.tex index 2f163c3b..d3850fba 100644 --- a/docs/manual-de/dirdconf.tex +++ b/docs/manual-de/dirdconf.tex @@ -1124,7 +1124,8 @@ by \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 @@ -1702,7 +1703,7 @@ 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]{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 @@ -1711,82 +1712,88 @@ 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 } - 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 } diff --git a/docs/manual-de/disk.tex b/docs/manual-de/disk.tex index 8a37f9e0..bba4f4be 100644 --- a/docs/manual-de/disk.tex +++ b/docs/manual-de/disk.tex @@ -19,8 +19,8 @@ backups run within a small time window, you may want to direct Bacula to 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 } @@ -153,13 +153,13 @@ much easier than trying to figure out Counter variables. See the \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. @@ -410,12 +410,15 @@ monthly cycle (take care about the amount of archive disk space used). 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 @@ -455,8 +458,56 @@ actually write the data to /disk2. The only minor inconvenience with this 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 } diff --git a/docs/manual-de/fileset.tex b/docs/manual-de/fileset.tex index ee27d71b..76c76c38 100644 --- a/docs/manual-de/fileset.tex +++ b/docs/manual-de/fileset.tex @@ -889,7 +889,7 @@ FileSet { Options { This wildfile = "*.Z" example wildfile = "*.gz" doesn't - Include = yes work + work } !!!!!!!!!!!! File = /myfile } @@ -912,7 +912,6 @@ FileSet { Options { wildfile = "*.Z" wildfile = "*.gz" - Include = yes } Options { Exclude = yes diff --git a/docs/manual-de/rpm-faq.tex b/docs/manual-de/rpm-faq.tex index 2e9b4d2e..ead5534a 100644 --- a/docs/manual-de/rpm-faq.tex +++ b/docs/manual-de/rpm-faq.tex @@ -184,3 +184,51 @@ For CentOS substitute '--define "build_centos4 1"' in place of rhel4. 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 + + diff --git a/docs/manual-de/version.tex b/docs/manual-de/version.tex index 0c6a6458..92dd8234 100644 --- a/docs/manual-de/version.tex +++ b/docs/manual-de/version.tex @@ -1 +1 @@ -1.38.0 (28 October 2005) + () diff --git a/docs/manual/console.tex b/docs/manual/console.tex index 7b2ef78b..68cd5be9 100644 --- a/docs/manual/console.tex +++ b/docs/manual/console.tex @@ -298,16 +298,16 @@ attempting to label it: 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 @@ -317,7 +317,6 @@ system {\bf mt} program, something like the following: \begin{verbatim} mt -f /dev/st0 rewind mt -f /dev/st0 weof - \end{verbatim} \normalsize @@ -1155,7 +1154,7 @@ Before adding a volume, you must know the following information: \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: diff --git a/docs/manual/dirdconf.tex b/docs/manual/dirdconf.tex index d2740268..d3850fba 100644 --- a/docs/manual/dirdconf.tex +++ b/docs/manual/dirdconf.tex @@ -1703,7 +1703,7 @@ 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]{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 @@ -1712,82 +1712,88 @@ 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 } - 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 } diff --git a/docs/manual/disk.tex b/docs/manual/disk.tex index 8a37f9e0..bba4f4be 100644 --- a/docs/manual/disk.tex +++ b/docs/manual/disk.tex @@ -19,8 +19,8 @@ backups run within a small time window, you may want to direct Bacula to 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 } @@ -153,13 +153,13 @@ much easier than trying to figure out Counter variables. See the \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. @@ -410,12 +410,15 @@ monthly cycle (take care about the amount of archive disk space used). 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 @@ -455,8 +458,56 @@ actually write the data to /disk2. The only minor inconvenience with this 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 } diff --git a/docs/manual/version.tex b/docs/manual/version.tex index df604b3e..92dd8234 100644 --- a/docs/manual/version.tex +++ b/docs/manual/version.tex @@ -1 +1 @@ -1.39.0 (05 November 2005) + () -- 2.39.5