Bacula 1.32 User's Guide | Chapter

FAQ | Index | 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.

FAQ | Index | Security Issues

Bacula 1.32 User's Guide The Network Backup Solution | Copyright © 2000-2003 Kern Sibbald and John Walker