Bacula, the Network Backup Tool for Linux, Unix, and Windows
Description: Bacula a network backup and restore program
Keywords: Bacula, backup, restore, file backup

> ## It comes by night and sucks the vital essence from your computers.

> General Bacula Home What is Bacula? Features Supported Systems Supported Tape Drives Supported Autochangers License Site Visits Testimonials Documentation Online Beta Manual Beta PDF Manual Beta Tared Manual Online Manual PDF Manual Tared Manual Projects Bacula Projects Support Email Lists Support Bug Reporting SourceForge Project Page Current Downloads All Downloads CVS |  | # Bacula Projects This page is intended to give you an idea of the major projects that are in planning for Bacula, their status, and who if anyone is working on them. If you want to contribute to Bacula, please carefully check this page to ensure that no one else is working on the project, then read the Bacula Developer Notes, and then contact me (kern at sibbald dot com). ## Major Projects
>     Projects:
>                          Bacula Projects Roadmap
>                            13 April 2004

>     Item 1:   Implement Base jobs.

>       What:   A base job is sort of like a Full save except that you
>               will want the FileSet to contain only files that are
>               unlikely to change in the future (i.e.  a snapshot of
>               most of your system after installing it).  After the
>               base job has been run, when you are doing a Full save,
>               you specify one or more Base jobs to be used.  All
>               files that have been backed up in the Base job/jobs but
>               not modified will then be excluded from the backup.
>               During a restore, the Base jobs will be automatically
>               pulled in where necessary.

>       Why:    This is something none of the competition does, as far as
>               we know (except 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.

>       Notes:  Huge savings in tape usage even for a single machine.
>               Will require more resources because the DIR must send
>               FD a list of files/attribs, and the FD must search the
>               list and compare it for each file to be saved.

>     Item 2:   Add Regular Expression Matching and Plug-ins to the
>               FileSet Include statements.

>       What:   Allow users to specify wild-card and/or regular
>               expressions to be matched in both the Include and
>               Exclude directives in a FileSet.  At the same time,
>               allow users to define plug-ins to be called (based on
>               regular expression/wild-card matching).

>       Why:    This would give the users the ultimate ability to control
>               how files are backed up/restored.  A user could write a
>               plug-in knows how to backup his Oracle database without
>               stopping/starting it, for example.

>     Item 3:   Implement a Migration job type that will move the job
>               data from one device to another.

>       What:   The ability to copy, move, or archive data that is on a
>               device to another device is very important.

>       Why:    An ISP might want to backup to disk, but after 30 days
>               migrate the data to tape backup and delete it from
>               disk.  Bacula should be able to handle this
>               automatically.  It needs to know what was put where,
>               and when, and what to migrate -- it is a bit like
>               retention periods.  Doing so would allow space to be
>               freed up for current backups while maintaining older
>               data on tape drives.

>       Notes:  Migration could be triggered by:
>                Number of Jobs
>                Number of Volumes
>                Age of Jobs
>                Highwater size (keep total size)
>                Lowwater mark

>     Item 4:   Embedded Perl Scripting (precursor to 5).

>       What:   On a configuration parameter, embed the Perl language in
>               Bacula.

>       Why:    The embedded Perl scripting can be called to implement
>               Events such as "Volume Name needed", "End of Tape",
>               "Tape at x% of rated capacity", "Job started",
>               "Job Ended", "Job error", ...

>       Notes:  This needs Events.

>     Item 5:   Implement Events

>       What:   When a particular user defined Event occurs, call the
>               embedded Perl interpreter.

>       Why:    This will provide the ultimate in user customization for
>               Bacula. Almost anything imaginable can be done if Events
>               are called at the appropriate place.

>       Notes:  There is a certain amount of work to be done on how
>               the user defines or "registers" events.

>     Item 6:   Multiple Storage Devices for a Single Job

>       What:   Allow any Job to use more than one Storage device.

>       Why:    With two devices, for example, the second device could
>               have the next backup tape pre-mounted reducing operator
>               intervention in the middle of the night.

>     Item  7:  Backup a Single Job Simultaneously to Multiple Storage
>               Devices

>       What:   Make two copies of the backup data at the same time.

>       Why:    Large shops typically do this and then take one set of
>               backups off-site.  Some design work it needed in how to
>               specify the type of backup (backup, archive, ...) for
>               each Device.

>     Item  8:  Break the one-to-one Relationship between a Job and a
>               Specific Storage Device (or Devices if #10 is implemented).

>       What:   Allow a Job to simply specify one or more MediaType, and
>               the Storage daemon will select a device for it.  In
>               fact, the user should be able to specify one or more
>               MediaType, Storage daemon, and/or device to be used.

>       Why:    To allow more flexibility in large shops that have multiple
>               drives and/or multiple drives of different types.

>     Item  9:  Implement data encryption (as opposed to communications
>               encryption)

>       What:   Currently the data that is stored on the Volume is not
>               encrypted. For confidentiality, encryption of data at
>               the File daemon level is essential. Note, communications
>               encryption encrypts the data when leaving the File daemon,
>               then decrypts the data on entry to the Storage daemon.
>               Data encryption encrypts the data in the File daemon and
>               decrypts the data in the File daemon during a restore.

>       Why:    Large sites require this.

>       Notes:  The only algorithm that is needed is AES.
>               http://csrc.nist.gov/CryptoToolkit/aes/

>     Item 10:  New daemon communication protocol.

>       What:   The current daemon to daemon protocol is basically an ASCII
>               printf() and sending the buffer. On the receiving end, the
>               buffer is sscanf()ed to unpack it. The new scheme would
>               retain the current ASCII sending, but would add an
>               argc, argv like table driven scanner to replace sscanf.

>       Why:    Named fields will permit error checking to ensure that
>               what is sent is what the receiver really wants.  The
>               fields can be in any order and additional fields can be
>               ignored allowing better upward compatibility.  Much
>               better checking of the types and values passed can be
>               done.

>       Notes:  These are internal improvements in the interest of the
>               long-term stability and evolution of the program.  On
>               the one hand, the sooner they're done, the less code we
>               have to rip up when the time comes to install them.  On
>               the other hand, they don't bring an immediately
>               perceptible benefit to potential users.

>     Completed items from last year's list:
>     Item 1:   Multiple simultaneous Jobs. (done)
>     Item 3:   Write the bscan program -- also write a bcopy program (done).
>     Item 5:   Implement Label templates (done).
>     Item 6:   Write a regression script (done)
>     Item 9:   Add SSL to daemon communications (For now, implement with
>               stunnel)
>     Item 10:  Define definitive tape format (done)
>     Item 3:   GUI for interactive restore. Partially Implemented in 1.34
>               Note, there is now a complete Webmin plugin, a partial
>               GNOME console, and a partial wxWidgets console.
>     Item 4:   GUI for interactive backup
>     Item 2:   Job Data Spooling.
> ## Status of the Major Projects GUI -- Mark Martin <beosdude at users dot sourceforge dot net> began working 29 May 2003 on a wxWindows implemention with the first client on Win32. He is an experienced programmer. Kern is continuing to maintain and very slowly enhance the GNOME user interface, but would like to switch to wxWindows to avoid porting problems such as GNOME 1.4 -> 2.0. Andreas Moroder <andreas dot moroder at inwind dot it> (July 2003) has contacted the Webmin guys about writing a Webmin module for Bacula. Due to vacations and all, we expect an answer around the end of August 2003. Base jobs -- Kern is working on this, but it is going slowly. Multiple storage devices -- unassigned. Disk spooling -- unassigned. Job Migration -- unassigned. SSL communications -- Resolved by Dan Langille by using stunnel. Data encryption -- unassigned. ## GUI Project Since this is by far the project that most people would like to do, I've added a chapter to the manual that contains some of my thoughts on this subject. Please see: The Bacula GUI Interface. If you are seriously thinking about working on any project, please read the first six chapters under Bacula Internal Component Designs. ## Minor or Smaller Projects Please see kernstodo in the main Bacula directory for an update list of things needing doing/thought/documenting/testing/fixing.