Section 6.5. Future Directions

6.5. Future Directions

Bacula's major long-term goal is to become a competitive enterprise-class backup system. Some enhancements, particularly to search speed in large catalogs, are necessary before it will be on the same footing with commercial enterprise backup systems.

Usability enhancements are also vital: chief among them is construction of a more complete and maintainable GUI for Bacula.

The list of in-progress Bacula projects can be found at http://bacula.cvs.sourceforge. net/bacula/bacula/projects?view=markup and is updated every six months or so. As of this writing, the top five unfinished projects are those detailed in the following sections (by the time this book is published, some or all of these may be present in the mainline Bacula code).

6.5.1. Pool Migration

This project aims to implement migration of stored data from one pool to another, which allows implementation of tiered storage; for example, backups can initially occur to disk, and then migrate to other storage media on a controlled schedule.

Migration of stored data has two benefits. First, by allowing optional use of the target media, pool migration can better use storage media. That is, it acts as a sophisticated spooling facility, which is especially important when using write-once media; in that case, it's best to use as much capacity on each volume as possible.

The second is convenience: although tape or optical storage may be the desired long-term storage medium, the most common use of Bacula is restoration of a single recently deleted file or directory. It is much more convenient if recent backups are maintained on disk so that the user doesn't have to search for backup media. However, the amount of disk space required can be kept reasonably small because backups are automatically migrated onto archival media according to a scheduling policy.

Copy pool creation is a related feature (it is the eighth item on the list), and is designed with off-site archival in mind. A single job writes backup output to volumes in multiple pools simultaneously; this facilitates, for instance, the creation of media for off-site storage.

As of November 2006, pool migration is functional, though still slightly rough around the edges. By the time of publication, it should be a stable and fully supported feature.

6.5.2. Tracking Deleted/Renamed Files

When Bacula does a differential or incremental backup, it does not notice whether a file or directory has vanished, only whether its contents have changed. Thus restoration of a file set from a particular date, which requires first a full restoration and then application of a differential or incremental restoration, restores files that were present in the full backup but had actually been deleted or renamed by the time the differential or incremental backup was taken. A similar situation exists with respect to files whose hard link count has changed. Note that as it stands, no data is lost by Bacula; however, until this item is implemented, unwanted data may be restored and have to be deleted manually. The primary use of this item is creation of a correct point-in-time snapshot.

6.5.3. Python-Based GUI Tool

The existing wxWidgets GUI is written in C++ and is difficult to maintain. An enhanced Python-based GUI built with Qt Designer will be easier to maintain, more accessible to user customization, and more easily portable.

6.5.4. Base Job Support

A "base" job is one that backs up files that are expected to change very rarely and are likely to be identical across many clients. If you have 50 Linux machines all running the same distribution and release, most of the system binaries are both identical across all those machines and are unlikely to change often. A single job that could represent the initial shared state of these machines would vastly reduce the amount of backup media required as well as the amount of media changing required if mass recovery of all these machines were ever needed.

6.5.5. Client-Initiated Backups

Consider an organization with intermittently connected machines, such as a company with many users who often travel with their laptops, and who may not be in the office on any given day. It would be very helpful for such an organization to allow the client to initiate a backup when it recognizes that it is on its home network and can connect to the Bacula director.

6.5.6. Plug-in Support for File Daemons

This project is lower down on the list than the previous five projects, but it represents an extremely interesting possibility for creating a general structure for Bacula backup of challenging applications (e.g., running databases). While the existing file daemon supports backing up anything that can be stored as a file, the fact that Bacula does all work over TCP/IP opens up the possibility of more special-purpose file daemon plug-ins designed to back up more difficult applications. For example, at this time, at least one user has reported success in creating a simple, Windows-based file daemon plug-in that, instead of backing up files, knows how to interact with MS SQL server to perform full, proper backups. Work to use this technique to integrate Bacula with VM/CMS and with AFS is also underway.

BackupCentral.com has a wiki page for every chapter in this book. Read or contribute updated information about this chapter at http://www.backupcentral.com.