$ 50 Ludovic Strappazon
$100 Pontis Corporation, Pavlo Tabashov
$ 20 Jan Kesten
- $100 Ulrich Schaefer
+ $100 Anonymous
$442 GDC A Kendall, Dominic Marks
Total $682.73 After PayPal fees are deducted
The third form deletes the specified Job record from the catalog database.
The last form deletes JobId records for JobIds n,m,o,p, q,r, and t. Where each
one of the n,m,... is, of course, a number.
-\label{estimate}
+\label{estimate}
\item [estimate]
- \index[console]{estimate }
- Using this command, you can get an idea how many files will be backed up, or
-if you are unsure about your Include statements in your FileSet, you can test
-them without doing an actual backup. The default is to assume a Full backup.
-However, you can override this by specifying a {\bf level=Incremental} or
-{\bf level=Differential} on the command line. A Job name must be specified
-or you will be prompted for one, and optionally a Client and FileSet may be
-specified on the command line. It then contacts the client which computes
-the number of files and bytes that would be backed up. Please note that this
-is an estimate calculated from the number of blocks in the file rather than
-by reading the actual bytes. As such, the estimated backup size will
-generally be larger than an actual backup.
-
-Optionally you may specify the keyword {\bf listing} in which case, all the
-files to be backed up will be listed. Note, it could take quite some time to
-display them if the backup is large. The full form is:
+ \index[console]{estimate}
+ Using this command, you can get an idea how many files will be backed
+ up, or if you are unsure about your Include statements in your FileSet,
+ you can test them without doing an actual backup. The default is to
+ assume a Full backup. However, you can override this by specifying a
+ {\bf level=Incremental} or {\bf level=Differential} on the command line.
+ A Job name must be specified or you will be prompted for one, and
+ optionally a Client and FileSet may be specified on the command line.
+ It then contacts the client which computes the number of files and bytes
+ that would be backed up. Please note that this is an estimate
+ calculated from the number of blocks in the file rather than by reading
+ the actual bytes. As such, the estimated backup size will generally be
+ larger than an actual backup.
+
+ Optionally you may specify the keyword {\bf listing} in which case, all the
+ files to be backed up will be listed. Note, it could take quite some time to
+ display them if the backup is large. The full form is:
estimate job=\lt{}job-name\gt{} listing client=\lt{}client-name\gt{}
fileset=\lt{}fileset-name\gt{} level=\lt{}level-name\gt{}
@output /tmp/listing
estimate job=NightlySave listing level=Incremental
@output
-
\end{verbatim}
\normalsize
/tmp/listing}.
\item [help]
- \index[console]{help }
+ \index[console]{help}
This command displays the list of commands available.
\item [label]
- \index[console]{label }
+ \index[console]{label}
+ \index[console]{relabel}
+ \index[general]{label}
+ \index[general]{relabel}
This command is used to label physical volumes. The full form of this command
-is:
+ is:
label storage=\lt{}storage-name\gt{} volume=\lt{}volume-name\gt{}
slot=\lt{}slot\gt{}
\footnotesize
\begin{verbatim}
-
update storage=xxx pool=yyy slots=1-5,10 barcodes
\end{verbatim}
\normalsize
\item [list]
\index[console]{list }
The list command lists the requested contents of the Catalog. The various
-fields of each record are listed on a single line. The various forms
-of the list command are:
+ fields of each record are listed on a single line. The various forms
+ of the list command are:
\footnotesize
\begin{verbatim}
list jobs
list volumes job=\lt{}job-name\gt{}
- list volume=\lt{}volume-name\gt{} list nextvolume job=\lt{}job-name\gt{}
+ list volume=\lt{}volume-name\gt{}
+
+ list nextvolume job=\lt{}job-name\gt{}
list nextvol job=\lt{}job-name\gt{}
+
\end{verbatim}
\normalsize
-What most of the above commands do should be more or less obvious. In general
-if you do not specify all the command line arguments, the command will prompt
-you for what is needed.
-
-The {\bf list nextvol} command will print the Volume name to be used by the
-specified job. You should be aware that exactly what Volume will be used
-depends on a lot of factors including the time and what a prior job will do.
-It may fill a tape that is not full when you issue this command. As a
-consequence, this command will give you a good estimate of what Volume will
-be used but not a definitive answer. In addition, this command may have
-certain side effect because it runs through the same algorithm as a job,
-which means it may automatically purge or recycle a Volume.
-
-If you wish to add specialized commands that list the contents of the
-catalog, you can do so by adding them to the {\bf query.sql} file. However,
-this takes some knowledge of programming SQL. Please see the {\bf query}
-command below for additional information. See below for listing the full
-contents of a catalog record with the {\bf llist} command.
-
-As an example, the command {\bf list pools} might produce the following
-output:
+
+ What most of the above commands do should be more or less obvious. In
+ general if you do not specify all the command line arguments, the
+ command will prompt you for what is needed.
+
+ The {\bf list nextvol} command will print the Volume name to be used by
+ the specified job. You should be aware that exactly what Volume will be
+ used depends on a lot of factors including the time and what a prior job
+ will do. It may fill a tape that is not full when you issue this
+ command. As a consequence, this command will give you a good estimate
+ of what Volume will be used but not a definitive answer. In addition,
+ this command may have certain side effect because it runs through the
+ same algorithm as a job, which means it may automatically purge or
+ recycle a Volume.
+
+ If you wish to add specialized commands that list the contents of the
+ catalog, you can do so by adding them to the {\bf query.sql} file.
+ However, this takes some knowledge of programming SQL. Please see the
+ {\bf query} command below for additional information. See below for
+ listing the full contents of a catalog record with the {\bf llist}
+ command.
+
+ As an example, the command {\bf list pools} might produce the following
+ output:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-As mentioned above, the {\bf list} command lists what is in the database.
-Some things are put into the database immediately when Bacula starts up, but
-in general, most things are put in only when they are first used, which is
-the case for a Client as with Job records, etc.
+ As mentioned above, the {\bf list} command lists what is in the
+ database. Some things are put into the database immediately when Bacula
+ starts up, but in general, most things are put in only when they are
+ first used, which is the case for a Client as with Job records, etc.
-Bacula should create a client record in the database the first time you run a
-job for that client. Doing a {\bf status} will not cause a database record to
-be created. The client database record will be created whether or not the job
-fails, but it must at least start. When the Client is actually contacted,
-additional info from the client will be added to the client record (a "uname
--a" output).
+ Bacula should create a client record in the database the first time you
+ run a job for that client. Doing a {\bf status} will not cause a
+ database record to be created. The client database record will be
+ created whether or not the job fails, but it must at least start. When
+ the Client is actually contacted, additional info from the client will
+ be added to the client record (a "uname -a" output).
-If you want to see what Client resources you have available in your conf
-file, you use the Console command {\bf show clients}.
+ If you want to see what Client resources you have available in your conf
+ file, you use the Console command {\bf show clients}.
\item [llist]
- \index[console]{llist }
- The llist or "long list" command takes all the same arguments that the list
-command described above does. The difference is that the llist command list
-the full contents of each database record selected. It does so by listing the
-various fields of the record vertically, with one field per line. It is
-possible to produce a very large number of output lines with this command.
+ \index[console]{llist}
+ The llist or "long list" command takes all the same arguments that the
+ list command described above does. The difference is that the llist
+ command list the full contents of each database record selected. It
+ does so by listing the various fields of the record vertically, with one
+ field per line. It is possible to produce a very large number of output
+ lines with this command.
-If instead of the {\bf list pools} as in the example above, you enter {\bf
-llist pools} you might get the following output:
+ If instead of the {\bf list pools} as in the example above, you enter
+ {\bf llist pools} you might get the following output:
\footnotesize
\begin{verbatim}
\normalsize
\item [messages]
- \index[console]{messages }
+ \index[console]{messages}
This command causes any pending console messages to be immediately displayed.
\item [mount]
- \index[console]{mount }
- The mount command is used to get Bacula to read a volume on a physical
-device. It is a way to tell Bacula that you have mounted a tape and that
-Bacula should examine the tape. This command is used only after there was no
-Volume in a drive and Bacula requests you to mount a new Volume or when you
-have specifically unmounted a Volume with the {\bf unmount} console command,
-which causes Bacula to close the drive. If you have an autoloader, the mount
-command will not cause Bacula to operate the autoloader. The various forms of
-the mount command are:
+ \index[console]{mount}
+ The mount command is used to get Bacula to read a volume on a physical
+ device. It is a way to tell Bacula that you have mounted a tape and
+ that Bacula should examine the tape. This command is used only after
+ there was no Volume in a drive and Bacula requests you to mount a new
+ Volume or when you have specifically unmounted a Volume with the {\bf
+ unmount} console command, which causes Bacula to close the drive. If
+ you have an autoloader, the mount command will not cause Bacula to
+ operate the autoloader. The various forms of the mount command are:
mount storage=\lt{}storage-name\gt{}
mount [ jobid=\lt{}id\gt{} | job=\lt{}job-name\gt{} ]
-If you have specified {\bf Automatic Mount = yes} in the Storage daemon's
-Device resource, under most circumstances, Bacula will automatically access
-the Volume unless you have explicitly {\bf unmount}ed it in the Console
-program.
+ If you have specified {\bf Automatic Mount = yes} in the Storage daemon's
+ Device resource, under most circumstances, Bacula will automatically access
+ the Volume unless you have explicitly {\bf unmount}ed it in the Console
+ program.
\item[python]
\index[console]{python}
python restart
- This causes the Python interpreter in the Director to be
- reinitialized. This can be helpful for testing because once
- the Director starts and the Python interpreter is initialized,
- there is no other way to make it accept any changes to the
- startup script {\bf DirStartUp.py}. For more details on
- Python scripting, please see the \ilink{Python Scripting}{_ChapterStart60}
- chapter of this manual.
+ This causes the Python interpreter in the Director to be reinitialized.
+ This can be helpful for testing because once the Director starts and the
+ Python interpreter is initialized, there is no other way to make it
+ accept any changes to the startup script {\bf DirStartUp.py}. For more
+ details on Python scripting, please see the \ilink{Python
+ Scripting}{_ChapterStart60} chapter of this manual.
\label{ManualPruning}
\item [prune]
\index[console]{prune }
- The Prune command allows you to safely remove expired database records from
-Jobs and Volumes. This command works only on the Catalog database and does
-not affect data written to Volumes. In all cases, the Prune command applies
-a retention period to the specified records. You can Prune expired File
-entries from Job records; you can Prune expired Job records from the
-database, and you can Prune both expired Job and File records from specified
-Volumes.
+ The Prune command allows you to safely remove expired database records
+ from Jobs and Volumes. This command works only on the Catalog database
+ and does not affect data written to Volumes. In all cases, the Prune
+ command applies a retention period to the specified records. You can
+ Prune expired File entries from Job records; you can Prune expired Job
+ records from the database, and you can Prune both expired Job and File
+ records from specified Volumes.
prune files|jobs|volume client=\lt{}client-name\gt{}
volume=\lt{}volume-name\gt{}
-For a Volume to be pruned, the {\bf VolStatus} must be Full, Used, or Append,
-otherwise the pruning will not take place.
+ For a Volume to be pruned, the {\bf VolStatus} must be Full, Used, or
+ Append, otherwise the pruning will not take place.
\item [purge]
\index[console]{purge }
- The Purge command will delete associated Catalog database records from Jobs
-and Volumes without considering the retention period. {\bf Purge} works only
-on the Catalog database and does not affect data written to Volumes. This
-command can be dangerous because you can delete catalog records associated
-with current backups of files, and we recommend that you do not use it
-unless you know what you are doing. The permitted forms of {\bf purge} are:
+ The Purge command will delete associated Catalog database records from
+ Jobs and Volumes without considering the retention period. {\bf Purge}
+ works only on the Catalog database and does not affect data written to
+ Volumes. This command can be dangerous because you can delete catalog
+ records associated with current backups of files, and we recommend that
+ you do not use it unless you know what you are doing. The permitted
+ forms of {\bf purge} are:
purge files jobid=\lt{}jobid\gt{}|job=\lt{}job-name\gt{}|client=\lt{}client-name\gt{}
The actual data written to the Volume will be unaffected by this command.
\item [relabel]
- \index[console]{relabel }
- This command is used to label physical volumes. The full form of this command
-is:
+ \index[console]{relabel}
+ \index[general]{relabel}
+ This command is used to label physical volumes. The full form of this
+ command is:
relabel storage=\lt{}storage-name\gt{} oldvolume=\lt{}old-volume-name\gt{}
volume=\lt{}newvolume-name\gt{}
-If you leave out any part, you will be prompted for it. In order for the
-Volume (old-volume-name) to be relabeled, it must be in the catalog, and the
-volume status must be marked {\bf Purged} or {\bf Recycle}. This happens
-automatically as a result of applying retention periods, or you may
-explicitly purge the volume using the {\bf purge} command.
+ If you leave out any part, you will be prompted for it. In order for
+ the Volume (old-volume-name) to be relabeled, it must be in the catalog,
+ and the volume status must be marked {\bf Purged} or {\bf Recycle}.
+ This happens automatically as a result of applying retention periods, or
+ you may explicitly purge the volume using the {\bf purge} command.
-Once the volume is physically relabeled, the old data previously written
-on the Volume is lost and cannot be recovered.
+ Once the volume is physically relabeled, the old data previously written
+ on the Volume is lost and cannot be recovered.
\item [release]
\index[console]{release }
- This command is used to cause the Storage daemon to rewind (release) the
-current tape in the drive, and to re-read the Volume label the next time the
-tape is used.
+ This command is used to cause the Storage daemon to rewind (release) the
+ current tape in the drive, and to re-read the Volume label the next time
+ the tape is used.
release storage=\lt{}storage-name\gt{}
-After a release command, the device is still kept open by Bacula (unless
-Always Open is set to No in the Storage Daemon's configuration) so it cannot
-be used by another program. However, with some tape drives, the operator can
-remove the current tape and to insert a different one, and when the next Job
-starts, Bacula will know to re-read the tape label to find out what tape is
-mounted. If you want to be able to use the drive with another program (e.g.
-{\bf mt}), you must use the {\bf unmount} command to cause Bacula to
-completely release (close) the device.
+ After a release command, the device is still kept open by Bacula (unless
+ Always Open is set to No in the Storage Daemon's configuration) so it
+ cannot be used by another program. However, with some tape drives, the
+ operator can remove the current tape and to insert a different one, and
+ when the next Job starts, Bacula will know to re-read the tape label to
+ find out what tape is mounted. If you want to be able to use the drive
+ with another program (e.g. {\bf mt}), you must use the {\bf unmount}
+ command to cause Bacula to completely release (close) the device.
\item [reload]
\index[console]{reload}
command. Once at least one old set of config values has been
released it will again accept new reload commands.
-While it is possible to reload the Director's configuration on the fly,
-even while jobs are executing, this is a complex operation and not
-without side effects. Accordingly, if you have to reload the Director's
-configuration while Bacula is running, it is advisable to restart the
-Director at the next convenient opportunity.
+ While it is possible to reload the Director's configuration on the fly,
+ even while jobs are executing, this is a complex operation and not
+ without side effects. Accordingly, if you have to reload the Director's
+ configuration while Bacula is running, it is advisable to restart the
+ Director at the next convenient opportunity.
\item [restore]
\index[console]{restore }
- The restore command allows you to select one or more Jobs (JobIds) to be
-restored using various methods. Once the JobIds are selected, the File
-records for those Jobs are placed in an internal Bacula directory tree, and
-the restore enters a file selection mode that allows you to interactively
-walk up and down the file tree selecting individual files to be restored.
-This mode is somewhat similar to the standard Unix {\bf restore} program's
-interactive file selection mode.
+ The restore command allows you to select one or more Jobs (JobIds) to be
+ restored using various methods. Once the JobIds are selected, the File
+ records for those Jobs are placed in an internal Bacula directory tree,
+ and the restore enters a file selection mode that allows you to
+ interactively walk up and down the file tree selecting individual files
+ to be restored. This mode is somewhat similar to the standard Unix {\bf
+ restore} program's interactive file selection mode.
restore storage=\lt{}storage-name\gt{} client=\lt{}client-name\gt{}
-where=\lt{}path\gt{} pool=\lt{}pool-name\gt{} fileset=\lt{}fileset-name\gt{}
-select current all done
+ where=\lt{}path\gt{} pool=\lt{}pool-name\gt{} fileset=\lt{}fileset-name\gt{}
+ select current all done
-Where {\bf current}, if specified, tells the restore command to automatically
-select a restore to the most current backup. If not specified, you will be
-prompted. The {\bf all} specification tells the restore command to restore
-all files. If it is not specified, you will be prompted for the files to
-restore. For details of the {\bf restore} command, please see the
-\ilink{Restore Chapter}{_ChapterStart13} of this manual.
+ Where {\bf current}, if specified, tells the restore command to
+ automatically select a restore to the most current backup. If not
+ specified, you will be prompted. The {\bf all} specification tells the
+ restore command to restore all files. If it is not specified, you will
+ be prompted for the files to restore. For details of the {\bf restore}
+ command, please see the \ilink{Restore Chapter}{_ChapterStart13} of this
+ manual.
\item [run]
\index[console]{run }
This command allows you to schedule jobs to be run immediately. The full form
-of the command is:
+ of the command is:
run job=\lt{}job-name\gt{} client=\lt{}client-name\gt{}
-fileset=\lt{}FileSet-name\gt{} level=\lt{}level-keyword\gt{}
-storage=\lt{}storage-name\gt{} where=\lt{}directory-prefix\gt{}
-when=\lt{}universal-time-specification\gt{} yes
+ fileset=\lt{}FileSet-name\gt{} level=\lt{}level-keyword\gt{}
+ storage=\lt{}storage-name\gt{} where=\lt{}directory-prefix\gt{}
+ when=\lt{}universal-time-specification\gt{} yes
-Any information that is needed but not specified will be listed for
-selection, and before starting the job, you will be prompted to accept,
-reject, or modify the parameters of the job to be run, unless you have
-specified {\bf yes}, in which case the job will be immediately sent to the
-scheduler.
+ Any information that is needed but not specified will be listed for
+ selection, and before starting the job, you will be prompted to accept,
+ reject, or modify the parameters of the job to be run, unless you have
+ specified {\bf yes}, in which case the job will be immediately sent to
+ the scheduler.
-On my system, when I enter a run command, I get the following prompt:
+ On my system, when I enter a run command, I get the following prompt:
\footnotesize
\begin{verbatim}
desired start time in YYYY-MM-DD HH:MM:SS format.
\item [setdebug]
- \index[dir]{setdebug }
+ \index[dir]{setdebug}
This command is used to set the debug level in each daemon. The form of this
-command is:
+ command is:
setdebug level=nn [trace=0/1 client=\lt{}client-name\gt{} | dir | director |
-storage=\lt{}storage-name\gt{} | all]
+ storage=\lt{}storage-name\gt{} | all]
-If trace=1 is set, then the tracing will be enabled, and the daemon where the
-setdebug applies will be placed in trace mode, and all debug output will go
-to the file {\bf bacula.trace} in the current directory of the daemon.
-Normally, tracing is used only for Win32 clients where the debug output
-cannot be written to a terminal or redirected to a file. When tracing, each
-debug output message is appended to the trace file. You must explicitly
-delete the file when you are done.
+ If trace=1 is set, then the tracing will be enabled, and the daemon
+ where the setdebug applies will be placed in trace mode, and all debug
+ output will go to the file {\bf bacula.trace} in the current directory
+ of the daemon. Normally, tracing is used only for Win32 clients where
+ the debug output cannot be written to a terminal or redirected to a
+ file. When tracing, each debug output message is appended to the trace
+ file. You must explicitly delete the file when you are done.
\item [show]
\index[console]{show }
- The show command will list the Director's resource records as defined in the
-Director's configuration file (normally {\bf bacula-dir.conf}). This command
-is used mainly for debugging purposes by developers. The following keywords
-are accepted on the show command line: directors, clients, counters, jobs,
-storages, catalogs, schedules, filesets, groups, pools, messages, all, help.
-Please don't confuse this command with the {\bf list}, which displays the
-contents of the catalog.
+ The show command will list the Director's resource records as defined in
+ the Director's configuration file (normally {\bf bacula-dir.conf}).
+ This command is used mainly for debugging purposes by developers. The
+ following keywords are accepted on the show command line: directors,
+ clients, counters, jobs, storages, catalogs, schedules, filesets,
+ groups, pools, messages, all, help. Please don't confuse this command
+ with the {\bf list}, which displays the contents of the catalog.
\item [sqlquery]
\index[dir]{sqlquery }
- The sqlquery command puts the Console program into SQL query mode where each
-line you enter is concatenated to the previous line until a semicolon (;) is
-seen. The semicolon terminates the command, which is then passed directly to
-the SQL database engine. When the output from the SQL engine is displayed,
-the formation of a new SQL command begins. To terminate SQL query mode and
-return to the Console command prompt, you enter a period (.) in column 1.
-
-Using this command, you can query the SQL catalog database directly. Note you
-should really know what you are doing otherwise you could damage the catalog
-database. See the {\bf query} command below for simpler and safer way of
-entering SQL queries.
-
-Depending on what database engine you are using (MySQL, PostgreSQL or SQLite), you will
-have somewhat different SQL commands available. For more detailed
-information, please refer to the MySQL, PostgreSQL or SQLite documentation.
+ The sqlquery command puts the Console program into SQL query mode where
+ each line you enter is concatenated to the previous line until a
+ semicolon (;) is seen. The semicolon terminates the command, which is
+ then passed directly to the SQL database engine. When the output from
+ the SQL engine is displayed, the formation of a new SQL command begins.
+ To terminate SQL query mode and return to the Console command prompt,
+ you enter a period (.) in column 1.
+
+ Using this command, you can query the SQL catalog database directly.
+ Note you should really know what you are doing otherwise you could
+ damage the catalog database. See the {\bf query} command below for
+ simpler and safer way of entering SQL queries.
+
+ Depending on what database engine you are using (MySQL, PostgreSQL or
+ SQLite), you will have somewhat different SQL commands available. For
+ more detailed information, please refer to the MySQL, PostgreSQL or
+ SQLite documentation.
\item [status]
\index[dir]{status }
- This command will display the status of the next jobs that are scheduled
-during the next twenty-four hours as well as the status of currently running
-jobs. The full form of this command is:
+ This command will display the status of the next jobs that are scheduled
+ during the next twenty-four hours as well as the status of currently
+ running jobs. The full form of this command is:
status [all | dir=\lt{}dir-name\gt{} | director |
-client=\lt{}client-name\gt{} | storage=\lt{}storage-name\gt{}]
+ client=\lt{}client-name\gt{} | storage=\lt{}storage-name\gt{}]
-If you do a {\bf status dir}, the console will list any currently running
-jobs, a summary of all jobs scheduled to be run in the next 24 hours, and a
-listing of the last 10 terminated jobs with their statuses. The scheduled
-jobs summary will include the Volume name to be used. You should be aware of
-two things: 1. to obtain the volume name, the code goes through the same code
-that will be used when the job runs, which means that it may prune or recycle
-a Volume; 2. The Volume listed is only a best guess. The Volume actually
-used may be different because of the time difference (more durations may
-expire when the job runs) and another job could completely fill the Volume
-requiring a new one.
+ If you do a {\bf status dir}, the console will list any currently
+ running jobs, a summary of all jobs scheduled to be run in the next 24
+ hours, and a listing of the last 10 terminated jobs with their statuses.
+ The scheduled jobs summary will include the Volume name to be used. You
+ should be aware of two things: 1. to obtain the volume name, the code
+ goes through the same code that will be used when the job runs, which
+ means that it may prune or recycle a Volume; 2. The Volume listed is
+ only a best guess. The Volume actually used may be different because of
+ the time difference (more durations may expire when the job runs) and
+ another job could completely fill the Volume requiring a new one.
-In the Running Jobs listing, you may find the following types of information:
+ In the Running Jobs listing, you may find the following types of
+ information:
\footnotesize
\end{verbatim}
\normalsize
-Looking at the above listing from bottom to top, obviously JobId 5343 (Rufus)
-is running. JobId 5348 (Minou) is waiting for JobId 5343 to finish because it
-is using the Storage resource, hence the "waiting on max Storage jobs".
-JobId 5349 has a lower priority than all the other jobs so it is waiting for
-higher priority jobs to finish, and finally, JobId 2508 (MatouVerify) is
-waiting because only one job can run at a time, hence it is simply "waiting
-execution"
+ Looking at the above listing from bottom to top, obviously JobId 5343
+ (Rufus) is running. JobId 5348 (Minou) is waiting for JobId 5343 to
+ finish because it is using the Storage resource, hence the "waiting on
+ max Storage jobs". JobId 5349 has a lower priority than all the other
+ jobs so it is waiting for higher priority jobs to finish, and finally,
+ JobId 2508 (MatouVerify) is waiting because only one job can run at a
+ time, hence it is simply "waiting execution"
\item [unmount]
\index[console]{unmount }
\footnotesize
\begin{verbatim}
-.die cause the Director to segment fault (for debugging)
-.jobs list all job names
-.filesets list all fileset names
-.clients list all client names
-.msgs return any queued messages
-.quit quit
-.exit quit
+.backups job=xxx list backups for specified job
+.defaults client=xxx fileset=yyy list defaults for specified client
+.die cause the Director to segment fault (for debugging)
+.dir when in tree mode prints the equivalent to the dir command,
+ but with fields separated by commas rather than spaces.
+.jobs list all job names
+.levels list all levels
+.filesets list all fileset names
+.clients list all client names
+.pools list all pool names
+.types list job types
+.msgs return any queued messages
+.messages get quick messages
+.help help command output
+.quit quit
+.status get status output
+.exit quit
\end{verbatim}
\normalsize
\item
\ilink{Director}{DirectorResource4} -- to define the Director's
name and its access password used for authenticating the Console program.
-Only a single Director resource definition may appear in the Director's
-configuration file. 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.
+ Only a single Director resource definition may appear in the Director's
+ configuration file. 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.
\item
\ilink{Job}{JobResource} -- to define the backup/restore Jobs
and to tie together the Client, FileSet and Schedule resources to be used
\item [Password = \lt{}UA-password\gt{}]
\index[dir]{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.
+ 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.
\item [Messages = \lt{}Messages-resource-name\gt{}]
\index[dir]{Messages }
The messages resource specifies where to deliver Director messages that are
-not associated with a specific Job. Most messages are specific to a job and
-will be directed to the Messages resource specified by the job. However,
-there are a few messages that can occur when no job is running. This
-directive is required.
+ not associated with a specific Job. Most messages are specific to a job and
+ will be directed to the Messages resource specified by the job. However,
+ there are a few messages that can occur when no job is running. This
+ directive is required.
\item [Working Directory = \lt{}Directory\gt{}]
\index[dir]{Working Directory }
\item [Scripts Directory = \lt{}Directory\gt{}]
\index[dir]{Scripts Directory }
- This directive is optional and, if defined, specifies a directory in which
-the Director
-will look for the Python startup script {\bf DirStartup.py}. This directory
-may be shared by other Bacula daemons. Standard shell expansion of the
-directory is done when the configuration file is read so that values such
-as {\bf \$HOME} will be properly expanded.
+ This directive is optional and, if defined, specifies a directory in
+ which the Director will look for the Python startup script {\bf
+ DirStartup.py}. This directory may be shared by other Bacula daemons.
+ Standard shell expansion of the directory is done when the configuration
+ file is read so that values such as {\bf \$HOME} will be properly
+ expanded.
\item [QueryFile = \lt{}Path\gt{}]
\index[dir]{QueryFile }
- This directive is mandatory and specifies a directory and file in which the
-Director can find the canned SQL statements for the {\bf Query} command of
-the Console. Standard shell expansion of the {\bf Path} is done when the
-configuration file is read so that values such as {\bf \$HOME} will be
-properly expanded. This directive is required.
-\label{DirMaxConJobs}
+ This directive is mandatory and specifies a directory and file in which
+ the Director can find the canned SQL statements for the {\bf Query}
+ command of the Console. Standard shell expansion of the {\bf Path} is
+ done when the configuration file is read so that values such as {\bf
+ \$HOME} will be properly expanded. This directive is required.
+\label{DirMaxConJobs}
\item [Maximum Concurrent Jobs = \lt{}number\gt{}]
\index[dir]{Maximum Concurrent Jobs }
\index[general]{Simultaneous Jobs}
\item [FD Connect Timeout = \lt{}time\gt{}]
\index[dir]{FD Connect Timeout }
- where {\bf time} is the time that the Director should continue attempting
-to
-contact the File daemon to start a job, and after which the Director will
-cancel the job. The default is 30 minutes.
+ where {\bf time} is the time that the Director should continue
+ attempting to contact the File daemon to start a job, and after which
+ the Director will cancel the job. The default is 30 minutes.
\item [SD Connect Timeout = \lt{}time\gt{}]
\index[dir]{SD Connect Timeout }
- where {\bf time} is the time that the Director should continue attempting
-to
-contact the Storage daemon to start a job, and after which the Director will
-cancel the job. The default is 30 minutes.
+ where {\bf time} is the time that the Director should continue
+ attempting to contact the Storage daemon to start a job, and after which
+ the Director will cancel the job. The default is 30 minutes.
\item [DirAddresses = \lt{}IP-address-specification\gt{}]
\index[dir]{DirAddresses }
- Specify the ports and addresses on which the Director daemon will listen for
-Bacula Console connections. Probably the simplest way to explain this is to
-show
-an example:
+ Specify the ports and addresses on which the Director daemon will listen
+ for Bacula Console connections. Probably the simplest way to explain
+ this is to show an example:
\footnotesize
\begin{verbatim}
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
+ 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
\item [Pool]
\index[dir]{Pool}
- Start of the Pool resource. There must be at least one Pool resource
-defined.
+ Start of the Pool resource. There must be at least one Pool resource
+ defined.
\item [Name = \lt{}name\gt{}]
\index[dir]{Name }
- The name of the pool. For most applications, you will use the default pool
-name {\bf Default}. This directive is required.
+ The name of the pool. For most applications, you will use the default
+ pool name {\bf Default}. This directive is required.
\item [Number of Volumes = \lt{}number\gt{}]
\index[dir]{Number of Volumes }
- This directive specifies the number of volumes (tapes or files) contained in
-the pool. Normally, it is defined and updated automatically by the Bacula
-catalog handling routines.
-\label{MaxVolumes}
+ This directive specifies the number of volumes (tapes or files)
+ contained in the pool. Normally, it is defined and updated
+ automatically by the Bacula catalog handling routines.
+\label{MaxVolumes}
\item [Maximum Volumes = \lt{}number\gt{}]
\index[dir]{Maximum Volumes }
- This directive specifies the maximum number of volumes (tapes or files)
-contained in the pool. This directive is optional, if omitted or set to zero,
-any number of volumes will be permitted. In general, this directive is useful
-for Autochangers where there is a fixed number of Volumes, or for File
-storage where you wish to ensure that the backups made to disk files do not
-become too numerous or consume too much space.
+ This directive specifies the maximum number of volumes (tapes or files)
+ contained in the pool. This directive is optional, if omitted or set to
+ zero, any number of volumes will be permitted. In general, this
+ directive is useful for Autochangers where there is a fixed number of
+ Volumes, or for File storage where you wish to ensure that the backups
+ made to disk files do not become too numerous or consume too much space.
\item [Pool Type = \lt{}type\gt{}]
\index[dir]{Pool Type }
- This directive defines the pool type, which corresponds to the type of Job
-being run. It is required and may be one of the following:
+ This directive defines the pool type, which corresponds to the type of
+ Job being run. It is required and may be one of the following:
\begin{itemize}
\item [Backup]
\item [Use Volume Once = \lt{}yes|no\gt{}]
\index[dir]{Use Volume Once }
- This directive if set to {\bf yes} specifies that each volume is to be used
-only once. This is most useful when the Media is a file and you want a new
-file for each backup that is done. The default is {\bf no} (i.e. use volume
-any number of times). This directive will most likely be phased out
-(deprecated), so you are recommended to use {\bf Maximum Volume Jobs = 1}
-instead.
-
-Please note that the value defined by this directive in the bacula-dir.conf
-file is the default value used when a Volume is created. Once the volume is
-created, changing the value in the bacula-dir.conf file will not change what
-is stored for the Volume. To change the value for an existing Volume you
-must use the {\bf update} command in the Console.
+ This directive if set to {\bf yes} specifies that each volume is to be
+ used only once. This is most useful when the Media is a file and you
+ want a new file for each backup that is done. The default is {\bf no}
+ (i.e. use volume any number of times). This directive will most likely
+ be phased out (deprecated), so you are recommended to use {\bf Maximum
+ Volume Jobs = 1} instead.
+
+ The value defined by this directive in the bacula-dir.conf file is the
+ default value used when a Volume is created. Once the volume is
+ created, changing the value in the bacula-dir.conf file will not change
+ what is stored for the Volume. To change the value for an existing
+ Volume you must use the {\bf update} command in the Console.
\item [Maximum Volume Jobs = \lt{}positive-integer\gt{}]
\index[dir]{Maximum Volume Jobs }
- This directive specifies the maximum number of Jobs that can be written to
-the Volume. If you specify zero (the default), there is no limit. Otherwise,
-when the number of Jobs backed up to the Volume equals {\bf positive-integer}
-the Volume will be marked {\bf Used}. When the Volume is marked {\bf Used} it
-can no longer be used for appending Jobs, much like the {\bf Full} status but
-it can be recycled if recycling is enabled, and thus used again.
-By setting {\bf
-MaximumVolumeJobs} to one, you get the same effect as setting {\bf
-UseVolumeOnce = yes}.
-
-Please note that the value defined by this directive in the bacula-dir.conf
+ This directive specifies the maximum number of Jobs that can be written
+ to the Volume. If you specify zero (the default), there is no limit.
+ Otherwise, when the number of Jobs backed up to the Volume equals {\bf
+ positive-integer} the Volume will be marked {\bf Used}. When the Volume
+ is marked {\bf Used} it can no longer be used for appending Jobs, much
+ like the {\bf Full} status but it can be recycled if recycling is
+ enabled, and thus used again. By setting {\bf MaximumVolumeJobs} to
+ one, you get the same effect as setting {\bf UseVolumeOnce = yes}.
+
+The value defined by this directive in the bacula-dir.conf
file is the default value used when a Volume is created. Once the volume is
created, changing the value in the bacula-dir.conf file will not change what
is stored for the Volume. To change the value for an existing Volume you
\item [Maximum Volume Files = \lt{}positive-integer\gt{}]
\index[dir]{Maximum Volume Files }
- This directive specifies the maximum number of files that can be written to
-the Volume. If you specify zero (the default), there is no limit. Otherwise,
-when the number of files written to the Volume equals {\bf positive-integer}
-the Volume will be marked {\bf Used}. When the Volume is marked {\bf Used} it
-can no longer be used for appending Jobs, much like the {\bf Full} status but
-it can be recycled if recycling is enabled and thus used again.
-This value is checked and the
-{\bf Used} status is set only at the end of a job that writes to the
-particular volume.
-
-Please note that the value defined by this directive in the bacula-dir.conf
-file is the default value used when a Volume is created. Once the volume is
-created, changing the value in the bacula-dir.conf file will not change what
-is stored for the Volume. To change the value for an existing Volume you
-must use the {\bf update} command in the Console.
+ This directive specifies the maximum number of files that can be written
+ to the Volume. If you specify zero (the default), there is no limit.
+ Otherwise, when the number of files written to the Volume equals {\bf
+ positive-integer} the Volume will be marked {\bf Used}. When the Volume
+ is marked {\bf Used} it can no longer be used for appending Jobs, much
+ like the {\bf Full} status but it can be recycled if recycling is
+ enabled and thus used again. This value is checked and the {\bf Used}
+ status is set only at the end of a job that writes to the particular
+ volume.
+
+ The value defined by this directive in the bacula-dir.conf file is the
+ default value used when a Volume is created. Once the volume is
+ created, changing the value in the bacula-dir.conf file will not change
+ what is stored for the Volume. To change the value for an existing
+ Volume you must use the {\bf update} command in the Console.
\item [Maximum Volume Bytes = \lt{}size\gt{}]
\index[dir]{Maximum Volume Bytes }
- This directive specifies the maximum number of bytes that can be written to
-the Volume. If you specify zero (the default), there is no limit except the
-physical size of the Volume. Otherwise, when the number of bytes written to
-the Volume equals {\bf size} the Volume will be marked {\bf Used}. When the
-Volume is marked {\bf Used} it can no longer be used for appending Jobs, much
-like the {\bf Full} status but it can be recycled if recycling is enabled,
-and thus the Volume can be re-used after recycling.
-This value is checked and the {\bf Used} status set while the job is writing
-to the particular volume.
-
-Please note that the value defined by this directive in the bacula-dir.conf
-file is the default value used when a Volume is created. Once the volume is
-created, changing the value in the bacula-dir.conf file will not change what
-is stored for the Volume. To change the value for an existing Volume you
-must use the {\bf update} command in the Console.
+ This directive specifies the maximum number of bytes that can be written
+ to the Volume. If you specify zero (the default), there is no limit
+ except the physical size of the Volume. Otherwise, when the number of
+ bytes written to the Volume equals {\bf size} the Volume will be marked
+ {\bf Used}. When the Volume is marked {\bf Used} it can no longer be
+ used for appending Jobs, much like the {\bf Full} status but it can be
+ recycled if recycling is enabled, and thus the Volume can be re-used
+ after recycling. This value is checked and the {\bf Used} status set
+ while the job is writing to the particular volume.
+
+ The value defined by this directive in the bacula-dir.conf file is the
+ default value used when a Volume is created. Once the volume is
+ created, changing the value in the bacula-dir.conf file will not change
+ what is stored for the Volume. To change the value for an existing
+ Volume you must use the {\bf update} command in the Console.
\item [Volume Use Duration = \lt{}time-period-specification\gt{}]
\index[dir]{Volume Use Duration }
\item [Name = \lt{}name\gt{}]
\index[dir]{Name }
- The name of the Catalog. No necessary relation to the database server name.
-This name will be specified in the Client resource directive indicating that
-all catalog data for that Client is maintained in this Catalog. This
-directive is required.
+ The name of the Catalog. No necessary relation to the database server
+ name. This name will be specified in the Client resource directive
+ indicating that all catalog data for that Client is maintained in this
+ Catalog. This directive is required.
\item [password = \lt{}password\gt{}]
\index[dir]{password }
- This specifies the password to use when logging into the database. This
-directive is required.
+ This specifies the password to use when logging into the database. This
+ directive is required.
\item [DB Name = \lt{}name\gt{}]
\index[dir]{DB Name }
- This specifies the name of the database. If you use multiple catalogs
-(databases), you specify which one here. If you are using an external
-database server rather than the internal one, you must specify a name that
-is known to the server (i.e. you explicitly created the Bacula tables using
-this name. This directive is required.
+ This specifies the name of the database. If you use multiple catalogs
+ (databases), you specify which one here. If you are using an external
+ database server rather than the internal one, you must specify a name
+ that is known to the server (i.e. you explicitly created the Bacula
+ tables using this name. This directive is required.
\item [user = \lt{}user\gt{}]
\index[dir]{user }
- This specifies what user name to use to log into the database. This
-directive
-is required.
+ This specifies what user name to use to log into the database. This
+ directive is required.
\item [DB Socket = \lt{}socket-name\gt{}]
\index[dir]{DB Socket }
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
+/disk2}. If you then create a standard Storage daemon Device resource for
backing up to the first disk, it will look like the following:
\footnotesize
\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
+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.
simultaneously. Once the maximum connections has been reached, each
Bacula component will reject all new connections.
+ Finally, make sure you have no {\bf hosts.allow} or {\bf hosts.deny}
+ file that is not permitting access to the site trying to connect.
+
\label{AccessProblems}
\subsection*{Bacula Runs Fine but Cannot Access a Client on a Different Machine.
Why? }
Director's conf file must be known (resolvable) by the File daemon,
because it is passed symbolically to the File daemon, which then
resolves it to get an IP address used to contact the Storage daemon.
+\item You may have a {\bf hosts.allow} or {\bf hosts.deny} file that is
+ not permitting access.
\end{itemize}
\label{startover}
rufus-fd: Filesystem change prohibited. Will not descend into /selinux
rufus-fd: Filesystem change prohibited. Will not descend into /sys
rufus-fd: Filesystem change prohibited. Will not descend into /dev
+rufus-fd: Filesystem change prohibited. Will not descend into /home
\end{verbatim}
\normalsize
If you wish to backup multiple filesystems, you can explicitly
Change: 2005-09-27 17:52:32.000000000 +0200
stat /net
- File: `/net'
- Size: 0 Blocks: 0 IO Block: 4096 directory
-Device: 15h/21d Inode: 6518 Links: 2
+ File: `/home'
+ Size: 4096 Blocks: 16 IO Block: 4096 directory
+Device: 308h/776d Inode: 2 Links: 7
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
-Access: 2005-11-10 14:47:42.943222157 +0100
-Modify: 2005-09-27 17:52:37.314265968 +0200
-Change: 2005-09-27 17:52:37.314265968 +0200
+Access: 2005-11-10 12:28:02.000000000 +0100
+Modify: 2005-11-06 12:36:48.000000000 +0100
+Change: 2005-11-06 12:36:48.000000000 +0100
\end{verbatim}
\normalsize
- Also be aware that even if you include {\bf /net} in your list
- of files to backup, you will get the informational message about
- Filesystem change prohibited when Bacula is processing the {\bf /}
- directory.
+ Also be aware that even if you include {\bf /home} in your list
+ of files to backup, as you most likely should, you will get the
+ informational message about Filesystem change prohibited when Bacula is
+ processing the {\bf /} directory.
\label{portable}
really sparse.
\label{readfifo}
-
\item [readfifo=yes|no]
\index[fd]{readfifo }
If enabled, tells the Client to read the data on a backup and write the
FIFO. When this is not enabled (default), the Client simply saves the
directory entry for the FIFO.
+ Unfortunately, when Bacula runs a RunBeforeJob, it waits until that
+ script terminates, and if the script accesses the FIFO to write
+ into the it, the Bacula job will block and everything will stall.
+ However, Vladimir Stavrinov as supplied tip that allows this feature
+ to work correctly. He simply adds the following to the beginning
+ of the RunBeforeJob script:
+
+\begin{verbatim}
+ exec > /dev/null
+\end{verbatim}
+
+
\item [mtimeonly=yes|no]
\index[dir]{mtimeonly }
If enabled, tells the Client that the selection of files during
business.
If you know what filesystems you have mounted on your system, e.g.
- for RedHat Linux normally only ext2 and ext3, you can use:
+ for RedHat Linux normally only ext2 and ext3, you can backup
+ all local fileystems using something like:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
- if {\bf /home/abc/fifo} is a fifo device, Bacula will open the fifo, read it,
- and store all data thus obtained on the Volume. Please note, you must have a
- process on the system that is writing into the fifo, or Bacula will hang,
- and after one minute of waiting, Bacula will give up and go on to the next
- file. The data read can be anything since Bacula treats it as a stream.
-
- This feature can be an excellent way to do a "hot" backup of a very large
- database. You can use the {\bf RunBeforeJob} to create the fifo and to start
- a program that dynamically reads your database and writes it to the fifo.
- Bacula will then write it to the Volume.
-
- During the restore operation, the inverse is true, after Bacula creates the
- fifo if there was any data stored with it (no need to explicitly list it or
- add any options), that data will be written back to the fifo. As a
- consequence, if any such FIFOs exist in the fileset to be restored, you must
- ensure that there is a reader program or Bacula will block, and after one
- minute, Bacula will time out the write to the fifo and move on to the next
- file.
+ if {\bf /home/abc/fifo} is a fifo device, Bacula will open the fifo,
+ read it, and store all data thus obtained on the Volume. Please note,
+ you must have a process on the system that is writing into the fifo, or
+ Bacula will hang, and after one minute of waiting, Bacula will give up
+ and go on to the next file. The data read can be anything since Bacula
+ treats it as a stream.
+
+ This feature can be an excellent way to do a "hot" backup of a very
+ large database. You can use the {\bf RunBeforeJob} to create the fifo
+ and to start a program that dynamically reads your database and writes
+ it to the fifo. Bacula will then write it to the Volume. Be sure to
+ read the \ilink{readfifo section}{readfifo} that gives a
+ tip to ensure that the RunBeforeJob does not block Bacula.
+
+ During the restore operation, the inverse is true, after Bacula creates
+ the fifo if there was any data stored with it (no need to explicitly
+ list it or add any options), that data will be written back to the fifo.
+ As a consequence, if any such FIFOs exist in the fileset to be restored,
+ you must ensure that there is a reader program or Bacula will block, and
+ after one minute, Bacula will time out the write to the fifo and move on
+ to the next file.
\end{itemize}
\subsubsection*{FileSet Examples}
\index[general]{FileSet Examples}
\addcontentsline{toc}{subsection}{FileSet Examples}
-The following is an example of a valid FileSet resource definition. Note, the
-first Include pulls in the contents of the file {\bf /etc/backup.list} when
-Bacula is started (i.e. the @), and that file must have each filename to be
-backed up preceded by a {\bf File =} and on a separate line.
+The following is an example of a valid FileSet resource definition. Note,
+the first Include pulls in the contents of the file {\bf /etc/backup.list}
+when Bacula is started (i.e. the @), and that file must have each filename
+to be backed up preceded by a {\bf File =} and on a separate line.
\footnotesize
\begin{verbatim}
request of the Director, finds the files to be backed up and sends them (their
data) to the Storage daemon.
-The File daemon configuration file is found in the directory specified on the
-{\bf \verb:--:sysconfdir} option that you specified on the {\bf ./configure}
-command.
-By default, the File daemon's configuration file is named {\bf
+The File daemon configuration file is found in the directory specified on
+the {\bf \verb:--:sysconfdir} option that you specified on the {\bf ./configure}
+command. By default, the File daemon's configuration file is named {\bf
bacula-fd.conf}. Normally, for first time users, no change is needed to this
file. Reasonable defaults are set. However, if you are going to back up more
than one machine, you will need to install the File daemon with a unique
The Director configuration file is found in the directory specified on the
{\bf \verb:--:sysconfdir} option that you specified on the {\bf ./configure}
-command.
-Normally the Director's configuration file is named {\bf bacula-dir.conf}.
+command. Normally the Director's configuration file is named {\bf bacula-dir.conf}.
In general, the only change you must make is modify the FileSet resource so
that the {\bf Include} configuration directive contains at least one line with
name, address, and password. We have found that giving your daemons the same
name as your system but post fixed with {\bf -fd} helps a lot in debugging.
That is, if your system name is {\bf foobaz}, you would give the File daemon
-the name {\bf foobaz-fd}. For the Director, you might use {\bf foobaz-dir},
+the name {\bf foobaz-fd}. For the Director, you should use {\bf foobaz-dir},
and for the storage daemon, you might use {\bf foobaz-sd}.
+Each of your Bacula components {\bf must} have a unique name. If you
+make them all the same, aside fromt the fact that you will not
+know what daemon is sending what message, if they share the same
+working directory, the daemons temporary file names will not
+be unique, and you will get many strange failures.
\subsubsection*{
\ilink{Configuring the Storage daemon}{_ChapterStart31}}
\addcontentsline{toc}{subsection}{Testing Bacula Compatibility with Your Tape
Drive}
-Before spending a lot of time on Bacula only to find that it doesn't work with
-your tape drive, please read the
-\ilink{btape -- Testing Your Tape Drive}{_ChapterStart27}
-chapter of this manual. If you have a modern standard SCSI tape drive on a
-Linux or Solaris, most likely it will work, but better test than be sorry. For
-FreeBSD (and probably other xBSD flavors), reading the above mentioned tape
-testing chapter is a must. Also, for FreeBSD, please see
-\elink{The FreeBSD Diary}{http://www.freebsddiary.org/bacula.php} for a
-detailed description on how to make Bacula work on your system. In addition,
-users of FreeBSD prior to 4.9-STABLE dated Mon Dec 29 15:18:01 2003 UTC who
-plan to use tape devices, please see the file {\bf
-platforms/freebsd/pthreads-fix.txt} in the main Bacula directory concerning
-important information concerning compatibility of Bacula and your system.
-\label{notls}
+Before spending a lot of time on Bacula only to find that it doesn't work
+with your tape drive, please read the \ilink{btape -- Testing Your Tape
+Drive}{_ChapterStart27} chapter of this manual. If you have a modern
+standard SCSI tape drive on a Linux or Solaris, most likely it will work,
+but better test than be sorry. For FreeBSD (and probably other xBSD
+flavors), reading the above mentioned tape testing chapter is a must.
+Also, for FreeBSD, please see \elink{The FreeBSD
+Diary}{http://www.freebsddiary.org/bacula.php} for a detailed description
+on how to make Bacula work on your system. In addition, users of FreeBSD
+prior to 4.9-STABLE dated Mon Dec 29 15:18:01 2003 UTC who plan to use tape
+devices, please see the file {\bf platforms/freebsd/pthreads-fix.txt} in
+the main Bacula directory concerning important information concerning
+compatibility of Bacula and your system. \label{notls}
\subsection*{Get Rid of the /lib/tls Directory}
\index[general]{Directory!Get Rid of the /lib/tls }
\item GZIP compression on a file by file basis done by the Client program if
requested before network transit.
\item Computation of MD5 or SHA1 signatures of the file data if requested.
-\item Saves and restores POSIX ACLs if enabled.
+\item Saves and restores POSIX ACLs on most OSes if enabled.
\item Autochanger support using a simple shell interface that can interface
to virtually any autoloader program. A script for {\bf mtx} is provided.
\item Support for autochanger barcodes -- automatic tape labeling from
\item Support ANSI and IBM tape labels.
\item Support for Unicode filenames (e.g. Chinese) on Win32 machines on
version 1.37.28 and greater.
-
+\item Consistent backup of open files on Win32 systems (WinXP, Win2003),
+ but not Win2000, using Volume Shadow Copy (VSS).
\end{itemize}
\subsection*{Advantages of Bacula Over Other Backup Programs}
\addcontentsline{toc}{subsection}{Current Implementation Restrictions}
\begin{itemize}
-\item Typical of Microsoft, not all files can always be saved on WinNT, Win2K
- and WinXP when they are in use by another program. Anyone knowing the magic
- incantations, please step forward. The files that are skipped seem to be in
- exclusive use by some other process, and don't appear to be too important.
-
- Volume Shadow Copy (VSS) is now (July 2005) implemented in the Bacula Win32 File
- daemon. The code is there, and it is being tested, but it is not yet
- released.
\item Path and filenames longer than 260 characters on Win32 systems are
not supported. They will be backed up, but they cannot be restored. By
using the {\bf Portable=yes} directive in your FileSet, files with
since Bacula will read it on each poll. This can be avoided by ejecting the
tape using the {\bf Offline On Unmount} and the {\bf Close on Poll}
directives.
+ However, if you are using a Linux 2.6 kernel or other OSes
+ such as FreeBSD or Solaris, the Offline On Unmount will leave the drive
+ with no tape, and Bacula will not be able to properly open the drive and
+ may fail the job. For more information on this problem, please see the
+ \ilink{description of Offline On Unmount}{NoTapeInDrive} in the Tape
+ Testing chapter.
\item [Close on Poll= {\it Yes|No}]
\index[sd]{Close on Poll}
case the drive will be taken offline preventing wear on the tape during any
future polling. Once the operator inserts a new tape, Bacula will recognize
the drive on the next poll and automatically continue with the backup.
+ Please see above more more details.
\item [Maximum Open Wait = {\it time}]
\index[sd]{Maximum Open Wait }
to changing the volume. However, most devices do not and may get very
confused.
+ If you are using a Linux 2.6 kernel or other OSes
+ such as FreeBSD or Solaris, the Offline On Unmount will leave the drive
+ with no tape, and Bacula will not be able to properly open the drive and
+ may fail the job. For more information on this problem, please see the
+ \ilink{description of Offline On Unmount}{NoTapeInDrive} in the Tape
+ Testing chapter.
+
+
\item [Maximum Volume Size = {\it size}]
\index[sd]{Maximum Volume Size }
No more than {\bf size} bytes will be written onto a given volume on the
\item [Maximum Network Buffer Size = {\it bytes}]
\index[sd]{Maximum Network Buffer Size }
where {\it bytes} specifies the initial network buffer size to use with the
-File daemon. This size will be adjusted down if it is too large until it is
-accepted by the OS. Please use care in setting this value since if it is too
-large, it will be trimmed by 512 bytes until the OS is happy, which may
-require a large number of system calls. The default value is 32,768 bytes.
+ File daemon. This size will be adjusted down if it is too large until
+ it is accepted by the OS. Please use care in setting this value since if
+ it is too large, it will be trimmed by 512 bytes until the OS is happy,
+ which may require a large number of system calls. The default value is
+ 32,768 bytes.
+
+ The default size was chosen to be relatively large but not too big in
+ the case that you are transmitting data over Internet. It is clear that
+ on a high speed local network, you can increase this number and improve
+ performance. For example, some users have found that if you use a value
+ of 65,536 bytes they get 5-10 times the throughput. Larger values for
+ most users don't seem to improve performance. If you are interested
+ in improving your backup speeds, this is definitely a place to
+ experiment. You will probably also want to make the corresponding change
+ in each of your File daemons conf files.
+
\item [Maximum Spool Size = {\it bytes}]
\index[sd]{Maximum Spool Size }
where the bytes specify the maximum spool size for all jobs that are running.
-The default is no limit.
+ The default is no limit.
\item [Maximum Job Spool Size = {\it bytes}]
\index[sd]{Maximum Job Spool Size }
completed. In particular, you may want to look at the
\ilink{ Tips for Resolving Problems}{problems1} section below.
+\label{NoTapeInDrive}
+\subsubsection*{Problems When no Tape in Drive}
+\index[general]{Problems When no Tape in Drive}
+\addcontentsline{toc}{subsubsection}{Problems When no Tape in Drive}
+When Bacula was first written the Linux 2.4 kernel permitted opening the
+drive whether or not there was a tape in the drive. Thus the Bacula code is
+based on the concept that if the drive cannot be opened, there is a serious
+problem, and the job is failed.
+
+With version 2.6 of the Linux kernel, if there is no tape in the drive, the
+OS will wait 2 minutes (default) then return a failure, and consequently,
+Bacula version 1.36 and below will fail the job. This is important to keep
+in mind, because if you use and option such as {\bf Offline on Unmount =
+yes}, there will be a point when there is no tape in the drive, and if
+another job starts or if Bacula asks the operator to mount a tape, when
+Bacula attempts to open the drive (about a 20 minute delay), it will fail
+and Bacula will fail the job.
+
+In version 1.38.x, the Bacula code partially gets around this problem -- at
+least in the initial open of the drive. However, functions like Polling
+the drive do not work correctly if there is no tape in the drive.
+Providing you do not use {\bf Offline on Unmount = yes}, you should not
+experience job failures as mentioned above. If you do experience such
+failures, you can also increase the {\bf Maximum Open Wait} time interval,
+which will give you more time to mount the next tape before the job is
+failed.
+
+
+
\subsubsection*{Specifying the Configuration File}
\index[general]{File!Specifying the Configuration}
\index[general]{Specifying the Configuration File}
http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}
{http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}.
Note, this link may change.
+
+\subsection*{Example TLS Configuration Files}
+\index[general]{Example!TLS Configuration Files}
+\index[general]{TLS Configuration Files}
+\addcontentsline{toc}{subsection}{Example TLS Configuration Files}
+
+Landon has supplied us with the TLS portions of his configuration
+files, which should help you setting up your own.
+
+{\bf bacula-dir.conf}
+\footnotesize
+\begin{verbatim}
+ Director { # define myself
+ Name = backup1-dir
+ ...
+ TLS Require = yes
+ TLS Verify Peer = yes
+ TLS Allowed CN = "bacula@backup1.example.com"
+ TLS Allowed CN = "administrator@example.com"
+ TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
+ # This is a server certificate, used for incoming
+ # console connections.
+ TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem
+ TLS Key = /usr/local/etc/ssl/backup1/key.pem
+ }
+
+ Storage {
+ Name = File
+ Address = backup1.example.com
+ ...
+ TLS Require = yes
+ TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
+ # This is a client certificate, used by the director to
+ # connect to the storage daemon
+ TLS Certificate = /usr/local/etc/ssl/bacula@backup1/cert.pem
+ TLS Key = /usr/local/etc/ssl/bacula@backup1/key.pem
+ }
+\end{verbatim}
+\normalsize
+
+{\bf bacula-fd.conf}
+\footnotesize
+\begin{verbatim}
+ Director {
+ Name = backup1-dir
+ ...
+ TLS Require = yes
+ TLS Verify Peer = yes
+ # Allow only the Director to connect
+ TLS Allowed CN = "bacula@backup1.example.com"
+ TLS CA Certificate File = /usr/local/etc/ssl/ca.pem\
+ # This is a server certificate. It is used by connecting
+ # directors to verify the authenticity of this file daemon
+ TLS Certificate = /usr/local/etc/ssl/server1/cert.pem
+ TLS Key = /usr/local/etc/ssl/server1/key.pem
+ }
+\end{verbatim}
+\normalsize
+
+{\bf bacula-sd.conf}
+\footnotesize
+\begin{verbatim}
+ Storage { # definition of myself
+ Name = backup1-sd
+ ...
+ # These TLS configuration options are used for incoming
+ # file daemon connections. Director TLS settings are handled
+ # below.
+ TLS Require = yes
+ # Peer certificate is not required/requested -- peer validity
+ # is verified by the storage connection cookie provided to the
+ # File Daemon by the director.
+ TLS Verify Peer = no
+ TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
+ # This is a server certificate. It is used by connecting
+ # file daemons to verify the authenticity of this storage daemon
+ TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem
+ TLS Key = /usr/local/etc/ssl/backup1/key.pem
+ }
+
+ #
+ # List Directors who are permitted to contact Storage daemon
+ #
+ Director {
+ Name = backup1-dir
+ ...
+ TLS Require = yes
+ # Require the connecting director to provide a certificate
+ # with the matching CN.
+ TLS Verify Peer = yes
+ TLS Allowed CN = "bacula@backup1.example.com"
+ TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
+ # This is a server certificate. It is used by the connecting
+ # director to verify the authenticity of this storage daemon
+ TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem
+ TLS Key = /usr/local/etc/ssl/backup1/key.pem
+ }
+\end{verbatim}
+\normalsize
+
+
+
\footnotesize
\begin{verbatim}
-./bacula start -d20
+./bacula start -d100
\end{verbatim}
\normalsize
+This can be particularly helpful if your daemons do not start correctly,
+because direct daemon output to the console is normally directed to the
+NULL device, but with the debug level greater than zero, the output
+will be sent to the starting terminal.
+
To stop the three daemons, enter the following from the install directory:
\footnotesize
-1.38.1 (12 November 2005)
+1.38.1 (14 November 2005)
The third form deletes the specified Job record from the catalog database.
The last form deletes JobId records for JobIds n,m,o,p, q,r, and t. Where each
one of the n,m,... is, of course, a number.
-\label{estimate}
+\label{estimate}
\item [estimate]
- \index[console]{estimate }
- Using this command, you can get an idea how many files will be backed up, or
-if you are unsure about your Include statements in your FileSet, you can test
-them without doing an actual backup. The default is to assume a Full backup.
-However, you can override this by specifying a {\bf level=Incremental} or
-{\bf level=Differential} on the command line. A Job name must be specified
-or you will be prompted for one, and optionally a Client and FileSet may be
-specified on the command line. It then contacts the client which computes
-the number of files and bytes that would be backed up. Please note that this
-is an estimate calculated from the number of blocks in the file rather than
-by reading the actual bytes. As such, the estimated backup size will
-generally be larger than an actual backup.
-
-Optionally you may specify the keyword {\bf listing} in which case, all the
-files to be backed up will be listed. Note, it could take quite some time to
-display them if the backup is large. The full form is:
+ \index[console]{estimate}
+ Using this command, you can get an idea how many files will be backed
+ up, or if you are unsure about your Include statements in your FileSet,
+ you can test them without doing an actual backup. The default is to
+ assume a Full backup. However, you can override this by specifying a
+ {\bf level=Incremental} or {\bf level=Differential} on the command line.
+ A Job name must be specified or you will be prompted for one, and
+ optionally a Client and FileSet may be specified on the command line.
+ It then contacts the client which computes the number of files and bytes
+ that would be backed up. Please note that this is an estimate
+ calculated from the number of blocks in the file rather than by reading
+ the actual bytes. As such, the estimated backup size will generally be
+ larger than an actual backup.
+
+ Optionally you may specify the keyword {\bf listing} in which case, all the
+ files to be backed up will be listed. Note, it could take quite some time to
+ display them if the backup is large. The full form is:
estimate job=\lt{}job-name\gt{} listing client=\lt{}client-name\gt{}
fileset=\lt{}fileset-name\gt{} level=\lt{}level-name\gt{}
@output /tmp/listing
estimate job=NightlySave listing level=Incremental
@output
-
\end{verbatim}
\normalsize
/tmp/listing}.
\item [help]
- \index[console]{help }
+ \index[console]{help}
This command displays the list of commands available.
\item [label]
- \index[console]{label }
+ \index[console]{label}
+ \index[console]{relabel}
+ \index[general]{label}
+ \index[general]{relabel}
This command is used to label physical volumes. The full form of this command
-is:
+ is:
label storage=\lt{}storage-name\gt{} volume=\lt{}volume-name\gt{}
slot=\lt{}slot\gt{}
\footnotesize
\begin{verbatim}
-
update storage=xxx pool=yyy slots=1-5,10 barcodes
\end{verbatim}
\normalsize
\item [list]
\index[console]{list }
The list command lists the requested contents of the Catalog. The various
-fields of each record are listed on a single line. The various forms
-of the list command are:
+ fields of each record are listed on a single line. The various forms
+ of the list command are:
\footnotesize
\begin{verbatim}
list jobs
list volumes job=\lt{}job-name\gt{}
- list volume=\lt{}volume-name\gt{} list nextvolume job=\lt{}job-name\gt{}
+ list volume=\lt{}volume-name\gt{}
+
+ list nextvolume job=\lt{}job-name\gt{}
list nextvol job=\lt{}job-name\gt{}
+
\end{verbatim}
\normalsize
-What most of the above commands do should be more or less obvious. In general
-if you do not specify all the command line arguments, the command will prompt
-you for what is needed.
-
-The {\bf list nextvol} command will print the Volume name to be used by the
-specified job. You should be aware that exactly what Volume will be used
-depends on a lot of factors including the time and what a prior job will do.
-It may fill a tape that is not full when you issue this command. As a
-consequence, this command will give you a good estimate of what Volume will
-be used but not a definitive answer. In addition, this command may have
-certain side effect because it runs through the same algorithm as a job,
-which means it may automatically purge or recycle a Volume.
-
-If you wish to add specialized commands that list the contents of the
-catalog, you can do so by adding them to the {\bf query.sql} file. However,
-this takes some knowledge of programming SQL. Please see the {\bf query}
-command below for additional information. See below for listing the full
-contents of a catalog record with the {\bf llist} command.
-
-As an example, the command {\bf list pools} might produce the following
-output:
+
+ What most of the above commands do should be more or less obvious. In
+ general if you do not specify all the command line arguments, the
+ command will prompt you for what is needed.
+
+ The {\bf list nextvol} command will print the Volume name to be used by
+ the specified job. You should be aware that exactly what Volume will be
+ used depends on a lot of factors including the time and what a prior job
+ will do. It may fill a tape that is not full when you issue this
+ command. As a consequence, this command will give you a good estimate
+ of what Volume will be used but not a definitive answer. In addition,
+ this command may have certain side effect because it runs through the
+ same algorithm as a job, which means it may automatically purge or
+ recycle a Volume.
+
+ If you wish to add specialized commands that list the contents of the
+ catalog, you can do so by adding them to the {\bf query.sql} file.
+ However, this takes some knowledge of programming SQL. Please see the
+ {\bf query} command below for additional information. See below for
+ listing the full contents of a catalog record with the {\bf llist}
+ command.
+
+ As an example, the command {\bf list pools} might produce the following
+ output:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-As mentioned above, the {\bf list} command lists what is in the database.
-Some things are put into the database immediately when Bacula starts up, but
-in general, most things are put in only when they are first used, which is
-the case for a Client as with Job records, etc.
+ As mentioned above, the {\bf list} command lists what is in the
+ database. Some things are put into the database immediately when Bacula
+ starts up, but in general, most things are put in only when they are
+ first used, which is the case for a Client as with Job records, etc.
-Bacula should create a client record in the database the first time you run a
-job for that client. Doing a {\bf status} will not cause a database record to
-be created. The client database record will be created whether or not the job
-fails, but it must at least start. When the Client is actually contacted,
-additional info from the client will be added to the client record (a "uname
--a" output).
+ Bacula should create a client record in the database the first time you
+ run a job for that client. Doing a {\bf status} will not cause a
+ database record to be created. The client database record will be
+ created whether or not the job fails, but it must at least start. When
+ the Client is actually contacted, additional info from the client will
+ be added to the client record (a "uname -a" output).
-If you want to see what Client resources you have available in your conf
-file, you use the Console command {\bf show clients}.
+ If you want to see what Client resources you have available in your conf
+ file, you use the Console command {\bf show clients}.
\item [llist]
- \index[console]{llist }
- The llist or "long list" command takes all the same arguments that the list
-command described above does. The difference is that the llist command list
-the full contents of each database record selected. It does so by listing the
-various fields of the record vertically, with one field per line. It is
-possible to produce a very large number of output lines with this command.
+ \index[console]{llist}
+ The llist or "long list" command takes all the same arguments that the
+ list command described above does. The difference is that the llist
+ command list the full contents of each database record selected. It
+ does so by listing the various fields of the record vertically, with one
+ field per line. It is possible to produce a very large number of output
+ lines with this command.
-If instead of the {\bf list pools} as in the example above, you enter {\bf
-llist pools} you might get the following output:
+ If instead of the {\bf list pools} as in the example above, you enter
+ {\bf llist pools} you might get the following output:
\footnotesize
\begin{verbatim}
\normalsize
\item [messages]
- \index[console]{messages }
+ \index[console]{messages}
This command causes any pending console messages to be immediately displayed.
\item [mount]
- \index[console]{mount }
- The mount command is used to get Bacula to read a volume on a physical
-device. It is a way to tell Bacula that you have mounted a tape and that
-Bacula should examine the tape. This command is used only after there was no
-Volume in a drive and Bacula requests you to mount a new Volume or when you
-have specifically unmounted a Volume with the {\bf unmount} console command,
-which causes Bacula to close the drive. If you have an autoloader, the mount
-command will not cause Bacula to operate the autoloader. The various forms of
-the mount command are:
+ \index[console]{mount}
+ The mount command is used to get Bacula to read a volume on a physical
+ device. It is a way to tell Bacula that you have mounted a tape and
+ that Bacula should examine the tape. This command is used only after
+ there was no Volume in a drive and Bacula requests you to mount a new
+ Volume or when you have specifically unmounted a Volume with the {\bf
+ unmount} console command, which causes Bacula to close the drive. If
+ you have an autoloader, the mount command will not cause Bacula to
+ operate the autoloader. The various forms of the mount command are:
mount storage=\lt{}storage-name\gt{}
mount [ jobid=\lt{}id\gt{} | job=\lt{}job-name\gt{} ]
-If you have specified {\bf Automatic Mount = yes} in the Storage daemon's
-Device resource, under most circumstances, Bacula will automatically access
-the Volume unless you have explicitly {\bf unmount}ed it in the Console
-program.
+ If you have specified {\bf Automatic Mount = yes} in the Storage daemon's
+ Device resource, under most circumstances, Bacula will automatically access
+ the Volume unless you have explicitly {\bf unmount}ed it in the Console
+ program.
\item[python]
\index[console]{python}
python restart
- This causes the Python interpreter in the Director to be
- reinitialized. This can be helpful for testing because once
- the Director starts and the Python interpreter is initialized,
- there is no other way to make it accept any changes to the
- startup script {\bf DirStartUp.py}. For more details on
- Python scripting, please see the \ilink{Python Scripting}{_ChapterStart60}
- chapter of this manual.
+ This causes the Python interpreter in the Director to be reinitialized.
+ This can be helpful for testing because once the Director starts and the
+ Python interpreter is initialized, there is no other way to make it
+ accept any changes to the startup script {\bf DirStartUp.py}. For more
+ details on Python scripting, please see the \ilink{Python
+ Scripting}{_ChapterStart60} chapter of this manual.
\label{ManualPruning}
\item [prune]
\index[console]{prune }
- The Prune command allows you to safely remove expired database records from
-Jobs and Volumes. This command works only on the Catalog database and does
-not affect data written to Volumes. In all cases, the Prune command applies
-a retention period to the specified records. You can Prune expired File
-entries from Job records; you can Prune expired Job records from the
-database, and you can Prune both expired Job and File records from specified
-Volumes.
+ The Prune command allows you to safely remove expired database records
+ from Jobs and Volumes. This command works only on the Catalog database
+ and does not affect data written to Volumes. In all cases, the Prune
+ command applies a retention period to the specified records. You can
+ Prune expired File entries from Job records; you can Prune expired Job
+ records from the database, and you can Prune both expired Job and File
+ records from specified Volumes.
prune files|jobs|volume client=\lt{}client-name\gt{}
volume=\lt{}volume-name\gt{}
-For a Volume to be pruned, the {\bf VolStatus} must be Full, Used, or Append,
-otherwise the pruning will not take place.
+ For a Volume to be pruned, the {\bf VolStatus} must be Full, Used, or
+ Append, otherwise the pruning will not take place.
\item [purge]
\index[console]{purge }
- The Purge command will delete associated Catalog database records from Jobs
-and Volumes without considering the retention period. {\bf Purge} works only
-on the Catalog database and does not affect data written to Volumes. This
-command can be dangerous because you can delete catalog records associated
-with current backups of files, and we recommend that you do not use it
-unless you know what you are doing. The permitted forms of {\bf purge} are:
+ The Purge command will delete associated Catalog database records from
+ Jobs and Volumes without considering the retention period. {\bf Purge}
+ works only on the Catalog database and does not affect data written to
+ Volumes. This command can be dangerous because you can delete catalog
+ records associated with current backups of files, and we recommend that
+ you do not use it unless you know what you are doing. The permitted
+ forms of {\bf purge} are:
purge files jobid=\lt{}jobid\gt{}|job=\lt{}job-name\gt{}|client=\lt{}client-name\gt{}
The actual data written to the Volume will be unaffected by this command.
\item [relabel]
- \index[console]{relabel }
- This command is used to label physical volumes. The full form of this command
-is:
+ \index[console]{relabel}
+ \index[general]{relabel}
+ This command is used to label physical volumes. The full form of this
+ command is:
relabel storage=\lt{}storage-name\gt{} oldvolume=\lt{}old-volume-name\gt{}
volume=\lt{}newvolume-name\gt{}
-If you leave out any part, you will be prompted for it. In order for the
-Volume (old-volume-name) to be relabeled, it must be in the catalog, and the
-volume status must be marked {\bf Purged} or {\bf Recycle}. This happens
-automatically as a result of applying retention periods, or you may
-explicitly purge the volume using the {\bf purge} command.
+ If you leave out any part, you will be prompted for it. In order for
+ the Volume (old-volume-name) to be relabeled, it must be in the catalog,
+ and the volume status must be marked {\bf Purged} or {\bf Recycle}.
+ This happens automatically as a result of applying retention periods, or
+ you may explicitly purge the volume using the {\bf purge} command.
-Once the volume is physically relabeled, the old data previously written
-on the Volume is lost and cannot be recovered.
+ Once the volume is physically relabeled, the old data previously written
+ on the Volume is lost and cannot be recovered.
\item [release]
\index[console]{release }
- This command is used to cause the Storage daemon to rewind (release) the
-current tape in the drive, and to re-read the Volume label the next time the
-tape is used.
+ This command is used to cause the Storage daemon to rewind (release) the
+ current tape in the drive, and to re-read the Volume label the next time
+ the tape is used.
release storage=\lt{}storage-name\gt{}
-After a release command, the device is still kept open by Bacula (unless
-Always Open is set to No in the Storage Daemon's configuration) so it cannot
-be used by another program. However, with some tape drives, the operator can
-remove the current tape and to insert a different one, and when the next Job
-starts, Bacula will know to re-read the tape label to find out what tape is
-mounted. If you want to be able to use the drive with another program (e.g.
-{\bf mt}), you must use the {\bf unmount} command to cause Bacula to
-completely release (close) the device.
+ After a release command, the device is still kept open by Bacula (unless
+ Always Open is set to No in the Storage Daemon's configuration) so it
+ cannot be used by another program. However, with some tape drives, the
+ operator can remove the current tape and to insert a different one, and
+ when the next Job starts, Bacula will know to re-read the tape label to
+ find out what tape is mounted. If you want to be able to use the drive
+ with another program (e.g. {\bf mt}), you must use the {\bf unmount}
+ command to cause Bacula to completely release (close) the device.
\item [reload]
\index[console]{reload}
command. Once at least one old set of config values has been
released it will again accept new reload commands.
-While it is possible to reload the Director's configuration on the fly,
-even while jobs are executing, this is a complex operation and not
-without side effects. Accordingly, if you have to reload the Director's
-configuration while Bacula is running, it is advisable to restart the
-Director at the next convenient opportunity.
+ While it is possible to reload the Director's configuration on the fly,
+ even while jobs are executing, this is a complex operation and not
+ without side effects. Accordingly, if you have to reload the Director's
+ configuration while Bacula is running, it is advisable to restart the
+ Director at the next convenient opportunity.
\item [restore]
\index[console]{restore }
- The restore command allows you to select one or more Jobs (JobIds) to be
-restored using various methods. Once the JobIds are selected, the File
-records for those Jobs are placed in an internal Bacula directory tree, and
-the restore enters a file selection mode that allows you to interactively
-walk up and down the file tree selecting individual files to be restored.
-This mode is somewhat similar to the standard Unix {\bf restore} program's
-interactive file selection mode.
+ The restore command allows you to select one or more Jobs (JobIds) to be
+ restored using various methods. Once the JobIds are selected, the File
+ records for those Jobs are placed in an internal Bacula directory tree,
+ and the restore enters a file selection mode that allows you to
+ interactively walk up and down the file tree selecting individual files
+ to be restored. This mode is somewhat similar to the standard Unix {\bf
+ restore} program's interactive file selection mode.
restore storage=\lt{}storage-name\gt{} client=\lt{}client-name\gt{}
-where=\lt{}path\gt{} pool=\lt{}pool-name\gt{} fileset=\lt{}fileset-name\gt{}
-select current all done
+ where=\lt{}path\gt{} pool=\lt{}pool-name\gt{} fileset=\lt{}fileset-name\gt{}
+ select current all done
-Where {\bf current}, if specified, tells the restore command to automatically
-select a restore to the most current backup. If not specified, you will be
-prompted. The {\bf all} specification tells the restore command to restore
-all files. If it is not specified, you will be prompted for the files to
-restore. For details of the {\bf restore} command, please see the
-\ilink{Restore Chapter}{_ChapterStart13} of this manual.
+ Where {\bf current}, if specified, tells the restore command to
+ automatically select a restore to the most current backup. If not
+ specified, you will be prompted. The {\bf all} specification tells the
+ restore command to restore all files. If it is not specified, you will
+ be prompted for the files to restore. For details of the {\bf restore}
+ command, please see the \ilink{Restore Chapter}{_ChapterStart13} of this
+ manual.
\item [run]
\index[console]{run }
This command allows you to schedule jobs to be run immediately. The full form
-of the command is:
+ of the command is:
run job=\lt{}job-name\gt{} client=\lt{}client-name\gt{}
-fileset=\lt{}FileSet-name\gt{} level=\lt{}level-keyword\gt{}
-storage=\lt{}storage-name\gt{} where=\lt{}directory-prefix\gt{}
-when=\lt{}universal-time-specification\gt{} yes
+ fileset=\lt{}FileSet-name\gt{} level=\lt{}level-keyword\gt{}
+ storage=\lt{}storage-name\gt{} where=\lt{}directory-prefix\gt{}
+ when=\lt{}universal-time-specification\gt{} yes
-Any information that is needed but not specified will be listed for
-selection, and before starting the job, you will be prompted to accept,
-reject, or modify the parameters of the job to be run, unless you have
-specified {\bf yes}, in which case the job will be immediately sent to the
-scheduler.
+ Any information that is needed but not specified will be listed for
+ selection, and before starting the job, you will be prompted to accept,
+ reject, or modify the parameters of the job to be run, unless you have
+ specified {\bf yes}, in which case the job will be immediately sent to
+ the scheduler.
-On my system, when I enter a run command, I get the following prompt:
+ On my system, when I enter a run command, I get the following prompt:
\footnotesize
\begin{verbatim}
desired start time in YYYY-MM-DD HH:MM:SS format.
\item [setdebug]
- \index[dir]{setdebug }
+ \index[dir]{setdebug}
This command is used to set the debug level in each daemon. The form of this
-command is:
+ command is:
setdebug level=nn [trace=0/1 client=\lt{}client-name\gt{} | dir | director |
-storage=\lt{}storage-name\gt{} | all]
+ storage=\lt{}storage-name\gt{} | all]
-If trace=1 is set, then the tracing will be enabled, and the daemon where the
-setdebug applies will be placed in trace mode, and all debug output will go
-to the file {\bf bacula.trace} in the current directory of the daemon.
-Normally, tracing is used only for Win32 clients where the debug output
-cannot be written to a terminal or redirected to a file. When tracing, each
-debug output message is appended to the trace file. You must explicitly
-delete the file when you are done.
+ If trace=1 is set, then the tracing will be enabled, and the daemon
+ where the setdebug applies will be placed in trace mode, and all debug
+ output will go to the file {\bf bacula.trace} in the current directory
+ of the daemon. Normally, tracing is used only for Win32 clients where
+ the debug output cannot be written to a terminal or redirected to a
+ file. When tracing, each debug output message is appended to the trace
+ file. You must explicitly delete the file when you are done.
\item [show]
\index[console]{show }
- The show command will list the Director's resource records as defined in the
-Director's configuration file (normally {\bf bacula-dir.conf}). This command
-is used mainly for debugging purposes by developers. The following keywords
-are accepted on the show command line: directors, clients, counters, jobs,
-storages, catalogs, schedules, filesets, groups, pools, messages, all, help.
-Please don't confuse this command with the {\bf list}, which displays the
-contents of the catalog.
+ The show command will list the Director's resource records as defined in
+ the Director's configuration file (normally {\bf bacula-dir.conf}).
+ This command is used mainly for debugging purposes by developers. The
+ following keywords are accepted on the show command line: directors,
+ clients, counters, jobs, storages, catalogs, schedules, filesets,
+ groups, pools, messages, all, help. Please don't confuse this command
+ with the {\bf list}, which displays the contents of the catalog.
\item [sqlquery]
\index[dir]{sqlquery }
- The sqlquery command puts the Console program into SQL query mode where each
-line you enter is concatenated to the previous line until a semicolon (;) is
-seen. The semicolon terminates the command, which is then passed directly to
-the SQL database engine. When the output from the SQL engine is displayed,
-the formation of a new SQL command begins. To terminate SQL query mode and
-return to the Console command prompt, you enter a period (.) in column 1.
-
-Using this command, you can query the SQL catalog database directly. Note you
-should really know what you are doing otherwise you could damage the catalog
-database. See the {\bf query} command below for simpler and safer way of
-entering SQL queries.
-
-Depending on what database engine you are using (MySQL, PostgreSQL or SQLite), you will
-have somewhat different SQL commands available. For more detailed
-information, please refer to the MySQL, PostgreSQL or SQLite documentation.
+ The sqlquery command puts the Console program into SQL query mode where
+ each line you enter is concatenated to the previous line until a
+ semicolon (;) is seen. The semicolon terminates the command, which is
+ then passed directly to the SQL database engine. When the output from
+ the SQL engine is displayed, the formation of a new SQL command begins.
+ To terminate SQL query mode and return to the Console command prompt,
+ you enter a period (.) in column 1.
+
+ Using this command, you can query the SQL catalog database directly.
+ Note you should really know what you are doing otherwise you could
+ damage the catalog database. See the {\bf query} command below for
+ simpler and safer way of entering SQL queries.
+
+ Depending on what database engine you are using (MySQL, PostgreSQL or
+ SQLite), you will have somewhat different SQL commands available. For
+ more detailed information, please refer to the MySQL, PostgreSQL or
+ SQLite documentation.
\item [status]
\index[dir]{status }
- This command will display the status of the next jobs that are scheduled
-during the next twenty-four hours as well as the status of currently running
-jobs. The full form of this command is:
+ This command will display the status of the next jobs that are scheduled
+ during the next twenty-four hours as well as the status of currently
+ running jobs. The full form of this command is:
status [all | dir=\lt{}dir-name\gt{} | director |
-client=\lt{}client-name\gt{} | storage=\lt{}storage-name\gt{}]
+ client=\lt{}client-name\gt{} | storage=\lt{}storage-name\gt{}]
-If you do a {\bf status dir}, the console will list any currently running
-jobs, a summary of all jobs scheduled to be run in the next 24 hours, and a
-listing of the last 10 terminated jobs with their statuses. The scheduled
-jobs summary will include the Volume name to be used. You should be aware of
-two things: 1. to obtain the volume name, the code goes through the same code
-that will be used when the job runs, which means that it may prune or recycle
-a Volume; 2. The Volume listed is only a best guess. The Volume actually
-used may be different because of the time difference (more durations may
-expire when the job runs) and another job could completely fill the Volume
-requiring a new one.
+ If you do a {\bf status dir}, the console will list any currently
+ running jobs, a summary of all jobs scheduled to be run in the next 24
+ hours, and a listing of the last 10 terminated jobs with their statuses.
+ The scheduled jobs summary will include the Volume name to be used. You
+ should be aware of two things: 1. to obtain the volume name, the code
+ goes through the same code that will be used when the job runs, which
+ means that it may prune or recycle a Volume; 2. The Volume listed is
+ only a best guess. The Volume actually used may be different because of
+ the time difference (more durations may expire when the job runs) and
+ another job could completely fill the Volume requiring a new one.
-In the Running Jobs listing, you may find the following types of information:
+ In the Running Jobs listing, you may find the following types of
+ information:
\footnotesize
\end{verbatim}
\normalsize
-Looking at the above listing from bottom to top, obviously JobId 5343 (Rufus)
-is running. JobId 5348 (Minou) is waiting for JobId 5343 to finish because it
-is using the Storage resource, hence the "waiting on max Storage jobs".
-JobId 5349 has a lower priority than all the other jobs so it is waiting for
-higher priority jobs to finish, and finally, JobId 2508 (MatouVerify) is
-waiting because only one job can run at a time, hence it is simply "waiting
-execution"
+ Looking at the above listing from bottom to top, obviously JobId 5343
+ (Rufus) is running. JobId 5348 (Minou) is waiting for JobId 5343 to
+ finish because it is using the Storage resource, hence the "waiting on
+ max Storage jobs". JobId 5349 has a lower priority than all the other
+ jobs so it is waiting for higher priority jobs to finish, and finally,
+ JobId 2508 (MatouVerify) is waiting because only one job can run at a
+ time, hence it is simply "waiting execution"
\item [unmount]
\index[console]{unmount }
\footnotesize
\begin{verbatim}
-.die cause the Director to segment fault (for debugging)
-.jobs list all job names
-.filesets list all fileset names
-.clients list all client names
-.msgs return any queued messages
-.quit quit
-.exit quit
+.backups job=xxx list backups for specified job
+.defaults client=xxx fileset=yyy list defaults for specified client
+.die cause the Director to segment fault (for debugging)
+.dir when in tree mode prints the equivalent to the dir command,
+ but with fields separated by commas rather than spaces.
+.jobs list all job names
+.levels list all levels
+.filesets list all fileset names
+.clients list all client names
+.pools list all pool names
+.types list job types
+.msgs return any queued messages
+.messages get quick messages
+.help help command output
+.quit quit
+.status get status output
+.exit quit
\end{verbatim}
\normalsize
\item
\ilink{Director}{DirectorResource4} -- to define the Director's
name and its access password used for authenticating the Console program.
-Only a single Director resource definition may appear in the Director's
-configuration file. 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.
+ Only a single Director resource definition may appear in the Director's
+ configuration file. 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.
\item
\ilink{Job}{JobResource} -- to define the backup/restore Jobs
and to tie together the Client, FileSet and Schedule resources to be used
\item [Password = \lt{}UA-password\gt{}]
\index[dir]{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.
+ 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.
\item [Messages = \lt{}Messages-resource-name\gt{}]
\index[dir]{Messages }
The messages resource specifies where to deliver Director messages that are
-not associated with a specific Job. Most messages are specific to a job and
-will be directed to the Messages resource specified by the job. However,
-there are a few messages that can occur when no job is running. This
-directive is required.
+ not associated with a specific Job. Most messages are specific to a job and
+ will be directed to the Messages resource specified by the job. However,
+ there are a few messages that can occur when no job is running. This
+ directive is required.
\item [Working Directory = \lt{}Directory\gt{}]
\index[dir]{Working Directory }
\item [Scripts Directory = \lt{}Directory\gt{}]
\index[dir]{Scripts Directory }
- This directive is optional and, if defined, specifies a directory in which
-the Director
-will look for the Python startup script {\bf DirStartup.py}. This directory
-may be shared by other Bacula daemons. Standard shell expansion of the
-directory is done when the configuration file is read so that values such
-as {\bf \$HOME} will be properly expanded.
+ This directive is optional and, if defined, specifies a directory in
+ which the Director will look for the Python startup script {\bf
+ DirStartup.py}. This directory may be shared by other Bacula daemons.
+ Standard shell expansion of the directory is done when the configuration
+ file is read so that values such as {\bf \$HOME} will be properly
+ expanded.
\item [QueryFile = \lt{}Path\gt{}]
\index[dir]{QueryFile }
- This directive is mandatory and specifies a directory and file in which the
-Director can find the canned SQL statements for the {\bf Query} command of
-the Console. Standard shell expansion of the {\bf Path} is done when the
-configuration file is read so that values such as {\bf \$HOME} will be
-properly expanded. This directive is required.
-\label{DirMaxConJobs}
+ This directive is mandatory and specifies a directory and file in which
+ the Director can find the canned SQL statements for the {\bf Query}
+ command of the Console. Standard shell expansion of the {\bf Path} is
+ done when the configuration file is read so that values such as {\bf
+ \$HOME} will be properly expanded. This directive is required.
+\label{DirMaxConJobs}
\item [Maximum Concurrent Jobs = \lt{}number\gt{}]
\index[dir]{Maximum Concurrent Jobs }
\index[general]{Simultaneous Jobs}
\item [FD Connect Timeout = \lt{}time\gt{}]
\index[dir]{FD Connect Timeout }
- where {\bf time} is the time that the Director should continue attempting
-to
-contact the File daemon to start a job, and after which the Director will
-cancel the job. The default is 30 minutes.
+ where {\bf time} is the time that the Director should continue
+ attempting to contact the File daemon to start a job, and after which
+ the Director will cancel the job. The default is 30 minutes.
\item [SD Connect Timeout = \lt{}time\gt{}]
\index[dir]{SD Connect Timeout }
- where {\bf time} is the time that the Director should continue attempting
-to
-contact the Storage daemon to start a job, and after which the Director will
-cancel the job. The default is 30 minutes.
+ where {\bf time} is the time that the Director should continue
+ attempting to contact the Storage daemon to start a job, and after which
+ the Director will cancel the job. The default is 30 minutes.
\item [DirAddresses = \lt{}IP-address-specification\gt{}]
\index[dir]{DirAddresses }
- Specify the ports and addresses on which the Director daemon will listen for
-Bacula Console connections. Probably the simplest way to explain this is to
-show
-an example:
+ Specify the ports and addresses on which the Director daemon will listen
+ for Bacula Console connections. Probably the simplest way to explain
+ this is to show an example:
\footnotesize
\begin{verbatim}
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
+ 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
\item [Pool]
\index[dir]{Pool}
- Start of the Pool resource. There must be at least one Pool resource
-defined.
+ Start of the Pool resource. There must be at least one Pool resource
+ defined.
\item [Name = \lt{}name\gt{}]
\index[dir]{Name }
- The name of the pool. For most applications, you will use the default pool
-name {\bf Default}. This directive is required.
+ The name of the pool. For most applications, you will use the default
+ pool name {\bf Default}. This directive is required.
\item [Number of Volumes = \lt{}number\gt{}]
\index[dir]{Number of Volumes }
- This directive specifies the number of volumes (tapes or files) contained in
-the pool. Normally, it is defined and updated automatically by the Bacula
-catalog handling routines.
-\label{MaxVolumes}
+ This directive specifies the number of volumes (tapes or files)
+ contained in the pool. Normally, it is defined and updated
+ automatically by the Bacula catalog handling routines.
+\label{MaxVolumes}
\item [Maximum Volumes = \lt{}number\gt{}]
\index[dir]{Maximum Volumes }
- This directive specifies the maximum number of volumes (tapes or files)
-contained in the pool. This directive is optional, if omitted or set to zero,
-any number of volumes will be permitted. In general, this directive is useful
-for Autochangers where there is a fixed number of Volumes, or for File
-storage where you wish to ensure that the backups made to disk files do not
-become too numerous or consume too much space.
+ This directive specifies the maximum number of volumes (tapes or files)
+ contained in the pool. This directive is optional, if omitted or set to
+ zero, any number of volumes will be permitted. In general, this
+ directive is useful for Autochangers where there is a fixed number of
+ Volumes, or for File storage where you wish to ensure that the backups
+ made to disk files do not become too numerous or consume too much space.
\item [Pool Type = \lt{}type\gt{}]
\index[dir]{Pool Type }
- This directive defines the pool type, which corresponds to the type of Job
-being run. It is required and may be one of the following:
+ This directive defines the pool type, which corresponds to the type of
+ Job being run. It is required and may be one of the following:
\begin{itemize}
\item [Backup]
\item [Use Volume Once = \lt{}yes|no\gt{}]
\index[dir]{Use Volume Once }
- This directive if set to {\bf yes} specifies that each volume is to be used
-only once. This is most useful when the Media is a file and you want a new
-file for each backup that is done. The default is {\bf no} (i.e. use volume
-any number of times). This directive will most likely be phased out
-(deprecated), so you are recommended to use {\bf Maximum Volume Jobs = 1}
-instead.
-
-Please note that the value defined by this directive in the bacula-dir.conf
-file is the default value used when a Volume is created. Once the volume is
-created, changing the value in the bacula-dir.conf file will not change what
-is stored for the Volume. To change the value for an existing Volume you
-must use the {\bf update} command in the Console.
+ This directive if set to {\bf yes} specifies that each volume is to be
+ used only once. This is most useful when the Media is a file and you
+ want a new file for each backup that is done. The default is {\bf no}
+ (i.e. use volume any number of times). This directive will most likely
+ be phased out (deprecated), so you are recommended to use {\bf Maximum
+ Volume Jobs = 1} instead.
+
+ The value defined by this directive in the bacula-dir.conf file is the
+ default value used when a Volume is created. Once the volume is
+ created, changing the value in the bacula-dir.conf file will not change
+ what is stored for the Volume. To change the value for an existing
+ Volume you must use the {\bf update} command in the Console.
\item [Maximum Volume Jobs = \lt{}positive-integer\gt{}]
\index[dir]{Maximum Volume Jobs }
- This directive specifies the maximum number of Jobs that can be written to
-the Volume. If you specify zero (the default), there is no limit. Otherwise,
-when the number of Jobs backed up to the Volume equals {\bf positive-integer}
-the Volume will be marked {\bf Used}. When the Volume is marked {\bf Used} it
-can no longer be used for appending Jobs, much like the {\bf Full} status but
-it can be recycled if recycling is enabled, and thus used again.
-By setting {\bf
-MaximumVolumeJobs} to one, you get the same effect as setting {\bf
-UseVolumeOnce = yes}.
-
-Please note that the value defined by this directive in the bacula-dir.conf
+ This directive specifies the maximum number of Jobs that can be written
+ to the Volume. If you specify zero (the default), there is no limit.
+ Otherwise, when the number of Jobs backed up to the Volume equals {\bf
+ positive-integer} the Volume will be marked {\bf Used}. When the Volume
+ is marked {\bf Used} it can no longer be used for appending Jobs, much
+ like the {\bf Full} status but it can be recycled if recycling is
+ enabled, and thus used again. By setting {\bf MaximumVolumeJobs} to
+ one, you get the same effect as setting {\bf UseVolumeOnce = yes}.
+
+The value defined by this directive in the bacula-dir.conf
file is the default value used when a Volume is created. Once the volume is
created, changing the value in the bacula-dir.conf file will not change what
is stored for the Volume. To change the value for an existing Volume you
\item [Maximum Volume Files = \lt{}positive-integer\gt{}]
\index[dir]{Maximum Volume Files }
- This directive specifies the maximum number of files that can be written to
-the Volume. If you specify zero (the default), there is no limit. Otherwise,
-when the number of files written to the Volume equals {\bf positive-integer}
-the Volume will be marked {\bf Used}. When the Volume is marked {\bf Used} it
-can no longer be used for appending Jobs, much like the {\bf Full} status but
-it can be recycled if recycling is enabled and thus used again.
-This value is checked and the
-{\bf Used} status is set only at the end of a job that writes to the
-particular volume.
-
-Please note that the value defined by this directive in the bacula-dir.conf
-file is the default value used when a Volume is created. Once the volume is
-created, changing the value in the bacula-dir.conf file will not change what
-is stored for the Volume. To change the value for an existing Volume you
-must use the {\bf update} command in the Console.
+ This directive specifies the maximum number of files that can be written
+ to the Volume. If you specify zero (the default), there is no limit.
+ Otherwise, when the number of files written to the Volume equals {\bf
+ positive-integer} the Volume will be marked {\bf Used}. When the Volume
+ is marked {\bf Used} it can no longer be used for appending Jobs, much
+ like the {\bf Full} status but it can be recycled if recycling is
+ enabled and thus used again. This value is checked and the {\bf Used}
+ status is set only at the end of a job that writes to the particular
+ volume.
+
+ The value defined by this directive in the bacula-dir.conf file is the
+ default value used when a Volume is created. Once the volume is
+ created, changing the value in the bacula-dir.conf file will not change
+ what is stored for the Volume. To change the value for an existing
+ Volume you must use the {\bf update} command in the Console.
\item [Maximum Volume Bytes = \lt{}size\gt{}]
\index[dir]{Maximum Volume Bytes }
- This directive specifies the maximum number of bytes that can be written to
-the Volume. If you specify zero (the default), there is no limit except the
-physical size of the Volume. Otherwise, when the number of bytes written to
-the Volume equals {\bf size} the Volume will be marked {\bf Used}. When the
-Volume is marked {\bf Used} it can no longer be used for appending Jobs, much
-like the {\bf Full} status but it can be recycled if recycling is enabled,
-and thus the Volume can be re-used after recycling.
-This value is checked and the {\bf Used} status set while the job is writing
-to the particular volume.
-
-Please note that the value defined by this directive in the bacula-dir.conf
-file is the default value used when a Volume is created. Once the volume is
-created, changing the value in the bacula-dir.conf file will not change what
-is stored for the Volume. To change the value for an existing Volume you
-must use the {\bf update} command in the Console.
+ This directive specifies the maximum number of bytes that can be written
+ to the Volume. If you specify zero (the default), there is no limit
+ except the physical size of the Volume. Otherwise, when the number of
+ bytes written to the Volume equals {\bf size} the Volume will be marked
+ {\bf Used}. When the Volume is marked {\bf Used} it can no longer be
+ used for appending Jobs, much like the {\bf Full} status but it can be
+ recycled if recycling is enabled, and thus the Volume can be re-used
+ after recycling. This value is checked and the {\bf Used} status set
+ while the job is writing to the particular volume.
+
+ The value defined by this directive in the bacula-dir.conf file is the
+ default value used when a Volume is created. Once the volume is
+ created, changing the value in the bacula-dir.conf file will not change
+ what is stored for the Volume. To change the value for an existing
+ Volume you must use the {\bf update} command in the Console.
\item [Volume Use Duration = \lt{}time-period-specification\gt{}]
\index[dir]{Volume Use Duration }
\item [Name = \lt{}name\gt{}]
\index[dir]{Name }
- The name of the Catalog. No necessary relation to the database server name.
-This name will be specified in the Client resource directive indicating that
-all catalog data for that Client is maintained in this Catalog. This
-directive is required.
+ The name of the Catalog. No necessary relation to the database server
+ name. This name will be specified in the Client resource directive
+ indicating that all catalog data for that Client is maintained in this
+ Catalog. This directive is required.
\item [password = \lt{}password\gt{}]
\index[dir]{password }
- This specifies the password to use when logging into the database. This
-directive is required.
+ This specifies the password to use when logging into the database. This
+ directive is required.
\item [DB Name = \lt{}name\gt{}]
\index[dir]{DB Name }
- This specifies the name of the database. If you use multiple catalogs
-(databases), you specify which one here. If you are using an external
-database server rather than the internal one, you must specify a name that
-is known to the server (i.e. you explicitly created the Bacula tables using
-this name. This directive is required.
+ This specifies the name of the database. If you use multiple catalogs
+ (databases), you specify which one here. If you are using an external
+ database server rather than the internal one, you must specify a name
+ that is known to the server (i.e. you explicitly created the Bacula
+ tables using this name. This directive is required.
\item [user = \lt{}user\gt{}]
\index[dir]{user }
- This specifies what user name to use to log into the database. This
-directive
-is required.
+ This specifies what user name to use to log into the database. This
+ directive is required.
\item [DB Socket = \lt{}socket-name\gt{}]
\index[dir]{DB Socket }
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
+/disk2}. If you then create a standard Storage daemon Device resource for
backing up to the first disk, it will look like the following:
\footnotesize
\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
+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.
since Bacula will read it on each poll. This can be avoided by ejecting the
tape using the {\bf Offline On Unmount} and the {\bf Close on Poll}
directives.
+ However, if you are using a Linux 2.6 kernel or other OSes
+ such as FreeBSD or Solaris, the Offline On Unmount will leave the drive
+ with no tape, and Bacula will not be able to properly open the drive and
+ may fail the job. For more information on this problem, please see the
+ \ilink{description of Offline On Unmount}{NoTapeInDrive} in the Tape
+ Testing chapter.
\item [Close on Poll= {\it Yes|No}]
\index[sd]{Close on Poll}
case the drive will be taken offline preventing wear on the tape during any
future polling. Once the operator inserts a new tape, Bacula will recognize
the drive on the next poll and automatically continue with the backup.
+ Please see above more more details.
\item [Maximum Open Wait = {\it time}]
\index[sd]{Maximum Open Wait }
to changing the volume. However, most devices do not and may get very
confused.
+ If you are using a Linux 2.6 kernel or other OSes
+ such as FreeBSD or Solaris, the Offline On Unmount will leave the drive
+ with no tape, and Bacula will not be able to properly open the drive and
+ may fail the job. For more information on this problem, please see the
+ \ilink{description of Offline On Unmount}{NoTapeInDrive} in the Tape
+ Testing chapter.
+
+
\item [Maximum Volume Size = {\it size}]
\index[sd]{Maximum Volume Size }
No more than {\bf size} bytes will be written onto a given volume on the
\item [Maximum Network Buffer Size = {\it bytes}]
\index[sd]{Maximum Network Buffer Size }
where {\it bytes} specifies the initial network buffer size to use with the
-File daemon. This size will be adjusted down if it is too large until it is
-accepted by the OS. Please use care in setting this value since if it is too
-large, it will be trimmed by 512 bytes until the OS is happy, which may
-require a large number of system calls. The default value is 32,768 bytes.
+ File daemon. This size will be adjusted down if it is too large until
+ it is accepted by the OS. Please use care in setting this value since if
+ it is too large, it will be trimmed by 512 bytes until the OS is happy,
+ which may require a large number of system calls. The default value is
+ 32,768 bytes.
+
+ The default size was chosen to be relatively large but not too big in
+ the case that you are transmitting data over Internet. It is clear that
+ on a high speed local network, you can increase this number and improve
+ performance. For example, some users have found that if you use a value
+ of 65,536 bytes they get 5-10 times the throughput. Larger values for
+ most users don't seem to improve performance. If you are interested
+ in improving your backup speeds, this is definitely a place to
+ experiment. You will probably also want to make the corresponding change
+ in each of your File daemons conf files.
+
\item [Maximum Spool Size = {\it bytes}]
\index[sd]{Maximum Spool Size }
where the bytes specify the maximum spool size for all jobs that are running.
-The default is no limit.
+ The default is no limit.
\item [Maximum Job Spool Size = {\it bytes}]
\index[sd]{Maximum Job Spool Size }
completed. In particular, you may want to look at the
\ilink{ Tips for Resolving Problems}{problems1} section below.
+\label{NoTapeInDrive}
+\subsubsection*{Problems When no Tape in Drive}
+\index[general]{Problems When no Tape in Drive}
+\addcontentsline{toc}{subsubsection}{Problems When no Tape in Drive}
+When Bacula was first written the Linux 2.4 kernel permitted opening the
+drive whether or not there was a tape in the drive. Thus the Bacula code is
+based on the concept that if the drive cannot be opened, there is a serious
+problem, and the job is failed.
+
+With version 2.6 of the Linux kernel, if there is no tape in the drive, the
+OS will wait 2 minutes (default) then return a failure, and consequently,
+Bacula version 1.36 and below will fail the job. This is important to keep
+in mind, because if you use and option such as {\bf Offline on Unmount =
+yes}, there will be a point when there is no tape in the drive, and if
+another job starts or if Bacula asks the operator to mount a tape, when
+Bacula attempts to open the drive (about a 20 minute delay), it will fail
+and Bacula will fail the job.
+
+In version 1.38.x, the Bacula code partially gets around this problem -- at
+least in the initial open of the drive. However, functions like Polling
+the drive do not work correctly if there is no tape in the drive.
+Providing you do not use {\bf Offline on Unmount = yes}, you should not
+experience job failures as mentioned above. If you do experience such
+failures, you can also increase the {\bf Maximum Open Wait} time interval,
+which will give you more time to mount the next tape before the job is
+failed.
+
+
+
\subsubsection*{Specifying the Configuration File}
\index[general]{File!Specifying the Configuration}
\index[general]{Specifying the Configuration File}
-1.38.1 (12 November 2005)
+1.38.1 (14 November 2005)
projects / bacula / docs / commitdiff