Autochanger Support

Bacula provides autochanger support for reading and writing tapes. In order to work with an autochanger, Bacula requires a number of things, each of which is explained in more detail after this list:

• A script that actually controls the autochanger according to commands sent by Bacula. We furnish such a script that works with mtx found in the depkgs distribution.

• That each Volume (tape) to be used must be defined in the Catalog and have a Slot number assigned to it so that Bacula knows where the Volume is in the autochanger. This is generally done with the label command, but can also done after the tape is labeled using the update slots command. See below for more details. You must pre-label the tapes manually before using them.

• Modifications to your Storage daemon's Device configuration resource to identify that the device is a changer, as well as a few other parameters.

• You should also modify your Storage resource definition in the Director's configuration file so that you are automatically prompted for the Slot when labeling a Volume.

• You need to ensure that your Storage daemon (if not running as root) has access permissions to both the tape drive and the control device.

• You need to have Autochanger = yes in your Storage resource in your bacula-dir.conf file so that you will be prompted for the slot number when you label Volumes.

In version 1.37 and later, there is a new Autochanger resource that permits you to group Device resources thus creating a multi-drive autochanger. If you have an autochanger, you must use this new resource.

Bacula uses its own mtx-changer script to interface with a program that actually does the tape changing. Thus in principle, mtx-changer can be adapted to function with any autochanger program, or you can call any other script or program. The current version of mtx-changer works with the mtx program. However, FreeBSD users have provided a script in the examples/autochangers directory that allows Bacula to use the chio program.

Bacula also supports autochangers with barcode readers. This support includes two Console commands: label barcodes and update slots. For more details on these commands, see the “Barcode Support” section below.

Current Bacula autochanger support does not include cleaning, stackers, or silos. Stackers and silos are not supported because Bacula expects to be able to access the slots randomly. However, if you are very careful to setup Bacula to access the Volumes in the autochanger sequentially, you may be able to make Bacula work with stackers (gravity feed and such).

Support for multi-drive autochangers requires the Autochanger resource introduced in version 1.37. This resource is also recommended for single drive autochangers.

In principle, if mtx will operate your changer correctly, then it is just a question of adapting the mtx-changer script (or selecting one already adapted) for proper interfacing. You can find a list of autochangers supported by mtx at the following link: mtx.opensource-sw.net/compatibility.php. The home page for the mtx project can be found at: mtx.opensource-sw.net/.

Note, we have feedback from some users that there are certain incompatibilities between the Linux kernel and mtx. For example between kernel 2.6.18-8.1.8.el5 of CentOS and RedHat and version 1.3.10 and 1.3.11 of mtx. This was fixed by upgrading to a version 2.6.22 kernel.

In addition, apparently certain versions of mtx, for example, version 1.3.11 limit the number of slots to a maximum of 64. The solution was to use version 1.3.10.

If you are having troubles, please use the auto command in the btape program to test the functioning of your autochanger with Bacula. When Bacula is running, please remember that for many distributions (e.g. FreeBSD, Debian, ...) the Storage daemon runs as bacula.tape rather than root.root, so you will need to ensure that the Storage daemon has sufficient permissions to access the autochanger.

Some users have reported that the the Storage daemon blocks under certain circumstances in trying to mount a volume on a drive that has a different volume loaded. As best we can determine, this is simply a matter of waiting a bit. The drive was previously in use writing a Volume, and sometimes the drive will remain BLOCKED for a good deal of time (up to 7 minutes on a slow drive) waiting for the cassette to rewind and to unload before the drive can be used with a different Volume.

Knowing What SCSI Devices You Have

Under Linux, you can

cat /proc/scsi/scsi

to see what SCSI devices you have available. You can also:

cat /proc/scsi/sg/device_hdr /proc/scsi/sg/devices

to find out how to specify their control address (/dev/sg0 for the first, /dev/sg1 for the second, ...) on the Changer Device = Bacula directive.

You can also use the excellent lsscsi tool.

$ lsscsi -g
 [1:0:2:0]    tape    SEAGATE  ULTRIUM06242-XXX 1619  /dev/st0  /dev/sg9
 [1:0:14:0]   mediumx STK      L180             0315  /dev/sch0 /dev/sg10
 [2:0:3:0]    tape    HP       Ultrium 3-SCSI   G24S  /dev/st1  /dev/sg11
 [3:0:0:0]    enclosu HP       A6255A           HP04  -         /dev/sg3
 [3:0:1:0]    disk    HP 36.4G ST336753FC       HP00  /dev/sdd  /dev/sg4

For more detailed information on what SCSI devices you have please see the Linux SCSI Tricks section of the Tape Testing chapter of the Bacula Enterprise Problems Resolution guide.

Under FreeBSD, you can use:

camcontrol devlist

To list the SCSI devices as well as the /dev/passn that you will use on the Bacula Changer Device = directive.

Please check that your Storage daemon has permission to access this device.

The following tip for FreeBSD users comes from Danny Butroyd: on reboot Bacula will NOT have permission to control the device /dev/pass0 (assuming this is your changer device). To get around this just edit the /etc/devfs.conf file and add the following to the bottom:

own     pass0   root:bacula
perm    pass0   0666
own     nsa0.0  root:bacula
perm    nsa0.0  0666

This gives the bacula group permission to write to the nsa0.0 device too just to be on the safe side. To bring these changes into effect just run:

/etc/rc.d/devfs restart

Basically this will stop you having to manually change permissions on these devices to make Bacula work when operating the AutoChanger after a reboot.

Example Scripts

Please read the sections below so that you understand how autochangers work with Bacula. Although we supply a default mtx-changer script, your autochanger may require some additional changes. If you want to see examples of configuration files and scripts, please look in the <bacula-src>/examples/devices directory where you will find an example HP-autoloader.conf Bacula Device resource, and several mtx-changer scripts that have been modified to work with different autochangers.

Slots

To properly address autochangers, Bacula must know which Volume is in each slot of the autochanger. Slots are where the changer cartridges reside when not loaded into the drive. Bacula numbers these slots from one to the number of cartridges contained in the autochanger.

Bacula will not automatically use a Volume in your autochanger unless it is labeled and the slot number is stored in the catalog and the Volume is marked as InChanger. This is because it must know where each volume is (slot) to be able to load the volume.

For each Volume in your changer, you will, using the Console program, assign a slot. This information is kept in Bacula's catalog database along with the other data for the volume. If no slot is given, or the slot is set to zero, Bacula will not attempt to use the autochanger even if all the necessary configuration records are present. When doing a mount command on an autochanger, you must specify which slot you want mounted. If the drive is loaded with a tape from another slot, it will unload it and load the correct tape, but normally, no tape will be loaded because an unmount command causes Bacula to unload the tape in the drive.

You can check if the Slot number and InChanger flag are set by doing a:

list Volumes

in the Console program.

Multiple Devices

Some autochangers have more than one read/write device (drive). The new Autochanger resource introduced in version 1.37 permits you to group Device resources, where each device represents a drive. The Director may still reference the Devices (drives) directly, but doing so, bypasses the proper functioning of the drives together. Instead, the Director (in the Storage resource) should reference the Autochanger resource name. Doing so permits the Storage daemon to ensure that only one drive uses the mtx-changer script at a time, and also that two drives don't reference the same Volume.

Multi-drive requires the use of the Drive Index directive in the Device resource of the Storage daemon's configuration file. Drive numbers or the Device Index are numbered beginning at zero (0), which is the default. To use the second Drive in an autochanger, you need to define a second Device resource and set the Drive Index to 1 for that device. In general, the second device will have the same Changer Device (control channel) as the first drive, but a different Archive Device.

As a default, Bacula jobs will prefer to write to a Volume that is already mounted. If you have a multiple drive autochanger and you want Bacula to write to more than one Volume in the same Pool at the same time, you will need to set Prefer Mounted Volumes in the Directors Job resource to no. This will cause the Storage daemon to maximize the use of drives.

Device Configuration Records

Configuration of autochangers within Bacula is done in the Device resource of the Storage daemon. Four records: Autochanger, Changer Device, Changer Command, and Maximum Changer Wait control how Bacula uses the autochanger.

These four records, permitted in Device resources, are described in detail below. Note, however, that the Changer Device and the Changer Command directives are not needed in the Device resource if they are present in the Autochanger resource.

Autochanger = <yes|no>

The Autochanger record specifies that the current device is or is not an autochanger. The default is no.

Changer Device = <device-name>

In addition to the Archive Device name, you must specify a Changer Device name. This is because most autochangers are controlled through a different device than is used for reading and writing the cartridges. For example, on Linux, one normally uses the generic SCSI interface for controlling the autochanger, but the standard SCSI interface for reading and writing the tapes. On Linux, for the Archive Device = /dev/nst0, you would typically have Changer Device = /dev/sg0. Note, some of the more advanced autochangers will locate the changer device on /dev/sg1. Such devices typically have several drives and a large number of tapes.

On FreeBSD systems, the changer device will typically be on /dev/pass0 through /dev/passn.

On Solaris, the changer device will typically be some file under /dev/rdsk.

Please ensure that your Storage daemon has permission to access this device.

Changer Command = <command>

This record is used to specify the external program to call and what arguments to pass to it. The command is assumed to be a standard program or shell script that can be executed by the operating system. This command is invoked each time that Bacula wishes to manipulate the autochanger. The following substitutions are made in the command before it is sent to the operating system for execution:

%% = %
%a = archive device name
%c = changer device name
%d = changer drive index base 0
%f = Client's name
%j = Job name
%o = command  (loaded, load, or unload)
%s = Slot base 0
%S = Slot base 1
%v = Volume name

An actual example for using mtx with the mtx-changer script (part of the Bacula distribution) is:

Changer Command = "/opt/bacula/scripts/mtx-changer %c %o %S %a %d"

Where you will need to adapt the /opt/bacula to be the actual path on your system where the mtx-changer script resides. Details of the three commands currently used by Bacula (loaded, load, unload) as well as the output expected by Bacula are give in the Bacula Autochanger Interface section below.

Maximum Changer Wait = <time>

This record is used to define the maximum amount of time that Bacula will wait for an autoloader to respond to a command (e.g. load). The default is set to 120 seconds. If you have a slow autoloader you may want to set it longer.

If the autoloader program fails to respond in this time, it will be killed and Bacula will request operator intervention.

Drive Index = <number>

This record allows you to tell Bacula to use the second or subsequent drive in an autochanger with multiple drives. Since the drives are numbered from zero, the second drive is defined by

Drive Index = 1

To use the second drive, you need a second Device resource definition in the Bacula configuration file. See the Multiple Drive section above in this chapter for more information.

In addition, for proper functioning of the Autochanger, you must define an Autochanger resource.