
#include "template.inc" name=projects

<h1>Bacula Projects</h1>
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.  
<p>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
<a href="www.bacula.org/html-manual/developers.html">
Developer Notes</a>, and then contact me 
(kern at sibbald dot com).

<h2>Major Projects</h2>
<pre>
                
                
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.

</pre>

<h2>Status of the Major Projects</h2>
<ol>
  <li>GUI -- Mark Martin &lt;beosdude at users dot sourceforge dot net&gt; began
      working 29 May 2003 on a wxWindows implemention with the first
      client on Win32.  He is an experienced programmer.
      <p>Kern is continuing to maintain and <b>very</b> slowly enhance the
      GNOME user interface, but would like to switch to wxWindows to
      avoid porting problems such as GNOME 1.4 -&gt; 2.0.
      <p>Andreas Moroder &lt;andreas dot moroder at inwind dot it&gt; (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.
      </li>
   <li>Base jobs -- Kern is working on this, but it is going slowly. </li>
      <p>
    <li>Multiple storage devices -- unassigned.</li>
   <li>Disk spooling -- unassigned.</li>
    <li>Job Migration -- unassigned.</li>
   <li>SSL communications -- Resolved by Dan Langille by using
       stunnel.</p> </li>
    <li>Data encryption -- unassigned.</li>

</ol>

<h2>GUI Project</h2>
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: <a href="http://www.bacula.org/html-manual/gui-interface.html">
The Bacula GUI Interface</a>.                          
<p>
If you are seriously thinking about working on any project, please read 
the first six chapters under <a href="http://www.bacula.org/html-manual/internals.html">
Bacula Internal Component Designs</a>.
      
<h2>Minor or Smaller Projects</h2>      
Please see <b>kernstodo</b> in the main Bacula directory for an
update list of things needing doing/thought/documenting/testing/fixing.
