X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=bacula%2Fprojects;h=76c0e48a7647daf1df43c8cf21cc345601464427;hb=ad14d3946b4817451e48f990f8592d5eac9dca76;hp=6c3450ed3759c59c74825b8a5e4caf184c5b835c;hpb=d788c7298ec0f7da8dc629de2338f0d72a8ad838;p=bacula%2Fbacula

diff --git a/bacula/projects b/bacula/projects
index 6c3450ed37..76c0e48a76 100644
--- a/bacula/projects
+++ b/bacula/projects
@@ -1,43 +1,57 @@
                 
 Projects:
                      Bacula Projects Roadmap 
-                       29 November 2005
+                Prioritized by user vote 07 December 2005
+                    Status updated 30 July 2006
 
 Summary:
-Item 1:   Implement Migration that moves Jobs from one Pool to another.
-Item 2:   Implement extraction of Win32 BackupWrite data.
-Item 3:   Implement a Bacula GUI/management tool using Python.
-Item 4:   Implement a Python interface to the Bacula catalog.
-Item 5:   Implement more Python events in Bacula.
-Item 6:   Implement Base jobs.
-Item 7:   Add Plug-ins to the FileSet Include statements.
-Item 8:   Implement huge exclude list support using hashing.
-Item 9:   Implement data encryption (as opposed to comm encryption)
-Item 10:  Permit multiple Media Types in an Autochanger
-Item 11:  Allow different autochanger definitions for one autochanger.
-Item 12:  Implement red/black binary tree routines.
-Item 13:  Improve Baculas tape and drive usage and cleaning management.
-Item 14:  Merge multiple backups (Synthetic Backup or Consolidation).
-Item 15:  Automatic disabling of devices
-Item 16:  Directive/mode to backup only file changes, not entire file
-Item 17:  Quick release of FD-SD connection after backup.
-Item 18:  Add support for FileSets in user directories  CACHEDIR.TAG
-Item 19:  Implement new {Client}Run{Before|After}Job feature.
-Item 20:  Allow FD to initiate a backup
-Item 21:  Multiple threads in file daemon for the same job
-Item 22:  Archival (removal) of User Files to Tape
-Item 23:  Deletion of Disk-Based  BaculaVolumes
-Item 24:  Accurate restoration of renamed/deleted files from
-Item 25:  Implement creation and maintenance of copy pools
+Item  1:  Implement data encryption (as opposed to comm encryption)
+Item  2:  Implement Migration that moves Jobs from one Pool to another.
+Item  3:  Accurate restoration of renamed/deleted files from
+Item  4:  Implement a Bacula GUI/management tool using Python.
+Item  5:  Implement Base jobs.
+Item  6:  Allow FD to initiate a backup
+Item  7:  Improve Bacula's tape and drive usage and cleaning management.
+Item  8:  Implement creation and maintenance of copy pools
+Item  9:  Implement new {Client}Run{Before|After}Job feature.
+Item 10:  Merge multiple backups (Synthetic Backup or Consolidation).
+Item 11:  Deletion of Disk-Based Bacula Volumes
+Item 12:  Directive/mode to backup only file changes, not entire file
+Item 13:  Multiple threads in file daemon for the same job
+Item 14:  Implement red/black binary tree routines.
+Item 15:  Add support for FileSets in user directories  CACHEDIR.TAG
+Item 16:  Implement extraction of Win32 BackupWrite data.
+Item 17:  Implement a Python interface to the Bacula catalog.
+Item 18:  Archival (removal) of User Files to Tape
+Item 19:  Add Plug-ins to the FileSet Include statements.
+Item 20:  Implement more Python events in Bacula.
+Item 21:  Quick release of FD-SD connection after backup.
+Item 22:  Permit multiple Media Types in an Autochanger
+Item 23:  Allow different autochanger definitions for one autochanger.
+Item 24:  Automatic disabling of devices
+Item 25:  Implement huge exclude list support using hashing.
 
 
 Below, you will find more information on future projects:
 
-Item 1:   Implement Migration that moves Jobs from one Pool to another.
+Item  1:  Implement data encryption (as opposed to comm encryption)
+  Date:   28 October 2005
+  Origin: Sponsored by Landon and 13 contributors to EFF.
+  Status: Done: Landon Fuller has implemented this in 1.39.x.
+                  
+  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. 
+          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.
+
+Item 2:   Implement Migration that moves Jobs from one Pool to another.
   Origin: Sponsored by Riege Software International GmbH. Contact:
           Daniel Holtkamp <holtkamp at riege dot com>
   Date:   28 October 2005
-  Status: Partially coded in 1.37 -- much more to do. Assigned to
+  Status: 90% complete: Working in 1.39, more to do. Assigned to
           Kern.
 
   What:   The ability to copy, move, or archive data that is on a
@@ -61,28 +75,43 @@ Item 1:   Implement Migration that moves Jobs from one Pool to another.
            Number of Jobs
            Number of Volumes
 
+Item  3:  Accurate restoration of renamed/deleted files from
+          Incremental/Differential backups
+  Date:   28 November 2005
+  Origin: Martin Simmons (martin at lispworks dot com)
+  Status:
 
-Item 2:   Implement extraction of Win32 BackupWrite data.
-  Origin: Thorsten Engel <thorsten.engel at matrix-computer dot com>
-  Date:   28 October 2005
-  Status: Assigned to Thorsten. Implemented in current CVS
+  What:   When restoring a fileset for a specified date (including "most
+          recent"), Bacula should give you exactly the files and directories
+          that existed at the time of the last backup prior to that date.
 
-  What:   This provides the Bacula File daemon with code that
-          can pick apart the stream output that Microsoft writes
-          for BackupWrite data, and thus the data can be read
-          and restored on non-Win32 machines.
+          Currently this only works if the last backup was a Full backup.
+          When the last backup was Incremental/Differential, files and
+          directories that have been renamed or deleted since the last Full
+          backup are not currently restored correctly.  Ditto for files with
+          extra/fewer hard links than at the time of the last Full backup.
 
-  Why:    BackupWrite data is the portable=no option in Win32
-          FileSets, and in previous Baculas, this data could
-          only be extracted using a Win32 FD. With this new code,
-          the Windows data can be extracted and restored on
-          any OS.
+  Why:    Incremental/Differential would be much more useful if this worked.
+
+  Notes:  Item 14 (Merging of multiple backups into a single one) seems to
+          rely on this working, otherwise the merged backups will not be
+          truly equivalent to a Full backup.  
+
+          Kern: notes shortened. This can be done without the need for 
+          inodes. It is essentially the same as the current Verify job,
+          but one additional database record must be written, which does 
+          not need any database change.
 
+          Kern: see if we can correct restoration of directories if
+          replace=ifnewer is set.  Currently, if the directory does not
+          exist, a "dummy" directory is created, then when all the files
+          are updated, the dummy directory is newer so the real values
+          are not updated.
 
-Item 3:   Implement a Bacula GUI/management tool using Python.
+Item 4:   Implement a Bacula GUI/management tool using Python.
   Origin: Kern
   Date:   28 October 2005
-  Status: 
+  Status: Lucus is working on this for Python GTK+.
 
   What:   Implement a Bacula console, and management tools
           using Python and Qt or GTK.
@@ -101,40 +130,7 @@ Item 3:   Implement a Bacula GUI/management tool using Python.
  Notes:   This is currently being implemented using Python-GTK by       
           Lucas Di Pentima <lucas at lunix dot com dot ar>
 
-
-Item 4:   Implement a Python interface to the Bacula catalog.
-  Date:   28 October 2005
-  Origin: Kern
-  Status: 
-
-  What:   Implement an interface for Python scripts to access
-          the catalog through Bacula.
-
-  Why:    This will permit users to customize Bacula through
-          Python scripts.
-
-Item 5:   Implement more Python events in Bacula.
-  Date:   28 October 2005
-  Origin: 
-  Status: 
-
-  What:   Allow Python scripts to be called at more places 
-          within Bacula and provide additional access to Bacula
-          internal variables.
-
-  Why:    This will permit users to customize Bacula through
-          Python scripts.
-
-  Notes:  Recycle event
-          Scratch pool event
-          NeedVolume event
-          MediaFull event
-           
-          Also add a way to get a listing of currently running
-          jobs (possibly also scheduled jobs).
-
-
-Item 6:   Implement Base jobs.
+Item 5:   Implement Base jobs.
   Date:   28 October 2005
   Origin: Kern
   Status: 
@@ -168,101 +164,19 @@ Item 6:   Implement Base jobs.
           FD a list of files/attribs, and the FD must search the
           list and compare it for each file to be saved.
 
-Item 7:   Add Plug-ins to the FileSet Include statements.
-  Date:   28 October 2005
-  Origin:
-  Status: Partially coded in 1.37 -- much more to do.
-
-  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 8:   Implement huge exclude list support using hashing.
-  Date:   28 October 2005
-  Origin: Kern
-  Status: 
-
-  What:   Allow users to specify very large exclude list (currently
-          more than about 1000 files is too many).
-
-  Why:    This would give the users the ability to exclude all
-          files that are loaded with the OS (e.g. using rpms
-          or debs). If the user can restore the base OS from
-          CDs, there is no need to backup all those files. A
-          complete restore would be to restore the base OS, then
-          do a Bacula restore. By excluding the base OS files, the
-          backup set will be *much* smaller.
-
-
-Item  9:  Implement data encryption (as opposed to comm encryption)
-  Date:   28 October 2005
-  Origin: Sponsored by Landon and 13 contributors to EFF.
-  Status: Landon Fuller is currently implementing this.
-                  
-  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. 
-          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.
-
-Item 10:  Permit multiple Media Types in an Autochanger
-  Origin: Kern
-  Status: Now implemented
-
-  What:   Modify the Storage daemon so that multiple Media Types
-          can be specified in an autochanger. This would be somewhat
-          of a simplistic implementation in that each drive would
-          still be allowed to have only one Media Type.  However,
-          the Storage daemon will ensure that only a drive with
-          the Media Type that matches what the Director specifies
-          is chosen.
-
-  Why:    This will permit user with several different drive types
-          to make full use of their autochangers.
-
-Item 11:  Allow different autochanger definitions for one autochanger.
-  Date:   28 October 2005
-  Origin: Kern
-  Status: 
-
-  What:   Currently, the autochanger script is locked based on
-          the autochanger. That is, if multiple drives are being
-          simultaneously used, the Storage daemon ensures that only
-          one drive at a time can access the mtx-changer script.
-          This change would base the locking on the control device,
-          rather than the autochanger. It would then permit two autochanger
-          definitions for the same autochanger, but with different 
-          drives. Logically, the autochanger could then be "partitioned"
-          for different jobs, clients, or class of jobs, and if the locking
-          is based on the control device (e.g. /dev/sg0) the mtx-changer
-          script will be locked appropriately.
-
-  Why:    This will permit users to partition autochangers for specific
-          use. It would also permit implementation of multiple Media
-          Types with no changes to the Storage daemon.
-
-Item 12:  Implement red/black binary tree routines.
-  Date:   28 October 2005
-  Origin: Kern
-  Status: 
+Item  6:  Allow FD to initiate a backup
+  Origin: Frank Volf (frank at deze dot org)
+  Date:   17 November 2005
+  Status:
 
-  What:   Implement a red/black binary tree class. This could 
-          then replace the current binary insert/search routines
-          used in the restore in memory tree.  This could significantly
-          speed up the creation of the in memory restore tree.
+   What:  Provide some means, possibly by a restricted console that
+          allows a FD to initiate a backup, and that uses the connection
+          established by the FD to the Director for the backup so that
+          a Director that is firewalled can do the backup.
 
-  Why:    Performance enhancement.
+   Why:   Makes backup of laptops much easier.
 
-Item 13:  Improve Baculas tape and drive usage and cleaning management.
+Item  7:  Improve Bacula's tape and drive usage and cleaning management.
   Date:   8 November 2005, November 11, 2005
   Origin: Adam Thornton <athornton at sinenomine dot net>,
           Arno Lehmann <al at its-lehmann dot de>
@@ -330,11 +244,153 @@ Item 13:  Improve Baculas tape and drive usage and cleaning management.
           sub-projects: Measuring Tape and Drive usage, retiring
           volumes, and handling drive cleaning and TAPEALERTs.
 
+Item  8:  Implement creation and maintenance of copy pools
+  Date:   27 November 2005
+  Origin: David Boyes (dboyes at sinenomine dot net)
+  Status:
+
+  What:   I would like Bacula to have the capability to write copies
+          of backed-up data on multiple physical volumes selected
+          from different pools without transferring the data
+          multiple times, and to accept any of the copy volumes
+          as valid for restore.
+
+  Why:    In many cases, businesses are required to keep offsite
+          copies of backup volumes, or just wish for simple
+          protection against a human operator dropping a storage
+          volume and damaging it. The ability to generate multiple
+          volumes in the course of a single backup job allows
+          customers to simple check out one copy and send it
+          offsite, marking it as out of changer or otherwise
+          unavailable. Currently, the library and magazine
+          management capability in Bacula does not make this process
+          simple.
+
+          Restores would use the copy of the data on the first
+          available volume, in order of copy pool chain definition.
+
+          This is also a major scalability issue -- as the number of
+          clients increases beyond several thousand, and the volume
+          of data increases, transferring the data multiple times to
+          produce additional copies of the backups will become
+          physically impossible due to transfer speed
+          issues. Generating multiple copies at server side will
+          become the only practical option. 
+
+  How:    I suspect that this will require adding a multiplexing
+          SD that appears to be a SD to a specific FD, but 1-n FDs
+          to the specific back end SDs managing the primary and copy
+          pools.  Storage pools will also need to acquire parameters
+          to define the pools to be used for copies. 
+
+  Notes:  I would commit some of my developers' time if we can agree
+          on the design and behavior. 
+
+Item  9:  Implement new {Client}Run{Before|After}Job feature.
+  Date:   26 September 2005
+  Origin: Phil Stracchino
+  Status: Done. This has been implemented by Eric Bollengier
+
+  What:   Some time ago, there was a discussion of RunAfterJob and
+          ClientRunAfterJob, and the fact that they do not run after failed
+          jobs.  At the time, there was a suggestion to add a
+          RunAfterFailedJob directive (and, presumably, a matching
+          ClientRunAfterFailedJob directive), but to my knowledge these
+          were never implemented.
+
+          The current implementation doesn't permit to add new feature easily.
+
+          An alternate way of approaching the problem has just occurred to
+          me.  Suppose the RunBeforeJob and RunAfterJob directives were
+          expanded in a manner like this example:
+
+          RunScript {
+              Command = "/opt/bacula/etc/checkhost %c"
+              RunsOnClient = No          # default
+              AbortJobOnError = Yes      # default
+              RunsWhen = Before
+          }
+          RunScript {
+              Command = c:/bacula/systemstate.bat
+              RunsOnClient = yes
+              AbortJobOnError = No
+              RunsWhen = After
+              RunsOnFailure = yes
+          }
+
+          RunScript {
+              Command = c:/bacula/deletestatefile.bat
+              Target = rico-fd
+              RunsWhen = Always
+          }
+
+          It's now possible to specify more than 1 command per Job.
+          (you can stop your database and your webserver without a script)
+
+          ex :
+          Job {
+              Name = "Client1"
+              JobDefs = "DefaultJob"
+              Write Bootstrap = "/tmp/bacula/var/bacula/working/Client1.bsr"
+              FileSet = "Minimal"
+
+              RunBeforeJob = "echo test before ; echo test before2"       
+              RunBeforeJob = "echo test before (2nd time)"
+              RunBeforeJob = "echo test before (3rd time)"
+              RunAfterJob = "echo test after"
+              ClientRunAfterJob = "echo test after client"
+
+              RunScript {
+                Command = "echo test RunScript in error"
+                Runsonclient = yes
+                RunsOnSuccess = no
+                RunsOnFailure = yes
+                RunsWhen = After            # never by default
+              }
+              RunScript {
+                Command = "echo test RunScript on success"
+                Runsonclient = yes
+                RunsOnSuccess = yes # default
+                RunsOnFailure = no  # default
+                RunsWhen = After
+              }
+          }
+
+  Why:    It would be a significant change to the structure of the
+          directives, but allows for a lot more flexibility, including
+          RunAfter commands that will run regardless of whether the job
+          succeeds, or RunBefore tasks that still allow the job to run even
+          if that specific RunBefore fails.
+
+  Notes:  (More notes from Phil, Kern, David and Eric)
+          I would prefer to have a single new Resource called
+          RunScript.
+
+            RunsWhen = After|Before|Always
+            RunsAtJobLevels = All|Full|Diff|Inc # not yet implemented
+
+          The AbortJobOnError, RunsOnSuccess and RunsOnFailure directives
+          could be optional, and possibly RunWhen as well.
+
+          AbortJobOnError would be ignored unless RunsWhen was set to Before
+          and would default to Yes if omitted.
+          If AbortJobOnError was set to No, failure of the script
+          would still generate a warning.
+
+          RunsOnSuccess would be ignored unless RunsWhen was set to After
+          (or RunsBeforeJob set to No), and default to Yes.
+
+          RunsOnFailure would be ignored unless RunsWhen was set to After,
+          and default to No.
+
+          Allow having the before/after status on the script command
+          line so that the same script can be used both before/after.
 
-Item 14:  Merge multiple backups (Synthetic Backup or Consolidation).
+Item 10:  Merge multiple backups (Synthetic Backup or Consolidation).
   Origin: Marc Cousin and Eric Bollengier 
   Date:   15 November 2005
-  Status: Depends on first implementing project Item 1 (Migration).
+  Status: Waiting implementation. Depends on first implementing 
+          project Item 2 (Migration).
 
   What:   A merged backup is a backup made without connecting to the Client.
           It would be a Merge of existing backups into a single backup.
@@ -366,38 +422,32 @@ Item 14:  Merge multiple backups (Synthetic Backup or Consolidation).
           data can then be pruned (or not) from the catalog, possibly
           allowing older volumes to be recycled
 
-Item 15:  Automatic disabling of devices
-   Date:   2005-11-11
-   Origin: Peter Eriksson <peter at ifm.liu dot se>
-   Status:
+Item 11:  Deletion of Disk-Based Bacula Volumes
+  Date:   Nov 25, 2005
+  Origin: Ross Boylan <RossBoylan at stanfordalumni dot org> (edited
+          by Kern)
+  Status:         
 
-   What:  After a configurable amount of fatal errors with a tape drive
-          Bacula should automatically disable further use of a certain
-          tape drive. There should also be "disable"/"enable" commands in
-          the "bconsole" tool.
+   What:  Provide a way for Bacula to automatically remove Volumes
+          from the filesystem, or optionally to truncate them.
+          Obviously, the Volume must be pruned prior removal.
 
-   Why:   On a multi-drive jukebox there is a possibility of tape drives
-          going bad during large backups (needing a cleaning tape run,
-          tapes getting stuck). It would be advantageous if Bacula would
-          automatically disable further use of a problematic tape drive
-          after a configurable amount of errors has occurred.
+  Why:    This would allow users more control over their Volumes and
+          prevent disk based volumes from consuming too much space.
 
-          An example: I have a multi-drive jukebox (6 drives, 380+ slots)
-          where tapes occasionally get stuck inside the drive. Bacula will
-          notice that the "mtx-changer" command will fail and then fail
-          any backup jobs trying to use that drive. However, it will still
-          keep on trying to run new jobs using that drive and fail -
-          forever, and thus failing lots and lots of jobs... Since we have
-          many drives Bacula could have just automatically disabled
-          further use of that drive and used one of the other ones
-          instead.
+  Notes:  The following two directives might do the trick:
 
+          Volume Data Retention = <time period>
+          Remove Volume After = <time period>
 
-Item 16:  Directive/mode to backup only file changes, not entire file
+          The migration project should also remove a Volume that is
+          migrated. This might also work for tape Volumes.
+
+Item 12:  Directive/mode to backup only file changes, not entire file
   Date:   11 November 2005
   Origin: Joshua Kugler <joshua dot kugler at uaf dot edu>
           Marek Bajon <mbajon at bimsplus dot com dot pl>
-  Status: RFC
+  Status: 
 
   What:   Currently when a file changes, the entire file will be backed up in
           the next incremental or full backup.  To save space on the tapes
@@ -410,48 +460,49 @@ Item 16:  Directive/mode to backup only file changes, not entire file
   Notes:  This would require the usage of disk-based volumes as comparing 
           files would not be feasible using a tape drive.
 
-Item 17:  Quick release of FD-SD connection after backup.
-  Origin: Frank Volf (frank at deze dot org)
-  Date:   17 November 2005
+Item 13:  Multiple threads in file daemon for the same job
+  Date:   27 November 2005
+  Origin: Ove Risberg (Ove.Risberg at octocode dot com)
   Status:
 
-   What:  In the Bacula implementation a backup is finished after all data
-          and attributes are successfully written to storage.  When using a
-          tape backup it is very annoying that a backup can take a day,
-          simply because the current tape (or whatever) is full and the
-          administrator has not put a new one in.  During that time the
-          system cannot be taken off-line, because there is still an open
-          session between the storage daemon and the file daemon on the
-          client.
+  What:   I want the file daemon to start multiple threads for a backup
+          job so the fastest possible backup can be made.
 
-          Although this is a very good strategy for making "safe backups"
-          This can be annoying for e.g.  laptops, that must remain
-          connected until the backup is completed.
+          The file daemon could parse the FileSet information and start
+          one thread for each File entry located on a separate
+          filesystem.
 
-          Using a new feature called "migration" it will be possible to
-          spool first to harddisk (using a special 'spool' migration
-          scheme) and then migrate the backup to tape.
+          A configuration option in the job section should be used to
+          enable or disable this feature. The configuration option could
+          specify the maximum number of threads in the file daemon.
 
-          There is still the problem of getting the attributes committed.
-          If it takes a very long time to do, with the current code, the
-          job has not terminated, and the File daemon is not freed up.  The
-          Storage daemon should release the File daemon as soon as all the
-          file data and all the attributes have been sent to it (the SD).
-          Currently the SD waits until everything is on tape and all the
-          attributes are transmitted to the Director before signaling
-          completion to the FD. I don't think I would have any problem
-          changing this.  The reason is that even if the FD reports back to
-          the Dir that all is OK, the job will not terminate until the SD
-          has done the same thing -- so in a way keeping the SD-FD link
-          open to the very end is not really very productive ...
+          If the theads could spool the data to separate spool files
+          the restore process will not be much slower.
 
-   Why:   Makes backup of laptops much easier.
+  Why:    Multiple concurrent backups of a large fileserver with many
+          disks and controllers will be much faster.
 
+  Notes:  I am willing to try to implement this but I will probably
+          need some help and advice.  (No problem -- Kern)
 
-Item 18:  Add support for FileSets in user directories  CACHEDIR.TAG
+Item 14:  Implement red/black binary tree routines.
+  Date:   28 October 2005
+  Origin: Kern
+  Status: Class code is complete. Code needs to be integrated into
+          restore tree code.
+
+  What:   Implement a red/black binary tree class. This could 
+          then replace the current binary insert/search routines
+          used in the restore in memory tree.  This could significantly
+          speed up the creation of the in memory restore tree.
+
+  Why:    Performance enhancement.
+
+Item 15:  Add support for FileSets in user directories  CACHEDIR.TAG
   Origin: Norbert Kiesel <nkiesel at tbdnetworks dot com>
   Date:   21 November 2005
-  Status:
+  Status: (I think this is better done using a Python event that I
+           will implement in version 1.39.x).
 
   What:   CACHDIR.TAG is a proposal for identifying directories which
           should be ignored for archiving/backup.  It works by ignoring
@@ -478,127 +529,36 @@ Item 18:  Add support for FileSets in user directories  CACHEDIR.TAG
   Notes:  I envision this as an optional feature to a fileset
           specification.
 
-Item 19:  Implement new {Client}Run{Before|After}Job feature.
-  Date:   26 September 2005
-  Origin: Phil Stracchino <phil.stracchino at speakeasy dot net>
-  Status: 
-
-  What:   Some time ago, there was a discussion of RunAfterJob and
-          ClientRunAfterJob, and the fact that they do not run after failed
-          jobs.  At the time, there was a suggestion to add a
-          RunAfterFailedJob directive (and, presumably, a matching
-          ClientRunAfterFailedJob directive), but to my knowledge these
-          were never implemented.
-
-          An alternate way of approaching the problem has just occurred to
-          me.  Suppose the RunBeforeJob and RunAfterJob directives were
-          expanded in a manner something like this example:
-
-          RunBeforeJob {
-              Command = "/opt/bacula/etc/checkhost %c"
-              RunsOnClient = No
-              RunsAtJobLevels = All       # All, Full, Diff, Inc
-              AbortJobOnError = Yes
-          }
-          RunBeforeJob {
-              Command = c:/bacula/systemstate.bat
-              RunsOnClient = yes
-              RunsAtJobLevels = All       # All, Full, Diff, Inc
-              AbortJobOnError = No
-          }
-
-          RunAfterJob {
-              Command = c:/bacula/deletestatefile.bat
-              RunsOnClient = Yes
-              RunsAtJobLevels = All       # All, Full, Diff, Inc
-              RunsOnSuccess = Yes
-              RunsOnFailure = Yes
-          }
-          RunAfterJob {
-              Command = c:/bacula/somethingelse.bat
-              RunsOnClient = Yes
-              RunsAtJobLevels = All
-              RunsOnSuccess = No
-              RunsOnFailure = Yes
-          }
-          RunAfterJob {
-              Command = "/opt/bacula/etc/checkhost -v %c"
-              RunsOnClient = No
-              RunsAtJobLevels = All
-              RunsOnSuccess = No
-              RunsOnFailure = Yes
-          }
-
-
-  Why:    It would be a significant change to the structure of the
-          directives, but allows for a lot more flexibility, including
-          RunAfter commands that will run regardless of whether the job
-          succeeds, or RunBefore tasks that still allow the job to run even
-          if that specific RunBefore fails.
-
-  Notes:  By Kern: I would prefer to have a single new Resource called
-          RunScript. More notes from Phil:
-
-            RunBeforeJob = yes|no
-            RunAfterJob = yes|no
-            RunsAtJobLevels = All|Full|Diff|Inc
-
-          The AbortJobOnError, RunsOnSuccess and RunsOnFailure directives
-          could be optional, and possibly RunsWhen as well.
-
-          AbortJobOnError would be ignored unless RunsWhen was set to Before
-          (or RunsBefore Job set to Yes), and would default to Yes if
-          omitted.  If AbortJobOnError was set to No, failure of the script
-          would still generate a warning.
-
-          RunsOnSuccess would be ignored unless RunsWhen was set to After
-          (or RunsBeforeJob set to No), and default to Yes.
 
-          RunsOnFailure would be ignored unless RunsWhen was set to After,
-          and default to No.
-
-          Allow having the before/after status on the script command
-          line so that the same script can be used both before/after.
-          David Boyes.
-
-Item 20:  Allow FD to initiate a backup
-  Origin: Frank Volf (frank at deze dot org)
-  Date:   17 November 2005
-  Status:
-
-   What:  Provide some means, possibly by a restricted console that
-          allows a FD to initiate a backup, and that uses the connection
-          established by the FD to the Director for the backup so that
-          a Director that is firewalled can do the backup.
-
-   Why:   Makes backup of laptops much easier.
-
-Item 21:  Multiple threads in file daemon for the same job
-  Date:   27 November 2005
-  Origin: Ove Risberg (Ove.Risberg at octocode dot com)
-  Status:
+Item 16:  Implement extraction of Win32 BackupWrite data.
+  Origin: Thorsten Engel <thorsten.engel at matrix-computer dot com>
+  Date:   28 October 2005
+  Status: Done. Assigned to Thorsten. Implemented in current CVS
 
-  What:   I want the file daemon to start multiple threads for a backup
-          job so the fastest possible backup can be made.
+  What:   This provides the Bacula File daemon with code that
+          can pick apart the stream output that Microsoft writes
+          for BackupWrite data, and thus the data can be read
+          and restored on non-Win32 machines.
 
-          The file daemon could parse the FileSet information and start
-          one thread for each File entry located on a separate
-          filesystem.
+  Why:    BackupWrite data is the portable=no option in Win32
+          FileSets, and in previous Baculas, this data could
+          only be extracted using a Win32 FD. With this new code,
+          the Windows data can be extracted and restored on
+          any OS.
 
-          A configuration option in the job section should be used to
-          enable or disable this feature. The configuration option could
-          specify the maximum number of threads in the file daemon.
 
-          If the theads could spool the data to separate spool files
-          the restore process will not be much slower.
+Item 18:  Implement a Python interface to the Bacula catalog.
+  Date:   28 October 2005
+  Origin: Kern
+  Status: 
 
-  Why:    Multiple concurrent backups of a large fileserver with many
-          disks and controllers will be much faster.
+  What:   Implement an interface for Python scripts to access
+          the catalog through Bacula.
 
-  Notes:  I am willing to try to implement this but I will probably
-          need some help and advice.  (No problem -- Kern)
+  Why:    This will permit users to customize Bacula through
+          Python scripts.
 
-Item 22:  Archival (removal) of User Files to Tape
+Item 18:  Archival (removal) of User Files to Tape
 
   Date:   Nov. 24/2005 
 
@@ -627,109 +587,158 @@ Item 22:  Archival (removal) of User Files to Tape
           access time.  Then after another 6 months (or possibly as one
           storage pool gets full) data is migrated to Tape.
 
+Item 19:  Add Plug-ins to the FileSet Include statements.
+  Date:   28 October 2005
+  Origin:
+  Status: Partially coded in 1.37 -- much more to do.
 
-Item 23:  Deletion of Disk-Based Bacula Volumes
-  Date:   Nov 25, 2005
-  Origin: Ross Boylan <RossBoylan at stanfordalumni dot org> (edited
-          by Kern)
-  Status:         
+  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).
 
-   What:  Provide a way for Bacula to automatically remove Volumes
-          from the filesystem, or optionally to truncate them.
-          Obviously, the Volume must be pruned prior removal.
+  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.
 
-  Why:    This would allow users more control over their Volumes and
-          prevent disk based volumes from consuming too much space.
+Item 20:  Implement more Python events in Bacula.
+  Date:   28 October 2005
+  Origin: 
+  Status: 
 
-  Notes:  The following two directives might do the trick:
+  What:   Allow Python scripts to be called at more places 
+          within Bacula and provide additional access to Bacula
+          internal variables.
 
-          Volume Data Retention = <time period>
-          Remove Volume After = <time period>
+  Why:    This will permit users to customize Bacula through
+          Python scripts.
 
-          The migration project should also remove a Volume that is
-          migrated. This might also work for tape Volumes.
+  Notes:  Recycle event
+          Scratch pool event
+          NeedVolume event
+          MediaFull event
+           
+          Also add a way to get a listing of currently running
+          jobs (possibly also scheduled jobs).
 
 
-Item 24:  Accurate restoration of renamed/deleted files from
-          Incremental/Differential backups
-  Date:   28 November 2005
-  Origin: Martin Simmons (martin at lispworks dot com)
+Item 21:  Quick release of FD-SD connection after backup.
+  Origin: Frank Volf (frank at deze dot org)
+  Date:   17 November 2005
   Status:
 
-  What:   When restoring a fileset for a specified date (including "most
-          recent"), Bacula should give you exactly the files and directories
-          that existed at the time of the last backup prior to that date.
+   What:  In the Bacula implementation a backup is finished after all data
+          and attributes are successfully written to storage.  When using a
+          tape backup it is very annoying that a backup can take a day,
+          simply because the current tape (or whatever) is full and the
+          administrator has not put a new one in.  During that time the
+          system cannot be taken off-line, because there is still an open
+          session between the storage daemon and the file daemon on the
+          client.
 
-          Currently this only works if the last backup was a Full backup.
-          When the last backup was Incremental/Differential, files and
-          directories that have been renamed or deleted since the last Full
-          backup are not currently restored correctly.  Ditto for files with
-          extra/fewer hard links than at the time of the last Full backup.
+          Although this is a very good strategy for making "safe backups"
+          This can be annoying for e.g.  laptops, that must remain
+          connected until the backup is completed.
 
-  Why:    Incremental/Differential would be much more useful if this worked.
+          Using a new feature called "migration" it will be possible to
+          spool first to harddisk (using a special 'spool' migration
+          scheme) and then migrate the backup to tape.
 
-  Notes:  Item 14 (Merging of multiple backups into a single one) seems to
-          rely on this working, otherwise the merged backups will not be
-          truely equivalent to a Full backup.  
+          There is still the problem of getting the attributes committed.
+          If it takes a very long time to do, with the current code, the
+          job has not terminated, and the File daemon is not freed up.  The
+          Storage daemon should release the File daemon as soon as all the
+          file data and all the attributes have been sent to it (the SD).
+          Currently the SD waits until everything is on tape and all the
+          attributes are transmitted to the Director before signaling
+          completion to the FD. I don't think I would have any problem
+          changing this.  The reason is that even if the FD reports back to
+          the Dir that all is OK, the job will not terminate until the SD
+          has done the same thing -- so in a way keeping the SD-FD link
+          open to the very end is not really very productive ...
 
-          Kern: notes shortened. This can be done without the need for 
-          inodes. It is essentially the same as the current Verify job,
-          but one additional database record must be written, which does 
-          not need any database change.
+   Why:   Makes backup of laptops much easier.
 
-Item 25:  Implement creation and maintenance of copy pools
-  Date:   27 November 2005
-  Origin: David Boyes (dboyes at sinenomine dot net)
-  Status:
+Item 22:  Permit multiple Media Types in an Autochanger
+  Origin: Kern
+  Status: Done. Implemented in 1.38.9 (I think).  
 
-  What:   I would like Bacula to have the capability to write copies
-          of backed-up data on multiple physical volumes selected
-          from different pools without transferring the data
-          multiple times, and to accept any of the copy volumes
-          as valid for restore.
+  What:   Modify the Storage daemon so that multiple Media Types
+          can be specified in an autochanger. This would be somewhat
+          of a simplistic implementation in that each drive would
+          still be allowed to have only one Media Type.  However,
+          the Storage daemon will ensure that only a drive with
+          the Media Type that matches what the Director specifies
+          is chosen.
 
-  Why:    In many cases, businesses are required to keep offsite
-          copies of backup volumes, or just wish for simple
-          protection against a human operator dropping a storage
-          volume and damaging it. The ability to generate multiple
-          volumes in the course of a single backup job allows
-          customers to simple check out one copy and send it
-          offsite, marking it as out of changer or otherwise
-          unavailable. Currently, the library and magazine
-          management capability in Bacula does not make this process
-          simple.
+  Why:    This will permit user with several different drive types
+          to make full use of their autochangers.
 
-          Restores would use the copy of the data on the first
-          available volume, in order of copy pool chain definition.
+Item 23:  Allow different autochanger definitions for one autochanger.
+  Date:   28 October 2005
+  Origin: Kern
+  Status: 
 
-          This is also a major scalability issue -- as the number of
-          clients increases beyond several thousand, and the volume
-          of data increases, transferring the data multiple times to
-          produce additional copies of the backups will become
-          physically impossible due to transfer speed
-          issues. Generating multiple copies at server side will
-          become the only practical option. 
+  What:   Currently, the autochanger script is locked based on
+          the autochanger. That is, if multiple drives are being
+          simultaneously used, the Storage daemon ensures that only
+          one drive at a time can access the mtx-changer script.
+          This change would base the locking on the control device,
+          rather than the autochanger. It would then permit two autochanger
+          definitions for the same autochanger, but with different 
+          drives. Logically, the autochanger could then be "partitioned"
+          for different jobs, clients, or class of jobs, and if the locking
+          is based on the control device (e.g. /dev/sg0) the mtx-changer
+          script will be locked appropriately.
 
-  How:    I suspect that this will require adding a multiplexing
-          SD that appears to be a SD to a specific FD, but 1-n FDs
-          to the specific back end SDs managing the primary and copy
-          pools.  Storage pools will also need to acquire parameters
-          to define the pools to be used for copies. 
+  Why:    This will permit users to partition autochangers for specific
+          use. It would also permit implementation of multiple Media
+          Types with no changes to the Storage daemon.
 
-  Notes:  I would commit some of my developers' time if we can agree
-          on the design and behavior. 
-===============================================
-Not in Dec 2005 Vote:
-Item n:   One line summary ...
-  Date:   29 November 2005
-  Origin: Florian Schnabel <florian.schnabel at docufy dot de>
-  Status:
+Item 24:  Automatic disabling of devices
+   Date:   2005-11-11
+   Origin: Peter Eriksson <peter at ifm.liu dot se>
+   Status:
+
+   What:  After a configurable amount of fatal errors with a tape drive
+          Bacula should automatically disable further use of a certain
+          tape drive. There should also be "disable"/"enable" commands in
+          the "bconsole" tool.
+
+   Why:   On a multi-drive jukebox there is a possibility of tape drives
+          going bad during large backups (needing a cleaning tape run,
+          tapes getting stuck). It would be advantageous if Bacula would
+          automatically disable further use of a problematic tape drive
+          after a configurable amount of errors has occurred.
+
+          An example: I have a multi-drive jukebox (6 drives, 380+ slots)
+          where tapes occasionally get stuck inside the drive. Bacula will
+          notice that the "mtx-changer" command will fail and then fail
+          any backup jobs trying to use that drive. However, it will still
+          keep on trying to run new jobs using that drive and fail -
+          forever, and thus failing lots and lots of jobs... Since we have
+          many drives Bacula could have just automatically disabled
+          further use of that drive and used one of the other ones
+          instead.
+
+Item 25:  Implement huge exclude list support using hashing.
+  Date:   28 October 2005
+  Origin: Kern
+  Status: 
+
+  What:   Allow users to specify very large exclude list (currently
+          more than about 1000 files is too many).
+
+  Why:    This would give the users the ability to exclude all
+          files that are loaded with the OS (e.g. using rpms
+          or debs). If the user can restore the base OS from
+          CDs, there is no need to backup all those files. A
+          complete restore would be to restore the base OS, then
+          do a Bacula restore. By excluding the base OS files, the
+          backup set will be *much* smaller.
 
-     What: An easy option to skip a certain job  on a certain date.
-     Why:  You could then easily skip tape backups on holidays.  Especially
-           if you got no autochanger and can only fit one backup on a tape
-           that would be really handy, other jobs could proceed normally
-           and you won't get errors that way.
 
 ============= Empty Feature Request form ===========
 Item n:   One line summary ...
@@ -743,3 +752,325 @@ Item n:   One line summary ...
 
   Notes:  Additional notes or features (omit if not used)
 ============== End Feature Request form ==============
+
+
+===============================================
+Feature requests submitted after cutoff for December 2005 vote
+  and not yet discussed.
+===============================================
+Item n:   Allow skipping execution of Jobs
+  Date:   29 November 2005
+  Origin: Florian Schnabel <florian.schnabel at docufy dot de>
+  Status:
+
+     What: An easy option to skip a certain job  on a certain date.
+     Why:  You could then easily skip tape backups on holidays.  Especially
+           if you got no autochanger and can only fit one backup on a tape
+           that would be really handy, other jobs could proceed normally
+           and you won't get errors that way.
+
+===================================================
+
+Item n: archive data
+
+  Origin: calvin streeting calvin at absentdream dot com
+  Date:   15/5/2006
+
+  What:   The abilty to archive to media (dvd/cd) in a uncompressd format
+          for dead filing (archiving not backing up)
+
+  Why:  At my works when jobs are finished and moved off of the main file
+        servers (raid based systems) onto a simple linux file server (ide based
+        system) so users can find old information without contacting the IT
+        dept.
+
+        So this data dosn't realy change it only gets added to,
+        But it also needs backing up.  At the moment it takes
+        about 8 hours to back up our servers (working data) so
+        rather than add more time to existing backups i am trying
+        to implement a system where we backup the acrhive data to
+        cd/dvd these disks would only need to be appended to
+        (burn only new/changed files to new disks for off site
+        storage).  basialy understand the differnce between
+        achive data and live data.
+
+  Notes: scan the data and email me when it needs burning divide
+          into predifind chunks keep a recored of what is on what
+          disk make me a label (simple php->mysql=>pdf stuff) i
+          could do this bit ability to save data uncompresed so
+          it can be read in any other system (future proof data)
+          save the catalog with the disk as some kind of menu
+          system 
+
+Item :  Tray monitor window cleanups
+  Origin: Alan Brown ajb2 at mssl dot ucl dot ac dot uk
+  Date:   24 July 2006
+  Status:
+  What:   Resizeable and scrollable windows in the tray monitor.
+
+  Why:    With multiple clients, or with many jobs running, the displayed
+          window often ends up larger than the available screen, making
+          the trailing items difficult to read.
+
+   Notes:
+
+  Item :  Clustered file-daemons
+  Origin: Alan Brown ajb2 at mssl dot ucl dot ac dot uk
+  Date:   24 July 2006
+  Status:
+  What:   A "virtual" filedaemon, which is actually a cluster of real ones.
+
+  Why:    In the case of clustered filesystems (SAN setups, GFS, or OCFS2, etc)
+          multiple machines may have access to the same set of filesystems
+
+          For performance reasons, one may wish to initate backups from
+          several of these machines simultaneously, instead of just using
+          one backup source for the common clustered filesystem.
+
+          For obvious reasons, normally backups of $A-FD/$PATH and
+          B-FD/$PATH are treated as different backup sets. In this case
+          they are the same communal set.
+
+          Likewise when restoring, it would be easier to just specify
+          one of the cluster machines and let bacula decide which to use.
+
+          This can be faked to some extent using DNS round robin entries
+          and a virtual IP address, however it means "status client" will
+          always give bogus answers. Additionally there is no way of
+          spreading the load evenly among the servers.
+
+          What is required is something similar to the storage daemon
+          autochanger directives, so that Bacula can keep track of
+          operating backups/restores and direct new jobs to a "free"
+          client.
+
+   Notes:
+
+Item :  Tray monitor window cleanups
+  Origin: Alan Brown ajb2 at mssl dot ucl dot ac dot uk
+  Date:   24 July 2006
+  Status:
+  What:   Resizeable and scrollable windows in the tray monitor.
+
+  Why:    With multiple clients, or with many jobs running, the displayed
+          window often ends up larger than the available screen, making
+          the trailing items difficult to read.
+
+  Notes:
+
+Item:    Commercial database support
+  Origin: Russell Howe <russell_howe dot wreckage dot org>
+  Date:   26 July 2006
+  Status:
+
+  What:   It would be nice for the database backend to support more 
+          databases. I'm thinking of SQL Server at the moment, but I guess Oracle, 
+          DB2, MaxDB, etc are all candidates. SQL Server would presumably be 
+          implemented using FreeTDS or maybe an ODBC library?
+
+  Why:    We only really have one database server, which is MS SQL Server 
+          2000. Maintaining a second one for the backup software (we grew out of 
+          SQLite, which I liked, but which didn't work so well with our database 
+          size). We don't really have a machine with the resources to run 
+          postgres, and would rather only maintain a single DBMS. We're stuck with 
+          SQL Server because pretty much all the company's custom applications 
+          (written by consultants) are locked into SQL Server 2000. I can imagine 
+          this scenario is fairly common, and it would be nice to use the existing 
+          properly specced database server for storing Bacula's catalog, rather 
+          than having to run a second DBMS.
+
+
+Item n:   Split documentation
+  Origin: Maxx <maxxatworkat gmail dot com>
+  Date:   27th July 2006
+  Status:
+
+  What:   Split documentation in several books
+
+  Why:    Bacula manual has now more than 600 pages, and looking for
+          implementation details is getting complicated.  I think
+          it would be good to split the single volume in two or
+          maybe three parts:
+
+          1) Introduction, requirements and tutorial, typically
+             are useful only until first installation time
+
+          2) Basic installation and configuration, with all the
+             gory details about the directives supported 3)
+             Advanced Bacula: testing, troubleshooting, GUI and
+             ancillary programs, security managements, scripting,
+             etc.
+
+  Notes:
+
+Item n: Include an option to operate on all pools when doing
+        update vol parameters
+
+   Origin: Dmitriy Pinchukov <absh@bossdev.kiev.ua>
+   Date:   16 August 2006
+   Status:
+
+   What: When I do update -> Volume parameters -> All Volumes
+         from Pool, then I have to select pools one by one.  I'd like
+         console to have an option like "0: All Pools" in the list of
+         defined pools.
+
+   Why: I have many pools and therefore unhappy with manually
+        updating each of them using update -> Volume parameters -> All
+        Volumes from Pool -> pool #.
+
+Item n:   Automatic promotion of backup levels
+   Date:   19 January 2006
+   Origin: Adam Thornton <athornton@sinenomine.net>
+   Status: Blue sky
+
+   What: Amanda has a feature whereby it estimates the space that a  
+         differential, incremental, and full backup would take.  If the  
+         difference in space required between the scheduled level and the next  
+         level up is beneath some user-defined critical threshold, the backup  
+         level is bumped to the next type.  Doing this minimizes the number of  
+         volumes necessary during a restore, with a fairly minimal cost in  
+         backup media space.
+
+   Why:   I know at least one (quite sophisticated and smart) user  
+          for whom the absence of this feature is a deal-breaker in terms of  
+          using Bacula; if we had it it would eliminate the one cool thing  
+          Amanda can do and we can't (at least, the one cool thing I know of).
+
+
+
+
+Item n+1:   Incorporation of XACML2/SAML2 parsing
+   Date:   19 January 2006
+   Origin: Adam Thornton <athornton@sinenomine.net>
+   Status: Blue sky
+
+   What:   XACML is "eXtensible Access Control Markup Language" and  
+          "SAML is the "Security Assertion Markup Language"--an XML standard  
+          for making statements about identity and authorization.  Having these  
+          would give us a framework to approach ACLs in a generic manner, and  
+          in a way flexible enough to support the four major sorts of ACLs I  
+          see as a concern to Bacula at this point, as well as (probably) to  
+          deal with new sorts of ACLs that may appear in the future.
+
+   Why:    Bacula is beginning to need to back up systems with ACLs  
+          that do not map cleanly onto traditional Unix permissions.  I see  
+          four sets of ACLs--in general, mutually incompatible with one  
+          another--that we're going to need to deal with.  These are: NTFS  
+          ACLs, POSIX ACLs, NFSv4 ACLS, and AFS ACLS.  (Some may question the  
+          relevance of AFS; AFS is one of Sine Nomine's core consulting  
+          businesses, and having a reputable file-level backup and restore  
+          technology for it (as Tivoli is probably going to drop AFS support  
+          soon since IBM no longer supports AFS) would be of huge benefit to  
+          our customers; we'd most likely create the AFS support at Sine Nomine  
+          for inclusion into the Bacula (and perhaps some changes to the  
+          OpenAFS volserver) core code.)
+
+          Now, obviously, Bacula already handles NTFS just fine.  However, I  
+          think there's a lot of value in implementing a generic ACL model, so  
+          that it's easy to support whatever particular instances of ACLs come  
+          down the pike: POSIX ACLS (think SELinux) and NFSv4 are the obvious  
+          things arriving in the Linux world in a big way in the near future.   
+          XACML, although overcomplicated for our needs, provides this  
+          framework, and we should be able to leverage other people's  
+          implementations to minimize the amount of work *we* have to do to get  
+          a generic ACL framework.  Basically, the costs of implementation are  
+          high, but they're largely both external to Bacula and already sunk.
+
+Item 1:   Add an over-ride in the Schedule configuration to use a
+          different pool for different backup types.
+
+Date:   19 Jan 2005
+Origin: Chad Slater <chad.slater@clickfox.com>
+Status: 
+                                                
+  What:   Adding a FullStorage=BigTapeLibrary in the Schedule resource
+          would help those of us who use different storage devices for different
+          backup levels cope with the "auto-upgrade" of a backup.
+
+  Why:    Assume I add several new device to be backed up, i.e. several
+          hosts with 1TB RAID.  To avoid tape switching hassles, incrementals are
+          stored in a disk set on a 2TB RAID.  If you add these devices in the
+          middle of the month, the incrementals are upgraded to "full" backups,
+          but they try to use the same storage device as requested in the
+          incremental job, filling up the RAID holding the differentials.  If we
+          could override the Storage parameter for full and/or differential
+          backups, then the Full job would use the proper Storage device, which
+          has more capacity (i.e. a 8TB tape library.
+
+
+Item:     Implement multiple numeric backup levels as supported by dump
+Date:     3 April 2006
+Origin:   Daniel Rich <drich@employees.org>
+Status:
+What:     Dump allows specification of backup levels numerically instead of just
+          "full", "incr", and "diff".  In this system, at any given level, all
+          files are backed up that were were modified since the last backup of a
+          higher level (with 0 being the highest and 9 being the lowest).  A
+          level 0 is therefore equivalent to a full, level 9 an incremental, and
+          the levels 1 through 8 are varying levels of differentials.  For
+          bacula's sake, these could be represented as "full", "incr", and
+          "diff1", "diff2", etc.
+
+Why:      Support of multiple backup levels would provide for more advanced backup
+          rotation schemes such as "Towers of Hanoi".  This would allow better
+          flexibility in performing backups, and can lead to shorter recover
+          times.
+
+Notes:    Legato Networker supports a similar system with full, incr, and 1-9 as
+          levels.
+
+Kern notes: I think this would add very little functionality, but a *lot* of
+          additional overhead to Bacula.
+
+Item 1:   include JobID in spool file name
+  Origin: Mark Bergman <mark.bergman@uphs.upenn.edu>
+  Date:  Tue Aug 22 17:13:39 EDT 2006
+  Status:
+
+  What:   Change the name of the spool file to include the JobID
+
+  Why:    JobIDs are the common key used to refer to jobs, yet the 
+        spoolfile name doesn't include that information. The date/time
+        stamp is useful (and should be retained).
+
+
+
+Item 2:   include timestamp of job launch in "stat clients" output
+  Origin: Mark Bergman <mark.bergman@uphs.upenn.edu>
+  Date:  Tue Aug 22 17:13:39 EDT 2006
+  Status:
+
+  What:   The "stat clients" command doesn't include any detail on when
+        the active backup jobs were launched.
+
+  Why:   Including the timestamp would make it much easier to decide whether
+        a job is running properly. 
+
+  Notes: It may be helpful to have the output from "stat clients" formatted 
+        more like that from "stat dir" (and other commands), in a column
+        format. The per-client information that's currently shown (level,
+        client name, JobId, Volume, pool, device, Files, etc.) is good, but
+        somewhat hard to parse (both programmatically and visually), 
+        particularly when there are many active clients.
+
+Item 1:   Filesystemwatch triggered backup.
+  Date:   31 August 2006
+  Origin: Jesper Krogh <jesper@krogh.cc>
+  Status: Unimplemented, depends probably on "client initiated backups"
+
+  What:   With inotify and similar filesystem triggeret notification
+          systems is it possible to have the file-daemon to monitor
+          filesystem changes and initiate backup.
+
+  Why:    There are 2 situations where this is nice to have.
+          1) It is possible to get a much finer-grained backup than
+             the fixed schedules used now.. A file created and deleted
+             a few hours later, can automatically be caught.
+
+          2) The introduced load on the system will probably be
+             distributed more even on the system.
+
+  Notes:  This can be combined with configration that specifies
+          something like: "at most every 15 minutes or when changes
+          consumed XX MB".