3.1. Bareos Console¶

The Bareos Console (bconsole) is a program that allows the user or the System Administrator, to interact with the Bareos Director daemon while the daemon is running.

The current Bareos Console comes as a shell interface (TTY style). It permit the administrator or authorized users to interact with Bareos. 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 Director through the network, your Console and Director 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 Bareos to be able to write on more than one tape, because when Bareos requests a new tape, it waits until the user, via the Console program, indicates that the new tape is mounted.

3.1.1. Console Configuration¶

When the Console starts, it reads a standard Bareos configuration file named bconsole.conf unless you specify the -c command line option (see below). This file allows default configuration of the Console, and at the current time, the only Resource Record defined is the Director resource, which gives the Console the name and address of the Director. For more information on configuration of the Console program, please see the Console Configuration chapter of this document.

3.1.2. Running the Console Program¶

The console program can be run with the following options:

bconsole command line options}{}{bconsole -?¶

Usage: bconsole [-s] [-c config_file] [-d debug_level]
       -D <dir>    select a Director
       -l          list Directors defined
       -c <file>   set configuration file to file
       -d <nn>     set debug level to <nn>
       -dt         print timestamp in debug output
       -n          no conio
       -s          no signals
       -u <nn>     set command execution timeout to <nn> seconds
       -t          test - read configuration and exit
       -?          print this message.

After launching the Console program (bconsole), 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:

where command is one of the commands listed below; keyword is one of the keywords listed below (usually followed by an argument); and 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 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:

will list all files saved for JobId 23. Or:

will display all the Pool resource records.

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

3.1.2.1. Exit the Console Program¶

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

There is currently no way to interrupt a Console command once issued (i.e. 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 (.), 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.

3.1.2.2. Running the Console 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:

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 RunBeforeJob or RunAfterJob records.

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

where the file named filename contains any set of console commands.

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

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

3.1.3. 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:

jobid=536

all: Permitted on the status and show commands to specify all components or resources respectively.
allfrompool: Permitted on the update command to specify that all Volumes in the pool (specified on the command line) should be updated.
allfrompools: Permitted on the update command to specify that all Volumes in all pools should be updated.
before: Used in the restore command.
bootstrap: Used in the restore command.
catalog: Allowed in the use command to specify the catalog name to be used.
catalogs: Used in the show command. Takes no arguments.

client | fd clients

Used in the show, list, and llist commands. Takes no arguments.

counters: Used in the show command. Takes no arguments.
current: Used in the restore command. Takes no argument.
days: Used to define the number of days the list nextvol command should consider when looking for jobs to be run. The days keyword can also be used on the status dir command so that it will display jobs scheduled for the number of days you want. It can also be used on the rerun command, where it will automatically select all failed jobids in the last number of days for rerunning.
devices: Used in the show command. Takes no arguments.

director | dir directors

Used in the show command. Takes no arguments.

directory: Used in the restore command. Its argument specifies the directory to be restored.
enabled: This keyword can appear on the update volume as well as the update slots commands, and can allows one of the following arguments: yes, true, no, false, archived, 0, 1, 2. Where 0 corresponds to no or false, 1 corresponds to yes or true, and 2 corresponds to 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.
done: Used in the restore command. Takes no argument.
file: Used in the restore command.
files: Used in the list and llist commands. Takes no arguments.

fileset filesets

Used in the show command. Takes no arguments.

help

Used in the show command. Takes no arguments.

hours

Used on the rerun command to select all failed jobids in the last number of hours for rerunning.

jobs

Used in the show, list and llist commands. Takes no arguments.

jobmedia

Used in the list and llist commands. Takes no arguments.

jobtotals

Used in the list and llist commands. Takes no arguments.

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.

JobId can be used on the rerun command to select all jobs failed after and including the given jobid for rerunning.

job | jobname

The Job or Jobname keyword refers to the name you specified in the Job resource, 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.

level listing

Permitted on the estimate command. Takes no argument.

limit messages

Used in the show command. Takes no arguments.

media: Used in the list and llist commands. Takes no arguments.
nextvolume | nextvol: Used in the list and llist commands. Takes no arguments.
on: Takes no keyword.
off: Takes no keyword.

pool pools

Used in the show, list, and llist commands. Takes no arguments.

select: Used in the restore command. Takes no argument.
limit: Used in the setbandwidth command. Takes integer in KB/s unit.
schedules: Used in the show command. Takes no arguments.

storage | store | sd storages

Used in the show command. Takes no arguments.

ujobid: The 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 Name directive 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.

volume volumes

Used in the list and llist commands. Takes no arguments.

where: Used in the restore command.
yes: Used in the restore command. Takes no argument.

3.1.4. Console Commands¶

The following commands are currently implemented:

add

add¶

    add [pool=<pool-name>] [storage=<storage>] [jobid=<JobId>]

Normally, the :strong:`label` command is used rather than this command because the :strong:`label` command labels the physical media (tape, disk,, ...) and does the equivalent of the :strong:`add` command. The :strong:`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 :strong:`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 :strong:`label` command for the list of legal characters in a Volume name.

autodisplay

automount

cancel

cancel¶

    cancel [jobid=<number> job=<job-name> ujobid=<unique-jobid>]

Once a Job is marked to be cancelled, 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.

It is possible to cancel multiple jobs at once. Therefore, the following extra options are available for the job-selection:

-  all jobs

-  all jobs with a created state

-  all jobs with a blocked state

-  all jobs with a waiting state

-  all jobs with a running state

Usage:

cancel all¶

    cancel all
    cancel all state=<created|blocked|waiting|running>

Sometimes the Director already removed the job from its running queue, but the storage daemon still thinks it is doing a backup (or another job) - so you cannot cancel the job from within a console anymore. Therefore it is possible to cancel a job by JobId on the storage daemon. It might be helpful to execute a :strong:`status storage` on the Storage Daemon to make sure what job you want to cancel.

Usage:

cancel on Storage Daemon¶

    cancel storage=<Storage Daemon> Jobid=<JobId>

This way you can also remove a job that blocks any other jobs from running without the need to restart the whole storage daemon.

create

create¶

    create [pool=<pool-name>]

When starting a Job, if Bareos determines that there is no Pool record in the database, but there is a Pool resource of the appropriate name, it will create it for you. If you want the Pool record to appear in the database immediately, simply use this command to force it to be created.

configure

Configures director resources during runtime. The first configure subcommands are configure add and configure export. Other subcommands may follow in later releases.

configure add

This command allows to add resources during runtime. Usage:

configure add usage¶

        configure add <resourcetype> name=<resourcename> <directive1>=<value1> <directive2>=<value2> ...

    Values that must be quoted in the resulting configuration must be added as:

configure add usage with values containing spaces¶

        configure add <resourcetype> name=<resourcename> <directive1>="\"<value containing spaces>\"" ...

    The command generates and loads a new valid resource. As the new resource is also stored at

       :file:`<CONFIGDIR>/bareos-dir.d/<resourcetype>/<resourcename>.conf`

    (see :ref:`section-ConfigurationResourceFileConventions`) it is persistent upon reload and restart.

    This feature requires :ref:`section-ConfigurationSubdirectories`.

    All kinds of resources can be added. When adding a client resource, the :ref:`ClientResourceDirector` for the |bareosFd| is also created and stored at:

       :file:`<CONFIGDIR>/bareos-dir-export/client/<clientname>/bareos-fd.d/director/<clientname>.conf`

Example: adding a client and a job resource during runtime¶

        *configure add client name=client2-fd address=192.168.0.2 password=secret
        Created resource config file "/etc/bareos/bareos-dir.d/client/client2-fd.conf":
        Client {
          Name = client2-fd
          Address = 192.168.0.2
          Password = secret
        }
        *configure add job name=client2-job client=client2-fd jobdefs=DefaultJob
        Created resource config file "/etc/bareos/bareos-dir.d/job/client2-job.conf":
        Job {
          Name = client2-job
          Client = client2-fd
          JobDefs = DefaultJob
        }

    These two commands create three resource configuration files:

    -



          :file:`/etc/bareos/bareos-dir.d/client/client2-fd.conf`

    -  :file:`/etc/bareos/bareos-dir-export/client/client2-fd/bareos-fd.d/director/bareos-dir.conf` (assuming your director resource is named **bareos-dir**)

    -



          :file:`/etc/bareos/bareos-dir.d/job/client2-job.conf`

    The files in :file:`bareos-dir-export/client/` directory are not used by the |bareosDir|. However, they can be copied to new clients to configure these clients for the |bareosDir|.

Warning

Don’t be confused by the extensive output of bcommand{help{configure}. As bcommand{configure}{add} allows configuring arbitrary resources, the output of bcommand{help}{configure} lists all the resources, each with all valid directives. The same data is also used for command{bconsole} command line completion.}

Available since Bareos 16.2.4.

configure export

This command allows to export the ^Fd Director resource for clients already configured in the Bareos Director Daemon.

Usage:

Export the bareos-fd Director resource for the client bareos-fd¶

        configure export client=bareos-fd
        Exported resource file "/etc/bareos/bareos-dir-export/client/bareos-fd/bareos-fd.d/director/bareos-dir.conf":
        Director {
          Name = bareos-dir
          Password = "[md5]932d1d3ef3c298047809119510f4bee6"
        }

    To use it, copy the :sup:`Fd` :strong:`Director` resource file to the client machine (on Linux: to :file:`/etc/bareos/bareos-fd.d/director/`) and restart the |bareosFd|.

    Available since Bareos 16.2.4.

delete

delete¶

    delete pool=<pool-name>
    delete volume=<volume-name> pool=<pool-name>
    delete JobId=<job-id> JobId=<job-id2> ...
    delete Job JobId=n,m,o-r,t ...

The first form deletes a Pool record from the catalog database. The second form deletes a Volume record from the specified pool in the catalog database. 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. That is a "delete jobid" accepts lists and ranges of jobids.

disable

disable¶

    disable job=<job-name>

enable

enable¶

    enable job=<job-name>

estimate

estimate¶

    estimate job=<job-name> listing client=<client-name> accurate=<yes|no> fileset=<fileset-name> level=<level-name>

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

As an example, you might do:

estimate: redirected output¶

    @output /tmp/listing
    estimate job=NightlySave listing level=Incremental
    @output

which will do a full listing of all files to be backed up for the Job **NightlySave** during an Incremental save and put it in the file **/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 Bareos will
backup if the sparse option is not specified in the FileSet. There is currently no way to get an estimate of the real file size that would be found should the sparse option be enabled.

exit

export

export¶

    export storage=<storage-name> srcslots=<slot-selection> [dstslots=<slot-selection> volume=<volume-name> scan]

The export command does exactly the opposite of the import command. You can specify which slots should be transferred to import/export slots. The most useful application of the export command is the possibility to automatically transfer the volumes of a certain backup into the import/export slots for external storage.

To be able to to this, the export command also accepts a list of volume names to be exported.

Example:

export volume¶

    export volume=A00020L4|A00007L4|A00005L4

Instead of exporting volumes by names you can also select a number of slots via the srcslots keyword and export those to the slots you specify in dstslots. The export command will check if the slots have content (e.g. otherwise there is not much to export) and if there are enough export slots and if those are really import/export slots.

Example:

export slots¶

    export srcslots=1-2 dstslots=37-38

To automatically export the Volumes used by a certain backup job, you can use the following RunScript in that job:

automatic export¶

    RunScript {
        Console = "export storage=TandbergT40 volume=%V"
        RunsWhen = After
        RunsOnClient = no
    }

To send an e-mail notification via the Messages resource regarding export tapes you can use the Variable %V substitution in the Messages resource, which is implemented in Bareos 13.2. However, it does also work in earlier releases inside the job resources. So in versions prior to Bareos 13.2 the following workaround can be used:

e-mail notification via messages resource regarding export tapes¶

    RunAfterJob = "/bin/bash -c \"/bin/echo Remove Tape %V | \
    /usr/sbin/bsmtp -h localhost -f root@localhost -s 'Remove Tape %V' root@localhost \""

gui

help

import

import¶

    import storage=<storage-name> [srcslots=<slot-selection> dstslots=<slot-selection> volume=<volume-name> scan]

To import new tapes into the autochanger, you only have to load the new tapes into the import/export slots and call import from the cmdline.

The import command will automatically transfer the new tapes into free slots of the autochanger. The slots are filled in order of the slot numbers. To import all tapes, there have to be enough free slots to load all tapes.

Example with a Library with 36 Slots and 3 Import/Export Slots:

import example¶

    *import storage=TandbergT40
    Connecting to Storage daemon TandbergT40 at bareos:9103 ...
    3306 Issuing autochanger "slots" command.
    Device "Drive-1" has 39 slots.
    Connecting to Storage daemon TandbergT40 at bareos:9103 ...
    3306 Issuing autochanger "listall" command.
    Connecting to Storage daemon TandbergT40 at bareos:9103 ...
    3306 Issuing autochanger transfer command.
    3308 Successfully transfered volume from slot 37 to 20.
    Connecting to Storage daemon TandbergT40 at bareos:9103 ...
    3306 Issuing autochanger transfer command.
    3308 Successfully transfered volume from slot 38 to 21.
    Connecting to Storage daemon TandbergT40 at bareos:9103 ...
    3306 Issuing autochanger transfer command.
    3308 Successfully transfered volume from slot 39 to 25.

You can also import certain slots when you don’t have enough free slots in your autochanger to put all the import/export slots in.

Example with a Library with 36 Slots and 3 Import/Export Slots importing one slot:

import example¶

    *import storage=TandbergT40 srcslots=37 dstslots=20
    Connecting to Storage daemon TandbergT40 at bareos:9103 ...
    3306 Issuing autochanger "slots" command.
    Device "Drive-1" has 39 slots.
    Connecting to Storage daemon TandbergT40 at bareos:9103 ...
    3306 Issuing autochanger "listall" command.
    Connecting to Storage daemon TandbergT40 at bareos:9103 ...
    3306 Issuing autochanger transfer command.
    3308 Successfully transfered volume from slot 37 to 20.

label

label¶

    label storage=<storage-name> volume=<volume-name> slot=<slot>

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

The Volume name is restricted to letters, numbers, and the special characters hyphen (**-**), underscore (**\_**), colon (**:**), 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, Bareos will get **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:

           mt rewind
           mt weof

The label command can fail for a number of reasons:

#. The Volume name you specify is already in the Volume database.

#. The Storage daemon has a tape or other Volume already mounted on the device, in which case you must **unmount** the device, insert a blank tape, then do the **label** command.

#. The Volume in the device is already a Bareos labeled Volume. (Bareos will never relabel a Bareos labeled Volume unless it is recycled and you use the **relabel** command).

#. There is no Volume in the drive.

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

           mt -f /dev/st0 rewind
           mt -f /dev/st0 weof

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

Then you use the **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 purge the volume, either automatically, or explicitly with the :strong:`purge` command, then use the :strong:`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 :strong:`label barcodes` command. For each tape in the changer containing a barcode, Bareos 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 "CleaningPrefix=xxx" (default is "CLN") directive in the
Director’s Pool resource, 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:

Cleaning Tape¶

    Pool {
        Name ...
        Cleaning Prefix = "CLN"
    }

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

label¶

    label storage=xxx pool=yyy slots=1-5,10 barcodes

list

list¶

    list jobs
    list jobid=<id>           (list jobid id)
    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>
    list pools
    list clients
    list jobtotals
    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

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 :strong:`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 **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 :strong:`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 :file:`query.sql` file. However, this takes some knowledge of programming SQL. Please see the :strong:`query` command below for additional information. See below for listing the full contents of a catalog record with the :strong:`llist` command.

As an example, the command **list pools** might produce the following output:

list pools¶

    *list pools
    +------+---------+---------+---------+----------+-------------+
    | PoId | Name    | NumVols | MaxVols | PoolType | LabelFormat |
    +------+---------+---------+---------+----------+-------------+
    |    1 | Default |       0 |       0 | Backup   | *           |
    |    2 | Recycle |       0 |       8 | Backup   | File        |
    +------+---------+---------+---------+----------+-------------+

As mentioned above, the **list** command lists what is in the database. Some things are put into the database immediately when Bareos 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.

Bareos should create a client record in the database the first time you run a job for that client. Doing a **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 **show clients**.

llist

llist pools¶

    *llist pools
              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

messages

memory

mount

mount¶

    mount storage=<storage-name> [slot=<num>] [drive=<num>]
    mount [jobid=<id> | job=<job-name>]

If you have specified **Automatic  Mount**:sup:`Sd`:sub:`Device` = **yes**, under most circumstances, Bareos will automatically access the Volume unless you have explicitly :strong:`unmount`ed it in the Console program.

move

move¶

    *move storage=TandbergT40 srcslots=32 dstslots=33
    Connecting to Storage daemon TandbergT40 at bareos:9103 ...
    3306 Issuing autochanger "slots" command.
    Device "Drive-1" has 39 slots.
    Connecting to Storage daemon TandbergT40 at bareos:9103 ...
    3306 Issuing autochanger "listall" command.
    Connecting to Storage daemon TandbergT40 at bareos:9103 ...
    3306 Issuing autochanger transfer command.
    3308 Successfully transfered volume from slot 32 to 33.

prune

prune¶

    prune files [client=<client>] [pool=<pool>] [yes] |
          jobs [client=<client>] [pool=<pool>] [jobtype=<jobtype>] [yes] |
          volume [=volume] [pool=<pool>] [yes] |
          stats [yes]

For a Volume to be pruned, the volume status must be **Full**, **Used** or **Append** otherwise the pruning will not take place.

purge

purge¶

    purge [files [job=<job> | jobid=<jobid> | client=<client> | volume=<volume>]] |
          [jobs [client=<client> | volume=<volume>]] |
          [volume [=<volume>] [storage=<storage>] [pool=<pool>] [devicetype=<type>] [drive=<drivenum>] [action=<action>]] |
          [quota [client=<client>]]

For the :strong:`purge` command to work on volume catalog database records the volume status must be **Append**, **Full**, **Used** or **Error**.

The actual data written to the Volume will be unaffected by this command unless you are using the **Action On Purge**:sup:`Dir`:sub:`Pool` = **Truncate** option.

To ask Bareos to truncate your **Purged** volumes, you need to use the following command in interactive mode:

purge example¶

    *purge volume action=truncate storage=File pool=Full

However, normally you should use the :strong:`purge` command only to purge a volume from the catalog and use the :strong:`truncate` command to truncate the volume on the |bareosSd|.

resolve

resolve example¶

    *resolve www.bareos.com
    bareos-dir resolves www.bareos.com to host[ipv4:84.44.166.242]

    *resolve client=client1-fd www.bareos.com
    client1-fd resolves www.bareos.com to host[ipv4:84.44.166.242]

    *resolve storage=File www.bareos.com
    bareos-sd resolves www.bareos.com to host[ipv4:84.44.166.242]

query

quit .. index:

      single: quit
This command terminates the console program. The console program sends the **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 **.quit** command (i.e. quit preceded by a period).

relabel

relabel¶

    relabel storage=<storage-name> oldvolume=<old-volume-name> volume=<new-volume-name> pool=<pool-name> [encrypt]

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 **Purged** or **Recycle**. This happens automatically as a result of applying retention periods or you may explicitly purge the volume using the :strong:`purge` command.

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

release

release¶

    release storage=<storage-name>

After a release command, the device is still kept open by Bareos (unless **Always Open**:sup:`Sd`:sub:`Device` = **no**) 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, Bareos 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. :program:`mt`), you
must use the :strong:`unmount` command to cause Bareos to completely release (close) the device.

reload

rerun

rerun¶

    rerun jobid=<jobid> since_jobid=<jobid> days=<nr_days> hours=<nr_hours> yes

You can select the jobid(s) to rerun by using one of the selection criteria. Using jobid= will automatically select all jobs failed after and including the given jobid for rerunning. By using days= or hours=, you can select all failed jobids in the last number of days or number of hours respectively for rerunning.

restore .. index:

single: Restore

restore¶

    restore storage=<storage-name> client=<backup-client-name>
      where=<path> pool=<pool-name> fileset=<fileset-name>
      restoreclient=<restore-client-name>
      restorejob=<job-name>
      select current all done

Where **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 **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 **restore** command, please see the :ref:`Restore Chapter <RestoreChapter>` of this manual.

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 restoreclient keyword is specified, then the restore is written to that client.

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

For more details, see the :ref:`Restore chapter <RestoreChapter>`.

run

run¶

    run job=<job-name> client=<client-name> fileset=<fileset-name>
       level=<level> storage=<storage-name> where=<directory-prefix>
       when=<universal-time-specification> pool=<pool-name>
       pluginoptions=<plugin-options-string> accurate=<yes|no>
       comment=<text> spooldata=<yes|no> priority=<number>
       jobid=<jobid> catalog=<catalog> migrationjob=<job-name> backupclient=<client-name>
       backupformat=<format> nextpool=<pool-name> since=<universal-time-specification>
       verifyjob=<job-name> verifylist=<verify-list> migrationjob=<complete_name>
       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 **yes**, in which case the job will be immediately sent to the scheduler.

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

The 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.

setbandwidth

setbandwidth¶

    setbandwidth limit=<nb> [jobid=<id> | client=<cli>]

setdebug

setdebug¶

    setdebug level=nnn [trace=0/1 client=<client-name> | dir | director | storage=<storage-name> | all]

Each of the daemons normally has debug compiled into the program, but disabled. There are two ways to enable the debug output.

One is to add the **-d nnn** option on the command line when starting the daemon. The **nnn** is the debug level, and generally anything between 50 and 200 is reasonable. The higher the number, the more output is produced. The output is written to standard output.

The second way of getting debug output is to dynamically turn it on using the Console using the :program:`setdebug level=nnn` command. If none of the options are given, the command will prompt you. You can selectively turn on/off debugging in any or all the daemons (i.e. it is not necessary to specify all the components of the above command).

If 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 his trace file in the current directory of the daemon. When tracing, each debug output message is appended to the trace file. You must explicitly delete the file when you are done.

set Director debug level to 100 and get messages written to his trace file¶

    *setdebug level=100 trace=1 dir
    level=100 trace=1 hangup=0 timestamp=0 tracefilename=/var/lib/bareos/bareos-dir.example.com.trace

setip

A console is authorized to use the SetIP command only if it has a Console resource definition in both the Director and the Console. In addition, if the console name, provided on the Name = directive, must be the same as a Client name, the user of that console is permitted to use the SetIP command to change the Address directive in the Director’s client resource 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.

show

sqlquery

status

status¶

    status [all | dir=<dir-name> | director | scheduler | schedule=<schedule-name> |
            client=<client-name> | storage=<storage-name> slots | subscriptions]

If you do a **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:

status storage¶

    *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 usersave
    ====

    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 "File" (/tmp) is not open.
    ====

    In Use Volume status:
    ====

Now, what this tells me is that no jobs are running and that none of the devices are in use. Now, if I **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 I re-issue the status storage command, I get for the Device status:

status storage¶

    *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 "File" (/tmp) is not open.
        Device is BLOCKED waiting for media.
    ====
    ...

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 Bareos needs you to label a Volume.

The command :strong:`status scheduler` (12.4.4) can be used to check when a certain schedule will trigger. This gives more information than :strong:`status director`.

Called without parameters, :strong:`status scheduler` shows a preview for all schedules for the next 14 days. It first shows a list of the known schedules and the jobs that will be triggered by these jobs, and next, a table with date (including weekday), schedule name and applied overrides is displayed:

status scheduler¶

    *status scheduler
    Scheduler Jobs:

    Schedule               Jobs Triggered
    ===========================================================
    WeeklyCycle
                           BackupClient1

    WeeklyCycleAfterBackup
                           BackupCatalog

    ====

    Scheduler Preview for 14 days:

    Date                  Schedule                Overrides
    ==============================================================
    Di 04-Jun-2013 21:00  WeeklyCycle             Level=Incremental
    Di 04-Jun-2013 21:10  WeeklyCycleAfterBackup  Level=Full
    Mi 05-Jun-2013 21:00  WeeklyCycle             Level=Incremental
    Mi 05-Jun-2013 21:10  WeeklyCycleAfterBackup  Level=Full
    Do 06-Jun-2013 21:00  WeeklyCycle             Level=Incremental
    Do 06-Jun-2013 21:10  WeeklyCycleAfterBackup  Level=Full
    Fr 07-Jun-2013 21:00  WeeklyCycle             Level=Incremental
    Fr 07-Jun-2013 21:10  WeeklyCycleAfterBackup  Level=Full
    Sa 08-Jun-2013 21:00  WeeklyCycle             Level=Differential
    Mo 10-Jun-2013 21:00  WeeklyCycle             Level=Incremental
    Mo 10-Jun-2013 21:10  WeeklyCycleAfterBackup  Level=Full
    Di 11-Jun-2013 21:00  WeeklyCycle             Level=Incremental
    Di 11-Jun-2013 21:10  WeeklyCycleAfterBackup  Level=Full
    Mi 12-Jun-2013 21:00  WeeklyCycle             Level=Incremental
    Mi 12-Jun-2013 21:10  WeeklyCycleAfterBackup  Level=Full
    Do 13-Jun-2013 21:00  WeeklyCycle             Level=Incremental
    Do 13-Jun-2013 21:10  WeeklyCycleAfterBackup  Level=Full
    Fr 14-Jun-2013 21:00  WeeklyCycle             Level=Incremental
    Fr 14-Jun-2013 21:10  WeeklyCycleAfterBackup  Level=Full
    Sa 15-Jun-2013 21:00  WeeklyCycle             Level=Differential
    Mo 17-Jun-2013 21:00  WeeklyCycle             Level=Incremental
    Mo 17-Jun-2013 21:10  WeeklyCycleAfterBackup  Level=Full
    ====

:strong:`status scheduler` accepts the following parameters:

client=clientname
    shows only the schedules that affect the given client.

job=jobname
    shows only the schedules that affect the given job.

schedule=schedulename
    shows only the given schedule.

days=number
    of days shows only the number of days in the scheduler preview. Positive numbers show the future, negative numbers show the past. days can be combined with the other selection criteria. days= can be combined with the other selection criteria.

In case you are running a maintained version of Bareos, the command :strong:`status subscriptions` (12.4.4) can help you to keep the overview over the subscriptions that are used.

To enable this functionality, just add the configuration **Subscriptions**:sup:`Dir`:sub:`Director`  directive and specify the number of subscribed clients, for example:

enable subscription check¶

    Director {
       ...
       Subscriptions = 50
    }

Using the console command :strong:`status subscriptions`, the status of the subscriptions can be checked any time interactively:

status subscriptions¶

    *status subscriptions
    Ok: available subscriptions: 8 (42/50) (used/total)

Also, the number of subscriptions is checked after every job. If the number of clients is bigger than the configured limit, a Job warning is created a message like this:

subscriptions warning¶

    JobId 7: Warning: Subscriptions exceeded: (used/total) (51/50)

Please note: Nothing else than the warning is issued, no enforcement on backup, restore or any other operation will happen.

Setting the value for **Subscriptions**:sup:`Dir`:sub:`Director` = **0** disables this functionality:

disable subscription check¶

    Director {
       ...
       Subscriptions = 0
    }

Not configuring the directive at all also disables it, as the default value for the Subscriptions directive is zero.

time

trace

truncate .. index:

pair: Disk; Freeing disk space

If the status of a volume is Purged, it normally still contains data, even so it can not easily be accessed.

truncate¶

    truncate volstatus=Purged [storage=<storage>] [pool=<pool>] [volume=<volume>] [yes]

When using a disk volume (and other volume types also) the volume file still resides on the |bareosSd|. If you want to reclaim disk space, you can use the :strong:`truncate}{volstatus=Purged` command. When used on a volume, it rewrites the header and by this frees the rest of the disk space.

If the volume you want to get rid of has not the **Purged** status, you first have to use the :strong:`prune volume` or even the :strong:`purge volume` command to free the volume from all remaining jobs.

This command is available since Bareos 16.2.5.

umount

unmount

unmount¶

    unmount storage=<storage-name> [drive=<num>]
    unmount [jobid=<id> | job=<job-name>]

Once you unmount a storage device, Bareos will no longer be able to use it until you issue a mount command for that device. If Bareos 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.

In most cases, it is preferable to use the :strong:`release` instead.

update

volume

pool

slots

iobid

stats

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

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

For slots update slots, Bareos 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 Bareos to know what magazine (tape holder) is currently in the autochanger.

If you do not have barcodes, you can accomplish the same thing by using the update slots scan command. The scan keyword tells Bareos to physically mount each tape and to read its VolumeName.

For Pool update pool, Bareos will move the Volume record from its existing pool to the pool specified.

For Volume from Pool, All Volumes from Pool and All Volumes from all Pools, the following values are updated from the Pool record: Recycle, RecyclePool, VolRetention, VolUseDuration, MaxVolJobs, MaxVolFiles, and MaxVolBytes.

For updating the statistics, use updates stats, see Job Statistics.

The full form of the update command with all command line arguments is:

update¶

    update  volume=<volume-name> [volstatus=<status>]
            [volretention=<time-def>] [pool=<pool-name>]
            [recycle=<yes/no>] [slot=<number>] [inchanger=<yes/no>] |
            pool=<pool-name> [maxvolbytes=<size>] [maxvolfiles=<nb>]
            [maxvoljobs=<nb>][enabled=<yes/no>] [recyclepool=<pool-name>]
            [actiononpurge=<action>] |
            slots [storage=<storage-name>] [scan] |
            jobid=<jobid> [jobname=<name>] [starttime=<time-def>]
            [client=<client-name>] [filesetid=<fileset-id>]
            [jobtype=<job-type>] |
            stats [days=<number>]

use

use¶

    use [catalog=<catalog>]

var

version

wait

wait¶

    wait [jobid=<jobid>] [jobuid=<unique id>] [job=<job name>]

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

3.1.4.1. Special dot (.) 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. For details, see :raw-latex:`\bareosDeveloperGuideDotCommands`.

3.1.4.2. Special At (@) 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 at commands, all beginning with an at character (@), 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:

@input <filename>

:raw-latex:`\index[general]{Console!Command!\at{}input {\textless}filename{\textgreater}}` Read and execute the commands contained in the file specified.

@output <filename> <w|a>

:raw-latex:`\index[general]{Console!Command!\at{}output {\textless}filename{\textgreater} {\textless}w{\textbar}a{\textgreater}}` 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 @output without a filename specification. WARNING: be careful not to overwrite a valid file. A typical example during a regression test might be:

@output /dev/null commands … @output

@tee <filename> <w|a>

:raw-latex:`\index[general]{Console!Command!\at{}tee {\textless}filename{\textgreater} {\textless}w{\textbar}a{\textgreater}}` Send all subsequent output to both the specified file and the terminal. It is turned off by specifying @tee or @output without a filename.

@sleep <seconds>

:raw-latex:`\index[general]{Console!Command!\at{}sleep {\textless}seconds{\textgreater}}` Sleep the specified number of seconds.

@time

:raw-latex:`\index[general]{Console!Command!\at{}time}` Print the current time and date.

@version

:raw-latex:`\index[general]{Console!Command!\at{}version}` Print the console’s version.

@quit

:raw-latex:`\index[general]{Console!Command!\at{}quit}` quit

@exit

:raw-latex:`\index[general]{Console!Command!\at{}exit}` quit

@# anything

:raw-latex:`\index[general]{Console!Command!\at{}\# anything}` Comment

@help

:raw-latex:`\index[general]{Console!Command!\at{}help}` Get the list of every special @ commands.

@separator <char>

:raw-latex:`\index[general]{Console!Command!\at{}separator}` When using bconsole 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.

!$%&’()*+,-/:;<>?[]^`{|}~

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

3.1.5. Adding Volumes to a Pool¶

If you have used the 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 Bareos you will need to label it.

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

The name of the Pool (normally “Default”)
The Media Type as specified in the Storage Resource in the Director’s configuration file (e.g. “DLT8000”)
The number and names of the Volumes you wish to create.

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

To see what you have added, enter:

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.