Bacula Enterprise Edition Documentation text image transdoc

Main

Storage Daemon Configuration

The Storage Daemon configuration file has relatively few resource definitions. However, due to the great variation in backup media and system capabilities, the storage daemon must be highly configurable. As a consequence, there are quite a large number of directives in the Device Resource definition that allow you to define all the characteristics of your Storage device (normally a tape drive). Fortunately, with modern storage devices, the defaults are sufficient, and very few directives are actually needed.

Examples of Device resource directives that are known to work for a number of common tape drives can be found in the <bacula-src>/examples/devices directory, and most will also be listed here.

For a general discussion of configuration file and resources including the data types recognized by Bacula, please see the Configuration chapter of this manual. The following Storage Resource definitions must be defined:

Storage - to define the name of the Storage daemon.
Director - to define the Director's name and his access password.
Device - to define the characteristics of your storage device (tape drive).
Messages - to define where error and information messages are to be sent.

Storage Resource

In general, the properties specified under the Storage resource define global properties of the Storage daemon. Each Storage daemon configuration file must have one and only one Storage resource definition.

Name = <Storage-Daemon-Name>

Specifies the Name of the Storage daemon. This directive is required.

Working Directory = <Directory>

This directive is mandatory and specifies a directory in which the Storage daemon may put its status files. This directory should be used only by Bacula, but may be shared by other Bacula daemons provided the names given to each daemon are unique. This directive is required

Pid Directory = <Directory>

This directive is mandatory and specifies a directory in which the Storage daemon may put its process Id file files. The process Id file is used to shutdown Bacula and to prevent multiple copies of Bacula from running simultaneously. This directive is required. Standard shell expansion of the Directory is done when the configuration file is read so that values such as $HOME will be properly expanded.

Typically on Linux systems, you will set this to: /var/run. If you are not installing Bacula in the system directories, you can use the Working Directory as defined above.

Dedup Directory = <Directory>

This directive is mandatory when using Global Endpoint Deduplication feature, and specifies a directory in which the Storage daemon may put data block files for all devices of the type dedup. The Dedup Directory can be very large after some point, we advise you to use a logical volume manager to be able to extend the filesystem when needed with new disks.

Standard shell expansion of the Directory is done when the configuration file is read so that values such as $HOME will be properly expanded.

Dedup Index Directory = <Directory>

This directive is optional and specifies a directory in which the Storage daemon may put its index files for all devices of the type dedup.

Standard shell expansion of the Directory is done when the configuration file is read so that values such as $HOME will be properly expanded. The default value is set to DedupDirectory when set.

Heartbeat Interval = <time-interval>

This directive defines an interval of time in seconds. When the Storage daemon is waiting for the operator to mount a tape, each time interval, it will send a heartbeat signal to the File daemon. The default interval is 300s. This feature is particularly useful if you have a router such as 3Com that does not follow Internet standards and times out an valid connection after a short duration despite the fact that keepalive is set. This usually results in a broken pipe error message.

Client Connect Wait = <time-interval>

This directive defines an interval of time in seconds that the Storage daemon will wait for a Client (the File daemon) to connect. The default is 30 minutes. Be aware that the longer the Storage daemon waits for a Client, the more resources will be tied up.

Maximum Concurrent Jobs = <number>

where <number> is the maximum number of Jobs that may run concurrently. The default is set to 20, but you may set it to a larger number. Each contact from the Director (e.g. status request, job start request) is considered as a Job, so if you want to be able to do a status request in the console at the same time as a Job is running, you will need to set this value greater than 1. To run simultaneous Jobs, you will need to set a number of other directives in the Director's configuration file. Which ones you set depend on what you want, but you will almost certainly need to set the Maximum Concurrent Jobs in the Storage resource in the Director's configuration file and possibly those in the Job and Client resources.

SDAddresses = <IP-address-specification>

Specify the ports and addresses on which the Storage daemon will listen for Director connections. Normally, the default is sufficient and you do not need to specify this directive. Probably the simplest way to explain how this directive works is to show an example:

SDAddresses  = { ip = {
        addr = 1.2.3.4; port = 1205; }
    ipv4 = {
        addr = 1.2.3.4; port = http; }
    ipv6 = {
        addr = 1.2.3.4;
        port = 1205;
    }
    ip = {
        addr = 1.2.3.4
        port = 1205
    }
    ip = {
        addr = 1.2.3.4
    }
    ip = {
        addr = 201:220:222::2
    }
    ip = {
        addr = bluedot.thun.net
    }
}

where ip, ip4, ip6, addr, and port are all keywords. Note, that the address can be specified as either a dotted quadruple, or IPv6 colon notation, or as a symbolic name (only in the ip specification). Also, port can be specified as a number or as the mnemonic value from the /etc/services file. If a port is not specified, the default will be used. If an ip section is specified, the resolution can be made either by IPv4 or IPv6. If ip4 is specified, then only IPv4 resolutions will be permitted, and likewise with ip6.

Using this directive, you can replace both the SDPort and SDAddress directives shown below.

SDPort = <port-number>

Specifies port number on which the Storage daemon listens for Director connections. The default is 9103.

SDAddress = <IP-Address>

This directive is optional, and if it is specified, it will cause the Storage daemon server (for Director and File daemon connections) to bind to the specified IP-Address, which is either a domain name or an IP address specified as a dotted quadruple. If this directive is not specified, the Storage daemon will bind to any available address (the default).

CommCompression = <yes|no>

If the two Bacula components (DIR, FD, SD, bconsole) have the comm line compression enabled, the line compression will be enabled. The default value is yes.

In many cases, the volume of data transmitted across the communications line can be reduced by a factor of three when this directive is enabled. In the case that the compression is not effective, Bacula turns it off on a record by record basis.

If you are backing up data that is already compressed the comm line compression will not be effective, and you are likely to end up with an average compression ratio that is very small. In this case, Bacula reports None in the Job report.

TLS Enable = <yes|no>

Enable TLS support. If TLS is not enabled, none of the other TLS directives have any effect. In other words, even if you set TLS Require = yes you need to have TLS enabled or TLS will not be used.

TLS PSK Enable = <yes|no>

Enable or Disable automatic TLS PSK support. TLS PSK is enabled by default between all Bacula components. The Pre-Shared Key used between the programs is the Bacula password. If both TLS Enable and TLS PSK Enable are enabled, the system will use TLS certificates.

TLS Require = <yes|no>

Require TLS or TLS-PSK encryption. This directive is ignored unless one of TLS Enable or TLS PSK Enable is set to yes. If TLS is not required while TLS or TLS-PSK are enabled, then the Bacula component will connect with other components either with or without TLS or TLS-PSK

If TLS or TLS-PSK is enabled and TLS is required, then the Bacula component will refuse any connection request that does not use TLS.

TLS Authenticate = <yes|no>

When TLS Authenticate is enabled, after doing the CRAM-MD5 authentication, Bacula will also do TLS authentication, then TLS encryption will be turned off, and the rest of the communication between the two Bacula components will be done without encryption. If TLS-PSK is used instead of the regular TLS, the encryption is turned off after the TLS-PSK authentication step.

If you want to encrypt communications data, use the normal TLS directives but do not turn on TLS Authenticate.

TLS Certificate = <Filename>

The full path and filename of a PEM encoded TLS certificate. It will be used as either a client or server certificate, depending on the connection direction. PEM stands for Privacy Enhanced Mail, but in this context refers to how the certificates are encoded. This format is used because PEM files are base64 encoded and hence ASCII text based rather than binary. They may also contain encrypted information.

This directive is required in a server context, but it may not be specified in a client context if TLS Verify Peer is set to no in the corresponding server context.

Example:

File Daemon configuration file (bacula-fd.conf), Director resource configuration has TLS Verify Peer = no:

  Director {
    Name = bacula-dir
    Password = "password"
    Address = director.example.com
    
    # TLS configuration directives
    TLS Enable = yes
    TLS Require = yes
    TLS Verify Peer = no
    TLS CA Certificate File = /opt/bacula/ssl/certs/root_cert.pem
    TLS Certificate = /opt/bacula/ssl/certs/client1_cert.pem
    TLS Key = /opt/bacula/ssl/keys/client1_key.pem
  }

Having TLS Verify Peer = no, means the File Daemon, server context, will not check Directorâs public certificate, client context. There is no need to specify TLS Certificate File neither TLS Key directives in the Client resource, director configuration file. We can have the below client configuration in bacula-dir.conf:

  Client {
    Name = client1-fd
    Address = client1.example.com
    FDPort = 9102
    Catalog = MyCatalog
    Password = "password"
    ...
    # TLS configuration directives
    TLS Enable = yes
    TLS Require = yes
    TLS CA Certificate File = /opt/bacula/ssl/certs/ca_client1_cert.pem
  }

TLS Key = <Filename>

The full path and filename of a PEM encoded TLS private key. It must correspond to the TLS certificate.

TLS Verify Peer = <yes|no>

Verify peer certificate. Instructs server to request and verify the client's X.509 certificate. Any client certificate signed by a known-CA will be accepted. Additionally, the client's X509 certificate Common Name must meet the value of the Address directive. If the TLSAllowed CN onfiguration directive is used, the client's x509 certificate Common Name must also correspond to one of the CN specified in the TLS Allowed CN directive. This directive is valid only for a server and not in client context. The default is yes.

TLS Allowed CN = <string list>

Common name attribute of allowed peer certificates. This directive is valid for a server and in a client context. If this directive is specified, the peer certificate will be verified against this list. In the case this directive is configured on a server side, the allowed CN list will not be checked if TLS Verify Peer is set to no (TLS Verify Peer is yes by default). This can be used to ensure that only the CN-approved component may connect. This directive may be specified more than once.

In the case this directive is configured in a server side, the allowed CN list will only be checked if TLS Verify Peer = yes (default). For example, in bacula-fd.conf, Director resource definition:

  Director {
    Name = bacula-dir
    Password = "password"
    Address = director.example.com
    # TLS configuration directives
    TLS Enable = yes
    TLS Require = yes
    # if TLS Verify Peer = no, then TLS Allowed CN will not be checked.
    TLS Verify Peer = yes
    TLS Allowed CN = director.example.com
    TLS CA Certificate File = /opt/bacula/ssl/certs/root_cert.pem
    TLS Certificate = /opt/bacula/ssl/certs/client1_cert.pem
    TLS Key = /opt/bacula/ssl/keys/client1_key.pem
  }

In the case this directive is configured in a client side, the allowed CN list will always be checked.

  Client {
    Name = client1-fd
    Address = client1.example.com
    FDPort = 9102
    Catalog = MyCatalog
    Password = "password"
    ...
    # TLS configuration directives
    TLS Enable = yes
    TLS Require = yes
    # the Allowed CN will be checked for this client by director
    # the client's certificate Common Name must match any of
    # the values of the Allowed CN list
    TLS Allowed CN = client1.example.com
    TLS CA Certificate File = /opt/bacula/ssl/certs/ca_client1_cert.pem
    TLS Certificate = /opt/bacula/ssl/certs/director_cert.pem
    TLS Key = /opt/bacula/ssl/keys/director_key.pem
  }

If the client doesnât provide a certificate with a Common Name that meets any value in the TLS Allowed CN list, an error message will be issued:

16-Nov 17:30 bacula-dir JobId 0: Fatal error: bnet.c:273 TLS certificate
verification failed. Peer certificate did not match a required commonName
16-Nov 17:30 bacula-dir JobId 0: Fatal error: TLS negotiation failed with FD at
"192.168.100.2:9102".

TLS CA Certificate File = <Filename>

The full path and filename specifying a PEM encoded TLS CA certificate(s). Multiple certificates are permitted in the file. One of TLS CA Certificate File or TLS CA Certificate Dir are required in a server context, unless TLS Verify Peer (see above) is set to no, and are always required in a client context.

TLS CA Certificate Dir = <Directory>

Full path to TLS CA certificate directory. In the current implementation, certificates must be stored PEM encoded with OpenSSL-compatible hashes, which is the subject name's hash and an extension of .0. One of TLS CA Certificate File or TLS CA Certificate Dir are required in a server context, unless TLS Verify Peer is set to no, and are always required in a client context.

TLS DH File = <Directory>

Path to PEM encoded Diffie-Hellman parameter file. If this directive is specified, DH key exchange will be used for the ephemeral keying, allowing for forward secrecy of communications. DH key exchange adds an additional level of security because the key used for encryption/decryption by the server and the client is computed on each end and thus is never passed over the network if Diffie-Hellman key exchange is used. Even if DH key exchange is not used, the encryption/decryption key is always passed encrypted. This directive is only valid within a server context.

To generate the parameter file, you may use openssl:

openssl dhparam -out dh4096.pem -5 4096

The following is a typical Storage daemon Storage definition.

#
# "Global" Storage daemon configuration specifications appear
# under the Storage resource.
#
Storage {
  Name = "Storage daemon"
  Address = localhost
  WorkingDirectory = "~/bacula/working"
  Pid    Directory = "~/bacula/working"
}

Director Resource

The Director resource specifies the Name of the Director which is permitted to use the services of the Storage daemon. There may be multiple Director resources. The Director Name and Password must match the corresponding values in the Director's configuration file.

Name = <Director-Name>

Specifies the Name of the Director allowed to connect to the Storage daemon. This directive is required.

Password = <Director-password>

Specifies the password that must be supplied by the above named Director. This directive is required.

Monitor = <yes|no>

If Monitor is set to no (default), this director will have full access to this Storage daemon. If Monitor is set to yes, this director will only be able to fetch the current status of this Storage daemon.

Please note that if this director is being used by a Monitor, we highly recommend to set this directive to yes to avoid serious security problems.

TLS Enable = <yes|no>

Enable TLS support. If TLS is not enabled, none of the other TLS directives have any effect. In other words, even if you set TLS Require = yes you need to have TLS enabled or TLS will not be used.

TLS PSK Enable = <yes|no>

TLS Require = <yes|no>

If TLS or TLS-PSK is enabled and TLS is required, then the Bacula component will refuse any connection request that does not use TLS.

TLS Authenticate = <yes|no>

If you want to encrypt communications data, use the normal TLS directives but do not turn on TLS Authenticate.

TLS Certificate = <Filename>

This directive is required in a server context, but it may not be specified in a client context if TLS Verify Peer is set to no in the corresponding server context.

Example:

File Daemon configuration file (bacula-fd.conf), Director resource configuration has TLS Verify Peer = no:

  Director {
    Name = bacula-dir
    Password = "password"
    Address = director.example.com
    
    # TLS configuration directives
    TLS Enable = yes
    TLS Require = yes
    TLS Verify Peer = no
    TLS CA Certificate File = /opt/bacula/ssl/certs/root_cert.pem
    TLS Certificate = /opt/bacula/ssl/certs/client1_cert.pem
    TLS Key = /opt/bacula/ssl/keys/client1_key.pem
  }

  Client {
    Name = client1-fd
    Address = client1.example.com
    FDPort = 9102
    Catalog = MyCatalog
    Password = "password"
    ...
    # TLS configuration directives
    TLS Enable = yes
    TLS Require = yes
    TLS CA Certificate File = /opt/bacula/ssl/certs/ca_client1_cert.pem
  }

TLS Key = <Filename>

The full path and filename of a PEM encoded TLS private key. It must correspond to the TLS certificate.

TLS Verify Peer = <yes|no>

TLS Allowed CN = <string list>

In the case this directive is configured in a server side, the allowed CN list will only be checked if TLS Verify Peer = yes (default). For example, in bacula-fd.conf, Director resource definition:

  Director {
    Name = bacula-dir
    Password = "password"
    Address = director.example.com
    # TLS configuration directives
    TLS Enable = yes
    TLS Require = yes
    # if TLS Verify Peer = no, then TLS Allowed CN will not be checked.
    TLS Verify Peer = yes
    TLS Allowed CN = director.example.com
    TLS CA Certificate File = /opt/bacula/ssl/certs/root_cert.pem
    TLS Certificate = /opt/bacula/ssl/certs/client1_cert.pem
    TLS Key = /opt/bacula/ssl/keys/client1_key.pem
  }

In the case this directive is configured in a client side, the allowed CN list will always be checked.

  Client {
    Name = client1-fd
    Address = client1.example.com
    FDPort = 9102
    Catalog = MyCatalog
    Password = "password"
    ...
    # TLS configuration directives
    TLS Enable = yes
    TLS Require = yes
    # the Allowed CN will be checked for this client by director
    # the client's certificate Common Name must match any of
    # the values of the Allowed CN list
    TLS Allowed CN = client1.example.com
    TLS CA Certificate File = /opt/bacula/ssl/certs/ca_client1_cert.pem
    TLS Certificate = /opt/bacula/ssl/certs/director_cert.pem
    TLS Key = /opt/bacula/ssl/keys/director_key.pem
  }

If the client doesnât provide a certificate with a Common Name that meets any value in the TLS Allowed CN list, an error message will be issued:

16-Nov 17:30 bacula-dir JobId 0: Fatal error: bnet.c:273 TLS certificate
verification failed. Peer certificate did not match a required commonName
16-Nov 17:30 bacula-dir JobId 0: Fatal error: TLS negotiation failed with FD at
"192.168.100.2:9102".

TLS CA Certificate File = <Filename>

TLS CA Certificate Dir = <Directory>

TLS DH File = <Directory>

To generate the parameter file, you may use openssl:

openssl dhparam -out dh4096.pem -5 4096

The following is an example of a valid Director resource definition:

Director {
  Name = MainDirector
  Password = my_secret_password
}

Device Resource

The Device Resource specifies the details of each device (normally a tape drive) that can be used by the Storage daemon. There may be multiple Device resources for a single Storage daemon. In general, the properties specified within the Device resource are specific to the Device.

Name = <Device-Name>

Specifies the Name that the Director will use when asking to backup or restore to or from to this device. This is the logical Device name, and may be any string up to 127 characters in length. It is generally a good idea to make it correspond to the English name of the backup device. The physical name of the device is specified on the Archive Device directive described below. The name you specify here is also used in your Director's conf file on the Device directive in its Storage resource.

Archive Device = <name-string>

The specified name-string gives the system file name of the storage device managed by this storage daemon. This will usually be the device file name of a removable storage device (tape drive), for example /dev/nst0 or /dev/rmt/0mbn. It may also be a directory name if you are archiving to disk storage. In this case, you must supply the full absolute path to the directory. When specifying a tape device, it is preferable that the "non-rewind" variant of the device file name be given. In addition, on systems such as Sun, which have multiple tape access methods, you must be sure to specify to use Berkeley I/O conventions with the device. The b in the Solaris (Sun) archive specification /dev/rmt/0mbn is what is needed in this case. Bacula does not support SysV tape drive behavior.

As noted above, normally the Archive Device is the name of a tape drive, but you may also specify an absolute path to an existing directory. If the Device is a directory Bacula will write to file storage in the specified directory, and the filename used will be the Volume name as specified in the Catalog. If you want to write into more than one directory (i.e. to spread the load to different disk drives), you will need to define two Device resources, each containing an Archive Device with a different directory. In addition to a tape device name or a directory name, Bacula will accept the name of a FIFO. A FIFO is a special kind of file that connects two programs via kernel memory. If a FIFO device is specified for a backup operation, you must have a program that reads what Bacula writes into the FIFO. When the Storage daemon starts the job, it will wait for MaximumOpenWait seconds for the read program to start reading, and then time it out and terminate the job. As a consequence, it is best to start the read program at the beginning of the job perhaps with the RunBeforeJob directive. For this kind of device, you never want to specify AlwaysOpen, because you want the Storage daemon to open it only when a job starts, so you must explicitly set it to no. Since a FIFO is a one way device, Bacula will not attempt to read a label of a FIFO device, but will simply write on it. To create a FIFO Volume in the catalog, use the add command rather than the label command to avoid attempting to write a label.

Device {
  Name = FifoStorage
  Media Type = Fifo
  Device Type = Fifo
  Archive Device = /tmp/fifo
  LabelMedia = yes
  Random Access = no
  AutomaticMount = no
  RemovableMedia = no
  MaximumOpenWait = 60
  AlwaysOpen = no
}

During a restore operation, if the Archive Device is a FIFO, Bacula will attempt to read from the FIFO, so you must have an external program that writes into the FIFO. Bacula will wait MaximumOpenWait seconds for the program to begin writing and will then time it out and terminate the job. As noted above, you may use the RunBeforeJob to start the writer program at the beginning of the job.

The Archive Device directive is required.

Device Type = <type-specification>

The Device Type specification allows you to explicitly tell Bacula what kind of device you are defining. It the type-specification may be one of the following:

File: Tells Bacula that the device is a file. It may either be a file defined on fixed medium or a removable filesystem such as USB. All files must be random access devices.
Tape: The device is a tape device and thus is sequential access. Tape devices are controlled using ioctl() calls.
Fifo: The device is a first-in-first out sequential access read-only or write-only device.
Aligned: Tells Bacula that the device is special Aligned Device. Please see the specific Aligned User's guide for more information.
Dedup: The device is a Deduplication device. The Storage Daemon will use the deduplication engine. Please see the specific Deduplication User's guide for more information.
Cloud: The device is a Cloud device. The Storage Daemon will use the Cloud to upload/download volumes. Please see the specific Cloud User's guide for more information.

The Device Type directive is not required, and if not specified, Bacula will attempt to guess what kind of device has been specified using the Archive Device specification supplied. There are several advantages to explicitly specifying the Device Type. First, on some systems, block and character devices have the same type. Secondly, if you explicitly specify the Device Type, the mount point need not be defined until the device is opened. This is the case with most removable devices such as USB that are mounted by the HAL daemon. If the Device Type is not explicitly specified, then the mount point must exist when the Storage daemon starts.

Media Type = <name-string>

The specified name-string names the type of media supported by this device, for example, "DLT7000". Media type names are arbitrary in that you set them to anything you want, but they must be known to the volume database to keep track of which storage daemons can read which volumes. In general, each different storage type should have a unique Media Type associated with it. The same name-string must appear in the appropriate Storage resource definition in the Director's configuration file.

Even though the names you assign are arbitrary (i.e. you choose the name you want), you should take care in specifying them because the Media Type is used to determine which storage device Bacula will select during restore. Thus you should probably use the same Media Type specification for all drives where the Media can be freely interchanged. This is not generally an issue if you have a single Storage daemon, but it is with multiple Storage daemons, especially if they have incompatible media.

For example, if you specify a Media Type of "DDS-4" then during the restore, Bacula will be able to choose any Storage Daemon that handles "DDS-4". If you have an autochanger, you might want to name the Media Type in a way that is unique to the autochanger, unless you wish to possibly use the Volumes in other drives. You should also ensure to have unique Media Type names if the Media is not compatible between drives. This specification is required for all devices.

In addition, if you are using disk storage, each Device resource will generally have a different mount point or directory. In order for Bacula to select the correct Device resource, each one must have a unique Media Type.

Autochanger = <yes|no>

If yes, this device belongs to an automatic tape changer, and you must specify an Autochanger resource that points to the Device resources. You must also specify a Changer Device. If the Autochanger directive is set to no (default), the volume must be manually changed. You should also have an identical directive to the Storage resource in the Director's configuration file so that when labeling tapes you are prompted for the slot.

Changer Device = <name-string>

The specified name-string must be the generic SCSI device name of the autochanger that corresponds to the normal read/write Archive Device specified in the Device resource. This generic SCSI device name should be specified if you have an autochanger or if you have a standard tape drive and want to use the Alert Command (see below). For example, on Linux systems, for an Archive Device name of /dev/nst0, you would specify /dev/sg0 for the Changer Device name. Depending on your exact configuration, and the number of autochangers or the type of autochanger, what you specify here can vary. This directive is optional. See the Using Autochangers chapter of this manual for more details of using this and the following autochanger directives.

Changer Command = <name-string>

The name-string specifies an external program to be called that will automatically change volumes as required by Bacula. Normally, this directive will be specified only in the AutoChanger resource, which is then used for all devices. However, you may also specify the different Changer Command in each Device resource. Most frequently, you will specify the Bacula supplied mtx-changer script as follows:

Changer Command = "/path/mtx-changer %c %o %S %a %d"

and you will install the mtx on your system (found in the depkgs release). An example of this command is in the default bacula-sd.conf file. For more details on the substitution characters that may be specified to configure your autochanger please see the Autochangers chapter of this manual. For FreeBSD users, you might want to see one of the several chio scripts in examples/autochangers.

Control Device = <name-string>

The control device is the SCSI control device that corresponds to the Archive Device. The correspondance can be done via the lssci -g command.

/opt/bacula# lsscsi -g
[1:0:0:0] tape    HP       Ultrium 4-SCSI   H61W  /dev/st0  /dev/sg0
[1:0:0:1] tape    HP       Ultrium 4-SCSI   H61W  /dev/st1  /dev/sg1
[1:0:0:2] mediumx HP       MSL G3 Series    E.00  -         /dev/sg2

Alert Command = <name-string>

The name-string specifies an external program to be called at the completion of each Job after the device is released. The purpose of this command is to check for Tape Alerts, which are present when something is wrong with your tape drive (at least for most modern tape drives). The same substitution characters that may be specified in the Changer Command may also be used in this string. For more information, please see the Autochangers chapter of this manual.

The directive in the Device resource can call the tapealert script that is installed in the scripts directory. It is defined as follows:

Device {
    Name = ...
    Archive Device = /dev/nst0
    Alert Command = "/opt/bacula/scripts/tapealert %l"
    Control Device = /dev/sg1 # must be SCSI ctl for /dev/nst0
    ...
}

Once the above mentioned two directives (Alert Command and Control Device) are in place in each of your Device resources, Bacula will check for tape alerts at two points:

After the Drive is used and it becomes idle.
After each read or write error on the drive.

At each of the above times, Bacula will call the new tapealert script, which uses the tapeinfo program. The tapeinfo utility is part of the apt sg3-utils and rpm sg3_utils packages. Then for each tape alert that Bacula finds for that drive, it will emit a Job message that is either INFO, WARNING, or FATAL depending on the designation in the Tape Alert published by the T10 Technical Committee on SCSI Storage Interfaces. For the specification, please see: http://www.t10.org/ftp/t10/document.02/02-142r0.pdf

Worm Command = <name-string>

The name-string specifies an external program to be called when loading a new volume. The purpose of this command is to check if the current tape is a WORMnoteWrite Once Read Many tape. The same substitution characters that may be specified in the Changer Command ay also be used in this string.

The directive in the Device resource can call the isworm script that is installed in the scripts directory. It is defined as follows:

Device {
  Name = ...
  Archive Device = /dev/nst0
  Worm Command = "/opt/bacula/scripts/isworm %l"
  Control Device = /dev/sg1 # must be SCSI ctl for /dev/nst0
  ...
}

Bacula will call the isworm script, which uses the tapeinfo and sdparm program.

Drive Index = <number>

The Drive Index that you specify is passed to the mtx-changer script and is thus passed to the mtx program. By default, the Drive Index is zero, so if you have only one drive in your autochanger, everything will work normally. However, if you have multiple drives, you must specify multiple Bacula Device resources (one for each drive). The first Device should have the Drive Index set to 0, and the second Device Resource should contain a Drive Index set to 1, and so on. This will then permit you to use two or more drives in your autochanger. As of Bacula version 1.38.0, using the Autochanger resource, Bacula will automatically ensure that only one drive at a time uses the autochanger script, so you no longer need locking scripts as in the past - the default mtx-changer script works for any number of drives.

Autoselect = <yes|no>

If this directive is set to yes (default), and the Device belongs to an autochanger, then when the Autochanger is referenced by the Director, this device can automatically be selected. If this directive is set to no, then the Device can only be referenced by directly using the Device name in the Director. This is useful for reserving a drive for something special such as a high priority backup or restore operations.

Maximum Concurrent Jobs = <num>

Maximum Concurrent Jobs is a directive that permits setting the maximum number of Jobs that can run concurrently on a specified Device. Using this directive, it is possible to have different Jobs using multiple drives, because when the Maximum Concurrent Jobs limit is reached, the Storage Daemon will start new Jobs on any other available compatible drive. This facilitates writing to multiple drives with multiple Jobs that all use the same Pool.

Maximum Changer Wait = <time>

This directive specifies the maximum time in seconds for Bacula to wait for an autochanger to change the volume. If this time is exceeded, Bacula will invalidate the Volume slot number stored in the catalog and try again. If no additional changer volumes exist, Bacula will ask the operator to intervene. The default is 5 minutes.

Maximum Rewind Wait = <time>

This directive specifies the maximum time in seconds for Bacula to wait for a rewind before timing out. If this time is exceeded, Bacula will cancel the job. The default is 5 minutes.

Maximum Open Wait = <time>

This directive specifies the maximum time in seconds that Bacula will wait for a device that is busy. The default is 5 minutes. If the device cannot be obtained, the current Job will be terminated in error. Bacula will re-attempt to open the drive the next time a Job starts that needs the the drive.

Always Open = <yes|no>

If yes (default), Bacula will always keep the device open unless specifically unmounted by the Console program. This permits Bacula to ensure that the tape drive is always available, and properly positioned. If you set AlwaysOpen to no, Bacula will only open the drive when necessary, and at the end of the Job if no other Jobs are using the drive, it will be freed. The next time Bacula wants to append to a tape on a drive that was freed, Bacula will rewind the tape and position it to the end. To avoid unnecessary tape positioning and to minimize unnecessary operator intervention, it is highly recommended that Always Open = yes. This also ensures that the drive is available when Bacula needs it.

If you have Always Open = yes (recommended) and you want to use the drive for something else, simply use the unmount command in the Console program to release the drive. However, don't forget to remount the drive with mount when the drive is available or the next Bacula job will block.

For File storage, this directive is ignored. For a FIFO storage device, you must set this to no.

Please note that if you set this directive to no Bacula will release the tape drive between each job, and thus the next job will rewind the tape and position it to the end of the data. This can be a very time consuming operation. In addition, with this directive set to no, certain multiple drive autochanger operations will fail. We strongly recommend to keep Always Open set to yes

Volume Poll Interval = <time>

If the time specified on this directive is non-zero, after asking the operator to mount a new volume Bacula will periodically poll (or read) the drive at the specified interval to see if a new volume has been mounted. If the time interval is zero, no polling will occur. The default value is 5 mins. This directive can be useful if you want to avoid operator intervention via the console. Instead, the operator can simply remove the old volume and insert the requested one, and Bacula on the next poll will recognize the new tape and continue. Please be aware that if you set this interval too small, you may excessively wear your tape drive if the old tape remains in the drive, since Bacula will read it on each poll. This can be avoided by ejecting the tape using the Offline On Unmount and the Close on Poll directives. However, if you are using a Linux 2.6 kernel or other OSes such as FreeBSD or Solaris, the Offline On Unmount will leave the drive with no tape, and Bacula will not be able to properly open the drive and may fail the job. For more information on this problem, please see the description of Offline On Unmount subsection in the Tape Testing chapter of the Bacula Enterprise Problems Resolution guide.

Close on Poll = <yes|no>

If yes, Bacula close the device (equivalent to an unmount except no mount is required) and reopen it at each poll. Normally this is not too useful unless you have the Offline on Unmount directive set, in which case the drive will be taken offline preventing wear on the tape during any future polling. Once the operator inserts a new tape, Bacula will recognize the drive on the next poll and automatically continue with the backup. Please see above more more details.

Sync On Close = <yes|no>

If yes, Bacula will sync the device at the end of each job and when closing the device. Normally it might be useful if you store the data on network filesystems. The default value is no.

Maximum Open Wait = <time>

This directive specifies the maximum amount of time in seconds that Bacula will wait for a device that is busy. The default is 5 minutes. If the device cannot be obtained, the current Job will be terminated in error. Bacula will re-attempt to open the drive the next time a Job starts that needs the the drive.

Removable Media = <yes|no>

If yes, this device supports removable media (for example, tapes or CDs). If no, media cannot be removed (for example, an intermediate backup area on a hard disk). If Removable media is enabled on a File device (as opposed to a tape) the Storage daemon will assume that device may be something like a USB device that can be removed or a simply a removable harddisk. When attempting to open such a device, if the Volume is not found (for File devices, the Volume name is the same as the Filename), then the Storage daemon will search the entire device looking for likely Volume names, and for each one found, it will ask the Director if the Volume can be used. If so, the Storage daemon will use the first such Volume found. Thus it acts somewhat like a tape drive - if the correct Volume is not found, it looks at what actually is found, and if it is an appendable Volume, it will use it.

If the removable medium is not automatically mounted (e.g. udev), then you might consider using additional Storage daemon device directives such as Requires Mount, Mount Point, Mount Command, and Unmount Command, all of which can be used in conjunction with Removable Media.

Random Access = <yes|no>

If yes, the archive device is assumed to be a random access medium which supports the lseek (or lseek64 if Largefile is enabled during configuration) facility. This should be set to yes for all file systems such as USB, and fixed files. It should be set to no for non-random access devices such as tapes and named pipes.

Requires Mount = <yes|no>

When this directive is enabled, the Storage daemon will submit a Mount Command before attempting to open the device. You must set this directive to yes for removable file systems such as USB devices that are not automatically mounted by the operating system when plugged in or opened by Bacula. It should be set to no for all other devices such as tapes and fixed filesystems. It should also be set to no for any removable device that is automatically mounted by the operating system when opened (e.g. USB devices mounted by udev or hotplug). This directive indicates if the device requires to be mounted using the Mount Command. To be able to write devices need a mount, the following directives must also be defined: Mount Point, Mount Command, and Unmount Command.

Mount Point = <directory>

Directory where the device can be mounted. This directive is used only for devices that have Requires Mount enabled such as USB file devices.

Mount Command = <name-string>

This directive specifies the command that must be executed to mount devices such as many USB devices. Before the command is executed, %a is replaced with the Archive Device, and %m with the Mount Point.

See the Edit Codes section below for more details of the editing codes that can be used in this directive.

If you need to specify multiple commands, create a shell script.

Unmount Command = <name-string>

This directive specifies the command that must be executed to unmount devices such as many USB devices. Before the command is executed, %a is replaced with the Archive Device, and %m with the Mount Point.

Most frequently, you will define it as follows:

Unmount Command = "/bin/umount %m"

See the Edit Codes section below for more details of the editing codes that can be used in this directive.

If you need to specify multiple commands, create a shell script.

Block Checksum = <yes|no>

You may turn off the Block Checksum (CRC32) code that Bacula uses when writing blocks to a Volume. Doing so can reduce the Storage daemon CPU usage slightly. It will also permit Bacula to read a Volume that has corrupted data.

The default is yes - i.e. the checksum is computed on write and checked on read.

We do not recommend to turn this off particularly on older tape drives or for disk Volumes where doing so may allow corrupted data to go undetected.

Minimum block size = <size-in-bytes>

On most modern tape drives, you will not need or want to specify this directive, and if you do so, it will be to make Bacula use fixed block sizes. This statement applies only to non-random access devices (e.g. tape drives). Blocks written by the storage daemon to a non-random archive device will never be smaller than the given size-in-bytes. The Storage daemon will attempt to efficiently fill blocks with data received from active sessions but will, if necessary, add padding to a block to achieve the required minimum size.

To force the block size to be fixed, as is the case for some non-random access devices (tape drives), set the Minimum block size and the Maximum block size to the same value (zero included). The default is that both the minimum and maximum block size are zero and the default block size is 64,512 bytes.

For example, suppose you want a fixed block size of 100K bytes, then you would specify:

Minimum block size = 100K
Maximum block size = 100K

Please note that if you specify a fixed block size as shown above, the tape drive must either be in variable block size mode, or if it is in fixed block size mode, the block size (generally defined by mt) must be identical to the size specified in Bacula - otherwise when you attempt to re-read your Volumes, you will get an error.

If you want the block size to be variable but with a 64K minimum and 200K maximum (and default as well), you would specify:

Minimum block size = 64K
Maximum blocksize = 256K

Maximum block size = <size-in-bytes>

On most modern tape drives, you will not need to specify this directive. If you do so, it will most likely be to reduce shoe-shine and improve performance on more modern LTO drives. The Storage daemon will always attempt to write blocks of the specified size-in-bytes to the archive device. As a consequence, this statement specifies both the default block size and the maximum block size. The size written never exceeds the given size-in-bytes. If adding data to a block would cause it to exceed the given maximum size, the block will be written to the archive device, and the new data will begin a new block.

If no value is specified or zero is specified, the Storage daemon will use a default block size of 64,512 bytes (126 * 512).

The maximum size-in-bytes possible is 4,000,000.

Hardware End of Medium = <yes|no>

If no, the archive device is not required to support end of medium ioctl request, and the storage daemon will use the forward space file function to find the end of the recorded data. If yes, the archive device must support the ioctl MTEOM call, which will position the tape to the end of the recorded data. In addition, your SCSI driver must keep track of the file number on the tape and report it back correctly by the MTIOCGET ioctl. Note, some SCSI drivers will correctly forward space to the end of the recorded data, but they do not keep track of the file number. On Linux machines, the SCSI driver has a fast-eod option, which if set will cause the driver to lose track of the file number. You should ensure that this option is always turned off using the mt program.

Default setting for Hardware End of Medium is yes. This function is used before appending to a tape to ensure that no previously written data is lost. We recommend if you have a non-standard or unusual tape drive that you use the btape program to test your drive to see whether or not it supports this function. All modern (after 1998) tape drives support this feature.

Fast Forward Space File = <yes|no>

If no, the archive device is not required to support keeping track of the file number (MTIOCGET ioctl) during forward space file. If yes, the archive device must support the ioctl MTFSF call, which virtually all drivers support, but in addition, your SCSI driver must keep track of the file number on the tape and report it back correctly by the MTIOCGET ioctl. Note, some SCSI drivers will correctly forward space, but they do not keep track of the file number or more seriously, they do not report end of medium.

Default setting for Fast Forward Space File is yes.

Use MTIOCGET = <yes|no>

If no, the operating system is not required to support keeping track of the file number and reporting it in the (MTIOCGET ioctl). The default is yes. If you must set this to No, Bacula will do the proper file position determination, but it is very unfortunate because it means that tape movement is very inefficient. Fortunately, this operation system deficiency seems to be the case only on a few *BSD systems. Operating systems known to work correctly are Solaris, Linux and FreeBSD.

BSF at EOM = <yes|no>

If no, the default, no special action is taken by Bacula with the End of Medium (end of tape) is reached because the tape will be positioned after the last EOF tape mark, and Bacula can append to the tape as desired. However, on some systems, such as FreeBSD, when Bacula reads the End of Medium (end of tape), the tape will be positioned after the second EOF tape mark (two successive EOF marks indicated End of Medium). If Bacula appends from that point, all the appended data will be lost. The solution for such systems is to specify BSF at EOM which causes Bacula to backspace over the second EOF mark. Determination of whether or not you need this directive is done using the test command in the btape program.

TWO EOF = <yes|no>

If yes, Bacula will write two end of file marks when terminating a tape - i.e. after the last job or at the end of the medium. If no, the default, Bacula will only write one end of file to terminate the tape.

Backward Space Record = <yes|no>

If yes, the archive device supports the MTBSR ioctl to backspace records. If no, this call is not used and the device must be rewound and advanced forward to the desired position. Default is yes for non random-access devices. This function if enabled is used at the end of a Volume after writing the end of file and any ANSI/IBM labels to determine whether or not the last block was written correctly. If you turn this function off, the test will not be done. This causes no harm as the re-read process is precautionary rather than required.

Backward Space File = <yes|no>

If yes, the archive device supports the MTBSF and MTBSF ioctls to backspace over an end of file mark and to the start of a file. If no, these calls are not used and the device must be rewound and advanced forward to the desired position. Default is yes for non random-access devices.

Forward Space Record = <yes|no>

If yes, the archive device must support the MTFSR ioctl to forward space over records. If no, data must be read in order to advance the position on the device. Default is yes for non random-access devices.

Forward Space File = <yes|no>

If yes, the archive device must support the MTFSF ioctl to forward space by file marks. If no, data must be read to advance the position on the device. Default is yes for non random-access devices.

Offline On Unmount = <yes|no>

The default for this directive is no. If yes the archive device must support the MTOFFL ioctl to rewind and take the volume offline. In this case, Bacula will issue the offline (eject) request before closing the device during the unmount command. If no Bacula will not attempt to offline the device before unmounting it. After an offline is issued, the cassette will be ejected thus requiring operator intervention to continue, and on some systems require an explicit load command to be issued (mt -f /dev/xxx load) before the system will recognize the tape. If you are using an autochanger, some devices require an offline to be issued prior to changing the volume. However, most devices do not and may get very confused.

If you are using a Linux 2.6 kernel or other OSes such as FreeBSD or Solaris, the Offline On Unmount will leave the drive with no tape, and Bacula will not be able to properly open the drive and may fail the job. For more information on this problem, please see the description of Offline On Unmount subsection in the Tape Testing chapter of the Bacula Enterprise Problems Resolution guide.

Maximum Volume Size = <size>

No more than size bytes will be written onto a given volume on the archive device. This directive is used mainly in testing Bacula to simulate a small Volume. It can also be useful if you wish to limit the size of a File Volume to say less than 2GB of data. In some rare cases of really antiquated tape drives that do not properly indicate when the end of a tape is reached during writing (though I have read about such drives, I have never personally encountered one). Please note, this directive is deprecated (being phased out) in favor of the Maximum Volume Bytes defined in the Director's configuration file.

Maximum File Size = <size>

No more than size bytes will be written into a given logical file on the volume. Once this size is reached, an end of file mark is written on the volume and subsequent data are written into the next file. Breaking long sequences of data blocks with file marks permits quicker positioning to the start of a given stream of data and can improve recovery from read errors on the volume. The default is one Gigabyte. This directive creates EOF marks only on tape media. However, regardless of the medium type (tape, disk, USB ...) each time a the Maximum File Size is exceeded, a record is put into the catalog database that permits seeking to that position on the medium for restore operations. If you set this to a small value (e.g. 1MB), you will generate lots of database records (JobMedia) and may significantly increase CPU/disk overhead.

If you are configuring an LTO-3 or LTO-4 tape, you probably will want to set the Maximum File Size to 2GB to avoid making the drive stop to write an EOF mark.

Note, this directive does not limit the size of Volumes that Bacula will create regardless of whether they are tape or disk volumes. It changes only the number of EOF marks on a tape and the number of block positioning records (see below) that are generated. If you want to limit the size of all Volumes for a particular device, use the Maximum Volume Size directive (above), or use the Maximum Volume Bytes directive in the Director's Pool resource, which does the same thing but on a Pool (Volume) basis.

Maximum File Index = <size>

Some data might include information about the actual position of a block in the data stream. This information is stored in the catalog inside the FileMedia table. By default, one index record will be created every 100MB of data. The index permits quicker positioning to the start of a given block in the Bacula Volume and can improve the Single Item Restore feature. If you set this to a small value (e.g. 1MB), you will generate lots of database records (FileMedia) and may significantly increase CPU/disk overhead.

Maximum Part Size = <size>

This directive allows one to specify the maximum size for each part. Smaller part sizes will reduce restore costs, but may require a small additional overhead to handle multiple parts. The maximum number of parts permitted in a Cloud Volume is 524,288. The maximum size of any given part is approximately 17.5TB.

Block Positioning = <yes|no>

This directive tells Bacula not to use block positioning when doing restores. Turning this directive off can cause Bacula to be extremely slow when restoring files. You might use this directive if you wrote your tapes with Bacula in variable block mode (the default), but your drive was in fixed block mode. The default is yes.

Maximum Network Buffer Size = <bytes>

where bytes specifies the initial network buffer size to use with the File daemon. This size will be adjusted down if it is too large until it is accepted by the OS. Please use care in setting this value since if it is too large, it will be trimmed by 512 bytes until the OS is happy, which may require a large number of system calls. The default value is 32,768 bytes. The maximum value is 1,000,000 bytes.

The default size was chosen to be relatively large but not too big in the case that you are transmitting data over Internet. It is clear that on a high speed local network, you can increase this number and improve performance. For example, some users have found that if you use a value of 65,536 bytes they get five to ten times the throughput. Larger values for most users don't seem to improve performance. If you are interested in improving your backup speeds, this is definitely a place to experiment. You will probably also want to make the corresponding change in each of your File daemons conf files.

Maximum Spool Size = <bytes>

where the bytes specify the maximum spool size for all jobs that are running. The default is no limit.

Maximum Job Spool Size = <bytes>

where the bytes specify the maximum spool size for any one job that is running. The default is no limit. This directive is implemented only in version 1.37 and later.

Spool Directory = <directory>

specifies the name of the directory to be used to store the spool files for this device. This directory is also used to store temporary part files when writing to a device that requires mount (USB). The default is to use the working directory.

Cloud Resource

The Cloud Storage Driver must be installed in the Bacula Storage Daemon Plugin Directory to be used.

Name = <Device-Name>

The name of the Cloud resource. This is the logical Cloud name, and may be any string up to 127 characters in length.

Description = <Text>

The description is used for display purposes as is the case with all resource.

Driver = <DriverName>

This defines which driver to use. It can be S3 or Azure. There is also a File driver, which is used mostly for testing.

Host Name = <Name>

This directive specifies the hostname to be used in the URL. Each Cloud service provider has a different and unique hostname. The maximum size is 255 characters and may contain a TCP port specification. This directive is not used with Azure cloud.

Bucket Name = <Name>

This directive specifies the bucket name that you wish to use on the Cloud service. This name is normally a unique name that you create on the cloud service that identifies where you want to place your Cloud Volumes. The maximum bucket name size is 255 characters.

Access Key = <String>

The access key is your unique user identifier given to you by your cloud service provider.

Secret Key = <String>

The secret key is the security key that was given to you by your cloud service provider. It is equivalent to a password.

Protocol = <HTTP | HTTPS>

The protocol defines the communications protocol to use with the cloud service provider. The two protocols currently supported are: HTTPS and HTTP. The default is HTTPS.

Uri Style = <VirtualHost | Path>

This directive specifies the URI style to use to communicate with the cloud service provider. The two Uri Styles currently supported are: VirtualHost and Path. The default is VirtualHost.

Truncate Cache = <Truncate-kw>

This directive specifies when Bacula should automatically remove (truncate) the local cache parts. Local cache parts can only be removed if they have been uploaded to the cloud. The currently implemented values are:

No: Do not remove cache. With this option you must manually delete the cache parts with a bconsole truncate cache command, or do so with an Admin Job that runs an truncate cache command. This is the default.
AfterUpload: Each part will be removed just after it is uploaded. Note, if this optionnoteNot yet implemented. is specified, all restores will require a download from the Cloud.
AtEndOfJob: With this optionnoteNote yet implemented/ , at the end of the Job, every part that has been uploaded to the Cloud will be removed (truncated).

Upload = <Upload-kw>

This directive specifies when local cache parts will be uploaded to the Cloud. The options are:

No: Do not upload cache parts. With this option you must manually upload the cache parts with a bconsole upload command, or do so with an Admin Job that runs an upload command. This is the default.
EachPart: With this option, each part will be uploaded when it is complete i.e. when the next part is created or at the end of the Job.
AtEndOfJob: With this optionnoteNot implemented yet. all parts that have not been previously uploaded will be uploaded at the end of the Job.

Maximum Concurrent Uploads = <number>

The default is 3, but by using this directive, you may set it to any value you want.

Maximum Concurrent Downloads = <number>

The default is 3, but by using this directive, you may set it to any value you want.

Maximum Upload Bandwidth = <speed>

The default is unlimited, but by using this directive, you may limit the upload bandwidth used globally by all devices referencing this Cloud resource.

Maximum Download Bandwidth = <speed>

The default is unlimited, but by using this directive, you may limit the download bandwidth used globally by all devices referencing this Cloud resource.

Region = <String>

The Cloud resource can be configured to use a specific endpoint within a region. This directive is required for AWS-V4 regions. ex: Region = "eu-central-1"

An example of a Cloud Resource might be:

Cloud {
  Name = S3Cloud
  Driver = "S3"
  HostName = "s3.amazonaws.com"
  BucketName = "BaculaVolumes"
  AccessKey = "BZIXAIS39DYNER5FZ"
  SecretKey = "beesheeg7iTe0Gaex7aedie4aWohfuewohGaa0"
  Protocol = HTTPS
  UriStyle = VirtualHost
  Truncate Cache = No
  Upload = EachPart
  Region = "us-east-1" 
  MaximumUploadBandwidth = 5MB/s
}

Transfer Priority = <High | Medium | Low>

When restoring directly a part from Glacier, this directive indicates the rehydration priority level. Values can be High, Medium or Low. Default is High. Those values match respectively Expeditive, Standard and Bulk transfers tiers within S3.

Transfer Retention = <time-period-specification>

This directive indicates the number of days S3 should keep the rehydrated part online. The minimum value is 1 day. The default is 5 days.

Edit Codes for Mount and Unmount Directives

Before submitting the Mount Command, Unmount Command, Write Part Command, or Free Space Command directives to the operating system, Bacula performs character substitution of the following characters:

%% = %
%a = Archive device name
%e = erase (set if cannot mount and first part)
%n = part number
%m = mount point
%v = last part name (i.e. filename)

Devices that require a mount (USB)

All the directives in this section are implemented only in Bacula version 1.37 and later and hence are available in version 1.38.6.

As of version 1.39.5, the directives “Requires Mount”, “Mount Point”, “Mount Command”, and “Unmount Command” apply to removable filesystems such as USB.

Requires Mount = <yes|no>

You must set this directive to yes for removable devices such as USB unless they are automounted, and to no for all other devices (tapes/files). This directive indicates if the device requires to be mounted to be read, and if it must be written in a special way. If it set, Mount Point, Mount Command, Unmount Command directives must also be defined.

Mount Point = <directory>

Directory where the device can be mounted.

Mount Command = <name-string>

Command that must be executed to mount the device. Before the command is executed, %a is replaced with the Archive Device, and %m with the Mount Point.

Most frequently, you will define it as follows:

Mount Command = "/bin/mount -t iso9660 -o ro %a %m"

For some media, you may need multiple commands. If so, it is recommended that you use a shell script instead of putting them all into the Mount Command. For example, instead of this:

Mount Command = "/usr/local/bin/mymount"

Where that script contains:

#!/bin/sh
ndasadmin enable -s 1 -o w
sleep 2
mount /dev/ndas-00323794-0p1 /backup

Similar consideration should be given to all other Command parameters.

Unmount Command = <name-string>

Command that must be executed to unmount the device. Before the command is executed, %a is replaced with the Archive Device, and %m with the Mount Point.

Most frequently, you will define it as follows:

Unmount Command = "/bin/umount %m"

If you need to specify multiple commands, create a shell script.