\chapter{Bacula Enterprise Console}
\label{blb:ConsoleChapter}
\index[general]{Console!Bacula}
\index[general]{Bacula Console}

The \bConsole{} (sometimes called the \emph{User Agent}) is a program
that allows the user or the System Administrator, to interact with the
 \bDirector{} daemon while the daemon is running.

The current \bConsole{} comes in two versions: a shell interface (TTY
style), and a QT GUI interface (\bat{}). Both permit the administrator or
authorized users to interact with \bacula{}. You can determine the status of a
particular job, examine the contents of the Catalog as well as perform certain
tape manipulations with the Console program.

Since the Console program interacts with the \bacula{} \bDirector{} through the network,
 your \bConsole{} and \bDirector{} programs do not necessarily need to run on the
 same machine.

In fact, a certain minimal knowledge of the Console program is needed in order
for \bacula{} to be able to write on more than one tape, because when \bacula{}
requests a new tape, it waits until the user, via the Console program,
indicates that the new tape is mounted.

\section{Console Configuration}
\index[general]{Console Configuration}
\index[general]{Configuration!Console}

When the \bConsole{} starts, it reads a standard \bacula{} configuration file
named \bfilename{bconsole.conf} or \bfilename{bat.conf} in the case of the \bat{}
QT \bConsole{} version from the current directory unless you specify the \textbf{-c}
command line option (see below). This file allows default configuration
of the \bConsole{}, and at the current time, the only Resource Record defined
is the \bresource{Director}, which gives the \bConsole{} the name and address of
the \bDirector{}.  For more information on configuration of the \bConsole{}
program, please see the \bxlink{Console Configuration}{blb:ConsoleConfChapter}{main}{chapter} of the \bmainman{}.

\section{Running the Console Program}
\index[general]{Running the Console Program}
\index[general]{Program!Running the Console}

The \bconsole{} program can be run with the following options:
\begin{bVerbatim}
Usage: bconsole [-s] [-c config_file] [-d debug_level]
       -c <file>   set configuration file to file
       -dnn        set debug level to nn
       -n          no conio
       -s          no signals
       -u <nn>     set command execution timeout to <nn> seconds
       -t          test - read configuration and exit
       -?          print this message.
\end{bVerbatim}


After launching the \bConsole{} program (\bconsolename{}), it will prompt you for the next
command with an asterisk (*).  Generally, for all commands, you can simply
enter the command name and the Console program will prompt you for the
necessary arguments. Alternatively, in most cases, you may enter the command
followed by arguments. The general format is:

\begin{bVerbatim}
 <command> <keyword1>[=<argument1>] <keyword2>[=<argument2>] ...
\end{bVerbatim}

where \bhighlight{command} is one of the commands listed below; \bhighlight{keyword} is one
of the keywords listed below (usually followed by an argument); and \bhighlight{argument}
is the value. The command may be abbreviated to the shortest unique
form. If two commands have the same starting letters, the one that will be
selected is the one that appears first in the \bcommandname{help} listing. If you want
the second command, simply spell out the full command. None of the keywords
following the command may be abbreviated.

For example:
\begin{bVerbatim}
list files jobid=23
\end{bVerbatim}

will list all files saved for JobId 23. Or:

\begin{bVerbatim}
show pools
\end{bVerbatim}

will display all the \bresourcename{Pool} resource records. 

The maximum command line length is limited to \bvalue{511} characters, so if you
are scripting the console, you may need to take some care to limit the
line length.

\section{Stopping the Console Program}
\index[general]{Program!Stopping the Console}
\index[general]{Stopping the Console Program}

Normally, you simply enter \bcommandname{quit} or \bcommandname{exit} and the \bConsole{} program
will terminate. However, it waits until the \bDirector{} acknowledges the command.
If the \bDirector{} is already doing a lengthy command (e.g. \bcommandname{prune}), it may take
some time. If you want to immediately terminate the \bConsole{} program, enter the
\bcommandname{.quit} command.

There is currently no way to interrupt a \bConsole{} command once issued (i.e.
\texttt{Ctrl-C} does not work). However, if you are at a prompt that is asking you to
select one of several possibilities and you would like to abort the command,
you can enter a period (\bcommandname{.}), and in most cases, you will either be
returned to the main command prompt or if appropriate the previous prompt (in
the case of nested prompts). In a few places such as where it is asking for a
Volume name, the period will be taken to be the Volume name. In that case, you
will most likely be able to cancel at the next prompt. 

\label{blb:keywords}
\section{Alphabetic List of Console Keywords}
\index[general]{Keywords!Alphabetic List of Console}
\index[general]{Alphabetic List of Console Keywords}
Unless otherwise specified, each of the following keywords
takes an argument, which is specified after the keyword following
an equal sign. For example:

\begin{bVerbatim}
jobid=536
\end{bVerbatim}

% Please note, this list is incomplete as it is currently in
% the process of being created and is not currently totally in
% alphabetic
% order ...

\begin{bdescription}
\item [all]
  Permitted on the \bcommandname{status} and \bcommandname{show} commands to specify all components or
  resources respectively.
\item [frompool]
  Permitted on the \bcommandname{update volume} command to specify that the volume specified
  on the command line should be updated with pool parameters.
\item [allfrompool=\bbracket{pool}]
  Permitted on the \bcommandname{update} command to specify that all Volumes in the
  pool (specified on the command line) should be updated.
\item [fromallpools]
  Permitted on the \bcommandname{update} command to specify that all Volumes in all
  pools should be updated.
\item [before]
  Used in the \bcommandname{restore} command.
\item [bootstrap]
  Used in the \bcommandname{restore} command.
\item [catalog]
  Allowed in the \bcommandname{use} command to specify the catalog name
  to be used.
\item [catalogs]
  Used in the \bcommandname{show} command. Takes no arguments.
\item [client | fd]
\item [clients]
  Used in the \bcommandname{show}, \bcommandname{list}, and \bcommandname{llist} commands. Takes no arguments.
\item [counters]
  Used in the \bcommandname{show} command. Takes no arguments.
\item [current]
  Used in the \bcommandname{restore} command. Takes no argument.
\item [days]
  Used to define the number of days the \bcommandname{list nextvol} command
  should consider when looking for jobs to be run.  The \bcommandname{days} keyword
  can also be used on the \bcommandname{status dir} command so that it will display
  jobs scheduled for the number of days you want.
\item [devices]
  Used in the \bcommandname{show} command. Takes no arguments.
\item [dir | director]
\item [directors]
  Used in the \bcommandname{show} command. Takes no arguments.
\item [directory]
  Used in the \bcommandname{restore} command. Its argument specifies the directory
  to be restored.
\item [enabled]
  This keyword can appear on the \bcommandname{update volume} as well
  as the \bcommandname{update slots} commands, and can
  allows one of the following arguments: \bvalue{yes}, \bvalue{true}, \bvalue{no}, \bvalue{false}, \bvalue{archived},
  \bvalue{0}, \bvalue{1}, \bvalue{2}.  Where \bvalue{0} corresponds to no or false, \bvalue{1} corresponds to \bvalue{yes} or \bvalue{true}, and
  \bvalue{2} corresponds to \bvalue{archived}.  Archived volumes will not be used, nor will
  the Media record in the catalog be pruned. Volumes that are not enabled,
  will not be used for backup or restore.
\item [done]
  Used in the \bcommandname{restore} command. Takes no argument.
\item [file]
  Used in the \bcommandname{restore} command.
\item [files]
  Used in the \bcommandname{list} and \bcommandname{llist} commands. Takes no arguments.
\item [fileset]
\item [filesets]
  Used in the \bcommandname{show} command. Takes no arguments.
\item [help]
  Used in the \bcommandname{show} command. Takes no arguments.
\item [jobs]
  Used in the \bcommandname{show}, \bcommandname{list} and \bcommandname{llist} commands. Takes no arguments.
\item [jobmedia]
  Used in the \bcommandname{list} and \bcommandname{llist} commands. Takes no arguments.
\item [jobtotals]
  Used in the \bcommandname{list} and \bcommandname{llist} commands. Takes no arguments.
\item [jobid]
  The JobId is the numeric jobid that is printed in the Job
  Report output. It is the index of the database record for the
  given job. While it is unique for all the existing Job records
  in the catalog database, the same JobId can be reused once a
  Job is removed from the catalog. Probably you will refer
  specific Jobs that ran using their numeric JobId.
\item [job | jobname]
  The \bcommandname{job} or \bcommandname{jobname} keyword refers to the name you specified
  in the \bresource{Job}, and hence it refers to any number of
  Jobs that ran.  It is typically useful if you want to list
  all jobs of a particular name.
\item [level]
\item [listing]
  Permitted on the \bcommandname{estimate} command. Takes no argument.
\item [limit]
\item [messages]
  Used in the \bcommandname{show} command. Takes no arguments.
\item [media]
  Used in the \bcommandname{list} and \bcommandname{llist} commands. Takes no arguments.
\item [name]
  Used in the \bcommandname{list object} commands. Can specify an Object name.
\item [nextvol | nextvolume]
  Used in the \bcommandname{list} and \bcommandname{llist} commands. Takes no arguments.
\item [object]
  Used in the \bcommandname{list} commands. Takes no arguments.
\item [objectid]
  Used in the \bcommandname{list} and \bcommandname{restore} commands. Takes an ObjectId as argument.
\item [order]
  Used in the \bcommandname{list} to sort records. Can take ``ASC'' or ``DESC'' as argument.
\item [on]
  Takes no keyword.
\item [off]
  Takes no keyword.
\item [pool]
\item [pools]
  Used in the \bcommandname{show}, \bcommandname{list}, and \bcommandname{llist} commands. Takes no arguments.
\item [select]
  Used in the \bcommandname{restore} command. Takes no argument.
\item[limit]
  Used in the \bcommandname{setbandwidth} command. Takes integer in \texttt{KB/s} unit.
\item [storages]
  Used in the \bcommandname{show} command. Takes no arguments.
\item [schedules]
  Used in the \bcommandname{show} command. Takes no arguments.
\item [sd | store | storage]
\item [tag] Used in the \bcommandname{list} command. Takes no arguments.
\item [ujobid]
  The \bcommandname{ujobid} is a unique job identification that is printed
  in the Job Report output. At the current time, it consists
  of the Job name (from the \bdirective{Name} for the job) appended
  with the date and time the job was run. This keyword is useful
  if you want to completely identify the Job instance run.
\item [volume]
\item [volumes]
  Used in the \bcommandname{list} and \bcommandname{llist} commands. Takes no arguments.
\item [where]
  Used in the \bcommandname{restore} command.
\item [yes]
  Used in the \bcommandname{restore} command. Takes no argument.
\end{bdescription}

\label{blb:list}
\section{Alphabetic List of Console Commands}
\index[general]{Commands!Alphabetic List of Console}
\index[general]{Alphabetic List of Console Commands}
\index[general]{Commands!Alphabetic List of Console}
\index[general]{Alphabetic List of Console Commands}

The following commands are currently implemented:

\begin{bdescription}
\item [{add [pool=\bbracket{pool-name} storage=\bbracket{storage} jobid=\bbracket{JobId}]} ]
  
   \index[general]{add}
   This command is used to add Volumes to an existing Pool.  That is,
   it creates the Volume name in the catalog and inserts into the Pool
   in the catalog, but does not attempt to access the physical Volume.
   Once
   added, \bacula{} expects that Volume to exist and to be labeled.
   This command is not normally used since \bacula{} will
   automatically do the equivalent when Volumes are labeled. However,
   there may be times when you have removed a Volume from the catalog
   and want to later add it back.

   Normally, the \bcommandname{label} command is used rather than this command
   because the \bcommandname{label} command labels the physical media (tape, disk,
   DVD, \ldots{}) and does the equivalent of the \bcommandname{add} command.  The \bcommandname{add}
   command affects only the Catalog and not the physical media (data
   on Volumes).  The physical media must exist and be labeled before use
   (usually with the \bcommandname{label} command).  This command can, however, be
   useful if you wish to add a number of Volumes to the Pool that will be
   physically labeled at a later time.  It can also be useful if you are
   importing a tape from another site.  Please see the \bcommandname{label} command
   below for the list of legal characters in a Volume name.

\item [autodisplay on/off]
   \index[general]{autodisplay on/off}
   This command accepts \bvalue{on} or \bvalue{off} as an argument, and turns
   auto-display of messages on or off respectively.  The default for the
   console program is \bcommandname{off}, which means that you will be notified when
   there are console messages pending, but they will not automatically be
   displayed.

   When autodisplay is turned off, you must explicitly retrieve the
   messages with the \bcommandname{messages} command.  When \bcommandname{autodisplay} is turned
   on, the messages will be displayed on the console as they are received.

\item [automount on/off]
   \index[general]{automount on/off}
   This command accepts \bcommandname{on} or \bcommandname{off} as the argument, and turns
   auto-mounting of the Volume after a \bcommandname{label} command on or off
   respectively.  The default is \bcommandname{on}.  If \bcommandname{automount} is turned
   off, you must explicitly \bcommandname{mount} tape Volumes after a \bcommandname{label} command to
   use it.

\item [{cancel [jobid=\bbracket{number} job=\bbracket{job-name} ujobid=\bbracket{unique-jobid}] | [inactive client=<client-name> storage=<storage-name>]}]
   \index[general]{cancel jobid}
   This command is used to cancel a job and accepts \bvalue{jobid=nnn} or \bvalue{job=xxx}
   as an argument where \texttt{nnn} is replaced by the JobId and \texttt{xxx} is
   replaced by the job name.  If you do not specify a keyword, the \bConsole{}
   program will prompt you with the names of all the active jobs allowing
   you to choose one.

   Once a Job is marked to be canceled, it may take a bit of time
   (generally within a minute but up to two hours) before the Job actually
   terminates, depending on what operations it is doing.
   Don't be surprised that you receive a Job not found message. That just
   means that one of the three daemons had already canceled the job.
   Messages numbered in the 1000's are from the Director, 2000's are from
   the File daemon and 3000's from the Storage daemon.

   If the Job is still active on the Storage Daemon and/or the File Daemon, but
   not on the Director, it is possible to stop the Job with the
   \textbf{inactive} option of the \bcommandname{cancel} command.
   
 \item [{cloud [storage=\bbracket{sd-name} volume=\bbracket{vol-name} allpools allfrompool pool=\bbracket{p-name} mediatype=\bbracket{type-name} drive=\bbracket{num} slots=\bbracket{num}] [truncate | prune | list | upload]}]
    The \bcommandname{cloud} \bconsolename{} command allows you to do a number of things with cloud volumes.

    The \bcommandname{truncate} command will attempt to truncate the local cache for the specified Volume.

    The \bcommandname{prune} command will attempt to prune the local cache for the
    specified Volume. \bacula{} will respect the \bdirective{CacheRetention} volume attribute
    to determine if the cache can be truncated or not. Only parts that are
    uploaded to the cloud will be deleted from the cache.

    The \bcommandname{upload} command will attempt to upload the specified Volumes.

    The \bcommandname{list} command will list volumes stored in the Cloud. If a
    volume name is specified, the command will list all parts for the given
    volume.

\item [{create [pool=\bbracket{pool-name}]}]
   \index[general]{create pool}
   This command is not normally used as the Pool records are automatically
   created by the \bDirector{} when it starts based on what it finds in
   the conf file.  If needed, this command can be
   to create a \bPool{} record in the database using the
   \bresource{Pool} record defined in the \bDirector{}'s configuration file.  So
   in a sense, this command simply transfers the information from the \bresource{Pool}
   in the configuration file into the \bCatalog{}.  Normally this
   command is done automatically for you when the \bDirector{} starts providing
   the \bPool{} is referenced within a \bresource{Job}.  If you use this command
   on an existing \bPool{}, it will automatically update the \bCatalog{} to have
   the same information as the \bresource{Pool}.  After creating a \bPool{}, you
   will most likely use the \bcommandname{label} command to label one or more
   volumes and add their names to the Media database.

   When starting a \bJob{}, if \bacula{} determines that there is no \bPool{} record
   in the database, but there is a \bresource{Pool} of the appropriate name,
   it will create it for you.  If you want the \bPool{} record to appear in the
   database immediately, simply use this command to force it to be created.

\item [{delete [volume=\bbracket{vol-name} pool=\bbracket{pool-name} job jobid=\bbracket{id} object [objectid=id]]}]
   \index[general]{delete}
   The \bcommandname{delete} command is used to delete a \bVolume{}, \bPool{} \bJob{}, Object, Snapshot or \bClient{} record from
   the \bCatalog{} as well as all associated catalog Volume records that were
   created.  This command operates only on the \bCatalog{} database and has no
   effect on the actual data written to a \bVolume{}.  This command can be
   dangerous and we strongly recommend that you do not use it unless you
   know what you are doing.

   If the keyword \bvalue{Volume} appears on the command line, the named
   \bVolume{} will be deleted from the \bCatalog{}, if the keyword \bvalue{Pool}
   appears on the command line, a \bPool{} will be deleted, if the keyword \bvalue{Object} appears on the
   command line, an Object and all of its associated records (File) will be deleted from the catalog, and
	 if the keyword \bvalue{Job} appears on the command line, a \bJob{} and all of its associated
   records (File and JobMedia) will be deleted from the catalog.  The full
   form of this command is:

\begin{bVerbatim}
delete pool=<pool-name>
\end{bVerbatim}
   or
\begin{bVerbatim}
delete volume=<volume-name> pool=<pool-name>
\end{bVerbatim}
  or
\begin{bVerbatim}
delete JobId=<job-id> JobId=<job-id2> ...
\end{bVerbatim}
  or
\begin{bVerbatim}
delete JobId=n,m,o-r,t ...
\end{bVerbatim}
  or
\begin{bVerbatim}
delete client=xxx-fd
\end{bVerbatim}
  or
\begin{bVerbatim}
delete snapshot
\end{bVerbatim}
  or
\begin{bVerbatim}
delete object [objectid=id [all]] [category=obj\_cat] [type=obj\_type] [name=obj\_name] [uuid=obj\_uuid] [source=obj\_source]
\end{bVerbatim}


   The first form deletes a \bPool{} record from the catalog database.  The
   second form deletes a \bVolume{} record from the specified pool in the
   \bCatalog{} database.  The third form deletes the specified \bJob{} record from
   the catalog database.  The fourth form deletes \bJobId{} records for JobIds
   \bvalue{n, m, o, p, q, r} and \bvalue{t}.  Where each one of the \bvalue{n,m,\ldots{}}  is, of course, a
   number. That is a \bcommandname{delete jobid} accepts lists and ranges of
   jobids.

   The deletion of a \bClient{} record will prune all job records associated
   with the Client. This command is possible only of the \bClient{} resource
   is no longer defined in the Director configuration file.

   The deletion of a Snapshot record can be done with the sixth command.

   The deletion of an Object records can be done with the last command. Different filters can be used along with
   'delete object' command: category, type, name, uuid or source. Passing specific object id can be also used as a filter
   to delete many objects at once. Following command will delete all objects records with the same category,
   type, name, uuid and source as object with given id.

   \begin{bVerbatim}
   delete object objectid=1 all
   \end{bVerbatim}

\item [disable job\bbracket{job-name}]
  \index[general]{disable}
  This command permits you to disable a \bJob{} for automatic scheduling.
  The job may have been previously enabled with the \bresource{Job}
  \bdirective{Enabled} or using the console \bcommand{enable}.
  The next time the \bDirector{} is restarted,
  the \bvalue{Enable}/\bvalue{Disable} state will be set to the value in the \bresource{Job}
  (default \bvalue{enabled}) as defined in the \bfilename{bacula-dir.conf} file.

\item [disable job all]
  \index[general]{disable}
  This command permits you to disable all Jobs for automatic scheduling.
  The next time the \bDirector{} is restarted,
  the \bvalue{Enable}/\bvalue{Disable} state will be set to the value in the \bresource{Job}
  (default \bvalue{enabled}) as defined in the \bfilename{bacula-dir.conf} file.

\item [enable job\bbracket{job-name}]
  \index[general]{enable}
  This command permits you to enable a \bJob{} for automatic scheduling.
  The job may have been previously disabled with the \bresource{Job}
  \bdirective{Enabled} or using the console \bcommand{disable}.
  The next time the \bDirector{} is restarted,
  the \bvalue{Enable}/\bvalue{Disable} state will be set to the value in the \bresource{Job}
  (default \bvalue{enabled}) as defined in the \bfilename{bacula-dir.conf} file.

\item [enable job all]
  \index[general]{disable}
  This command permits you to enable all Jobs for automatic scheduling.
  It does not enable jobs which have \bdirective{Disabled} directive.
  The next time the \bDirector{} is restarted,
  the \bvalue{Enable}/\bvalue{Disable} state will be set to the value in the \bresource{Job}
  (default \bvalue{enabled}) as defined in the \bfilename{bacula-dir.conf} file.

\label{blb:estimate}
\item [estimate]
   \index[general]{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 \bFileSet{},
   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
   \bvalue{level=Incremental} or \bvalue{level=Differential} on the command line.
   A \bJob{} name must be specified or you will be prompted for one, and
   optionally a \bClient{} and \bFileSet{} 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.

   The \bcommandname{estimate} command can use the accurate code to detect changes
   and give a better estimation. You can set the accurate behavior on command
   line using \bvalue{accurate=yes/no} or use the \bJob{} setting as default value.

   Optionally you may specify the keyword \bkeyword{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:

\begin{bVerbatim}
estimate job=<job-name> listing client=<client-name> accurate=<yes/no>
         fileset=<fileset-name> level=<level-name>
\end{bVerbatim}

   Specification of the \bkeyword{job} is sufficient, but you can also override the
   \bkeyword{client}, \bkeyword{fileset}, \bkeyword{accurate} and/or \bkeyword{level} by specifying them on the \bcommandname{estimate}
   command line.


As an example, you might do:

\begin{bVerbatim}
@output /tmp/listing
estimate job=NightlySave listing level=Incremental
@output
\end{bVerbatim}

which will do a full listing of all files to be backed up for the  Job \textbf{NightlySave}
during an Incremental save and put it in the  file \bfilename{/tmp/listing}.
   Note, the byte estimate provided by this command is
   based on the file size contained in the directory item. This can give
   wildly incorrect estimates of the actual storage used if there are
   sparse files on your systems. Sparse files are often found on 64 bit
   systems for certain system files. The size that is returned is the size
   \bacula{} will backup if the sparse option is not specified in the \bFileSet{}.
   There is currently no way to get an estimate of the real file size that
   would be found should the sparse option be enabled.

\item [exit]
   \index[general]{exit}
   This command terminates the \bConsole{} program.

\item [gui]
   \index[general]{gui}
   Invoke the non-interactive gui mode.
\begin{bVerbatim}
gui [on|off]
\end{bVerbatim}

\item [help]
   \index[general]{help}
   This command displays the list of commands available.

\item [label]
   \index[general]{label}
   \index[general]{relabel}
   This command is used to label physical volumes.  The full form of this command
   is:

\begin{bVerbatim}
label storage=<storage-name> volume=<volume-name>
      slot=<slot>
\end{bVerbatim}

   If you leave out any part, you will be prompted for it.  The media type
   is automatically taken from the \bresource{Storage} definition that you
   supply.  Once the necessary information is obtained, the \bConsole{} program
   contacts the specified \bStorage{} daemon and requests that the \bVolume{} be
   labeled.  If the Volume labeling is successful, the Console program will
   create a \bVolume{} record in the appropriate \bPool{}.

   The Volume name is restricted to letters, numbers, and the special
   characters hyphen (-), underscore (\_), colon (\string:), and
   period (.).  All other characters including a space are invalid.
   This restriction is to ensure good readability of Volume names to reduce
   operator errors.

   Please note, when labeling a blank tape, \bacula{} will get \textbf{read I/O error}
   when it attempts to ensure that the tape is not already labeled.  If
   you wish to avoid getting these messages, please write an EOF mark on
   your tape before attempting to label it:

\begin{bVerbatim}
mt rewind
mt weof
\end{bVerbatim}

The \bcommandname{label} command can fail for a number of reasons:

\begin{benumerate}
\item The \bVolume{} name you specify is already in the  Volume database.

\item The \bStorage{} daemon has a tape or other Volume already mounted on the
   device, in which case you must \bcommandname{unmount} the device, insert a blank
   tape, then do the \bcommandname{label} command.

\item The Volume in the device is already a \bacula{} labeled Volume.  (\bacula{} will
   never relabel a \bacula{} labeled Volume unless it is recycled and you use the
   \bcommandname{relabel} command).

\item There is no Volume in the drive.
\end{benumerate}

There are two ways to relabel a volume that already has a \bacula{} label. The
brute  force method is to write an end of file mark on the tape  using the
system \btool{mt} program, something like the  following:

\begin{bVerbatim}
mt -f /dev/st0 rewind
mt -f /dev/st0 weof
\end{bVerbatim}

For a disk volume, you would manually delete the Volume.

Then you use the \bcommandname{label} command to add a new label.  However, this could
leave traces of the old volume in the  catalog.

The preferable method to relabel a Volume is to first \bcommandname{purge}  the volume,
either automatically, or explicitly with the  \bcommandname{purge} command, then use
the \bcommandname{relabel} command described  below.

If your autochanger has barcode labels, you can label all the Volumes in
your autochanger one after another by using the \bcommandname{label barcodes}
command.  For each tape in the changer containing a barcode, \bacula{} will
mount the tape and then label it with the same name as the barcode.  An
appropriate Media record will also be created in the catalog.  Any barcode
that begins with the same characters as specified on the
``\bvalueddirective{CleaningPrefix}{xxx}'' directive in the \bDirector{}'s \bresource{Pool}, will be
treated as a cleaning tape, and will not be labeled.  However, an entry for
the cleaning tape will be created in the catalog.  For example with:

\begin{bVerbatim}
Pool {
     Name ...
     Cleaning Prefix = "CLN"
}
\end{bVerbatim}

Any slot containing a barcode of \texttt{CLNxxxx} will be treated as a cleaning tape
and will not be mounted.  Note, the full form of the command is:

\begin{bVerbatim}
label storage=xxx pool=yyy slots=1-5,10 barcodes
\end{bVerbatim}

\item [list]
   \index[general]{list}
   The \bcommandname{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:
   \begin{bVerbatim}
list events

list jobs

list jobid=<id>                (list jobid id)

list jobs joberrors            (list jobs with errors)

list jobs jobstatus=f          (list jobs with jobstatus f)

list jobs limit=10 order=desc  (list the last 10 jobs)

list jobs limit=10 order=asc   (list the first 10 jobs)

list jobs client=xxx           (list jobs for client xxx)

list copies                    (list copy jobs)

list ujobid=<unique job name>  (list job with unique name)

list job=<job-name>            (list all jobs with "job-name")

list jobname=<job-name>        (same as above)

     In the above, you can add "limit=nn" to limit the output to
     nn jobs.

list joblog jobid=<id> (list job output if recorded in the catalog)

list jobmedia

list jobmedia jobid=<id>

list jobmedia job=<job-name>

list files jobid=<id>

list files job=<job-name>

     In the above, you can add type=<all|deleted> to see all file records or only
     deleted records.

list files type=<deleted|all> jobid=<id>

list pools

list clients

list jobtotals

list objects (list plugin objects)

list objects jobid=<id>

list object client=<client> (list plugin objects of specified client)

list object type=<type> (list plugin objects of specified type)

list objects category=<category> (list plugin objects of specified category)

list objects limit=10 order=desc  (list the last 10 objects)

list objects limit=10 order=asc   (list the first 10 objects)

list volumes

list volumes jobid=<id>

list volumes pool=<pool-name>

list volumes job=<job-name>

list volume=<volume-name>

list nextvolume job=<job-name>

list nextvol job=<job-name>

list nextvol job=<job-name> days=nnn
\end{bVerbatim}

   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 \bcommandname{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. By default, the job specified must run within the
   next two days or no volume will be found. You can, however, use the
   \bkeyword{days=nnn} specification to specify up to 50 days. For example,
   if on Friday, you want to see what Volume will be needed on Monday,
   for job MyJob, you would use \bcommandname{list nextvol job=MyJob days=3}.

   If you wish to add specialized commands that list the contents of the
   catalog, you can do so by adding them to the \bfilename{query.sql} file.
   However, this takes some knowledge of programming \btool{SQL}. Please see the
   \bcommandname{query} command below for additional information.  See below for
   listing the full contents of a catalog record with the \bcommandname{llist}
   command.

   As an example, the command \bcommandname{list pools} might produce  the following
   output:

\begin{bVerbatim}
+------+---------+---------+---------+----------+-------------+
| PoId | Name    | NumVols | MaxVols | PoolType | LabelFormat |
+------+---------+---------+---------+----------+-------------+
|    1 | Default |       0 |       0 | Backup   | *           |
|    2 | Recycle |       0 |       8 | Backup   | File        |
+------+---------+---------+---------+----------+-------------+
\end{bVerbatim}

   As mentioned above, the \bcommandname{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 \bcommandname{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 \btool{uname -a} output).

   If you want to see what \bresources{Client} you have available in your conf
   file, you use the Console command \bcommandname{show clients}.

\item [llist]
   \index[general]{llist}
   The \bcommandname{llist} or ``long list'' command takes all the same arguments that the
   \bcommandname{list} command described above does.  The difference is that the \bcommandname{llist}
   command \bcommandname{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 \bcommandname{list pools} as in the example above, you enter
   \bcommandname{llist pools} you might get the following output:

\begin{bVerbatim}
          PoolId: 1
            Name: Default
         NumVols: 0
         MaxVols: 0
         UseOnce: 0
      UseCatalog: 1
 AcceptAnyVolume: 1
    VolRetention: 1,296,000
  VolUseDuration: 86,400
      MaxVolJobs: 0
     MaxVolBytes: 0
       AutoPrune: 0
         Recycle: 1
        PoolType: Backup
     LabelFormat: *

          PoolId: 2
            Name: Recycle
         NumVols: 0
         MaxVols: 8
         UseOnce: 0
      UseCatalog: 1
 AcceptAnyVolume: 1
    VolRetention: 3,600
  VolUseDuration: 3,600
      MaxVolJobs: 1
     MaxVolBytes: 0
       AutoPrune: 0
         Recycle: 1
        PoolType: Backup
     LabelFormat: File
\end{bVerbatim}

\item [messages]
   \index[general]{messages}
   This command causes any pending  console messages to be immediately displayed.

\item [memory]
   \index[general]{memory}
   Print current memory usage.


\item [mount]
   \index[general]{mount}
   The \bcommandname{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 normally
   used only after there was no Volume in a drive and \bacula{} requests you to mount a new
   Volume or when you have specifically unmounted a Volume with the \bcommandname{unmount}
   console command, which causes \bacula{} to close the drive.  If
   you have an autoloader, the \bcommandname{mount} command will not cause \bacula{} to
   operate the autoloader unless you specify a \bkeyword{slot} and possibly a
   \bkeyword{drive}. The various forms of the mount command are:
\begin{bVerbatim}
mount storage=<storage-name> [ slot=<num> ] [ drive=<num> ]
\end{bVerbatim}


\begin{bVerbatim}
mount [ jobid=<id> | job=<job-name> ]
\end{bVerbatim}
   If you have specified \bdirectivename{Automatic Mount = yes} in the Storage daemon's
   \bresource{Device},  under most circumstances, \bacula{} will automatically access
   the Volume unless you have explicitly \bcommandname{unmount}ed it in  the Console
   program.

\label{blb:ManualPruning}
\item [prune]
   \index[general]{prune}
   The \bcommandname{prune} command allows you to safely remove expired database records from
   Jobs, Volumes and Statistics.  This command works only on the Catalog
   database and does not affect data written to Volumes.  In all cases, the
   \bcommandname{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.
\begin{bVerbatim}
prune files|jobs|volume|stats client=<client-name>
      volume=<volume-name>
\end{bVerbatim}
   For a Volume to be pruned, the \textbf{VolStatus} must be \bstatus{Full}, \bstatus{Used}, or
   \bstatus{Append}, otherwise the pruning will not take place.
   \smallskip
   
   With the \bkeyword{all} keyword, all combination of \bresourcename{Client}/\bresourcename{Pool} present
   in the \bJob{} table will be pruned. \bcommandname{prune jobs all yes}


\item [purge]
   \index[general]{purge}
   The \bcommandname{purge} command will delete associated Catalog database records from
   Jobs and Volumes without considering the retention period.  \bcommandname{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 \bcommandname{purge} are:
\begin{bVerbatim}
purge files jobid=<jobid>|job=<job-name>|client=<client-name>
\end{bVerbatim}
\begin{bVerbatim}
purge jobs client=<client-name> (of all jobs)
\end{bVerbatim}
\begin{bVerbatim}
purge volume|volume=<vol-name> (of all jobs)
\end{bVerbatim}
For the \bcommandname{purge} command to work on Volume Catalog database  records the
{\bf VolStatus}  must be \bvalue{Append}, \bvalue{Full}, \bvalue{Used}, or \bvalue{Error.}

The actual data written to the Volume will be unaffected by this command unless
you are using the \bdirectivename{ActionOnPurge=Truncate} option on those Media.

To ask \bacula{} to truncate your \texttt{Purged} volumes, you need to use the
following command in interactive mode or in a \bresourcename{RunScript}:
\begin{bVerbatim}
* purge volume action=truncate storage=File allpools
  
# or by default, action=all
* purge volume action storage=File pool=Default
\end{bVerbatim}

This is possible to specify the volume name, the media type, the pool, the
storage, etc\dots (see \bcommandname{help purge}) Be sure that your storage device is
idle when you decide to run this command.

\item [query]
   \index[general]{query}
   This command reads a predefined SQL query from  the query file (the name and
   location of the  query file is defined with the \bresource{QueryFile} record in
   the Director's configuration file). You are prompted to select  a query from
   the file, and possibly enter one or more parameters,  then the command is
   submitted to the Catalog database SQL engine.

The following queries are currently available (version 2.2.7):

\begin{bVerbatim}
Available queries:
1: List up to 20 places where a File is saved regardless of the directory
2: List where the most recent copies of a file are saved
3: List last 20 Full Backups for a Client
4: List all backups for a Client after a specified time
5: List all backups for a Client
6: List Volume Attributes for a selected Volume
7: List Volumes used by selected JobId
8: List Volumes to Restore All Files
9: List Pool Attributes for a selected Pool
10: List total files/bytes by Job
11: List total files/bytes by Volume
12: List Files for a selected JobId
13: List Jobs stored on a selected MediaId
14: List Jobs stored for a given Volume name
15: List Volumes Bacula thinks are in changer
16: List Volumes likely to need replacement from age or errors
Choose a query (1-16):
\end{bVerbatim}

\item [quit]
   \index[general]{quit}
   This command terminates the console program. The  console program sends the
   {\bf quit} request to the Director  and waits for acknowledgment. If the
   Director is busy doing  a previous command for you that has not terminated, it
   may  take some time. You may quit immediately by issuing the  \bcommandname{.quit}
   command (i.e. quit preceded by a period).

\item [relabel]
   \index[general]{relabel}
   This command is used to label physical volumes.  The full form of this
   command is:
\begin{bVerbatim}
relabel storage=<storage-name> oldvolume=<old-volume-name>
        volume=<newvolume-name>
\end{bVerbatim}
   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 \bvalue{Purged} or \bvalue{Recycle}.
   This happens automatically as a result of applying retention periods, or
   you may explicitly purge the volume using the \bcommandname{purge} command.

   Once the volume is physically relabeled, the old data previously written
   on the Volume is lost and cannot be recovered.

\item [release]
   \index[general]{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.
\begin{bVerbatim}
release storage=<storage-name>
\end{bVerbatim}
   After a \bcommandname{release} command, the device is still kept open by \bacula{} (unless
   \bdirectivename{Always Open} is set to \bvalue{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.  \btool{mt}), you must use the \bcommandname{unmount}
   command to cause \bacula{} to completely release (close) the device.

\item [reload]
  \index[general]{reload}
  The \bcommandname{reload} command causes the Director to re-read its configuration
  file and apply the new values. The new values will take effect
  immediately for all new jobs.  However, if you change schedules,
  be aware that the scheduler pre-schedules jobs up to two hours in
  advance, so any changes that are to take place during the next two
  hours may be delayed.  Jobs that have already been scheduled to run
  (i.e. surpassed their requested start time) will continue with the
  old values.  New jobs will use the new values. Each time you issue
  a \bcommandname{reload} command while jobs are running, the old config values
  will keptf until all jobs that were running before issuing
  the reload terminate, at which time the old config values will
  be released from memory.  As a default a maximum number of
  32 reload requests that can be made, which is generally sufficient.
  In the case that you make a very large number of reload requests,
  you may use the {\bf Maximum Reload Requests} directive in the
  Director resource of {\bf bacula-dir.conf} to set a larger maximum
  to that value you wish.


\label{blb:restart_command}
 \item [restart]
   \index[general]{restart}
   \index[general]{resume}
The \bcommandname{restart} command allows console users to restart
a canceled, failed, or incomplete Job.  For canceled and failed
Jobs, the Job will restart from the beginning.  For incomplete
Jobs the Job will restart at the point that it was stopped either
by a stop command or by some recoverable failure.
\smallskip

\label{blb:resume_command}
\item [resume]
  \index[general]{resume}
  The  \bcommandname{resume} command does exactly the same thing as a
\bcommandname{restart} command, but for some users the
name may be more logical because in general the
\bcommandname{restart} command is used to resume running
a Job that was incomplete.

\label{blb:restore_command}
\item [restore]
   \index[general]{restore}
   The \bcommandname{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 \btool{restore}
   program's interactive file selection mode.
   \begin{bVerbatim}
restore storage=<storage-name> client=<backup-client-name> where=<path>
        pool=<pool-name> fileset=<fileset-name>
        restoreclient=<restore-client-name> objectid=<id>
        restorejob=<job-name> jobuser=<user-name> jobgroup=<group-name>
        select current all done
\end{bVerbatim}
   Where \bkeyword{current}, if specified, tells the \bcommandname{restore} command to
   automatically select a restore to the most current backup.  If not
   specified, you will be prompted.  The \bkeyword{all} specification tells the
   \bcommandname{restore} command to restore all files.  If it is not specified, you will
   be prompted for the files to restore.  For details of the \bcommandname{restore}
   command, please see the \bxlink{Restore}{blb:RestoreChapter}{main}{chapter}
   of the \bmainman{}.

   The client keyword initially specifies the client from which the backup
   was made and the client to which the restore will be make.  However,
   if the \bkeyword{restoreclient} keyword is specified, then the restore is written
   to that client.

   The restore job rarely needs to be specified, as bacula installations
   commonly only have a single restore job configured. However, for certain
   cases, such as a varying list of \bresourcename{RunScript} specifications, multiple
   restore jobs may be configured. The \bkeyword{restorejob} argument allows the
   selection of one of these jobs.

\item [run]
   \index[general]{run}
   This command allows you to schedule jobs  to be run immediately. The full form of the command is:
\begin{bVerbatim}
run job=<job-name> client=<client-name>
    fileset=<FileSet-name>  level=<level-keyword>
    storage=<storage-name>  where=<directory-prefix>
    when=<universal-time-specification> spooldata=yes|no yes
\end{bVerbatim}
   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 \bvalue{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:

\begin{bVerbatim}
A job name must be specified.
The defined Job resources are:
     1: Matou
     2: Polymatou
     3: Rufus
     4: Minimatou
     5: Minou
     6: PmatouVerify
     7: MatouVerify
     8: RufusVerify
     9: Watchdog
Select Job resource (1-9):
\end{bVerbatim}

If I then select number 5, I am prompted with:

\begin{bVerbatim}
Run Backup job
JobName:  Minou
FileSet:  Minou Full Set
Level:    Incremental
Client:   Minou
Storage:  DLTDrive
Pool:     Default
When:     2003-04-23 17:08:18
OK to run? (yes/mod/no):

\end{bVerbatim}

If I now enter \bvalue{yes}, the Job will be run. If I enter \bvalue{mod},  I will
be presented with the following prompt:

\begin{bVerbatim}
Parameters to modify:
     1: Level
     2: Storage
     3: Job
     4: FileSet
     5: Client
     6: When
     7: Pool
Select parameter to modify (1-7):
\end{bVerbatim}

If you wish to start a job at a later time, you can do so by setting  the When
time. Use the \bvalue{mod} option and select \bvalue{When} (no. 6).  Then enter the
desired start time in \texttt{YYYY-MM-DD HH:MM:SS} format.

The \bkeyword{spooldata} argument of the run command cannot be modified through the menu
and is only accessible by setting its value on the intial command line. If
no spooldata flag is set, the job, storage or schedule flag is used.

\item[setbandwidth]
  \index[general]{setbandwidth}
  This command is used to limit the bandwidth of a running job or a client.
\begin{bVerbatim}
setbandwidth limit=<nb> [ jobid=<id> | client=<cli> ]
\end{bVerbatim}
\item [setdebug]
   \index[general]{setdebug}
   \index[general]{Debugging}
   \index[general]{Debugging Win32}
   \index[general]{Windows!debugging}
   This command is used to set the debug level in each  daemon. The form of this
   command is:
\begin{bVerbatim}
setdebug level=nn [trace=0/1 client=<client-name> | dir | director |
         storage=<storage-name> | all | options=0cidtTlp | tags=<tags>]
\end{bVerbatim}
   If \bkeyword{trace=1} is set, then tracing will be enabled, and the daemon will be
   placed in trace mode, which means that all debug output as set by the
   debug level will be directed to the file \bfilename{bacula.trace} in the
   current directory of the daemon.  Normally, tracing is needed 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.
   \smallskip

   If \bkeyword{options} parameter is set, the following arguments can be used
   to control debug functions.
   \begin{bdescription}
   \item [0] clear debug flags
   \item [i] Turn off, ignore bwrite() errors on restore on File Daemon
   \item [d] Turn off decomp of BackupRead() streams on File Daemon
   \item [t] Turn on timestamp in traces
   \item [T] Turn off timestamp in traces
   \item [c] Truncate trace file if trace file is activated
   \item [l] Turn on recoding events on P() and V()
   \item [p] Turn on the display of the event ring when doing a lockdump
   \end{bdescription}
   \smallskip

   It is now possible to use \emph{class} of debug messages called \texttt{tags}
   to control the debug output of \bacula{} daemons.

   \begin{bdescription}
   \item [all] Display all debug messages
   \item [bvfs] Display BVFS debug messages
   \item [sql] Display SQL related debug messages
   \item [memory] Display memory and poolmem allocation messages
   \item [scheduler] Display scheduler related debug messages
   \end{bdescription}

   \begin{bVerbatim}
* setdebug level=10 tags=bvfs,sql,memory
* setdebug level=10 tags=!bvfs
   \end{bVerbatim}

   The \texttt{tags} option is composed of a list of tags, tags are separated by
   ``,'' or ``+'' or ``-'' or ``!''. To disable a specific tag, use ``-'' or ``!''
   in front of the tag.

\item [setip]
   \index[general]{setip}
   Sets new client address --- if authorized.

   A console is authorized to use the \bcommandname{SetIP} command only if it has a
   \bresource{Console} definition in both the Director and the Console.  In
   addition, if the console name, provided on the \bdirective{Name},
   must be the same as a Client name, the user of that console is permitted
   to use the \bcommandname{SetIP} command to change the \bdirective{Address} in the
   Director's \bresource{Client} to the IP address of the Console.  This
   permits portables or other machines using DHCP (non-fixed IP addresses)
   to ``notify'' the Director of their current IP address.



\item [show]
   \index[general]{show}
   The \bcommandname{show} command will list the \bresourceq{Director} records as defined in
   the Director's configuration file (normally \bfilename{bacula-dir.conf}).
   This command is used mainly for debugging purposes by developers.
   The following keywords are accepted on the
   \bcommandname{show} command line:\bkeyword{catalogs}, \bkeyword{clients}, \bkeyword{counters}, \bkeyword{devices}, \bkeyword{directors}
   \bkeyword{filesets}, \bkeyword{jobs}, \bkeyword{messages}, \bkeyword{pools}, \bkeyword{schedules}, \bkeyword{storages}, \bkeyword{all}, \bkeyword{help}.
   Please don't confuse this command
   with the \bcommandname{list}, which displays the contents of the catalog.

\item [sqlquery]
   \index[general]{sqlquery}
   The \bcommandname{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 \bcommandname{query} command above for
   simpler and safer way of entering SQL queries.

   Depending on what database engine you are using (\mysql{} or \postgresql{}), you will have somewhat different SQL commands available.  For
   more detailed information, please refer to the \mysql{}, \postgresql{} documentation.

\item [status]
   \index[general]{status}

   This command will display the status of all components. For the director, it
   will display the next jobs that are scheduled during the next 24 hours as
   well as the status of currently running jobs. For the Storage Daemon, you
   will have drive status or autochanger content. The File Daemon will give you
   information about current jobs like average speed or file accounting. The
   full form of this command is:
\begin{bVerbatim}
status [all | dir=<dir-name> | director [days=nnn] |
       client=<client-name> | [slots] storage=<storage-name>] | network [bytes=<nb>]
\end{bVerbatim}
   If you do a \bcommandname{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 ten 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, but it
   does not do pruning nor recycling of Volumes; 2.  The Volume listed is
   at best a 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:


\begin{bVerbatim}
2507 Catalog MatouVerify.2004-03-13_05.05.02 is waiting execution
5349 Full    CatalogBackup.2004-03-13_01.10.00 is waiting for higher
             priority jobs to finish
5348 Differe Minou.2004-03-13_01.05.09 is waiting on max Storage jobs
5343 Full    Rufus.2004-03-13_01.05.04 is running
\end{bVerbatim}

   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 \bresource{Storage}, 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 2507 (MatouVerify) is waiting because only one job can run at a
   time, hence it is simply ``waiting execution''

   If you do a \bcommandname{status dir}, it will by default list the first
   occurrence of all jobs that are scheduled today and tomorrow.  If you
   wish to see the jobs that are scheduled in the next three days (e.g.  on
   Friday you want to see the first occurrence of what tapes are scheduled
   to be used on Friday, the weekend, and Monday), you can add the \bkeyword{days=3}
   option.  Note, a \bkeyword{days=0} shows the first occurrence of jobs
   scheduled today only.  If you have multiple run statements, the first
   occurrence of each run statement for the job will be displayed for the
   period specified.

   If your job seems to be blocked, you can get a general idea of the
   problem by doing a \bcommandname{status dir}, but you can most often get a
   much more specific indication of the problem by doing a
   \bcommandname{status storage=xxx}.  For example, on an idle test system, when
   we do \bcommandname{status storage=File}, we get:

\begin{bVerbatim}
status storage=File
Connecting to Storage daemon File at 192.168.68.112:8103

rufus-sd Version: 1.39.6 (24 March 2006) i686-pc-linux-gnu redhat (Stentz)
Daemon started 26-Mar-06 11:06, 0 Jobs run since started.

Running Jobs:
No Jobs running.
====

Jobs waiting to reserve a drive:
====

Terminated Jobs:
 JobId  Level   Files          Bytes Status   Finished        Name
======================================================================
    59  Full        234      4,417,599 OK       15-Jan-06 11:54 kernsave
====

Device status:
Autochanger "DDS-4-changer" with devices:
   "DDS-4" (/dev/nst0)
Device "DDS-4" (/dev/nst0) is mounted with Volume="TestVolume002"
Pool="*unknown*"
    Slot 2 is loaded in drive 0.
    Total Bytes Read=0 Blocks Read=0 Bytes/block=0
    Positioned at File=0 Block=0

Device "DVD-Writer" (/dev/hdc) is not open.
Device "File" (/tmp) is not open.
====

In Use Volume status:
====
\end{bVerbatim}

Now, what this tells us is that no jobs are running and that none of
the devices are in use.  Now, if we \bcommandname{unmount} the autochanger, which
will not be used in this example, and then start a Job that uses the
File device, the job will block.  When we re-issue the status storage
command, we get for the Device status:

\begin{bVerbatim}
status storage=File
...
Device status:
Autochanger "DDS-4-changer" with devices:
   "DDS-4" (/dev/nst0)
Device "DDS-4" (/dev/nst0) is not open.
    Device is BLOCKED. User unmounted.
    Drive 0 is not loaded.

Device "DVD-Writer" (/dev/hdc) is not open.
Device "File" (/tmp) is not open.
    Device is BLOCKED waiting for media.
====
...
\end{bVerbatim}
\normalsize

Now, here it should be clear that if a job were running that wanted
to use the Autochanger (with two devices), it would block because
the user unmounted the device. The real problem for the Job I started
using the ``File'' device is that the device is blocked waiting for
media --- that is \bacula{} needs you to label a Volume.
\smallskip

If you enter \bcommandname{status storage}, \bacula{} will prompt you with a
list of the storage resources. When you select one, the Storage daemon
will be requested to do a \bcommandname{status}.  However, note that the Storage
daemon will do a status of all the devices it has, and not just of the
one you requested.  In the current version of \bacula{}, when you enter
the \bcommandname{status storage} command, it prompts you only with a subset of
all the storage resources that the Director considers to be in different
Storage daemons. In other words, it attempts to remove duplicate
storage definitions. This can be a bit confusing at first, but can
vastly simplify the promt listing if you have defined a large number
of storage resources.

If you prefer to see the full list of all storage resources, simply
add the keyword \bkeyword{select} to the command such as: 
\bcommandname{status select storage} and you will get a prompt that includes
all storage resources even if they reference the same storage daemon.
\smallskip

If you enter \bcommandname{status network}, \bacula{} will prompt you with a
list of the storage resources and a list of the client resources. Then,
\bacula{} will test the network throughput between the two selected daemons.

\begin{bVerbatim}
*status network
The defined Client resources are:
     1: zog82-fd
     2: zog8-fd
Select Client (File daemon) resource (1-2): 2
Automatically selected Storage: File1
Connecting to Storage File1 at zog8:8103
Connecting to Client zog8-fd at zog8:8102
Running network test between Client=zog8-fd and Storage=File1 with 52.42 MB ...
2000 OK bytes=52428800 duration=48ms write_speed=1.088 GB/s
2000 OK bytes=52428800 duration=56ms read_speed=933.8 MB/s
\end{bVerbatim}


\item [tag]
   \index[general]{tag}
   The \bcommandname{tag} command will add, delete or list the tags associated with catalog records such as
   Clients, Jobs, Volumes or Objects. The command accepts all parameters in command line.
\begin{bVerbatim}
*tag add name="#test1" client=zog8-fd
1000 Tag added 

*tag
Available Tag operations:
     1: Add
     2: Delete
     3: List
Select Tag operation (1-3): 1
Available Tag target:
     1: Client
     2: Job
     3: Volume
Select Tag target (1-3): 1
Automatically selected Client: zog8-fd
Enter the Tag value: test1
1000 Tag added
*tag 
Available Tag operations:
     1: Add
     2: Delete
     3: List
Select Tag operation (1-3): 3
Available Tag target:
     1: Client
     2: Job
     3: Volume
Select Tag target (1-3): 1
Automatically selected Client: zog8-fd
+--------+----------+---------+
| tag    | clientid | client  |
+--------+----------+---------+
| test1  |        1 | zog8-fd |
| #test1 |        1 | zog8-fd |
+--------+----------+---------+
\end{bVerbatim}

\item [time]
   \index[general]{time}
   Prints the current time.

\item [trace]
   \index[general]{trace}
   Turn on/off trace to file.

\item [umount]
   \index[general]{umount|see{unmount}}
   For old-time Unix guys.  See the \bcommandname{unmount} command for full details.

\item [unmount]
   \index[general]{unmount}
   This command causes the indicated \bacula{} Storage  daemon to unmount the
   specified device. The forms of the command  are the same as the \bcommandname{mount} command:

\begin{bVerbatim}
unmount storage=<storage-name> [ drive=<num> ]
\end{bVerbatim}
\begin{bVerbatim}
unmount [ jobid=<id> | job=<job-name> ]
\end{bVerbatim}


   Once you unmount a storage device, \bacula{} will no longer be able to use
   it until you issue a mount command for that device. If \bacula{} needs to
   access that device, it will block and issue mount requests periodically
   to the operator.

   If the device you are unmounting is an autochanger, it will unload
   the drive you have specified on the command line. If no drive is
   specified, it will assume drive 1.

\label{blb:UpdateCommand}
\item [update]
   \index[general]{update}
   This command will update the catalog for either a specific Pool record, a Volume
   record, or the Slots in an  autochanger with barcode capability. In the case
   of updating a  Pool record, the new information will be automatically taken
   from  the corresponding Director's configuration resource record. It  can be
   used to increase the maximum number of volumes permitted or  to set a maximum
   number of volumes. The following main  keywords may be specified: \bkeyword{media},
   \bkeyword{volume}, \bkeyword{pool}, \bkeyword{slots}, \bkeyword{stats}.

In the case of updating a  Volume, you will be prompted for which value you
wish to change.  The following Volume parameters may be changed:

\begin{bVerbatim}
Volume Status
Volume Retention Period
Volume Use Duration
Maximum Volume Jobs
Maximum Volume Files
Maximum Volume Bytes
Recycle Flag
Recycle Pool
Slot
InChanger Flag
Pool
Volume Files
Volume from Pool
All Volumes from Pool
All Volumes from all Pools
\end{bVerbatim}


   For slots \bcommandname{update slots}, \bacula{} will obtain a list of slots and
   their barcodes from the Storage daemon, and for each barcode found, it
   will automatically update the slot in the catalog Media record to
   correspond to the new value.  This is very useful if you have moved
   cassettes in the magazine, or if you have removed the magazine and
   inserted a different one.  As the slot of each Volume is updated, the
   InChanger flag for that Volume will also be set, and any other Volumes
   in the Pool that were last mounted on the same Storage device
   will have their InChanger flag turned off.  This permits
   \bacula{} to know what magazine (tape holder) is currently in the
   autochanger.

   If you do not have barcodes, you can accomplish the same thing in
   version 1.33 and later by using the \bcommandname{update slots scan} command.
   The \bkeyword{scan} keyword tells \bacula{} to physically mount each tape and to
   read its VolumeName.

   For Pool \bcommandname{update pool}, \bacula{} will move the Volume record from its
   existing pool to the pool specified.

   For \bkeyword{Volume from Pool}, \bkeyword{All Volumes from Pool} and
   \bkeyword{All Volumes from all Pools}, the following values are updated from the Pool record:
   Recycle, RecyclePool, VolRetention, VolUseDuration, MaxVolJobs, MaxVolFiles,
   and MaxVolBytes.  (RecyclePool feature is available with \bacula{} 2.1.4 or
   higher.)

   The full form of the \bcommandname{update} command with all command line arguments is:

\begin{bVerbatim}
update volume=xxx pool=yyy slots volstatus=xxx VolRetention=ddd
       VolUse=ddd MaxVolJobs=nnn MaxVolBytes=nnn Recycle=yes|no
       slot=nnn enabled=n recyclepool=zzz actiononpurge=xxx
\end{bVerbatim}

\begin{bVerbatim}
update volume=xxx frompool
\end{bVerbatim}

\begin{bVerbatim}
update volume allfrompool=xxx
\end{bVerbatim}

\begin{bVerbatim}
update volume fromallpools
\end{bVerbatim}

\item [use]
   \index[general]{use}
   This command allows you to specify which Catalog  database to use. Normally,
you will be using only one database so  this will be done automatically. In
the case that you are using  more than one database, you can use this command
to switch from  one to another.

\begin{bVerbatim}
use [catalog=name-of-catalog]
\end{bVerbatim}

\item [var]
   \label{blb:var}
   \index[general]{var name}
   This command takes a string or quoted string and  does variable expansion on
   it the same way variable expansion  is done on the \bdirectivename{LabelFormat} string.
   Thus, for the  most part, you can test your LabelFormat strings. The
   difference  between the \bcommandname{var} command and the actual LabelFormat process
   is that during the var command, no job is running so ``dummy''  values are
   used in place of Job specific variables. Generally,  however, you will get a
   good idea of what is going to happen  in the real case.

\item [version]
   \index[general]{version}
   The command prints the Director's version.

\item [wait]
   \index[general]{wait}
   The \bcommandname{wait} command causes the Director to pause  until there are no jobs
   running. This command is useful in  a batch situation such as regression
   testing where you  wish to start a job and wait until that job completes
   before continuing. This command now has the following options:

\begin{bVerbatim}
wait [jobid=nn] [jobuid=unique id] [job=job name]
\end{bVerbatim}

   If specified with a specific JobId, the \bcommandname{wait} command will wait
   for that particular job to terminate before continuing.

\end{bdescription}

\label{blb:dotcommands}
\section{Special dot Commands}
\index[general]{Commands!Special dot (.)}
\index[general]{Special dot (.) Commands}
\index[general]{. commands}

There is a list of commands that are prefixed with a period (.). These
commands are intended to be used either by batch programs or graphical user
interface front-ends. They are not normally used by interactive users. Once
GUI development begins, this list will be considerably expanded. The following
is the list of dot commands:

\begin{bVerbatim}
.api
.backups job=xxx      list backups for specified job
.clients              list all client names
.catalogs
.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.
.dump
.exit                 quit
.events               list record custom events
.filesets             list all fileset names
.help                 help command output
.jobs                 list all job names
.estimate
.jlist                list catalog objects in JSON format (see list command)
.levels               list all levels
.messages             get quick messages
.msgs                 return any queued messages
.pools                list all pool names
.quit                 quit
.putfile
.schedule
.sql
.status               get status output
.storage              return storage resource names
.volstatus
.media
.mediatypes
.locations
.actiononpurge
.bvfs_lsdirs
.bvfs_lsfiles   [allfiles] [jobid=xxx] [pathid=xxx] [path=str]
.bvfs_get_volumes
.bvfs_update
.bvfs_get_jobids
.bvfs_get_jobs
.bvfs_get_bootstrap
.bvfs_get_fileindex
.bvfs_versions
.bvfs_get_delta
.bvfs_restore
.bvfs_cleanup
.bvfs_decode_lstat
.bvfs_clear_cache
.bvfs_update_fv
.bvfs_delete_fileid
.setuid
.ls
.types                list job types
.query
.tags                 list tags
\end{bVerbatim}

\label{blb:atcommands}
\section{Special At (@) Commands}
\index[general]{Commands!Special At (\symbol{64})}
\index[general]{Special At (\symbol{64}) Commands}
\index[general]{\symbol{64} commands}

Normally, all commands entered to the Console program are immediately
forwarded to the Director, which may be on another machine, to be executed.
However, there is a small list of \bcommandname{at} commands, all beginning with an at
character (\bcommandname{@}), that will not be sent to the Director, but rather interpreted
by the Console program directly. Note, these commands are implemented only in
the tty console program and not in the \bat{} Console. These commands are:

\begin{bdescription}
\item [@input \bbracket{filename}]
   \index[general]{\symbol{64}input \bbracket{filename}}
   Read and execute the commands  contained in the file specified.

\item [@output \bbracket{filename} w/a]
   \index[general]{\symbol{64}output \bbracket{filename} w/a}
   Send all following output to the  filename specified either overwriting the
file (w) or appending to  the file (a). To redirect the output to the
terminal, simply enter  \bcommandname{@output} without a filename specification.
WARNING: be careful  not to overwrite a valid file. A typical example during a
regression  test might be:

\begin{bVerbatim}
@output /dev/null
commands ...
@output
\end{bVerbatim}

\item [@tee \bbracket{filename} w/a]
  \index[general]{\symbol{64}tee \bbracket{filename} w/a}
  Send all subsequent output to  both the specified file and the terminal. It is
  turned off by  specifying \bcommandname{@tall}, \bcommandname{@tee} or \bcommandname{@output} without a filename.
  
\item [@tall \bbracket{filename} w/a]
  \index[general]{\symbol{64}tall \bbracket{filename} w/a}
  Send all subsequent input and output to  both the specified file and the terminal. It is
  turned off by specifying \bcommandname{@tall}, \bcommandname{@tee} or \bcommandname{@output} without a filename.

   
\item [@sleep \bbracket{seconds}]
   \index[general]{\symbol{64}sleep \bbracket{seconds}}
   Sleep the specified number of seconds.

\item [@time]
   \index[general]{\symbol{64}time}
   Print the current time and date.

\item [@version]
   \index[general]{\symbol{64}version}
   Print the console's version.

\item [@quit]
   \index[general]{\symbol{64}quit}
   quit

\item [@exit]
   \index[general]{\symbol{64}exit}
   quit

\item [@\# anything]
   \index[general]{anything}
   Comment

\item [@help]
   \index[general]{\symbol{64}help}
   Get the list of every special \bcommandname{@} commands.

\item [@separator \bbracket{char}]
\index[general]{\symbol{64}separator}
  When using \bconsolename{} with readline, you can set the command separator to one
  of those characters to write commands who require multiple input on one line,
  or to put multiple commands on a single line.
\begin{bVerbatim}
!$%&'()*+,-/:;<>?[]^`{|}~
\end{bVerbatim}

  Note, if you use a semicolon (;) as a separator character, which is
  common, you will not be able to use the \bcommandname{sql} command, which
  requires each command to be terminated by a semicolon.
\end{bdescription}

\label{blb:scripting}
\section{Running the Console from a Shell Script}
\index[general]{Script!Running the Console Program from a Shell}
\index[general]{Running the Console Program from a Shell Script}

You can automate many Console tasks by running the console program from a
shell script. For example, if you have created a file containing the following
commands:

\begin{bVerbatim}
./bconsole -c ./bconsole.conf <<END_OF_DATA
unmount storage=DDS-4
quit
END_OF_DATA
\end{bVerbatim}

when that file is executed, it will unmount the current DDS-4 storage device.
You might want to run this command during a Job by using the \bresourcename{RunBeforeJob}
or \bresourcename{RunAfterJob} records.

It is also possible to run the Console program from file input where the file
contains the commands as follows:

\begin{bVerbatim}
./bconsole -c ./bconsole.conf <filename
\end{bVerbatim}

where the file named \bfilename{filename} contains any set of console commands.

As a real example, the following script is part of the \bacula{} regression
tests. It labels a volume (a disk volume), runs a backup, then does a restore
of the files saved.

\begin{bVerbatim}
bin/bconsole -c bin/bconsole.conf <<END_OF_DATA
@output /dev/null
messages
@output /tmp/log1.out
label volume=TestVolume001
run job=Client1 yes
wait
messages
@#
@# now do a restore
@#
@output /tmp/log2.out
restore current all
yes
wait
messages
@output
quit
END_OF_DATA
\end{bVerbatim}

The output from the backup is directed to \bfilename{/tmp/log1.out} and the output from
the restore is directed to \bfilename{/tmp/log2.out}. To ensure that the backup and
restore ran correctly, the output files are checked with:

\begin{bVerbatim}
grep "^ *Termination: *Backup OK" /tmp/log1.out
backupstat=$?
grep "^ *Termination: *Restore OK" /tmp/log2.out
restorestat=$?
\end{bVerbatim}

\section{Adding Volumes to a Pool}
\index[general]{Adding Volumes to a Pool}
\index[general]{Pool!Adding Volumes to a}

If you have used the \bcommandname{label} command to label a Volume, it will be
automatically added to the Pool, and you will not need to add any media to the
pool.

Alternatively, you may choose to add a number of Volumes to the pool without
labeling them. At a later time when the Volume is requested by \bacula{} you
will need to label it.

Before adding a volume, you must know the following information:

\begin{benumerate}
\item The name of the Pool (normally ``Default'')
\item The Media Type as specified in the \bresource{Storage}  in the Director's
   configuration file (e.g. ``DLT8000'')
\item The number and names of the Volumes you wish to create.
\end{benumerate}

For example, to add media to a Pool, you would issue the following commands to
the console program:

\begin{bVerbatim}
*add
Enter name of Pool to add Volumes to: Default
Enter the Media Type: DLT8000
Enter number of Media volumes to create. Max=1000: 10
Enter base volume name: Save
Enter the starting number: 1
10 Volumes created in pool Default
*
\end{bVerbatim}

To see what you have added, enter:

\begin{bVerbatim}
*list media pool=Default
+-------+----------+---------+---------+-------+------------------+
| MedId | VolumeNa | MediaTyp| VolStat | Bytes | LastWritten      |
+-------+----------+---------+---------+-------+------------------+
|    11 | Save0001 | DLT8000 | Append  |     0 | 0000-00-00 00:00 |
|    12 | Save0002 | DLT8000 | Append  |     0 | 0000-00-00 00:00 |
|    13 | Save0003 | DLT8000 | Append  |     0 | 0000-00-00 00:00 |
|    14 | Save0004 | DLT8000 | Append  |     0 | 0000-00-00 00:00 |
|    15 | Save0005 | DLT8000 | Append  |     0 | 0000-00-00 00:00 |
|    16 | Save0006 | DLT8000 | Append  |     0 | 0000-00-00 00:00 |
|    17 | Save0007 | DLT8000 | Append  |     0 | 0000-00-00 00:00 |
|    18 | Save0008 | DLT8000 | Append  |     0 | 0000-00-00 00:00 |
|    19 | Save0009 | DLT8000 | Append  |     0 | 0000-00-00 00:00 |
|    20 | Save0010 | DLT8000 | Append  |     0 | 0000-00-00 00:00 |
+-------+----------+---------+---------+-------+------------------+
*
\end{bVerbatim}

Notice that the console program automatically appended a number to the base
Volume name that you specify (Save in this case). If you don't want it to
append a number, you can simply answer 0 (zero) to the question ``Enter number
of Media volumes to create. Max=1000:'', and in this case, it will create a
single Volume with the exact name you specify.
