Views |
||||||||||||||
Bacula
Bacula is an open-source backup product designed to scale from single machines to enterprise networks. It is capable of backing up to any combination of disk, tape, or optical media. The server currently runs on a Linux or Unix host with clients available for a variety of Unix and Linux, post-Win95 SE Windows, and Mac OS X systems. As of this writing, a Windows-based server is under active development; by the time you read this, it may very well be ready for production use. Bacula was originally written by John Walker and Kern Sibbald in 2000. John left the project not very long after its inception, and Kern, now the primary Bacula maintainer, worked on it alone from mid-2000 until Bacula’s initial public release in April 2002. Since then other developers have contributed additional work, augmenting Kern’s continued involvement. Bacula is available under the terms of a modified version of the GNU Public License version 2. The additional restrictions added to the GPL are available in the file LICENSE in the top-level Bacula source directory. The project’s homepage is http://www.bacula.org, and its downloadable files and CVS repository are hosted by SourceForge.
[edit] Bacula ArchitectureBacula is structured as a number of cooperating components, all of which use TCP sockets to communicate over a network connection. The use of TCP/IP as the intercomponent transport is essential to Bacula’s design philosophy since it allows components to be deployed on multiple or separate machines (according to capability or access to specialized hardware) and provides a ubiquitous method for intercomponent commands. The TCP transport can be wrapped with a standard Transport Layer Security (TLS) encryption layer to protect data while in transmission or in storage. TLS is discussed in more detail in “Advanced Features” later in this chapter. [edit] Bacula ComponentsFigure 6-1 shows the structure of Bacula and how its components are related. Figure 6-1. Bacula application interaction The separate application components illustrated here each provide a basic function within the Bacula environment. The description in the following list identifies each component and describes the function provided to the overall application.
Bacula also provides small status indicator application tray monitors for Windows, GNOME, and KDE (with some support for other windowing environments that support the freedesktop system tray standard). The tray monitor is simply an icon that resides in the system tray and indicates whether Bacula components on this machine are idle, currently running a job, or in an error state. These status monitor icons can be expanded to give complete status information. Example icons are shown in Figure 6-2. Figure 6-2 Bacula tray icons (idle, running, and error) [edit] File DaemonThe File daemon is the piece of Bacula that actually transfers the client’s data to the storage server. It must be installed on each machine that is to be backed up. This piece communicates with the director to determine what client data is to be backed up and which Storage daemon is to be used, and then transmits the data directly to the selected Storage daemon, including metadata about the files it is sending (such as file size, access control parameters, and ownership information) as well as file contents. [edit] Interaction Between ComponentsFigure 6-3 shows the information flows between Bacula components in a typical backup job: Figure 6-3. Information flow in Bacula During execution, the director instructs the file daemon to communicate directly with the appropriate storage daemon, thus removing the director from the high-traffic path of actual backup data. The director maintains its own scheduling service so that jobs may proceed (on a fixed schedule) without a console or any user commands. Output from scheduled jobs is sent via email to one or more administrators defined in the director configuration. [edit] AuthenticationEach communication path between Bacula components uses a component name and a password. These passwords are a shared secret, kept as clear text in the Bacula configuration files (although the package installation methods usually set them to random strings). They are used during authentication to hash the challenge and response tokens. The passwords are never directly sent over the network. It is also possible to configure Bacula with Transport Layer Security (TLS). TLS is discussed in more detail in “Advanced Features” later in this chapter. [edit] ConfigurationEach Bacula component (except the database server, which is controlled by the database’s configuration files) has its own configuration file consisting of one or more sets of resource definition statements describing Bacula objects and how the system should handle these objects. More complex configurations, such as ones with automatically generated components, can be split into multiple files and included individually. These resource definitions can be edited with any standard text editor, although the default configuration supplied with the package represents a sane basic configuration. [edit] Bacula FeaturesBacula has a number of features that differentiate it from other open-source backup systems. This section provides an overview of these features. [edit] SQL catalogThe catalog contains a list of files that have been backed up, the basic attributes of each file, including a checksum, the client each file came from, and the volumes where files are stored. Because of this, the catalog is absolutely vital to backups and restores: it stores the records of what has been backed up and when. Although the included bscan tool can help reconstruct the catalog should it be damaged, the catalog should, in general, be backed up separately after each backup cycle. [edit] Multivolume backupsOne of Bacula’s differentiating features is its excellent native support for multi-volume backups. When equipped with an autochanger, Bacula can simply span tapes without any human intervention (and, if properly configured, can label new volumes on the fly to support this goal). Even on a single-drive machine, Bacula automatically prompts, either via the console or email, for the next tape when it requires additional media. [edit] Flexible media supportBacula can back up to different types of media—using disk or tape equally easily. SCSI autochangers simply work “out of the box.” Bacula includes tools for easy transfer of backups to CD (bimagemgr) or DVD (dvd-handler), and the replaceable autochanger support allows very large storage silos to be integrated with Bacula with a modicum of effort. [edit] Backup LevelsAs with most other backup systems, Bacula differentiates between full (complete dumps), differential (files changed since last full backup), and incremental (changed files since the last backup of any sort) backups. The desired backup level is specified in the definition or schedule of a backup job, and can be overridden if a job is manually submitted. If a full backup is scheduled, but no full backup is present in the catalog, Bacula will automatically promote a differential or incremental backup job to a full backup job. [edit] Bacula storage formatAll data backed up by Bacula is stored on volumes. A volume is simply a repository for backup data and may be a tape, optical media, or a simple file. Bacula uses a unique format rather than a standard format like tar or dump. This design choice ensures consistency across platforms and implementations of Bacula. Consider the use of tar for an archive format. Although GNU tar is the tar present on most Linux implementations, other vendors may use a different implementation, and these implementations are not always compatible with each other, which can then create difficulty unpacking an archive created on a different platform. Bacula simply avoids this problem by completely specifying the storage format. While this design choice has distinct advantages, it also means that specialized tools are required to extract data from Bacula backups in the absence of a working Bacula installation. In general it is best to use a working Bacula director, catalog, and console to recover files. However, Bacula does provide the bls and bextract standalone utilities for last-resort recovery when the database is not available. The volume format is thoroughly documented in the Bacula source code and the developer’s guide. The block design of Bacula’s storage implementation also allows interleaving of files, which can allow multiple file daemons to communicate with a storage daemon simultaneously, although this slows down file restore by causing more seeks within a storage volume. [edit] Multiple pool supportBackup media in Bacula is drawn from pools, which are essentially lists of available media volumes that can be selected for use. In a small configuration, one pool may be sufficient, but Bacula also supports multiple pools and multiple backup devices extremely well. By supporting multiple pools, Bacula allows easy classification of different machine types or different data handling requirements into different backup pools. An ongoing project will allow migration of job data between pools; this is discussed in “Future Directions” later in this chapter. [edit] Macintosh HFS+ SupportAs of version 1.38.2, Bacula supports resource forks on Macintosh HFS+ volumes, which allows for correct backup and restoration of files that use resource as well as data forks. This support is completely transparent to the user. [edit] Windows VSS SupportThe Bacula 1.38 Win32 client is VSS (Volume Shadow Copy Service)-aware; this allows consistent backup of open Windows files, which makes backing up Windows systems a great deal easier and more reliable. Note that VSS support is present only in Windows XP and Windows Server 2003 and later. There is no VSS support for Windows 95, 98, ME, NT, or 2000: this is a Windows limitation, not a Bacula limitation. [edit] Standalone RecoveryBacula makes it quite easy to create a bootable Linux CD containing everything necessary to bring up a system from bare metal and begin restoration of files. Slightly more difficult (but still efficacious) processes exist for Solaris, FreeBSD, and Windows systems. This is discussed in a bit more detail in “Advanced Features” later in this chapter. [edit] DocumentationDocumentation is the Achilles’ heel of many Open Source projects. This is, thankfully, not the case with Bacula. Although the organization of the manual at the time of writing is a bit lacking, Bacula is thoroughly and accurately documented. [edit] ScalabilityBacula is designed to be an enterprise-class backup system. Because it has clearly defined logically separated components, it is possible to easily grow a Bacula installation to a very large size indeed. The modular design promotes easy scaling of a site’s backup architecture as it grows: in general, adding capacity is simply a matter of defining additional file daemons or storage daemons and adding them to the director’s configuration. Much work has gone into making Bacula interoperable with many enterprise-class tape silos and label conventions so that it can coexist with large commercial data management and operations. Despite its suitability for very large networks, Bacula’s configuration is simple enough that it is perfectly reasonable to run Bacula to back up a very small network or even just a single machine. Bacula is equally happy backing up 300 clients to a huge tape silo, or one laptop to a weekly burned DVD. [edit] Tape drive testingOne of the most commonly asked questions of Bacula (and probably any other backup system) is “Will it work with my tape drive?” While the online manual does have a good number of drives known to work well, a far more authoritative answer can be obtained by using the btape utility. This program will read the configuration you have defined for your tape drives and use it to run a comprehensive series of compatibility tests, including reading, writing, and various seek operations. If btape completes all testing successfully, you can be confident that your tape drive is both compatible with Bacula and correctly configured. [edit] An Example ConfigurationThe best way to illustrate how Bacula is used is to show you an extended example. The example network shown in Figure 6-5 incorporates three machines: an Intel Linux system running the Bacula server components, a Windows XP client, and a Mac OS X client. For simplicity’s sake, they are connected to the same network segment, but as long as IP connectivity is available between the server and the clients, this is not a requirement. Figure 6-4. Example Bacula configuration This example configures a recent Bacula distribution (at least version 1.38.2, so that we get Windows VSS support and Mac OS X resource fork support) on the Linux system and configures the Linux server to back up some of its own files. Once we have that working, we install and configure the Windows client and the Macintosh client and back up directories on each of them. In our sample configuration, we back up /etc on the Linux system, using a directory on the server as our storage device rather than tape or optical media. [edit] Setting Up the ServerTo install the Bacula application, we use RPMs provided by http://www.bacula.org, which can be installed using standard Linux system management techniques and tools. The packages install the Bacula configuration files for Linux in /etc/bacula, as mandated by the LSB (Linux Standard Base). For ease of installation, we chose the SQLite database (in a production network we would have used MySQL or PostgreSQL). Bacula is also available in Debian and other packaging formats. Although the version of Bacula available in Debian Sarge is ancient, Debian Etch is tracking recent Bacula releases, and backports of new Bacula versions to Sarge exist. For our simple example, we just rename the default client ID of Client1 to test1 and define a FileSet resource using the following line: File = /etc A FileSet specifies files to back up for a given Job. We need the following line in the default pool definition to tell Bacula to create new sequentially numbered volumes as it requires them: Label Format = TestVol The other supplied defaults are suitable for most small configurations. Configuring the storage daemon is just as easy; again, relying on Bacula to supply sane default settings, we use the FileStorage storage resource, pointing it to /opt/backups (owned by the bacula user) rather than to /tmp, ensure that Label Media = yes is set, and make sure that the passwords agree for the director, file daemon, and storage daemon. Following these updates, we restart the Bacula services using the /etc/init.d scripts installed with the package and run the Bacula bconsole to test the installation. [edit] Initial Backup (Linux Client)Once the Bacula console initializes, we use the supplied job definitions to initiate a backup job (test1 is the job we created with the settings shown earlier): *run A job name must be specified. The defined Job resources are: 1: test1 2: BackupCatalog 3: RestoreFiles Select Job resource (1-3): 1 Run Backup job JobName: test1 FileSet: Etc Level: Incremental Client: test1-fd Storage: File Pool: Default When: 2006-01-20 09:30:38 Priority: 10 OK to run? (yes/mod/no): yes Job started. JobId=4 After a while, the console says: You have messages. We then view the messages: *messages [ … lines detailing automatic creation/labeling of volume omitted … ] JobId: 4 Job: test1.2006-01-20_09.30.39 Backup Level: Full (upgraded from Incremental) Client: "test1-fd" i686-redhat-linux-gnu,redhat,(Heidelberg) FileSet: "Etc" 2006-01-19 10:47:39 Pool: "Default" Storage: "File" [ … lines omitted … ] FD Bytes Written: 40,129,258 SD Bytes Written: 40,656,235 [ … lines omitted … ] Termination: Backup OK This response shows that the backup succeeded and backed up about 40 MB. A full backup was actually performed even though we specified an incremental backup (because no full had been performed yet). [edit] Initial Restore (Linux Client)To test the backup, we restore a file. Choosing the file /etc/protocols at random, we use bconsole’s restore command to initiate the restore. From bconsole we enter the restore command, select option 7 to enter a list of files, select a client, enter the file to be restored, and press Enter. We verify that the file protocols is present in /tmp/bacula-restores/etc/protocols. Although it is possible to restore files in place, Bacula’s default configuration restores them under /tmp/bacula-restores to allow you to verify that the restored files are correct before committing them to their actual locations in the filesystem. [edit] Windows BackupNext we back up some files on the Windows workstation. First we use a text editor to define a new Job, FileSet, and Client in bacula-dir.conf: Job {
Name = "WinXP-test"
Client = winxp-fd
JobDefs = "DefaultJob"
FileSet = "WinTest"
}
FileSet {
Name = "WinTest"
Enable VSS = yes
Include {
[ … lines omitted … ]
File = C:/Windows/SYSTEM32/DRIVERS/ETC
File = "C:/Program Files/Wizards/eTools/User"
}
[ … lines omitted … ]
}
# Client (File Services) to backup
Client {
Name = winxp-fd
Address = vpc-xp2.fsf.net
…
}
The important points to notice here are Enable VSS = yes in the FileSet resource, which turns on VSS in Windows, and the format of the FileSet resource. Windows files are specified with forward slashes, and, if the filename contains spaces, it must be enclosed in double quotes. Use the reload command in the console to enable the director to pick up changes to its configuration files. Next we install the Bacula Windows client on the Windows workstation. It is a standard Windows package, installed like any other Windows application. The configuration files required editing to reflect the director (test1-dir) and its password. Once installed, the file daemon runs as a Windows service, and a little icon of a cassette tape appears in the Windows tray as described earlier. Running the wx-console command in the Bacula install diretory displays a screen like the one shown in Figure 6-5.. Figure 6-5. wx-console Running a backup job is very similar to running one for the Linux client, except that we run the WinXP-test Job rather than test1. The director logs look almost identical to the earlier backup: 20-Jan 14:49 winxp-fd: Generate VSS snapshots. Driver="VSS WinXP", Drive(s)="C" [ … lines omitted … ] Termination: Backup OK We’ll try something a bit different for the file restore, restoring this file: C:\Program Files\Wizards\eTools\User\Characters\lola13.chr Rather than entering a list of files, we choose the option to restore the most recent backup for our Windows client, and use bconsole rather than wx-console for this job. bconsole shows a directory listing interface that we navigate with cd and choose the file to restore with the mark command (with wx-console, we would have navigated the directory tree with the mouse and clicked on filenames to mark them). Running the restore job once again puts the file under /tmp/bacula-restores, which is translated to C:\tmp\bacula-restores in the Windows filesystem. From there it could be copied back into place. [edit] Mac OS X BackupMac OS X is really BSD Unix under the hood, so it should not be surprising that Bacula behaves on it very much as it does on any other Unix or Linux machine. Configuring the director was basically the same as adding the Windows client. However, in the FileSet resource we add this directive: HFS Plus Support = yes This option, which enables proper backing up of resource forks, should always be specified for Mac OS X clients. For this example, we specified the following directory to back up: File = "/Users/adam/Documents/Emulators/Virtual II" Note that, because the filename contains a space, the name must be enclosed in quotation marks. We chose this directory because it contains an application bundle. Macintosh applications are actually directory structures containing not only the binary executable, but resources and support files. If the application is to run successfully, the entire structure, including any associated resource forks, must be maintained. The backup process is identical to backing up any other client, and its output looks exactly the same. After backing up that directory, we removed it entirely, deleting the Virtual II application. When we ran the restore job this time, we used the restore all command; this is equivalent to marking all files in the tree in our Windows example (but obviously a great deal faster). As a result, the restore job restored the entire directory under /tmp/bacula-restores. After moving the directory back to its correct location, the Virtual II application ran without incident. This example demonstrated backup and restore for three different clients: Linux, Windows XP, and Mac OS X. All three were very similar in use; the primary difference in command usage was not system-specific, but simply in which restore option we chose: single named file restore, marking files in a filesystem tree, and restoring an entire tree. On the server side, we needed a single line of configuration for each non-Linux client to preserve unique filesystem features: VSS support for Windows and HFS+ support for Mac OS X. The default method of file restoration is to restore the files under /tmp/bacula-restores (the default), and then copy them to their final destinations once you are sure that you have restored the right files in their correct versions. Once familiar with Bacula’s operation, many users choose to restore files directly to their original locations. [edit] Advanced FeaturesIn addition to being able to back up and restore files over the network, Bacula has many advanced features, a brief summary of which follow. Complete information on these features can be found in the Bacula documentation at http://www.bacula.org. [edit] Bare-Metal RecoveryThe 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 facilitates the creation of 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 of the rescue files generated by the CD creation script, you should be able to create a useable 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 10). 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, 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, then 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 which includes a Bacula client. PEBuilder, the program that creates a BartPE rescue CD, can be found at http://www.nu2.nu/pebuilder/; it assists in the creation of a bootable Windows rescue CD if it is provided with Windows installation media to supply the necessary Windows files. [edit] Backup Traffic and Storage EncryptionFrequently, you have to back up machines over a network that can’t be trusted. The most obvious case is back up 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 will not know whether or not the certificate has been signed by a trusted CA, so as long as the system administrator trusts his or her 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 used to 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. [edit] Python Script SupportBacula 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 could 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. [edit] Client Script SupportBacula 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 configuration to a flat file that Bacula can restore. [edit] Autochanger SupportBacula interacts quite well with SCSI tape autochangers; in general, it uses the mtx command to manipulate the autochanger but wraps these commands inside Bacula’s own replaceable mtx-changer script. You can edit this script to customize mtx in your environment. The autochanger is capable of labeling 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 since Bacula is able to request the correct tape from the autochanger 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. [edit] ANSI and IBM Tape LabelsBacula, 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. [edit] File-based Intrusion DetectionOne 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. [edit] Future DirectionsBacula’s major long-term goal is to become a competitive enterprise-class backup system. It has a way to go before it can compete with enterprise-class commercial backup products. 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 as follows (by the time this book is published, some or all of these may be present in the mainline Bacula code): [edit] Pool MigrationThis project aims to implement migration of stored data from one pool to another. This allows implementation of tiered storage; for example, backups can initially occur to disk, and then migrate to other storage media on a controlled schedule. This has two benefits. The first is allowing much better use of storage media, by allowing optimal use of the target media. That is, pool migration can act as a sophisticated spooling facility; this is especially important when using write-once media, in which case it is important 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 will automatically be migrated onto archival media according to some scheduling policy. Copy pool creation is a related feature (it is the eighth item on the list), and is designed with offsite archival in mind. A single job will write backup output to volumes in multiple pools simultaneously; this facilitates, for instance, the creation of media for offsite storage. As of the time of writing, pool migration is functional, although support is quite rudimentary. By the time of publication it should be a stable and fully-supported feature. [edit] Tracking Deleted/Renamed FilesWhen 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 present on a particular date, which requires first a full restoration and then application of a differential or incremental restoration, will restore 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. [edit] Python-Based GUI ToolThe 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. [edit] Base Job SupportA “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. [edit] Client-initiated BackupsConsider 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. [edit] Plug-in support for File DaemonsThis project is lower down the list than the previous five project, but 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 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. |
||||||||||||||
| This page was last modified 23:10, 3 December 2006. | ||||||||||||||