Projects:
Bacula Projects Roadmap
- 05 April 2004
+ 23 April 2005
+
+The following major projects are scheduled for 1.37:
+#3 Migration (Move, Copy, Archive Jobs)
+#4 Embedded Python Scripting (implemented in all Daemons)
+#5 Events that call a Python program (Implemented in all
+ daemons, but more cleanup work to be done).
+#6 Select one from among Multiple Storage Devices for Job.
+ This is already implemented in 1.37.
+#7 Single Job Writing to Multiple Storage Devices. This is
+ currently implemented with a Clone feature.
+#- Full multiple drive Autochanger support (mostly implemented).
+#- We will have built in support for communications
+ encryption (TLS) done by Landon Fuller.
+# We will most likely have support for Unicode characters
+ (via UTF-8) on Win32 machines thanks to Thorsten Engle.
+
+
+Below, you will find more information on those projects as
+well of other projects planned at a future time.
Item 1: Implement Base jobs.
-
+ Status: Voted by users not to be implemented in 1.37
+
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
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 Plug-ins to the FileSet Include statements.
+ Status: In progress in 1.37 using Python scripting.
-Item 2: Job Data Spooling.
-Implemented in 1.34
-
- What: Make the Storage daemon use intermediate file storage to
-buffer
- the data to disk before writing it to the tape.
-
- Why: This would be a nice project and is the most requested
- feature. Even though you may finish a client job
- quicker by spooling 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. In addition, you can run multiple
- simultaneous jobs all spool to disk, then the data can
- be written one job at a time to the tape at full tape
- speed. This keeps the tape running smoothly and
- prevents blocks from different simultaneous jobs from
- being intermixed on the tape, which is very inefficient
- for restores.
-
- Notes: Need multiple spool directories. Should possibly be
- able to spool by Job type, ... Possibly need high and
- low spool data levels.
-
-
-Item 3: GUI for interactive restore
-Partially Implemented in 1.34
-Item 4: 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. Most 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.
+ 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 5: Implement a Migration job type that will move the job
+Item 3: Implement a Migration job type that will move the job
data from one device to another.
+ Status: Partially coded in 1.37 -- much more to do.
What: The ability to copy, move, or archive data that is on a
device to another device is very important.
Lowwater mark
-Item 6: Embedded Perl Scripting (precursor to 7).
+Item 4: Embedded Python Scripting (precursor to 5).
+ Status: Implemented in 1.37 in all 3 daemons.
- What: On a configuration parameter, embed the Perl language in
+ What: On a configuration parameter, embed the Python language in
Bacula.
- Why: The embedded Perl scripting can be called to implement
+ Why: The embedded Python 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 7: Implement Events
+Item 5: Implement Events that call the scripting language.
+ Status: Implemented in 1.37, but more events to complete and
+ more work to be done to cleanup the implementation.
What: When a particular user defined Event occurs, call the
- embedded Perl interpreter.
+ embedded Python interpreter.
Why: This will provide the ultimate in user customization for
Bacula. Almost anything imaginable can be done if Events
the user defines or "registers" events.
-Item 8: Multiple Storage Devices for a Single Job
+Item 6: Multiple Storage Devices for a Single Job
+ Status: This is already implemented in 1.37 (at least the
+ initial selection of one from a number of storage
+ devices.
- What: Allow any Job to use more than one Storage device.
+ What: Allow any Job to specify a number of storage devices,
+ from which one will be used.
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 9: Backup a Single Job Simultaneously to Multiple Storage
- Devices
+Item 7: Backup a Single Job Simultaneously to Multiple Storage Devices
+ Status: This will probably not be done in 1.37. However, version
+ 1.37 has a job Cloning feature, which permits essentially
+ the same thing.
What: Make two copies of the backup data at the same time.
each Device.
-Item 10: Break the one-to-one Relationship between a Job and a
+
+Item 8: Break the one-to-one Relationship between a Job and a
Specific Storage Device (or Devices if #10 is implemented).
+ Status: Mostly done in 1.37.
What: Allow a Job to simply specify one or more MediaType, and
the Storage daemon will select a device for it. In
drives and/or multiple drives of different types.
-Item 11: 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 12: Implement data encryption (as opposed to communications
+Item 9: Implement data encryption (as opposed to communications
encryption)
-
+ Status: Abel Menos expressed interest in this, but he is busy
+ at work.
+
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
http://csrc.nist.gov/CryptoToolkit/aes/
-Item 13: 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 5: Implement Label templates (done).
Item 6: Write a regression script (done)
Item 9: Add SSL to daemon communications (For now, implement with
-stunnel)
+ 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 an excellent wx-console GUI.
+Item 4: GUI for interactive backup
+Item 2: Job Data Spooling.
+ Done: Regular expression matching.
+Item 10: New daemon communication protocol (this has been dropped).
projects / bacula / bacula / blobdiff