Section 6.4. Advanced Features

6.4. Advanced Features

In addition to being able to back up and restore files over the network, Bacula has many advanced features, a brief summary of which follows. Complete information on these features can be found in the Bacula documentation at http://www.bacula.org.

6.4.1. Bare-Metal Recovery

The advanced feature of greatest importance to most users is the ability to do bare-metal recovery of machines using Bacula. Bacula provides tools for creating customized bootable CD images that can be used for recovery. This support is fairly complete for Linux. It is a largely manual process on Solaris and FreeBSD. A very different, but fairly efficient, process exists for Windows recovery. At this time, bare-metal restore is not possible for Macintosh clients.

Bacula can be run from a bootable rescue CD-ROM for Linux. This CD-ROM contains a minimal copy of the machine's OS, a statically linked Bacula file daemon, and configuration files describing the machine for which the rescue CD-ROM was created.

The basic strategy of the rescue CD is to boot, repartition the hard drive as described on the CD-ROM, bring the machine back onto the network, and then restore the files for that machine back onto the newly formatted drive. The process of building the CD-ROM creates scripts that handle network configuration, disk partitioning, and writing the appropriate boot record (using grub or lilo). A single CD-ROM can be used for multiple clients as long as each client has its own configuration directory on the CD-ROM.

As a last resort, if you have a suitable rescue disk and have backed up all the rescue files generated by the CD creation script, you should be able to create a usable Bacula restore CD even if the client has been lost.

Solaris and FreeBSD follow similar patterns, although without the benefit of a dedicated recovery CD: boot from rescue or installation media, format the disks appropriately, bring up the network, install a statically linked file daemon, and then restore all backup files. Rudimentary automated script creation support exists on Solaris, although not to the same degree as it does on Linux.

Because building the rescue CD-ROM requires a separate manual process for each client, some Linux users may find it easier to use Knoppix instead (see Chapter 11). Knoppix provides a run-from-CD Linux distribution that includes bacula-fd. If Knoppix is used, setting up the network and then partitioning and formatting the disk is a manual process, but once the user has done that, the restoration proceeds precisely as it does for any other Bacula restore job. The boot record creation must also be done by hand in this case.

Windows relies on the user having run ntbackup to save a copy of critical Windows system files prior to the Bacula backup (see Chapter 3); this can be implemented with client-side hooks, as described later in this section. In this case, install a minimal Windows system first, then install the Bacula client and restore the backup including the output of ntbackup, and finally restore the system identity from the ntbackup image.

Windows XP users have it a little easier: they can create a BartPE rescue CD that includes a Bacula client. PEBuilder, the program that generates this image can be found at http://www.nu2.nu/pebuilder/; it assists in creating a bootable Windows rescue CD. PEBuilder requires access to Windows installation media to supply the necessary Windows files.

6.4.2. Backup Traffic and Storage Encryption

Frequently, you have to back up machines over a network that can't be trusted. The most obvious case is backup over a WAN (or the Internet). Corporate compliance regulations may specify that such traffic must be encrypted in transit.

It has always been possible to tunnel Bacula using stunnel or ssh port-forwarding. This requires no Bacula configuration support other than pointing the various daemons at the proper ports; authentication issues are handled by stunnel or ssh.

In recent versions, Bacula includes TLS support. With TLS support, you can ensure that traffic between the file daemon, the director, and the storage daemon is not transmitted in clear text. Additionally, TLS provides another layer of authentication on top of the requirement for matching passwords in the daemons.

Bacula can use self-signed certificates created with a locally deployed certificate authority (CA). The Bacula manual discusses sources of information about creating a local CA. All the usual caveats about self-signed certificates apply to Bacula. However, the user does not know whether the certificate has been signed by a trusted CA, so as long as the system administrator trusts his own ability to sign and deploy certificates, there is little benefit to paying for a signed certificate for an internal backup infrastructure. If backup is being offered as a managed service, on the other hand, it may well be worth the trouble and expense to acquire a properly signed SSL certificate for the backup service.

Bacula 1.39 and later supports encryption of the actual stored data to prevent access to backup contents by unauthorized personnel. This is in addition to the traffic between Bacula components. Large organizations are beginning to require that backup data be encrypted when transferred and stored. However, it's equally useful for the casual user backing up to DVD-R, who would prefer that the thief who steals his backpack containing the backup DVD not also get all his personal data.

The encryption code uses TLS certificates to manage the encryption keys that secure the data. This allows you to optionally specify multiple master decryption keys for escrow purposes, helping to protect against data loss in case a single private key is lost. Encryption can be enabled on a client-by-client basis.

6.4.3. Python Script Support

Bacula includes support to run a script before or after a given backup job. This allows a job to invoke an external program, which can then communicate with Bacula via its standard output. Although not a particularly sophisticated tool, this can be effective for ensuring that all buffers are flushed before a backup run begins.

Recent versions of Bacula also support an embedded Python interpreter in the director, file daemon, and storage daemon. A Python script, running inside the Bacula director's address space, can register to handle any of a number of actions. One common use for this is to change job parameters on the fly in reaction to the environment: for instance, if a new volume name is required, the Python support can be employed to create it at runtime, perhaps incrementing a counter to generate the logical next volume name in a series. The embedded Python interpreter has full knowledge of Bacula's internal state; this gives it much more flexibility than the external-program approach, in which only a few pieces of information can be passed as parameters to the external program. An embedded interpreter in the file daemon allows for very sophisticated client-side job pre- and post-processing.

6.4.4. Client Script Support

Bacula allows the user to specify, as part of a job, a program that runs on the client before or after the backup occurs. This is particularly useful for backing up database servers. For example, the user may request that the database create (using its own maintenance tools) a flat-file snapshot of its state just before the job executes. After the backup is finished, the file dump can be removed to conserve space on the client.

Another common use of client-side hooks is to use ntbackup to dump essential Windows configurations to a flat file that Bacula can restore.

6.4.5. Autochanger Support

Bacula interacts quite well with SCSI tape autochangers; in general, it uses the mtx command to manipulate the autochanger but wraps this command inside Bacula's own replaceable mtx-changer script. You can edit this script to customize mtx in your environment.

The autochanger can label new volumes it finds, creating volume names based on a pattern, a barcode reader, or a Python script, and automatically mounting them. For large backups, where a single job spans multiple tapes, autochanger support makes it possible for Bacula to use as many tapes as it needs without requiring human intervention. It also automates the restore process because Bacula can request the correct tape from the autochanger in order to retrieve the volume with the desired backups.

For most purposes, the supplied script is adequate and contains hints for small site-specific customizations. For instance, it can easily be modified to simulate label barcodes for autochangers that do not support barcode tape identification.

However, mtx-changer is a much more generally applicable solution; it simply defines Bacula's interface to the autochanger and therefore can be replaced in its entirety. This allows Bacula to interact with devices that are radically different from SCSI autochangers, with no changes required to the core Bacula code.

One example of this is support for mainframe tape silos: in these environments, mtx-changer has been replaced with a network client and server so that Bacula can request tapes from a tape management system running under z/VM, despite the fact that the tape silo does not have anything like a SCSI autochanger interface.

6.4.6. ANSI and IBM Tape Labels

Bacula, as of version 1.38, can use standard ANSI and IBM tape labels. This enables Bacula to coexist peacefully with other enterprise backup systems and share a unified tape catalog with them.

6.4.7. File-Based Intrusion Detection

One of the simplest ways to monitor the status of a host is to watch for filesystem changes. Bacula is already watching the filesystem and storing information about it in the catalog, including filenames, sizes, permissions, and checksums. By periodically running a job of type verify against the catalog, you can use Bacula as a simple intrusion detection system, along the lines of tripwire.