Category Archives: Bacula Planet

Baculum – official rpm and deb package repositories

We have prepared the Baculum official packages and repositories for the following distributions:

– CentOS

– Fedora

– Debian

– Ubuntu

The repositories contain the latest version of Baculum (7.4.0-1) and they will be updated after each new version release.

Full installation instructions for the rpm and deb packages from the official repositories are available in the Bacula Console documentation chapter here:

http://www.bacula.org/7.4.x-manuals/en/console/Baculum_WebGUI_Tool.html

A baculum online demo is hosted here:

http://baculum.baculus.pl/

Login : admin

Password : admin

The demo environment is recreated from scratch each two hours.

 

Baculum – Current and upcoming features

1. Baculum Ubuntu/Debian packages

Preparing Baculum to use from bacula-gui source archive requires going
through a few steps as manual web server configuration, PHP installation
with dependencies, setting up authentication to Baculum. These actions
may need a few attempts and may take a little time.

For this reason, we have prepared Baculum binary packages for
Ubuntu/Debian distributions. Packages are available in Lauchpad.net
service here:

https://launchpad.net/~ganiuszka/+archive/ubuntu/baculum

Please note that it is an unofficial repository nevertheless the repository
is maintained by Baculum author.

2. Baculum online demo version

You will find the Baculum online demo version available here:

http://baculum.baculus.pl

login: admin, password: admin

The running version of the demo is based on a git snapshot that comes from the Bacula GUI repository and is rebuilt on a hourly basis (database, volumes, etc.)

3. Upcoming features

Within almost one year, a lot of new features have been introduced into Baculum (available from Bacula GUI repository)

Here below are listed the major changes:

– Stability and performance improvements
– Jobs graphs
– Running jobs are refreshed in real time
– Verify Jobs support
– Execute action on multiple volumes (prune, purge, delete) and jobs (delete) at a time
– Polish translation
– Enabled support to run Baculum in web server document root sub-directory

vchanger release 1.0.0 is out

Vchanger implements the Bacula Autochanger Interface to provide a virtual disk autochanger targeting the use of removable disk drives, such as USB external drives and RDX cartridge systems, as storage media. As compared to Bacula’s native virtual disk autochanger, vchanger has the following advantages:

– May simultaneously use volume files on an unlimited number of different filesystems, any of which may be simultaneously mounted.
– Simultaneously mounted storage space can be easily scaled by adding additional filesystems, requiring no change in Bacula’s configuration
– All volumes on all filesystems have the same Media Type and can be moved between filesystems arbitrarily with no need for updating volume information in the catalog and requiring no configuration changes.
– Filesystems can be specified by UUID, allowing any type of automounting to be used and filesystems to be mounted at arbitrary paths
– All filesystems needed for a restore can be mounted simultaneously, eliminating the need for operator intervention when volumes needed for a restore are spread across multiple filesystems.

Additional features include:

– Udev rule generator and scripts provided to implement automounting via udev
– Automatically issues an ‘update slots’ command via bconsole when needed
– Automatically issues a ‘label barcodes’ command when new volume files are created
– Allows plug-n-play attachment and detachment of removable drives
– Extended command LISTMAGS allows listing assigned filesystems and their status
– Extended command CREATEVOLS allows adding and automatically labeling volume files at any time

Source code, documentation, and RPM packages for RHEL/Centos 6 and 7 are available from SourceForge at http://sourceforge.net/projects/vchanger/files/?source=navbar.

A vchanger HowTo is available at http://sourceforge.net/projects/vchanger/files/vchangerHowto.html/download.


 

Release Notes for vchanger 1.0.0 2015-04-14

Release 1.0.0

This is a major release adding several features and a change in the
structure of magazines and the way volume files are “loaded” into
virtual drives. These changes allow for an unlimited and variable
number of volume files on each magazine, and allow adding and deleting
volumes to/from magazines, as well as moving volume files from one
magazine to another. Virtual drives are now symlinks dynamically
created by the LOAD command. An unlimited number of virtual drives per
autochanger is supported without requiring a vchanger configuration
change. The number of virtual drives used is determined solely by the
Device resources defined in bacula-sd.conf.

Also, vchanger will now automatically issue ‘update slots’ and
‘label barcodes’ commands to Bacula via bconsole when it detects a
change in the availability of any of its defined magazines or when
volume files are created with the CREATEVOLS command. Together with
an automounting mechanism, this makes the attachment and detachment
of removable drives a plug-n-play operation.

To aid in using removable drives on systems having udev, vchanger now
includes a udev rules generator and helper scripts to enable the
automatic mounting of magazine filesystems triggered by udev hotplug
events. The advantage to using this automounting method, as opposed to
autofs or window manager automounters using dbus, etc., is that these
scripts will invoke vchanger with a new REFRESH command that will issue
an ‘update slots’ command via bconsole whenever removable drives
are attached or detached.

Change Summary:

The concept of a ‘magazine’ has changed. A magazine remains a
directory, usually the mountpoint of a filesystem, however no metadata
files are now stored on the magazines and volume files are not renamed
when loading and unloading virtual drives. There is now no requirement
that all magazines have the same number of volumes, and volume files
may have any filename. New volume files can be created on a magazine
at any time. A new extended interface command, CREATEVOLS, has been
implemented for this purpose. A magazine is now simply a filesystem
(or directory) containing some variable number of volume files. Any
directory containing volume files can be used as a magazine in
vchanger, including for example volumes created using Bacula’s
built-in disk storage handling. Volume files may be deleted from
magazines or moved between magazines. The only caveat is that the
volume’s Media Type must match that of the autochanger’s Storage
resource.

Virtual drives are now simply a symlink in the autochanger’s work
directory. The drive number is the name of the symlink. For example,
if the autochanger’s work directory is /var/spool/vchanger/changer1,
then virtual drive 0 is a symlink at the path
/var/spool/vchanger/changer1/0. The symlink’s path is then specified as
the Archive Device in the Device resource defined in bacula-sd.conf for
the autochanger’s drive 0. Vchanger implements the LOAD command by
creating this symlink pointing at the volume file mapped to the slot
requested to be loaded. A subsequent UNLOAD command deletes the
symlink. In previous versions, a LOAD created a symlink pointing to the
mountpoint of the magazine and then renamed the volume file on the
magazine to ‘drive0’, ‘drive1’, etc. This was because the original
design criteria, (dating to before the release of Bacula 2.0.0),
required that vchanger run on Windows Server 2003, which did not have
the capability of file-level symlinks. However, file-level symlinks is
a much more robust method, handling any “out of space” conditions in a
clean, expected way. For that reason, use of vchanger on versions of
Windows without file-level symlinks is no longer supported.

An autochanger’s magazines are assigned in its vchanger configuration
file. An unlimited number of magazines is supported and the storage space used
by an autochanger can be scaled at any time by simply adding additional
magazines and creating volume files on them. Expansion of the storage
space does not require any change to Bacula’s configuration. Any
combination of one or more of the assigned magazines can be attached
(mounted) at any time.

When a magazine is attached or detached there is of course a change in
which volumes are available for reading and writing. Bacula must be
instructed to update its database to reflect the change. This is
analogous to swapping tapes in a tape autochanger library. Bacula has a
bconsole command used for this purpose, the ‘update slots’ command. In
general, one would insert or remove tapes and then issue an ‘update slots’
command in bconsole to inform Bacula of the change. With vchanger,
attaching or detaching a magazine also requires that the ‘update slots’
command be issued, however vchanger now detects changes to the currently
available volume files and automatically issues the ‘update slots’
command when needed. This allows swapping magazines to be a true
plug-n-play operation.

The scripts directory in the vchanger source tree contains a script to
generate the udev rules needed to automatically mount the magazines
filesystems defined in the vchanger configuration file. These rules will
cause udev to launch scripts, also included in the scripts directory, to
handle a “hot add” event by mounting the magazine filesystem and invoking
vchanger with the REFRESH command to issue an ‘update slots’ command to
Bacula. Likewise, a “hot delete” event will launch a script to unmount
the filesystem and again invoke vchanger with the REFRESH command.

If vchanger is compiled on a system supporting udev, then libudev will be
used to determine the device node of magazine partitions specified by
UUID. If compiled on a system without udev, the older method of using
libblkid and libuuid will be used if available. For Windows builds,
win32 API functions are used to map filesystem UUID to device node. If
the getmntent() function is not available on the target system for
determining a filesystem’s mountpoint, then vchanger will use the
getfsstat() function, allowing magazines to be specified by UUID on many
BSD and OSX systems. A build for a minimal system having neither libudev
nor libblkid will succeed, however specifying magazines by UUID will not
function and result in an error, meaning that such minimal systems must
only specify magazines by directory path. These changes should alleviate
many of the problems people have had in the past building vchanger for
non-Linux systems.

Bugs Fixed:
5 Compile errors on Debian or Ubuntu
6 Broken libblkid returns wrong device for UUID
7 Limitation on number of virtual drives
8 Compile errors under Solaris 10

 

Baculum Overview

Baculum is a Bacula web based interface, which enables several Bacula administration functions.
These include:
  •  Running Bacula jobs (backup, restore, verify…)
  •  Monitor Bacula services
  •  Bacula console available via web interface
  •  Support for customised and restricted consoles (Console ACL functionality)
  •  Multiple Directors support
  •  Volumes management including labeling new volumes
  •  User friendly graphs Basic storage daemon operations on volumes (mount, unmount, release actions)
  •  Easy in use configuration and restore wizards
  •  Many other features…
Baculum general operating system environment requirements

The Baculum installation should have the following components:

  • Web Server – with mod_rewrite module loaded. Baculum has been tested on Apache HTTP Server and Lighttpd.
  • PHP 5.3 or higher – as web server module or as FastCGI, with the following modules installed:

* PDO PHP support – depending on your catalog database: PDO PostgreSQL, PDO MySQL or PDO SQLite.
Note: If Bacula uses MySQL catalog backend, Baculum requires to install MySQL php native drivers. (often called php-msqlnd, and not php-msql)
* BCMath PHP module.
* cURL PHP module.
* MB String PHP module.
* JSON PHP module.

  • Bconsole – configured Bacula text based console
  • Access to Bacula catalog database – A computer with a Baculum installation should be able to connect to the Bacula catalog database

There is no need to install Baculum on the server with a Bacula Catalog database because Baculum can communicate with the Bacula database located on a remote server.

Above requirements are validated during Baculum’s initial startup. You will be informed if any components are missing in the installation environment.

Installation

Detailed information about manual installation of Baculum is available in the Baculum INSTALL file located in bacula-gui tar archive.