This chapter presents the new features that are currently under development in the 3.1.x versions to be released as Bacula version 3.2.0 sometime in late 2009 or early 2010.
Maximum Concurrent Jobs is a new Device directive in the Storage Daemon configuration permits setting the maximum number of Jobs that can run concurrently on a specified Device. Using this directive, it is possible to have different Jobs using multiple drives, because when the Maximum Concurrent Jobs limit is reached, the Storage Daemon will start new Jobs on any other available compatible drive. This facilitates writing to multiple drives with multiple Jobs that all use the same Pool.
Previously, you were able to restore from multiple devices in a single Storage Daemon. Now, Bacula is able to restore from multiple Storage Daemons. For example, if your full backup runs on a Storage Daemon with an autochanger, and your incremental jobs use another Storage Daemon with lots of disks, Bacula will switch automatically from one Storage Daemon to an other within the same Restore job.
You must upgrade your File Daemon to version 3.1.3 or greater to use this feature.
This project was funded by Bacula Systems with the help of Equiinet.
This is something none of the competition does, as far as we know (except perhaps BackupPC, which is a Perl program that saves to disk only). It is big win for the user, it makes Bacula stand out as offering a unique optimization that immediately saves time and money. Basically, imagine that you have 100 nearly identical Windows or Linux machine containing the OS and user files. Now for the OS part, a Base job will be backed up once, and rather than making 100 copies of the OS, there will be only one. If one or more of the systems have some files updated, no problem, they will be automatically restored.
A new Job directive Base=Jobx, Joby... permits to specify the list of files that will be used during Full backup as base.
Job { Name = BackupLinux Level= Base ... } Job { Name = BackupZog4 Base = BackupZog4, BackupLinux Accurate = yes ... }
In this example, the job BackupZog4 will use the most recent version of all files contained in BackupZog4 and BackupLinux jobs. Base jobs should have run with level=Base to be used.
By default, Bacula will compare permissions bits, user and group fields, modification time, size and the checksum of the file to choose between the current backup and the BaseJob file list. You can change this behavior with the BaseJob FileSet option. This option works like the verify= one, that is described in the FileSetFileSetResource chapter.
FileSet { Name = Full Include = { Options { BaseJob = pmugcs5 Accurate = mcs5 Verify = pin5 } File = / } }
This project was funded by Bacula Systems.
In previous versions, the accurate code used the file creation and modification times to determine if a file was modified or not. Now you can specify which attributes to use (time, size, checksum, permission, owner, group, ...), similar to the Verify options.
FileSet { Name = Full Include = { Options { Accurate = mcs5 Verify = pin5 } File = / } }
Important note: If you decide to use checksum in Accurate jobs, the File Daemon will have to read all files even if they normally would not be saved. This increases the I/O load, but also the accuracy of the deduplication. By default, Bacula will check modification/creation time and size.
To help developers of restore GUI interfaces, we have added new dot commands that permit browsing the catalog in a very simple way.
You can use limit=xxx and offset=yyy to limit the amount of data that will be displayed.
* .bvfs_update jobid=1,2 * .bvfs_update * .bvfs_lsdir path=/ jobid=1,2
To determine the best configuration of your tape drive, you can run the new speed command available in the btape program.
This command can have the following arguments:
*speed file_size=3 skip_raw btape.c:1078 Test with zero data and bacula block structure. btape.c:956 Begin writing 3 files of 3.221 GB with blocks of 129024 bytes. ++++++++++++++++++++++++++++++++++++++++++ btape.c:604 Wrote 1 EOF to "Drive-0" (/dev/nst0) btape.c:406 Volume bytes=3.221 GB. Write rate = 44.128 MB/s ... btape.c:383 Total Volume bytes=9.664 GB. Total Write rate = 43.531 MB/s btape.c:1090 Test with random data, should give the minimum throughput. btape.c:956 Begin writing 3 files of 3.221 GB with blocks of 129024 bytes. +++++++++++++++++++++++++++++++++++++++++++ btape.c:604 Wrote 1 EOF to "Drive-0" (/dev/nst0) btape.c:406 Volume bytes=3.221 GB. Write rate = 7.271 MB/s +++++++++++++++++++++++++++++++++++++++++++ ... btape.c:383 Total Volume bytes=9.664 GB. Total Write rate = 7.365 MB/s
When using compression, the random test will give your the minimum throughput of your drive . The test using constant string will give you the maximum speed of your hardware chain. (cpu, memory, scsi card, cable, drive, tape).
You can change the block size in the Storage Daemon configuration file.
Block Checksum = no
doing so can reduce the Storage daemon CPU usage slightly. It will also permit Bacula to read a Volume that has corrupted data.
The default is yes - i.e. the checksum is computed on write and checked on read.
We do not recommend to turn this off particularly on older tape drives or for disk Volumes where doing so may allow corrupted data to go undetected.
By double-clicking on a volume (on the Media list, in the Autochanger content
or in the Job information panel), you can access a detailed overview of your
Volume. (cf .)
By double-clicking on a Job record (on the Job run list or in the Media
information panel), you can access a detailed overview of your Job. (cf
.)
By double-clicking on a Storage record (on the Storage list panel), you can
access a detailed overview of your Autochanger. (cf .)