X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=bacula%2Fprojects;h=add7b575f3d943a932024ccac394c579dd863b2a;hb=867ad3783ac49e8bb476201cdc0a88d7ca547343;hp=32d851f7d6c2bc6be7c177e8d397cfa417440d4e;hpb=fe27bfb5190d54a23b063683901c13a3699c9f97;p=bacula%2Fbacula

diff --git a/bacula/projects b/bacula/projects
index 32d851f7d6..add7b575f3 100644
--- a/bacula/projects
+++ b/bacula/projects
@@ -1,91 +1,97 @@
                 
 Projects:
                      Bacula Projects Roadmap 
-                       29 November 2005
+                    Status updated 14 April 2007
+                   After re-ordering in vote priority
+
+Items Completed:
+Item:  18   Quick release of FD-SD connection after backup.
+Item:  40   Include JobID in spool file name
+Item:  25   Implement huge exclude list support using dlist   
+Item:  41   Enable to relocate files and directories when restoring
 
 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
-
-
-Below, you will find more information on future projects:
-
-Item 1:   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
-          Kern.
-
-  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:   Riege Software have asked for the following migration
-           triggers:
-           Age of Job
-           Highwater mark (stopped by Lowwater mark?)
-                            
-  Notes:  Migration could be additionally triggered by:
-           Number of Jobs
-           Number of Volumes
-
-
-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
+Item:   1   Accurate restoration of renamed/deleted files
+Item:   2   Implement a Bacula GUI/management tool.
+Item:   3   Allow FD to initiate a backup
+Item:   4   Merge multiple backups (Synthetic Backup or Consolidation).
+Item:   5   Deletion of Disk-Based Bacula Volumes
+Item:   6   Implement Base jobs.
+Item:   7   Implement creation and maintenance of copy pools
+Item:   8   Directive/mode to backup only file changes, not entire file
+Item:   9   Implement a server-side compression feature
+Item:  10   Improve Bacula's tape and drive usage and cleaning management.
+Item:  11   Allow skipping execution of Jobs
+Item:  12   Add a scheduling syntax that permits weekly rotations
+Item:  13   Archival (removal) of User Files to Tape
+Item:  14   Cause daemons to use a specific IP address to source communications
+Item:  15   Multiple threads in file daemon for the same job
+Item:  16   Add Plug-ins to the FileSet Include statements.
+Item:  17   Restore only file attributes (permissions, ACL, owner, group...)
+Item:  18*  Quick release of FD-SD connection after backup.
+Item:  19   Implement a Python interface to the Bacula catalog.
+Item:  20   Archive data
+Item:  21   Split documentation
+Item:  22   Implement support for stacking arbitrary stream filters, sinks.
+Item:  23   Implement from-client and to-client on restore command line.
+Item:  24   Add an override in Schedule for Pools based on backup types.
+Item:  25*  Implement huge exclude list support using hashing.
+Item:  26   Implement more Python events in Bacula.
+Item:  27   Incorporation of XACML2/SAML2 parsing
+Item:  28   Filesystem watch triggered backup.
+Item:  29   Allow inclusion/exclusion of files in a fileset by creation/mod times
+Item:  30   Tray monitor window cleanups
+Item:  31   Implement multiple numeric backup levels as supported by dump
+Item:  32   Automatic promotion of backup levels
+Item:  33   Clustered file-daemons
+Item:  34   Commercial database support
+Item:  35   Automatic disabling of devices
+Item:  36   An option to operate on all pools with update vol parameters
+Item:  37   Add an item to the restore option where you can select a pool
+Item:  38   Include timestamp of job launch in "stat clients" output
+Item:  39   Message mailing based on backup types
+Item:  40*  Include JobID in spool file name
+Item:  41*  Enable to relocate files and directories when restoring
+
+Item  1:  Accurate restoration of renamed/deleted files
+  Date:   28 November 2005
+  Origin: Martin Simmons (martin at lispworks dot com)
+  Status: Robert Nelson will implement this
+
+  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.
+
+          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.
 
-  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.
+  Why:    Incremental/Differential would be much more useful if this worked.
+
+  Notes:  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.  
 
-  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.
+          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  2:  Implement a Bacula GUI/management tool.
   Origin: Kern
   Date:   28 October 2005
-  Status: 
+  Status: In progress
 
   What:   Implement a Bacula console, and management tools
-          using Python and Qt or GTK.
+          probably using Qt3 and C++.
 
   Why:    Don't we already have a wxWidgets GUI?  Yes, but
           it is written in C++ and changes to the user interface
@@ -98,43 +104,81 @@ Item 3:   Implement a Bacula GUI/management tool using Python.
           Python, which will give many more users easy (or easier)
           access to making additions or modifications.
 
- Notes:   This is currently being implemented using Python-GTK by       
-          Lucas Di Pentima <lucas at lunix dot com dot ar>
+ Notes:   There is a partial Python-GTK implementation
+          Lucas Di Pentima <lucas at lunix dot com dot ar> but
+          it is no longer being developed.
 
+Item  3:  Allow FD to initiate a backup
+  Origin: Frank Volf (frank at deze dot org)
+  Date:   17 November 2005
+  Status:
 
-Item 4:   Implement a Python interface to the Bacula catalog.
-  Date:   28 October 2005
-  Origin: Kern
-  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.
 
-  What:   Implement an interface for Python scripts to access
-          the catalog through Bacula.
+   Why:   Makes backup of laptops much easier.
 
-  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: 
+Item  4:  Merge multiple backups (Synthetic Backup or Consolidation).
+  Origin: Marc Cousin and Eric Bollengier 
+  Date:   15 November 2005
+  Status: Waiting implementation. Depends on first implementing 
+          project Item 2 (Migration) which is now done.
 
-  What:   Allow Python scripts to be called at more places 
-          within Bacula and provide additional access to Bacula
-          internal variables.
+  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.
+          In effect, it is like a restore but to the backup medium.
 
-  Why:    This will permit users to customize Bacula through
-          Python scripts.
+          For instance, say that last Sunday we made a full backup.  Then
+          all week long, we created incremental backups, in order to do
+          them fast.  Now comes Sunday again, and we need another full.
+          The merged backup makes it possible to do instead an incremental
+          backup (during the night for instance), and then create a merged
+          backup during the day, by using the full and incrementals from
+          the week.  The merged backup will be exactly like a full made
+          Sunday night on the tape, but the production interruption on the
+          Client will be minimal, as the Client will only have to send
+          incrementals.
 
-  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).
+          In fact, if it's done correctly, you could merge all the
+          Incrementals into single Incremental, or all the Incrementals
+          and the last Differential into a new Differential, or the Full,
+          last differential and all the Incrementals into a new Full
+          backup.  And there is no need to involve the Client.
+
+  Why:    The benefit is that :
+          - the Client just does an incremental ;
+          - the merged backup on tape is just as a single full backup,
+            and can be restored very fast.
 
+          This is also a way of reducing the backup data since the old
+          data can then be pruned (or not) from the catalog, possibly
+          allowing older volumes to be recycled
 
-Item 6:   Implement Base jobs.
+Item  5:  Deletion of Disk-Based Bacula Volumes
+  Date:   Nov 25, 2005
+  Origin: Ross Boylan <RossBoylan at stanfordalumni dot org> (edited
+          by Kern)
+  Status:         
+
+   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 allow users more control over their Volumes and
+          prevent disk based volumes from consuming too much space.
+
+  Notes:  The following two directives might do the trick:
+
+          Volume Data Retention = <time period>
+          Remove Volume After = <time period>
+
+          The migration project should also remove a Volume that is
+          migrated. This might also work for tape Volumes.
+
+Item  6:  Implement Base jobs.
   Date:   28 October 2005
   Origin: Kern
   Status: 
@@ -168,101 +212,87 @@ 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: 
+Item  7:  Implement creation and maintenance of copy pools
+  Date:   27 November 2005
+  Origin: David Boyes (dboyes at sinenomine dot net)
+  Status:
 
-  What:   Allow users to specify very large exclude list (currently
-          more than about 1000 files is too many).
+  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:    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.
+  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.
 
-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
+          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:   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.
+  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 user with several different drive types
-          to make full use of their autochangers.
+  Notes:  I would commit some of my developers' time if we can agree
+          on the design and behavior. 
 
-Item 11:  Allow different autochanger definitions for one autochanger.
-  Date:   28 October 2005
-  Origin: Kern
+Item  8:  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: 
 
-  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: 
+  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
+          it would be nice to have a mode whereby only the changes to the
+          file would be backed up when it is changed.
 
-  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:    This would save lots of space when backing up large files such as 
+          logs, mbox files, Outlook PST files and the like.
 
-  Why:    Performance enhancement.
+  Notes:  This would require the usage of disk-based volumes as comparing 
+          files would not be feasible using a tape drive.
 
-Item 13:  Improve Baculas tape and drive usage and cleaning management.
+Item  9:  Implement a server-side compression feature
+  Date:   18 December 2006
+  Origin: Vadim A. Umanski , e-mail umanski@ext.ru
+  Status:
+  What:   The ability to compress backup data on server receiving data
+          instead of doing that on client sending data.
+  Why:    The need is practical. I've got some machines that can send
+          data to the network 4 or 5 times faster than compressing
+          them (I've measured that). They're using fast enough SCSI/FC
+          disk subsystems but rather slow CPUs (ex. UltraSPARC II).
+          And the backup server has got a quite fast CPUs (ex. Dual P4
+          Xeons) and quite a low load. When you have 20, 50 or 100 GB
+          of raw data - running a job 4 to 5 times faster - that
+          really matters. On the other hand, the data can be
+          compressed 50% or better - so losing twice more space for
+          disk backup is not good at all. And the network is all mine
+          (I have a dedicated management/provisioning network) and I
+          can get as high bandwidth as I need - 100Mbps, 1000Mbps...
+          That's why the server-side compression feature is needed!
+  Notes:
+
+Item 10:  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,90 +360,226 @@ 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 11:  Allow skipping execution of Jobs
+  Date:   29 November 2005
+  Origin: Florian Schnabel <florian.schnabel at docufy dot de>
+  Status:
 
-Item 14:  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).
+    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.
 
-  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.
-          In effect, it is like a restore but to the backup medium.
+Item 12:  Add a scheduling syntax that permits weekly rotations
+   Date:  15 December 2006
+  Origin: Gregory Brauer (greg at wildbrain dot com)
+  Status:
 
-          For instance, say that last Sunday we made a full backup.  Then
-          all week long, we created incremental backups, in order to do
-          them fast.  Now comes Sunday again, and we need another full.
-          The merged backup makes it possible to do instead an incremental
-          backup (during the night for instance), and then create a merged
-          backup during the day, by using the full and incrementals from
-          the week.  The merged backup will be exactly like a full made
-          Sunday night on the tape, but the production interruption on the
-          Client will be minimal, as the Client will only have to send
-          incrementals.
+   What:  Currently, Bacula only understands how to deal with weeks of the
+          month or weeks of the year in schedules.  This makes it impossible
+          to do a true weekly rotation of tapes.  There will always be a
+          discontinuity that will require disruptive manual intervention at
+          least monthly or yearly because week boundaries never align with
+          month or year boundaries.
+
+          A solution would be to add a new syntax that defines (at least)
+          a start timestamp, and repetition period.
+
+   Why:   Rotated backups done at weekly intervals are useful, and Bacula
+          cannot currently do them without extensive hacking.
+
+   Notes: Here is an example syntax showing a 3-week rotation where full
+          Backups would be performed every week on Saturday, and an
+          incremental would be performed every week on Tuesday.  Each
+          set of tapes could be removed from the loader for the following
+          two cycles before coming back and being reused on the third
+          week.  Since the execution times are determined by intervals
+          from a given point in time, there will never be any issues with
+          having to adjust to any sort of arbitrary time boundary.  In
+          the example provided, I even define the starting schedule
+          as crossing both a year and a month boundary, but the run times
+          would be based on the "Repeat" value and would therefore happen
+          weekly as desired.
+
+
+          Schedule {
+              Name = "Week 1 Rotation"
+              #Saturday.  Would run Dec 30, Jan 20, Feb 10, etc.
+              Run {
+                  Options {
+                      Type   = Full
+                      Start  = 2006-12-30 01:00
+                      Repeat = 3w
+                  }
+              }
+              #Tuesday.  Would run Jan 2, Jan 23, Feb 13, etc.
+              Run {
+                  Options {
+                      Type   = Incremental
+                      Start  = 2007-01-02 01:00
+                      Repeat = 3w
+                  }
+              }
+          }
 
-          In fact, if it's done correctly, you could merge all the
-          Incrementals into single Incremental, or all the Incrementals
-          and the last Differential into a new Differential, or the Full,
-          last differential and all the Incrementals into a new Full
-          backup.  And there is no need to involve the Client.
+          Schedule {
+              Name = "Week 2 Rotation"
+              #Saturday.  Would run Jan 6, Jan 27, Feb 17, etc.
+              Run {
+                  Options {
+                      Type   = Full
+                      Start  = 2007-01-06 01:00
+                      Repeat = 3w
+                  }
+              }
+              #Tuesday.  Would run Jan 9, Jan 30, Feb 20, etc.
+              Run {
+                  Options {
+                      Type   = Incremental
+                      Start  = 2007-01-09 01:00
+                      Repeat = 3w
+                  }
+              }
+          }
 
-  Why:    The benefit is that :
-          - the Client just does an incremental ;
-          - the merged backup on tape is just as a single full backup,
-            and can be restored very fast.
+          Schedule {
+              Name = "Week 3 Rotation"
+              #Saturday.  Would run Jan 13, Feb 3, Feb 24, etc.
+              Run {
+                  Options {
+                      Type   = Full
+                      Start  = 2007-01-13 01:00
+                      Repeat = 3w
+                  }
+              }
+              #Tuesday.  Would run Jan 16, Feb 6, Feb 27, etc.
+              Run {
+                  Options {
+                      Type   = Incremental
+                      Start  = 2007-01-16 01:00
+                      Repeat = 3w
+                  }
+              }
+          }
 
-          This is also a way of reducing the backup data since the old
-          data can then be pruned (or not) from the catalog, possibly
-          allowing older volumes to be recycled
+Item 13:  Archival (removal) of User Files to Tape
+  Date:   Nov. 24/2005 
+  Origin: Ray Pengelly [ray at biomed dot queensu dot ca
+  Status: 
 
-Item 15:  Automatic disabling of devices
-   Date:   2005-11-11
-   Origin: Peter Eriksson <peter at ifm.liu dot se>
-   Status:
+  What:   The ability to archive data to storage based on certain parameters
+          such as age, size, or location.  Once the data has been written to
+          storage and logged it is then pruned from the originating
+          filesystem. Note! We are talking about user's files and not
+          Bacula Volumes.
 
-   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:    This would allow fully automatic storage management which becomes
+          useful for large datastores.  It would also allow for auto-staging
+          from one media type to another.
 
-   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.
+          Example 1) Medical imaging needs to store large amounts of data.
+          They decide to keep data on their servers for 6 months and then put
+          it away for long term storage.  The server then finds all files
+          older than 6 months writes them to tape.  The files are then removed
+          from the server.
 
-          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.
+          Example 2) All data that hasn't been accessed in 2 months could be
+          moved from high-cost, fibre-channel disk storage to a low-cost
+          large-capacity SATA disk storage pool which doesn't have as quick of
+          access time.  Then after another 6 months (or possibly as one
+          storage pool gets full) data is migrated to Tape.
 
+Item 14:  Cause daemons to use a specific IP address to source communications
+ Origin:  Bill Moran <wmoran@collaborativefusion.com>
+ Date:    18 Dec 2006
+ Status:
+ What:    Cause Bacula daemons (dir, fd, sd) to always use the ip address
+          specified in the [DIR|DF|SD]Addr directive as the source IP
+          for initiating communication.
+ Why:     On complex networks, as well as extremely secure networks, it's
+          not unusual to have multiple possible routes through the network.
+          Often, each of these routes is secured by different policies
+          (effectively, firewalls allow or deny different traffic depending
+          on the source address)
+          Unfortunately, it can sometimes be difficult or impossible to
+          represent this in a system routing table, as the result is
+          excessive subnetting that quickly exhausts available IP space.
+          The best available workaround is to provide multiple IPs to
+          a single machine that are all on the same subnet.  In order
+          for this to work properly, applications must support the ability
+          to bind outgoing connections to a specified address, otherwise
+          the operating system will always choose the first IP that
+          matches the required route.
+ Notes:   Many other programs support this.  For example, the following
+          can be configured in BIND:
+          query-source address 10.0.0.1;
+          transfer-source 10.0.0.2;
+          Which means queries from this server will always come from
+          10.0.0.1 and zone transfers will always originate from
+          10.0.0.2.
+
+Item 15:  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:  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
+  What:   I want the file daemon to start multiple threads for a backup
+          job so the fastest possible backup can be made.
 
-  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
-          it would be nice to have a mode whereby only the changes to the
-          file would be backed up when it is changed.
+          The file daemon could parse the FileSet information and start
+          one thread for each File entry located on a separate
+          filesystem.
 
-  Why:    This would save lots of space when backing up large files such as 
-          logs, mbox files, Outlook PST files and the like.
+          A confiuration option in the job section should be used to
+          enable or disable this feature. The confgutration option could
+          specify the maximum number of threads in the file daemon.
 
-  Notes:  This would require the usage of disk-based volumes as comparing 
-          files would not be feasible using a tape drive.
+          If the theads could spool the data to separate spool files
+          the restore process will not be much slower.
+
+  Why:    Multiple concurrent backups of a large fileserver with many
+          disks and controllers will be much faster.
+
+Item 16:  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 17:  Restore only file attributes (permissions, ACL, owner, group...)
+  Origin: Eric Bollengier
+  Date:   30/12/2006
+  Status:
+
+  What:   The goal of this project is to be able to restore only rights
+          and attributes of files without crushing them.
+
+  Why:    Who have never had to repair a chmod -R 777, or a wild update
+          of recursive right under Windows? At this time, you must have
+          enough space to restore data, dump attributes (easy with acl,
+          more complex with unix/windows rights) and apply them to your 
+          broken tree. With this options, it will be very easy to compare
+          right or ACL over the time.
+
+  Notes:  If the file is here, we skip restore and we change rights.
+          If the file isn't here, we can create an empty one and apply
+          rights or do nothing.
 
-Item 17:  Quick release of FD-SD connection after backup.
+Item 18:  Quick release of FD-SD connection after backup.
   Origin: Frank Volf (frank at deze dot org)
   Date:   17 November 2005
-  Status:
+  Status: Done -- implemented by Kern -- in CVS 26Jan07
 
    What:  In the Bacula implementation a backup is finished after all data
           and attributes are successfully written to storage.  When using a
@@ -445,283 +611,650 @@ Item 17:  Quick release of FD-SD connection after backup.
           has done the same thing -- so in a way keeping the SD-FD link
           open to the very end is not really very productive ...
 
-   Why:   Makes backup of laptops much easier.
-
-
-Item 18:  Add support for FileSets in user directories  CACHEDIR.TAG
-  Origin: Norbert Kiesel <nkiesel at tbdnetworks dot com>
-  Date:   21 November 2005
-  Status:
+   Why:   Makes backup of laptops much faster.
 
-  What:   CACHDIR.TAG is a proposal for identifying directories which
-          should be ignored for archiving/backup.  It works by ignoring
-          directory trees which have a file named CACHEDIR.TAG with a
-          specific content.  See
-          http://www.brynosaurus.com/cachedir/spec.html
-          for details.
-
-          From Peter Eriksson:
-          I suggest that if this is implemented (I've also asked for this
-          feature some year ago) that it is made compatible with Legato
-          Networkers ".nsr" files where you can specify a lot of options on
-          how to handle files/directories (including denying further
-          parsing of .nsr files lower down into the directory trees).  A
-          PDF version of the .nsr man page can be viewed at:
-
-          http://www.ifm.liu.se/~peter/nsr.pdf
-
-  Why:    It's a nice alternative to "exclude" patterns for directories
-          which don't have regular pathnames.  Also, it allows users to
-          control backup for themselves.  Implementation should be pretty
-          simple.  GNU tar >= 1.14 or so supports it, too.
-
-  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>
+Item 19:  Implement a Python interface to the Bacula catalog.
+  Date:   28 October 2005
+  Origin: Kern
   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
-          }
-
+  What:   Implement an interface for Python scripts to access
+          the catalog through Bacula.
 
-  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.
+  Why:    This will permit users to customize Bacula through
+          Python scripts.
 
-  Notes:  By Kern: I would prefer to have a single new Resource called
-          RunScript. More notes from Phil:
+Item 20:  Archive data
+  Date:   15/5/2006
+  Origin: calvin streeting calvin at absentdream dot com
+  Status:
 
-            RunBeforeJob = yes|no
-            RunAfterJob = yes|no
-            RunsAtJobLevels = All|Full|Diff|Inc
+  What:   The abilty to archive to media (dvd/cd) in a uncompressed 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 21:  Split documentation
+  Origin: Maxx <maxxatworkat gmail dot com>
+  Date:   27th July 2006
+  Status:
 
-          The AbortJobOnError, RunsOnSuccess and RunsOnFailure directives
-          could be optional, and possibly RunsWhen as well.
+  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.
+
+
+Item 22:  Implement support for stacking arbitrary stream filters, sinks.
+Date:     23 November 2006
+Origin:   Landon Fuller <landonf@threerings.net>
+Status:   Planning. Assigned to landonf.
+
+  What:   Implement support for the following:
+          - Stacking arbitrary stream filters (eg, encryption, compression,  
+            sparse data handling))
+          - Attaching file sinks to terminate stream filters (ie, write out  
+            the resultant data to a file)
+          - Refactor the restoration state machine accordingly
+
+   Why:   The existing stream implementation suffers from the following:
+           - All state (compression, encryption, stream restoration), is  
+             global across the entire restore process, for all streams. There are  
+             multiple entry and exit points in the restoration state machine, and  
+             thus multiple places where state must be allocated, deallocated,  
+             initialized, or reinitialized. This results in exceptional complexity  
+             for the author of a stream filter.
+           - The developer must enumerate all possible combinations of filters  
+             and stream types (ie, win32 data with encryption, without encryption,  
+             with encryption AND compression, etc).
+
+  Notes:  This feature request only covers implementing the stream filters/ 
+          sinks, and refactoring the file daemon's restoration implementation  
+          accordingly. If I have extra time, I will also rewrite the backup  
+          implementation. My intent in implementing the restoration first is to  
+          solve pressing bugs in the restoration handling, and to ensure that  
+          the new restore implementation handles existing backups correctly.
+
+          I do not plan on changing the network or tape data structures to  
+          support defining arbitrary stream filters, but supporting that  
+          functionality is the ultimate goal.
+
+          Assistance with either code or testing would be fantastic.
+
+Item 23:  Implement from-client and to-client on restore command line.
+   Date:  11 December 2006
+  Origin: Discussion on Bacula-users entitled 'Scripted restores to
+          different clients', December 2006 
+  Status: New feature request
+ 
+  What:   While using bconsole interactively, you can specify the client
+          that a backup job is to be restored for, and then you can
+          specify later a different client to send the restored files
+          back to. However, using the 'restore' command with all options
+          on the command line, this cannot be done, due to the ambiguous
+          'client' parameter. Additionally, this parameter means different
+          things depending on if it's specified on the command line or
+          afterwards, in the Modify Job screens.
+ 
+     Why: This feature would enable restore jobs to be more completely
+          automated, for example by a web or GUI front-end.
+ 
+   Notes: client can also be implied by specifying the jobid on the command
+          line
+
+Item 24:  Add an override in Schedule for Pools based on 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 25:  Implement huge exclude list support using hashing (dlists).
+  Date:   28 October 2005
+  Origin: Kern
+  Status: Done in 2.1.2 but was done with dlists (doubly linked lists
+          since hashing will not help. The huge list also supports
+          large include lists).
 
-          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.
+  What:   Allow users to specify very large exclude list (currently
+          more than about 1000 files is too many).
 
-          RunsOnSuccess would be ignored unless RunsWhen was set to After
-          (or RunsBeforeJob set to No), and default to Yes.
+  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.
 
-          RunsOnFailure would be ignored unless RunsWhen was set to After,
-          and default to No.
+Item 26:  Implement more Python events in Bacula.
+  Date:   28 October 2005
+  Origin: Kern
+  Status: 
 
-          Allow having the before/after status on the script command
-          line so that the same script can be used both before/after.
-          David Boyes.
+  What:   Allow Python scripts to be called at more places 
+          within Bacula and provide additional access to Bacula
+          internal variables.
 
-Item 20:  Allow FD to initiate a backup
-  Origin: Frank Volf (frank at deze dot org)
-  Date:   17 November 2005
-  Status:
+  Why:    This will permit users to customize Bacula through
+          Python scripts.
 
-   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.
+  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).
 
-   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)
+Item 27:  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 28:  Filesystem watch 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".
+
+Kern Notes: I would rather see this implemented by an external program
+          that monitors the Filesystem changes, then uses the console
+          to start the appropriate job.
+
+Item 29:  Allow inclusion/exclusion of files in a fileset by creation/mod times
+  Origin: Evan Kaufman <evan.kaufman@gmail.com>
+  Date:   January 11, 2006
   Status:
 
-  What:   I want the file daemon to start multiple threads for a backup
-          job so the fastest possible backup can be made.
-
-          The file daemon could parse the FileSet information and start
-          one thread for each File entry located on a separate
-          filesystem.
+  What:   In the vein of the Wild and Regex directives in a Fileset's
+          Options, it would be helpful to allow a user to include or exclude
+          files and directories by creation or modification times.
 
-          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.
+          You could factor the Exclude=yes|no option in much the same way it
+          affects the Wild and Regex directives.  For example, you could exclude
+          all files modified before a certain date:
 
-          If the theads could spool the data to separate spool files
-          the restore process will not be much slower.
+   Options {
+     Exclude = yes
+     Modified Before = ####
+   }
 
-  Why:    Multiple concurrent backups of a large fileserver with many
-          disks and controllers will be much faster.
+           Or you could exclude all files created/modified since a certain date:
 
-  Notes:  I am willing to try to implement this but I will probably
-          need some help and advice.  (No problem -- Kern)
+   Options {
+      Exclude = yes
+     Created Modified Since = ####
+   }
 
-Item 22:  Archival (removal) of User Files to Tape
+           The format of the time/date could be done several ways, say the number
+           of seconds since the epoch:
+           1137008553 = Jan 11 2006, 1:42:33PM   # result of `date +%s`
 
-  Date:   Nov. 24/2005 
+           Or a human readable date in a cryptic form:
+           20060111134233 = Jan 11 2006, 1:42:33PM   # YYYYMMDDhhmmss
 
-  Origin: Ray Pengelly [ray at biomed dot queensu dot ca
-  Status: 
+  Why:    I imagine a feature like this could have many uses. It would
+          allow a user to do a full backup while excluding the base operating
+          system files, so if I installed a Linux snapshot from a CD yesterday,
+          I'll *exclude* all files modified *before* today.  If I need to
+          recover the system, I use the CD I already have, plus the tape backup.
+          Or if, say, a Windows client is hit by a particularly corrosive
+          virus, and I need to *exclude* any files created/modified *since* the
+          time of infection.
 
-  What:   The ability to archive data to storage based on certain parameters
-          such as age, size, or location.  Once the data has been written to
-          storage and logged it is then pruned from the originating
-          filesystem. Note! We are talking about user's files and not
-          Bacula Volumes.
+  Notes:  Of course, this feature would work in concert with other
+          in/exclude rules, and wouldnt override them (or each other).
 
-  Why:    This would allow fully automatic storage management which becomes
-          useful for large datastores.  It would also allow for auto-staging
-          from one media type to another.
+  Notes:  The directives I'd imagine would be along the lines of
+          "[Created] [Modified] [Before|Since] = <date>".
+          So one could compare against 'ctime' and/or 'mtime', but ONLY 'before'
+           or 'since'.
 
-          Example 1) Medical imaging needs to store large amounts of data.
-          They decide to keep data on their servers for 6 months and then put
-          it away for long term storage.  The server then finds all files
-          older than 6 months writes them to tape.  The files are then removed
-          from the server.
 
-          Example 2) All data that hasn't been accessed in 2 months could be
-          moved from high-cost, fibre-channel disk storage to a low-cost
-          large-capacity SATA disk storage pool which doesn't have as quick of
-          access time.  Then after another 6 months (or possibly as one
-          storage pool gets full) data is migrated to Tape.
+Item 30:  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.
+
+
+Item 31:  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.
+        
+Item 32:  Automatic promotion of backup levels
+   Date:  19 January 2006
+  Origin: Adam Thornton <athornton@sinenomine.net>
+  Status: 
 
+    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 33:  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.
 
-Item 23:  Deletion of Disk-Based Bacula Volumes
-  Date:   Nov 25, 2005
-  Origin: Ross Boylan <RossBoylan at stanfordalumni dot org> (edited
-          by Kern)
-  Status:         
+  Why:    In the case of clustered filesystems (SAN setups, GFS, or OCFS2, etc)
+          multiple machines may have access to the same set of filesystems
 
-   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.
+          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.
 
-  Why:    This would allow users more control over their Volumes and
-          prevent disk based volumes from consuming too much space.
+          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.
 
-  Notes:  The following two directives might do the trick:
+          Likewise when restoring, it would be easier to just specify
+          one of the cluster machines and let bacula decide which to use.
 
-          Volume Data Retention = <time period>
-          Remove Volume After = <time period>
+          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.
 
-          The migration project should also remove a Volume that is
-          migrated. This might also work for tape Volumes.
+          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 24:  Accurate restoration of renamed/deleted files from
-          Incremental/Differential backups
-  Date:   28 November 2005
-  Origin: Martin Simmons (martin at lispworks dot com)
+Item 34:  Commercial database support
+  Origin: Russell Howe <russell_howe dot wreckage dot org>
+  Date:   26 July 2006
   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.
-
-          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.
+  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 35:  Automatic disabling of devices
+   Date:  2005-11-11
+  Origin: Peter Eriksson <peter at ifm.liu dot se>
+  Status:
 
-  Why:    Incremental/Differential would be much more useful if this worked.
+   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.
 
-  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.  
+   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.
 
-          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.
+          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 creation and maintenance of copy pools
-  Date:   27 November 2005
-  Origin: David Boyes (dboyes at sinenomine dot net)
+Item 36:  An option to operate on all pools with update vol parameters
+  Origin: Dmitriy Pinchukov <absh@bossdev.kiev.ua>
+   Date:  16 August 2006
   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.
+   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:    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:   I have many pools and therefore unhappy with manually
+          updating each of them using update -> Volume parameters -> All
+          Volumes from Pool -> pool #.
 
-          Restores would use the copy of the data on the first
-          available volume, in order of copy pool chain definition.
+Item 37:  Add an item to the restore option where you can select a pool
+  Origin: kshatriyak at gmail dot com
+    Date: 1/1/2006
+  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: In the restore option (Select the most recent backup for a
+          client) it would be useful to add an option where you can limit
+          the selection to a certain pool.
+
+     Why: When using cloned jobs, most of the time you have 2 pools - a
+          disk pool and a tape pool.  People who have 2 pools would like to
+          select the most recent backup from disk, not from tape (tape
+          would be only needed in emergency).  However, the most recent
+          backup (which may just differ a second from the disk backup) may
+          be on tape and would be selected.  The problem becomes bigger if
+          you have a full and differential - the most "recent" full backup
+          may be on disk, while the most recent differential may be on tape
+          (though the differential on disk may differ even only a second or
+          so).  Bacula will complain that the backups reside on different
+          media then.  For now the only solution now when restoring things
+          when you have 2 pools is to manually search for the right
+          job-id's and enter them by hand, which is a bit fault tolerant.
+
+Item 38:  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:
 
-  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. 
+  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:  I would commit some of my developers' time if we can agree
-          on the design and behavior. 
+  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 39:  Message mailing based on backup types
+ Origin:  Evan Kaufman <evan.kaufman@gmail.com>
+   Date:  January 6, 2006
+ Status:
+
+   What:  In the "Messages" resource definitions, allowing messages
+          to be mailed based on the type (backup, restore, etc.) and level
+          (full, differential, etc) of job that created the originating
+          message(s).
+
+ Why:     It would, for example, allow someone's boss to be emailed
+          automatically only when a Full Backup job runs, so he can
+          retrieve the tapes for offsite storage, even if the IT dept.
+          doesn't (or can't) explicitly notify him.  At the same time, his
+          mailbox wouldnt be filled by notifications of Verifies, Restores,
+          or Incremental/Differential Backups (which would likely be kept
+          onsite).
+
+ Notes:   One way this could be done is through additional message types, for example:
+
+   Messages {
+     # email the boss only on full system backups
+     Mail = boss@mycompany.com = full, !incremental, !differential, !restore, 
+            !verify, !admin
+     # email us only when something breaks
+     MailOnError = itdept@mycompany.com = all
+   }
+
+
+Item 40:  Include JobID in spool file name ****DONE****
+  Origin: Mark Bergman <mark.bergman@uphs.upenn.edu>
+  Date:   Tue Aug 22 17:13:39 EDT 2006
+  Status: Done. (patches/testing/project-include-jobid-in-spool-name.patch)
+          No need to vote for this item.
+
+  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).
+
+============= New Freature Requests after vote of 26 Jan 2007 ========
+Item  41: Enable to relocate files and directories when restoring
+  Date:   2007-03-01
+  Origin: Eric Bollengier <eric@eb.homelinux.org>
+  Status: Done.
+
+  What:   The where= option is not powerful enough. It will be
+          a great feature if bacula can restore a file in the
+          same directory, but with a different name, or in 
+          an other directory without recreating the full path.
+
+  Why:    When i want to restore a production environment to a
+          development environment, i just want change the first
+          directory. ie restore /prod/data/file.dat to /rect/data/file.dat.
+          At this time, i have to move by hand files. You must have a big
+          dump space to restore and move data after.
+
+          When i use Linux or SAN snapshot, i mount them to /mnt/snap_xxx
+          so, when a restore a file, i have to move by hand
+          from /mnt/snap_xxx/file to /xxx/file. I can't replace a file
+          easily.
+
+          When a user ask me to restore a file in its personal folder,
+          (without replace the existing one), i can't restore from
+          my_file.txt to my_file.txt.old witch is very practical.
+
+          
+  Notes:  I think we can enhance the where= option very easily by
+          allowing regexp expression. 
+
+          Since, many users think that regexp are not user friendly, i think
+          that bat, bconsole or brestore must provide a simple way to
+          configure where= option (i think to something like in
+          openoffice "search and replace").
+
+          Ie, if user uses where=/tmp/bacula-restore, we keep the old
+          fashion.
+
+          If user uses something like where=s!/prod!/test!, files will
+          be restored from /prod/xxx to /test/xxx.
+
+          If user uses something like where=s/$/.old/, files will
+          be restored from /prod/xxx.txt to /prod/xxx.txt.old.
+
+          If user uses something like where=s/txt$/old.txt/, files will
+          be restored from /prod/xxx.txt to /prod/xxx.old.txt
+
+          if user uses something like where=s/([a-z]+)$/old.$1/, files will
+          be restored from /prod/xxx.ext to /prod/xxx.old.ext
+
+Item n:   Implement Catalog directive for Pool resource in Director
+configuration 
+  Origin: Alan Davis adavis@ruckus.com
+  Date:   6 March 2007
+  Status: Submitted
+ 
+  What:   The current behavior is for the director to create all pools
+          found in the configuration file in all catalogs.  Add a
+          Catalog directive to the Pool resource to specify which
+          catalog to use for each pool definition.
+ 
+  Why:    This allows different catalogs to have different pool
+          attributes and eliminates the side-effect of adding
+          pools to catalogs that don't need/use them.
+ 
+  Notes:  
+
+
+Item n:   Implement NDMP protocol support
+  Origin: Alan Davis
+  Date:   06 March 2007
+  Status: Submitted
+
+  What:   Network Data Management Protocol is implemented by a number of
+          NAS filer vendors to enable backups using third-party
+          software.
+
+  Why:    This would allow NAS filer backups in Bacula without incurring
+          the overhead of NFS or SBM/CIFS.
+
+  Notes:  Further information is available:
+          http://www.ndmp.org
+          http://www.ndmp.org/wp/wp.shtml
+          http://www.traakan.com/ndmjob/index.html
+
+          There are currently no viable open-source NDMP
+          implementations.  There is a reference SDK and example
+          app available from ndmp.org but it has problems
+          compiling on recent Linux and Solaris OS'.  The ndmjob
+          reference implementation from Traakan is known to
+          compile on Solaris 10.
+
+  Notes (Kern): I am not at all in favor of this until NDMP becomes
+          an Open Standard or until there are Open Source libraries
+          that interface to it.
+
+Item n: make changing "spooldata=yes|no" possible for
+        manual/interactive jobs
+
+Origin: Marc Schiffbauer <marc@schiffbauer.net>
+
+Date:   12 April 2007)
+
+Status: NEW
+
+What:   Make it possible to modify the spooldata option
+        for a job when being run from within the console.
+        Currently it is possible to modify the backup level
+        and the spooldata setting in a Schedule resource.
+        It is also possible to modify the backup level when using
+        the "run" command in the console. 
+        But it is currently not possible to to the same 
+        with "spooldata=yes|no" like:
+
+        run job=MyJob level=incremental spooldata=yes
+
+Why:    In some situations it would be handy to be able to switch
+        spooldata on or off for interactive/manual jobs based on
+        which data the admin expects or how fast the LAN/WAN
+        connection currently is.
 
+Notes:  ./.
 
 ============= Empty Feature Request form ===========
-Item n:   One line summary ...
+Item  n:  One line summary ...
   Date:   Date submitted 
   Origin: Name and email of originator.
   Status: