Bacula 1.29 User's Guide Chapter
Back
FAQ
Index
Index
Next
Security Issues

Bacula Projects

Projects

  • Test as many features of Bacula as possible. This is happening a bit with every release.
  • Ensure that the documentation is complete and clear.
  • Implement the Bacula Roadmap as defined below.
  • Enhance the file restore code to restore according to a large number of criteria (include list, exclude list, state of system as of date xxx, ...) (assigned to Kern)
  • Write a GUI interface for restoring files.
  • Define and write a regression script.
  • Implement verification of tape data -- compared to what is on disk.
  • Implement SSL between daemons.
  • Performance tuning.
  • Implement a scripting language for running Jobs.
  • Implement GNOME Bacula applet.
  • Implement new serial code for daemon-daemon comm and replace all sscanf's.
  • Complete review of SQL database usage, indexes, and table design.

Raw Todo List

Please see the file kernstodo in the main Bacula directory for the raw todo list.

Bacula Projects Roadmap

            Bacula Projects Roadmap
               17 August 2002
           last update 5 January 2003

Item 1:   Multiple simultaneous Jobs. (done)
Done -- Restore part needs better implementation to work correctly

  What:   Permit multiple simultaneous jobs in Bacula.

  Why:    An enterprise level solution needs to go fast without the
          need for the system administrator to carefully tweak
          timing.  Based on the benchmarks, during a full
          backup, NetWorker typically hit 10 times the bandwidth to
          the tape compared to Bacula--largely. This is probably due to
          running parallel jobs and multi-threaded filling of buffers
          and writing them to tape.  This should also make things work
          better when you have a mix of fast and slow machines backing
          up at the same time.

  Notes:  Bacula was designed to run multiple simultaneous jobs. Thus
          implementing this is a matter of some small cleanups and
          careful testing.


Item 2:   Make the Storage daemon use intermediate file storage to buffer data.
Deferred -- not necessary yet.

  What:   If data is coming into the SD too fast, buffer it to
          disk if the user has configured this option.

  Why:    This would be nice, especially if it more or less falls out
          when implementing (1) above.  If not, it probably should not
          be given a high priority because fundamentally the backup time
          is limited by the tape bandwidth.  Even though you may finish a
          client job quicker by spilling to disk, you still have to
          eventually get it onto tape.  If intermediate disk buffering
          allows us to improve write bandwidth to tape, it may make
          sense.

  Notes:  Whether or not this is implemented will depend upon performance
          testing after item 1 is implemented.


Item 3:   Write the bscan program -- also write a bcopy program.
Done

  What:   Write a program that reads a Bacula tape and puts all the
          appropriate data into the catalog. This allows recovery
          from a tape that is no longer in the database, or it allows
          re-creation of a database if lost.

  Why:    This is a fundamental robustness and disaster recovery tool
          which will increase the comfort level of a sysadmin
          considering adopting Bacula.

  Notes:  A skeleton of this program already exists, but much work
          needs to be done. Implementing this will also make apparent
          any deficiencies in the current Bacula tape format.


Item 4:   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 can specify to exclude
          all files saved by the base job that have not been modified.

  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.

  Notes:  Big savings in tape usage. Will require more resources because
          the e. 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 5:   Implement Label templates

  What:   This is a mechanism whereby Bacula can automatically create
          a tape label for new tapes according to a detailed specification
          provided by the user.

  Why:    It is a major convenience item for folks who use automated label
          creation.

  Notes:  Bacula already has a working form of automatic tape label
          creation, but it is very crude. The design for the complete
          tape labeling project is already documented in the manual.


Item 6:   Write a regression script.
Started

  What:   This is an automatic script that runs and tests as many features
          of Bacula as possible. The output is compared to previous
          versions of Bacula and any differences are reported.

  Why:    This is an enormous help in preventing introduction of new
          errors in parts of the program that already work correctly.

  Notes:  This probably should be ranked higher, it's something the typical
          user doesn't see.  Depending on how it's implemented, it may
          make sense to defer it until the archival tape format and
          user interface mature.


Item 7:   GUI for interactive restore
Item 8:   GUI for interactive backup

  What:   The current interactive restore is implemented with a tty
          interface. It would be much nicer to be able to "see" the
          list of files backed up in typical GUI tree format.
          The same mechanism could also be used for creating
          ad-hoc backup FileSets (item 8).

  Why:    Ease of use -- especially for the end user.

  Notes:  Rather than implementing in Gtk, we probably should go directly
          for a Browser implementation, even if doing so meant the
          capability wouldn't be available until much later.  Not only
          is there the question of Windows sites, most
          Solaris/HP/IRIX, etc,  shops can't currently run Gtk programs
          without installing lots of stuff admins are very wary about.
          Real sysadmins will always use the command line anyway, and
          the user who's doing an interactive restore or backup of his
          own files will in most cases be on a Windows machine running
          Exploder.


Item 9:   Add SSL to daemon communications.

  What:   This provides for secure communications between the daemons.

  Why:    This would allow doing backup across the Internet without
          privacy concerns (or with much less concern).

  Notes:  The vast majority of near term potential users will be backing up
          a single site over a LAN and, correctly or not, they probably
          won't be concerned with security, at least not enough to go to
          the trouble to set up keys, etc. to screw things down.  We suspect
          that many users genuinely interested in multi-site backup
          already run some form of VPN software in their internetwork
          connections, and are willing to delegate security to that layer.


Item 10:  Define definitive tape format.
Done (version 1.27)

  What:   Define that definitive tape format that will not change
          for the next millennium.

  Why:    Stability, security.

  Notes:  See notes for item 11 below.


Item 11:  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
          be a binary format that allows quick packing and unpacking
          of any data type with named fields.

  Why:    Using binary packing would be faster. Named fields will permit
          error checking to ensure that what is sent is what the
          receiver really wants.

  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.  Item 10 and possibly item 11 should be deferred until Bacula
          is well established with a growing user community more or
          less happy with the feature set.  At that time, it will make a
          good "next generation" upgrade in the interest of data
          immortality.



Back
FAQ
Index
Index
Next
Security Issues
Bacula 1.29 User's Guide
The Network Backup Solution
Copyright © 2000-2003
Kern Sibbald and John Walker