--with-mysql \
--with-working-dir=/var/bacula \
--with-pid-dir=/var/run \
- --with-subsys-dir=/var/lock/subsys \
--enable-conio
\end{verbatim}
\normalsize
-Beachten Sie bitte, dass Bacula davon ausgeht, dass die Verzeichnisse /var/bacula, /var/run, und /var/loc/subsys bereits existieren und es diese während der Installation nicht automatisch erzeugt.
+Beachten Sie bitte, dass Bacula davon ausgeht, dass die Verzeichnisse
+/var/bacula, /var/run, und /var/lock/subsys bereits existieren und es diese
+während der Installation nicht automatisch erzeugt.
Beachten Sie bitte, dass bei Benutzung einer AMD64 CPU, die unter 64 bit CentOS4 läuft, mit gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5) ein Compiler Bug auftritt, so dass Code erzeugt wird, der eine Segmentverletzung verusacht. Typischerweise macht sich dies zuerst beim Storage-Dämon bemerkbar. Eine Lösung ist es, Bacula ohne Optimierung zu kompilieren (normalerweise ist dies -O2).
form of this command is:
\begin{verbatim}
-delete pool=\lt{}pool-name\gt{}
+delete pool=<pool-name>
\end{verbatim}
or
\begin{verbatim}
-delete volume=\lt{}volume-name\gt{} pool=\lt{}pool-name\gt{} or
+delete volume=>volume-name> pool=>pool-name> or
\end{verbatim}
\begin{verbatim}
-delete JobId=\lt{}job-id\gt{} JobId=\lt{}job-id2\gt{} ... or
+delete JobId=>job-id> JobId=>job-id2> ... or
\end{verbatim}
\begin{verbatim}
\begin{verbatim}
-estimate job=\lt{}job-name\gt{} listing client=\lt{}client-name\gt{}
- fileset=\lt{}fileset-name\gt{} level=\lt{}level-name\gt{}
+estimate job=<job-name> listing client=<client-name>
+ fileset=<fileset-name> level=<level-name>
\end{verbatim}
Specification of the {\bf job} is sufficient, but you can also override
is:
\begin{verbatim}
-label storage=\lt{}storage-name\gt{} volume=\lt{}volume-name\gt{}
- slot=\lt{}slot\gt{}
+label storage=>storage-name> volume=>volume-name>
+ slot=>slot>
\end{verbatim}
If you leave out any part, you will be prompted for it. The media type
specified device. The forms of the command are the same as the mount command:
\footnotesize
\begin{verbatim}
-unmount storage=<storage-name> [ drive=\lt{}num\gt{} ]
+unmount storage=<storage-name> [ drive=<num> ]
unmount [ jobid=<id> | job=<job-name> ]
\end{verbatim}
Job, JobDefs, Client, Storage, Catalog, Schedule, FileSet, Pool, Director, or
Messages. We present them here in the most logical order for defining them:
+Note, everything revolves around a job and is tied to a job in one
+way or another.
+
\begin{itemize}
\item
\ilink{Director}{DirectorResource4} -- to define the Director's
\item
\ilink{Job}{JobResource} -- to define the backup/restore Jobs
and to tie together the Client, FileSet and Schedule resources to be used
- for each Job.
+ for each Job. Normally, you will Jobs of different names corresponding
+ to each client (i.e. one Job per client, but a different one with a different name
+ for each client).
\item
\ilink{JobDefs}{JobDefsResource} -- optional resource for
providing defaults for Job resources.
\item
\ilink{Schedule}{ScheduleResource} -- to define when a Job is to
- be automatically run by {\bf Bacula's} internal scheduler.
+ be automatically run by {\bf Bacula's} internal scheduler. You
+ may have any number of Schedules, but each job will reference only
+ one.
\item
\ilink{FileSet}{FileSetResource} -- to define the set of files
- to be backed up for each Client.
+ to be backed up for each Client. You may have any number of
+ FileSets but each Job will reference only one.
\item
- \ilink{Client}{ClientResource2} -- to define what Client is to be
- backed up.
+ \ilink{Client}{ClientResource2} -- to define what Client is to be
+ backed up. You will generally have multiple Client definitions. Each
+ Job will reference only a single client.
\item
\ilink{Storage}{StorageResource2} -- to define on what physical
- device the Volumes should be mounted.
+ device the Volumes should be mounted. You may have one or
+ more Storage definitions.
\item
\ilink{Pool}{PoolResource} -- to define the pool of Volumes
- that can be used for a particular Job.
+ that can be used for a particular Job. Most people use a
+ single default Pool. However, if you have a large number
+ of clients or volumes, you may want to have multiple Pools.
+ Pools allow you to restrict a Job (or a Client) to use
+ only a particular set of Volumes.
\item
\ilink{Catalog}{CatalogResource} -- to define in what database to
keep the list of files and the Volume names where they are backed up.
+ Most people only use a single catalog. However, if you want to
+ scale the Director to many clients, multiple catalogs can be helpful.
+ Multiple catalogs require a bit more management because in general
+ you must know what catalog contains what data. Currently, all
+ Pools are defined in each catalog. This restriction will be removed
+ in a later release.
\item
- \ilink{Messages}{MessagesChapter} -- to define where error and
- information messages are to be sent or logged.
+ \ilink{Messages}{MessagesChapter} -- to define where error and
+ information messages are to be sent or logged. You may define
+ multiple different message resources and hence direct particular
+ classes of messages to different users or locations (files, ...).
\end{itemize}
\section{The Director Resource}
\item [Password = \lt{}UA-password\gt{}]
\index[dir]{Password}
\index[dir]{Directive!Password}
- Specifies the password that must be supplied for the default Bacula Console
- to be authorized. The same password must appear in the {\bf Director}
- resource of the Console configuration file. For added security, the password
- is never actually passed across the network but rather a challenge response
- hash code created with the password. This directive is required. If you have
- either {\bf /dev/random} or {\bf bc} on your machine, Bacula will generate a
- random password during the configuration process, otherwise it will be left
- blank and you must manually supply it.
+ Specifies the password that must be supplied for the default Bacula
+ Console to be authorized. The same password must appear in the {\bf
+ Director} resource of the Console configuration file. For added
+ security, the password is never passed across the network but instead a
+ challenge response hash code created with the password. This directive
+ is required. If you have either {\bf /dev/random} or {\bf bc} on your
+ machine, Bacula will generate a random password during the configuration
+ process, otherwise it will be left blank and you must manually supply
+ it.
\item [Messages = \lt{}Messages-resource-name\gt{}]
\index[dir]{Messages}
projects / bacula / docs / commitdiff