Change text

[bacula/bacula] / bacula / projects

diff --git a/bacula/projects b/bacula/projects
index ef0dd3ec838b998a4cf9da65aa512658a4cfd9f6..e5b7e2c35e966a3368bc30f2b31c6c4bbba48146 100644 (file)
--- a/bacula/projects
+++ b/bacula/projects
@@ -1,7 +1,7 @@
                 
 Projects:
                      Bacula Projects Roadmap 
-                    Status updated 22 February 2008
+                    Status updated 19 March 2008
 
 Items Completed:
 
@@ -1274,6 +1274,56 @@ Item 1: Backup and Restore of Windows Encrypted Files through raw encryption fun
 
               Run = pool=Monthly last Day of the Month at 23:50
 
+   Date: 20 March 2008
+
+   Origin: Frank Sweetser <fs@wpi.edu>
+
+   What: Add a new SD directive, "minimum spool size" (or similar).  This
+         directive would specify a minimum level of free space available for
+         spooling.  If the unused spool space is less than this level, any new
+         spooling requests would be blocked as if the "maximum spool size"
+         threshold had bee reached.  Already spooling jobs would be unaffected
+         by this directive.
+
+   Why: I've been bitten by this scenario a couple of times:
+
+        Assume a maximum spool size of 100M. Two concurrent jobs, A and B, are
+        both running.  Due to timing quirks and previously running jobs, job A
+        has used 99.9M of space in the spool directory.  While A is busy
+        despooling to disk, B is happily using the remaining 0.1M of spool
+        space.  This ends up in a spool/despool sequence every 0.1M of data.
+        In addition to fragmenting the data on the volume far more than was
+        necessary, in larger data sets (ie, tens or hundreds of gigabytes) it
+        can easily produce multi-megabyte report emails!
+
+   Item n?: Expand the Verify Job capability to verify Jobs older than the 
+   last one. For VolumeToCatalog Jobs
+   Date: 17 Januar 2008
+   Origin: portrix.net Hamburg, Germany.
+   Contact: Christian Sabelmann
+   Status: 70% of the required Code is part of the Verify function since v. 2.x
+
+   What:
+   The ability to tell Bacula which Job should verify instead of 
+   automatically verify just the last one.
+
+   Why: 
+   It is sad that such a powerfull feature like Verify Jobs 
+   (VolumeToCatalog) is restricted to be used only with the last backup Job 
+   of a client. Actual users who have to do daily Backups are forced to 
+   also do daily Verify Jobs in order to take advantage of this useful 
+   feature.  This Daily Verify after Backup conduct is not always desired 
+   and Verify Jobs have to be sometimes scheduled. (Not necessarily 
+   scheduled in Bacula). With this feature Admins can verify Jobs once a 
+   Week or less per month, selecting the Jobs they want to verify.  This 
+   feature is also not to difficult to implement taking in account older 
+   bug reports about this feature and the selection of the Job to be verified.
+          
+   Notes: For the verify Job, the user could select the Job to be verified 
+   from a List of the latest Jobs of a client. It would also be possible to 
+   verify a certain volume.  All of these would naturaly apply only for 
+   Jobs whose file information are still in the catalog.
+
 ========== Already implemented ================================
 
 Item  n:  make changing "spooldata=yes|no" possible for