]> git.sur5r.net Git - bacula/bacula/blob - bacula/projects.old
Remove docs from spec
[bacula/bacula] / bacula / projects.old
1                 
2 Projects:
3                      Bacula Projects Roadmap 
4                     Status updated 04 February 2009
5
6 Items Completed for version 3.0.0:
7 Item  1:  Accurate restoration of renamed/deleted files
8 Item  3:  Merge multiple backups (Synthetic Backup or Consolidation)
9 Item  4:  Implement Catalog directive for Pool resource in Director
10 Item  5:  Add an item to the restore option where you can select a Pool
11 Item  8:  Implement Copy pools
12 Item 12:  Add Plug-ins to the FileSet Include statements.
13 Item 13:  Restore only file attributes (permissions, ACL, owner, group...)
14 Item 18:  Better control over Job execution
15 Item 26: Store and restore extended attributes, especially selinux file contexts
16 Item 27:  make changing "spooldata=yes|no" possible for
17 Item 28:  Implement an option to modify the last written date for volumes
18
19 Summary:
20 Item  2:  Allow FD to initiate a backup
21 Item  6:  Deletion of disk Volumes when pruned
22 Item  7:  Implement Base jobs
23 Item  9:  Scheduling syntax that permits more flexibility and options
24 Item 10:  Message mailing based on backup types
25 Item 11:  Cause daemons to use a specific IP address to source communications
26 Item 14:  Add an override in Schedule for Pools based on backup types
27 Item 15:  Implement more Python events and functions  --- Abandoned for plugins
28 Item 16:  Allow inclusion/exclusion of files in a fileset by creation/mod times
29 Item 17:  Automatic promotion of backup levels based on backup size
30 Item 19:  Automatic disabling of devices
31 Item 20:  An option to operate on all pools with update vol parameters
32 Item 21:  Include timestamp of job launch in "stat clients" output
33 Item 22:  Implement Storage daemon compression
34 Item 23:  Improve Bacula's tape and drive usage and cleaning management
35 Item 24:  Multiple threads in file daemon for the same job
36 Item 25:  Archival (removal) of User Files to Tape
37
38
39 Item  1:  Accurate restoration of renamed/deleted files
40   Date:   28 November 2005
41   Origin: Martin Simmons (martin at lispworks dot com)
42   Status: Done
43
44   What:   When restoring a fileset for a specified date (including "most
45           recent"), Bacula should give you exactly the files and directories
46           that existed at the time of the last backup prior to that date.
47
48           Currently this only works if the last backup was a Full backup.
49           When the last backup was Incremental/Differential, files and
50           directories that have been renamed or deleted since the last Full
51           backup are not currently restored correctly.  Ditto for files with
52           extra/fewer hard links than at the time of the last Full backup.
53
54   Why:    Incremental/Differential would be much more useful if this worked.
55
56   Notes:  Merging of multiple backups into a single one seems to
57           rely on this working, otherwise the merged backups will not be
58           truly equivalent to a Full backup.  
59
60   Note:   Kern: notes shortened. This can be done without the need for 
61           inodes. It is essentially the same as the current Verify job,
62           but one additional database record must be written, which does 
63           not need any database change.
64
65   Notes:  Kern: see if we can correct restoration of directories if
66           replace=ifnewer is set.  Currently, if the directory does not
67           exist, a "dummy" directory is created, then when all the files
68           are updated, the dummy directory is newer so the real values
69           are not updated.
70
71 Item  2:  Allow FD to initiate a backup
72   Origin: Frank Volf (frank at deze dot org)
73   Date:   17 November 2005
74   Status:
75
76    What:  Provide some means, possibly by a restricted console that
77           allows a FD to initiate a backup, and that uses the connection
78           established by the FD to the Director for the backup so that
79           a Director that is firewalled can do the backup.
80
81    Why:   Makes backup of laptops much easier.
82
83
84 Item  3:  Merge multiple backups (Synthetic Backup or Consolidation) 
85   Origin: Marc Cousin and Eric Bollengier 
86   Date:   15 November 2005
87   Status: Done
88
89   What:   A merged backup is a backup made without connecting to the Client.
90           It would be a Merge of existing backups into a single backup.
91           In effect, it is like a restore but to the backup medium.
92
93           For instance, say that last Sunday we made a full backup.  Then
94           all week long, we created incremental backups, in order to do
95           them fast.  Now comes Sunday again, and we need another full.
96           The merged backup makes it possible to do instead an incremental
97           backup (during the night for instance), and then create a merged
98           backup during the day, by using the full and incrementals from
99           the week.  The merged backup will be exactly like a full made
100           Sunday night on the tape, but the production interruption on the
101           Client will be minimal, as the Client will only have to send
102           incrementals.
103
104           In fact, if it's done correctly, you could merge all the
105           Incrementals into single Incremental, or all the Incrementals
106           and the last Differential into a new Differential, or the Full,
107           last differential and all the Incrementals into a new Full
108           backup.  And there is no need to involve the Client.
109
110   Why:    The benefit is that :
111           - the Client just does an incremental ;
112           - the merged backup on tape is just as a single full backup,
113             and can be restored very fast.
114
115           This is also a way of reducing the backup data since the old
116           data can then be pruned (or not) from the catalog, possibly
117           allowing older volumes to be recycled
118
119 Item  4:  Implement Catalog directive for Pool resource in Director
120   Origin: Alan Davis adavis@ruckus.com
121   Date:   6 March 2007
122   Status: Done, but not tested, and possibly not fully implemented.
123  
124   What:   The current behavior is for the director to create all pools
125           found in the configuration file in all catalogs.  Add a
126           Catalog directive to the Pool resource to specify which
127           catalog to use for each pool definition.
128  
129   Why:    This allows different catalogs to have different pool
130           attributes and eliminates the side-effect of adding
131           pools to catalogs that don't need/use them.
132  
133   Notes:  Kern: I think this is relatively easy to do, and it is really
134           a pre-requisite to a number of the Copy pool, ... projects
135           that are listed here.
136
137 Item  5:  Add an item to the restore option where you can select a Pool
138   Origin: kshatriyak at gmail dot com
139     Date: 1/1/2006
140   Status: Done at least via command line
141
142     What: In the restore option (Select the most recent backup for a
143           client) it would be useful to add an option where you can limit
144           the selection to a certain pool.
145
146      Why: When using cloned jobs, most of the time you have 2 pools - a
147           disk pool and a tape pool.  People who have 2 pools would like to
148           select the most recent backup from disk, not from tape (tape
149           would be only needed in emergency).  However, the most recent
150           backup (which may just differ a second from the disk backup) may
151           be on tape and would be selected.  The problem becomes bigger if
152           you have a full and differential - the most "recent" full backup
153           may be on disk, while the most recent differential may be on tape
154           (though the differential on disk may differ even only a second or
155           so).  Bacula will complain that the backups reside on different
156           media then.  For now the only solution now when restoring things
157           when you have 2 pools is to manually search for the right
158           job-id's and enter them by hand, which is a bit fault tolerant.
159
160   Notes:  Kern: This is a nice idea. It could also be the way to support
161           Jobs that have been Copied (similar to migration, but not yet
162           implemented).
163
164
165
166 Item  6:  Deletion of disk Volumes when pruned
167   Date:   Nov 25, 2005
168   Origin: Ross Boylan <RossBoylan at stanfordalumni dot org> (edited
169           by Kern)
170   Status:         
171
172    What:  Provide a way for Bacula to automatically remove Volumes
173           from the filesystem, or optionally to truncate them.
174           Obviously, the Volume must be pruned prior removal.
175
176   Why:    This would allow users more control over their Volumes and
177           prevent disk based volumes from consuming too much space.
178
179   Notes:  The following two directives might do the trick:
180
181           Volume Data Retention = <time period>
182           Remove Volume After = <time period>
183
184           The migration project should also remove a Volume that is
185           migrated. This might also work for tape Volumes.
186
187 Item  7:  Implement Base jobs 
188   Date:   28 October 2005
189   Origin: Kern
190   Status: 
191   
192   What:   A base job is sort of like a Full save except that you 
193           will want the FileSet to contain only files that are
194           unlikely to change in the future (i.e.  a snapshot of
195           most of your system after installing it).  After the
196           base job has been run, when you are doing a Full save,
197           you specify one or more Base jobs to be used.  All
198           files that have been backed up in the Base job/jobs but
199           not modified will then be excluded from the backup.
200           During a restore, the Base jobs will be automatically
201           pulled in where necessary.
202
203   Why:    This is something none of the competition does, as far as
204           we know (except perhaps BackupPC, which is a Perl program that
205           saves to disk only).  It is big win for the user, it
206           makes Bacula stand out as offering a unique
207           optimization that immediately saves time and money.
208           Basically, imagine that you have 100 nearly identical
209           Windows or Linux machine containing the OS and user
210           files.  Now for the OS part, a Base job will be backed
211           up once, and rather than making 100 copies of the OS,
212           there will be only one.  If one or more of the systems
213           have some files updated, no problem, they will be
214           automatically restored.
215
216   Notes:  Huge savings in tape usage even for a single machine.
217           Will require more resources because the DIR must send
218           FD a list of files/attribs, and the FD must search the
219           list and compare it for each file to be saved.
220
221
222 Item  8:  Implement Copy pools
223   Date:   27 November 2005
224   Origin: David Boyes (dboyes at sinenomine dot net)
225   Status: A trivial version of this is done.
226
227   What:   I would like Bacula to have the capability to write copies
228           of backed-up data on multiple physical volumes selected
229           from different pools without transferring the data
230           multiple times, and to accept any of the copy volumes
231           as valid for restore.
232
233   Why:    In many cases, businesses are required to keep offsite
234           copies of backup volumes, or just wish for simple
235           protection against a human operator dropping a storage
236           volume and damaging it. The ability to generate multiple
237           volumes in the course of a single backup job allows
238           customers to simple check out one copy and send it
239           offsite, marking it as out of changer or otherwise
240           unavailable. Currently, the library and magazine
241           management capability in Bacula does not make this process
242           simple.
243
244           Restores would use the copy of the data on the first
245           available volume, in order of Copy pool chain definition.
246
247           This is also a major scalability issue -- as the number of
248           clients increases beyond several thousand, and the volume
249           of data increases, transferring the data multiple times to
250           produce additional copies of the backups will become
251           physically impossible due to transfer speed
252           issues. Generating multiple copies at server side will
253           become the only practical option. 
254
255   How:    I suspect that this will require adding a multiplexing
256           SD that appears to be a SD to a specific FD, but 1-n FDs
257           to the specific back end SDs managing the primary and copy
258           pools.  Storage pools will also need to acquire parameters
259           to define the pools to be used for copies. 
260
261   Notes:  I would commit some of my developers' time if we can agree
262           on the design and behavior. 
263
264   Notes:  Additional notes from David:
265           I think there's two areas where new configuration would be needed. 
266
267           1) Identify a "SD mux" SD (specify it in the config just like a
268           normal SD. The SD configuration would need something like a
269           "Daemon Type = Normal/Mux" keyword to identify it as a
270           multiplexor.  (The director code would need modification to add
271           the ability to do the multiple session setup, but the impact of
272           the change would be new code that was invoked only when a SDmux is
273           needed).
274
275           2) Additional keywords in the Pool definition to identify the need
276           to create copies.  Each pool would acquire a Copypool= attribute
277           (may be repeated to generate more than one copy.  3 is about the
278           practical limit, but no point in hardcoding that).
279
280           Example:
281           Pool {
282             Name = Primary
283             Pool Type = Backup
284             Copypool = Copy1
285             Copypool = OffsiteCopy2
286           }
287
288           where Copy1 and OffsiteCopy2 are valid pools.
289
290           In terms of function (shorthand): Backup job X is defined
291           normally, specifying pool Primary as the pool to use.  Job gets
292           scheduled, and Bacula starts scheduling resources.  Scheduler
293           looks at pool definition for Primary, sees that there are a
294           non-zero number of copypool keywords.  The director then connects
295           to an available SDmux, passes it the pool ids for Primary, Copy1,
296           and OffsiteCopy2 and waits.  SDmux then goes out and reserves
297           devices and volumes in the normal SDs that serve Primary, Copy1
298           and OffsiteCopy2.  When all are ready, the SDmux signals ready
299           back to the director, and the FD is given the address of the SDmux
300           as the SD to communicate with.  Backup proceeds normally, with the
301           SDmux duplicating blocks to each connected normal SD, and
302           returning ready when all defined copies have been written.  At
303           EOJ, FD shuts down connection with SDmux, which closes down the
304           normal SD connections and goes back to an idle state.  SDmux does
305           not update database; normal SDs do (noting that file is present on
306           each volume it has been written to).
307
308           On restore, director looks for the volume containing the file in
309           pool Primary first, then Copy1, then OffsiteCopy2.  If the volume
310           holding the file in pool Primary is missing or busy (being written
311           in another job, etc), or one of the volumes from the copypool list
312           that have the file in question is already mounted and ready for
313           some reason, use it to do the restore, else mount one of the
314           copypool volumes and proceed.
315
316
317 Item  9:  Scheduling syntax that permits more flexibility and options
318    Date:  15 December 2006
319   Origin: Gregory Brauer (greg at wildbrain dot com) and
320           Florian Schnabel <florian.schnabel at docufy dot de>
321   Status:
322
323    What:  Currently, Bacula only understands how to deal with weeks of the
324           month or weeks of the year in schedules.  This makes it impossible
325           to do a true weekly rotation of tapes.  There will always be a
326           discontinuity that will require disruptive manual intervention at
327           least monthly or yearly because week boundaries never align with
328           month or year boundaries.
329
330           A solution would be to add a new syntax that defines (at least)
331           a start timestamp, and repetition period.
332
333           An easy option to skip a certain job  on a certain date.
334    
335
336      Why: Rotated backups done at weekly intervals are useful, and Bacula
337           cannot currently do them without extensive hacking.
338
339           You could then easily skip tape backups on holidays.  Especially
340           if you got no autochanger and can only fit one backup on a tape
341           that would be really handy, other jobs could proceed normally
342           and you won't get errors that way.
343
344
345    Notes: Here is an example syntax showing a 3-week rotation where full
346           Backups would be performed every week on Saturday, and an
347           incremental would be performed every week on Tuesday.  Each
348           set of tapes could be removed from the loader for the following
349           two cycles before coming back and being reused on the third
350           week.  Since the execution times are determined by intervals
351           from a given point in time, there will never be any issues with
352           having to adjust to any sort of arbitrary time boundary.  In
353           the example provided, I even define the starting schedule
354           as crossing both a year and a month boundary, but the run times
355           would be based on the "Repeat" value and would therefore happen
356           weekly as desired.
357
358
359           Schedule {
360               Name = "Week 1 Rotation"
361               #Saturday.  Would run Dec 30, Jan 20, Feb 10, etc.
362               Run {
363                   Options {
364                       Type   = Full
365                       Start  = 2006-12-30 01:00
366                       Repeat = 3w
367                   }
368               }
369               #Tuesday.  Would run Jan 2, Jan 23, Feb 13, etc.
370               Run {
371                   Options {
372                       Type   = Incremental
373                       Start  = 2007-01-02 01:00
374                       Repeat = 3w
375                   }
376               }
377           }
378
379           Schedule {
380               Name = "Week 2 Rotation"
381               #Saturday.  Would run Jan 6, Jan 27, Feb 17, etc.
382               Run {
383                   Options {
384                       Type   = Full
385                       Start  = 2007-01-06 01:00
386                       Repeat = 3w
387                   }
388               }
389               #Tuesday.  Would run Jan 9, Jan 30, Feb 20, etc.
390               Run {
391                   Options {
392                       Type   = Incremental
393                       Start  = 2007-01-09 01:00
394                       Repeat = 3w
395                   }
396               }
397           }
398
399           Schedule {
400               Name = "Week 3 Rotation"
401               #Saturday.  Would run Jan 13, Feb 3, Feb 24, etc.
402               Run {
403                   Options {
404                       Type   = Full
405                       Start  = 2007-01-13 01:00
406                       Repeat = 3w
407                   }
408               }
409               #Tuesday.  Would run Jan 16, Feb 6, Feb 27, etc.
410               Run {
411                   Options {
412                       Type   = Incremental
413                       Start  = 2007-01-16 01:00
414                       Repeat = 3w
415                   }
416               }
417           }
418
419    Notes: Kern: I have merged the previously separate project of skipping 
420           jobs (via Schedule syntax) into this.
421
422
423 Item 10:  Message mailing based on backup types
424  Origin:  Evan Kaufman <evan.kaufman@gmail.com>
425    Date:  January 6, 2006
426  Status:
427
428    What:  In the "Messages" resource definitions, allowing messages
429           to be mailed based on the type (backup, restore, etc.) and level
430           (full, differential, etc) of job that created the originating
431           message(s).
432
433  Why:     It would, for example, allow someone's boss to be emailed
434           automatically only when a Full Backup job runs, so he can
435           retrieve the tapes for offsite storage, even if the IT dept.
436           doesn't (or can't) explicitly notify him.  At the same time, his
437           mailbox wouldnt be filled by notifications of Verifies, Restores,
438           or Incremental/Differential Backups (which would likely be kept
439           onsite).
440
441  Notes:   One way this could be done is through additional message types, for example:
442
443    Messages {
444      # email the boss only on full system backups
445      Mail = boss@mycompany.com = full, !incremental, !differential, !restore, 
446             !verify, !admin
447      # email us only when something breaks
448      MailOnError = itdept@mycompany.com = all
449    }
450
451    Notes: Kern: This should be rather trivial to implement.
452
453
454 Item 11:  Cause daemons to use a specific IP address to source communications
455  Origin:  Bill Moran <wmoran@collaborativefusion.com>
456  Date:    18 Dec 2006
457  Status:
458  What:    Cause Bacula daemons (dir, fd, sd) to always use the ip address
459           specified in the [DIR|DF|SD]Addr directive as the source IP
460           for initiating communication.
461  Why:     On complex networks, as well as extremely secure networks, it's
462           not unusual to have multiple possible routes through the network.
463           Often, each of these routes is secured by different policies
464           (effectively, firewalls allow or deny different traffic depending
465           on the source address)
466           Unfortunately, it can sometimes be difficult or impossible to
467           represent this in a system routing table, as the result is
468           excessive subnetting that quickly exhausts available IP space.
469           The best available workaround is to provide multiple IPs to
470           a single machine that are all on the same subnet.  In order
471           for this to work properly, applications must support the ability
472           to bind outgoing connections to a specified address, otherwise
473           the operating system will always choose the first IP that
474           matches the required route.
475  Notes:   Many other programs support this.  For example, the following
476           can be configured in BIND:
477           query-source address 10.0.0.1;
478           transfer-source 10.0.0.2;
479           Which means queries from this server will always come from
480           10.0.0.1 and zone transfers will always originate from
481           10.0.0.2.
482
483
484 Item 12:  Add Plug-ins to the FileSet Include statements.
485   Date:   28 October 2005
486   Origin: Kern
487   Status: Partially coded in 1.37 -- much more to do.
488
489   What:   Allow users to specify wild-card and/or regular
490           expressions to be matched in both the Include and
491           Exclude directives in a FileSet.  At the same time,
492           allow users to define plug-ins to be called (based on
493           regular expression/wild-card matching).
494
495   Why:    This would give the users the ultimate ability to control
496           how files are backed up/restored.  A user could write a
497           plug-in knows how to backup his Oracle database without
498           stopping/starting it, for example.
499
500
501 Item 13:  Restore only file attributes (permissions, ACL, owner, group...)
502   Origin: Eric Bollengier
503   Date:   30/12/2006
504   Status: Implemented by Eric, see project-restore-attributes-only.patch
505
506   What:   The goal of this project is to be able to restore only rights
507           and attributes of files without crushing them.
508
509   Why:    Who have never had to repair a chmod -R 777, or a wild update
510           of recursive right under Windows? At this time, you must have
511           enough space to restore data, dump attributes (easy with acl,
512           more complex with unix/windows rights) and apply them to your 
513           broken tree. With this options, it will be very easy to compare
514           right or ACL over the time.
515
516   Notes:  If the file is here, we skip restore and we change rights.
517           If the file isn't here, we can create an empty one and apply
518           rights or do nothing.
519
520           This will not work with win32 stream, because it seems that we 
521           can't split the WriteBackup stream to get only ACL and ownerchip.
522
523 Item 14:  Add an override in Schedule for Pools based on backup types
524 Date:     19 Jan 2005
525 Origin:   Chad Slater <chad.slater@clickfox.com>
526 Status: 
527                                                 
528   What:   Adding a FullStorage=BigTapeLibrary in the Schedule resource
529           would help those of us who use different storage devices for different
530           backup levels cope with the "auto-upgrade" of a backup.
531
532   Why:    Assume I add several new devices to be backed up, i.e. several
533           hosts with 1TB RAID.  To avoid tape switching hassles, incrementals are
534           stored in a disk set on a 2TB RAID.  If you add these devices in the
535           middle of the month, the incrementals are upgraded to "full" backups,
536           but they try to use the same storage device as requested in the
537           incremental job, filling up the RAID holding the differentials.  If we
538           could override the Storage parameter for full and/or differential
539           backups, then the Full job would use the proper Storage device, which
540           has more capacity (i.e. a 8TB tape library.
541
542
543 Item 15:  Implement more Python events and functions
544   Date:   28 October 2005
545   Origin: Kern
546   Status: Project abandoned in favor of plugins.
547
548   What:   Allow Python scripts to be called at more places 
549           within Bacula and provide additional access to Bacula
550           internal variables.
551
552           Implement an interface for Python scripts to access the
553           catalog through Bacula.
554
555   Why:    This will permit users to customize Bacula through
556           Python scripts.
557
558   Notes:  Recycle event
559           Scratch pool event
560           NeedVolume event
561           MediaFull event
562            
563           Also add a way to get a listing of currently running
564           jobs (possibly also scheduled jobs).
565
566
567           to start the appropriate job.
568
569
570 Item 16:  Allow inclusion/exclusion of files in a fileset by creation/mod times
571   Origin: Evan Kaufman <evan.kaufman@gmail.com>
572   Date:   January 11, 2006
573   Status:
574
575   What:   In the vein of the Wild and Regex directives in a Fileset's
576           Options, it would be helpful to allow a user to include or exclude
577           files and directories by creation or modification times.
578
579           You could factor the Exclude=yes|no option in much the same way it
580           affects the Wild and Regex directives.  For example, you could exclude
581           all files modified before a certain date:
582
583    Options {
584      Exclude = yes
585      Modified Before = ####
586    }
587
588            Or you could exclude all files created/modified since a certain date:
589
590    Options {
591       Exclude = yes
592      Created Modified Since = ####
593    }
594
595            The format of the time/date could be done several ways, say the number
596            of seconds since the epoch:
597            1137008553 = Jan 11 2006, 1:42:33PM   # result of `date +%s`
598
599            Or a human readable date in a cryptic form:
600            20060111134233 = Jan 11 2006, 1:42:33PM   # YYYYMMDDhhmmss
601
602   Why:    I imagine a feature like this could have many uses. It would
603           allow a user to do a full backup while excluding the base operating
604           system files, so if I installed a Linux snapshot from a CD yesterday,
605           I'll *exclude* all files modified *before* today.  If I need to
606           recover the system, I use the CD I already have, plus the tape backup.
607           Or if, say, a Windows client is hit by a particularly corrosive
608           virus, and I need to *exclude* any files created/modified *since* the
609           time of infection.
610
611   Notes:  Of course, this feature would work in concert with other
612           in/exclude rules, and wouldnt override them (or each other).
613
614   Notes:  The directives I'd imagine would be along the lines of
615           "[Created] [Modified] [Before|Since] = <date>".
616           So one could compare against 'ctime' and/or 'mtime', but ONLY 'before'
617            or 'since'.
618
619         
620 Item 17:  Automatic promotion of backup levels based on backup size
621    Date:  19 January 2006
622   Origin: Adam Thornton <athornton@sinenomine.net>
623   Status: 
624
625     What: Amanda has a feature whereby it estimates the space that a  
626           differential, incremental, and full backup would take.  If the  
627           difference in space required between the scheduled level and the next  
628           level up is beneath some user-defined critical threshold, the backup  
629           level is bumped to the next type.  Doing this minimizes the number of  
630           volumes necessary during a restore, with a fairly minimal cost in  
631           backup media space.
632
633     Why:  I know at least one (quite sophisticated and smart) user  
634           for whom the absence of this feature is a deal-breaker in terms of  
635           using Bacula; if we had it it would eliminate the one cool thing  
636           Amanda can do and we can't (at least, the one cool thing I know of).
637
638
639 Item 18:  Better control over Job execution
640    Date:  18 August 2007
641   Origin: Kern
642   Status: 
643
644     What: Bacula needs a few extra features for better Job execution:
645           1. A way to prevent multiple Jobs of the same name from
646              being scheduled at the same time (ususally happens when
647              a job is missed because a client is down).
648           2. Directives that permit easier upgrading of Job types
649              based on a period of time. I.e. "do a Full at least
650              once every 2 weeks", or "do a differential at least
651              once a week". If a lower level job is scheduled when
652              it begins to run it will be upgraded depending on
653              the specified criteria.
654
655     Why:  Obvious.
656    
657
658 Item 19:  Automatic disabling of devices
659    Date:  2005-11-11
660   Origin: Peter Eriksson <peter at ifm.liu dot se>
661   Status:
662
663    What:  After a configurable amount of fatal errors with a tape drive
664           Bacula should automatically disable further use of a certain
665           tape drive. There should also be "disable"/"enable" commands in
666           the "bconsole" tool.
667
668    Why:   On a multi-drive jukebox there is a possibility of tape drives
669           going bad during large backups (needing a cleaning tape run,
670           tapes getting stuck). It would be advantageous if Bacula would
671           automatically disable further use of a problematic tape drive
672           after a configurable amount of errors has occurred.
673
674           An example: I have a multi-drive jukebox (6 drives, 380+ slots)
675           where tapes occasionally get stuck inside the drive. Bacula will
676           notice that the "mtx-changer" command will fail and then fail
677           any backup jobs trying to use that drive. However, it will still
678           keep on trying to run new jobs using that drive and fail -
679           forever, and thus failing lots and lots of jobs... Since we have
680           many drives Bacula could have just automatically disabled
681           further use of that drive and used one of the other ones
682           instead.
683
684 Item 20:  An option to operate on all pools with update vol parameters
685   Origin: Dmitriy Pinchukov <absh@bossdev.kiev.ua>
686    Date:  16 August 2006
687   Status: Patch made by  Nigel Stepp
688
689    What:  When I do update -> Volume parameters -> All Volumes
690           from Pool, then I have to select pools one by one.  I'd like
691           console to have an option like "0: All Pools" in the list of
692           defined pools.
693
694    Why:   I have many pools and therefore unhappy with manually
695           updating each of them using update -> Volume parameters -> All
696           Volumes from Pool -> pool #.
697
698
699 Item 21:  Include timestamp of job launch in "stat clients" output
700   Origin: Mark Bergman <mark.bergman@uphs.upenn.edu>
701   Date:   Tue Aug 22 17:13:39 EDT 2006
702   Status:
703
704   What:   The "stat clients" command doesn't include any detail on when
705           the active backup jobs were launched.
706
707   Why:    Including the timestamp would make it much easier to decide whether
708           a job is running properly. 
709
710   Notes:  It may be helpful to have the output from "stat clients" formatted 
711           more like that from "stat dir" (and other commands), in a column
712           format. The per-client information that's currently shown (level,
713           client name, JobId, Volume, pool, device, Files, etc.) is good, but
714           somewhat hard to parse (both programmatically and visually), 
715           particularly when there are many active clients.
716
717
718
719 Item 22:  Implement Storage daemon compression
720   Date:   18 December 2006
721   Origin: Vadim A. Umanski , e-mail umanski@ext.ru
722   Status:
723   What:   The ability to compress backup data on the SD receiving data
724           instead of doing that on client sending data.
725   Why:    The need is practical. I've got some machines that can send
726           data to the network 4 or 5 times faster than compressing
727           them (I've measured that). They're using fast enough SCSI/FC
728           disk subsystems but rather slow CPUs (ex. UltraSPARC II).
729           And the backup server has got a quite fast CPUs (ex. Dual P4
730           Xeons) and quite a low load. When you have 20, 50 or 100 GB
731           of raw data - running a job 4 to 5 times faster - that
732           really matters. On the other hand, the data can be
733           compressed 50% or better - so losing twice more space for
734           disk backup is not good at all. And the network is all mine
735           (I have a dedicated management/provisioning network) and I
736           can get as high bandwidth as I need - 100Mbps, 1000Mbps...
737           That's why the server-side compression feature is needed!
738   Notes:
739
740 Item 23:  Improve Bacula's tape and drive usage and cleaning management 
741   Date:   8 November 2005, November 11, 2005
742   Origin: Adam Thornton <athornton at sinenomine dot net>,
743           Arno Lehmann <al at its-lehmann dot de>
744   Status:
745
746   What:   Make Bacula manage tape life cycle information, tape reuse
747           times and drive cleaning cycles.
748
749   Why:    All three parts of this project are important when operating
750           backups.
751           We need to know which tapes need replacement, and we need to
752           make sure the drives are cleaned when necessary.  While many
753           tape libraries and even autoloaders can handle all this
754           automatically, support by Bacula can be helpful for smaller
755           (older) libraries and single drives.  Limiting the number of
756           times a tape is used might prevent tape errors when using
757           tapes until the drives can't read it any more.  Also, checking
758           drive status during operation can prevent some failures (as I
759           [Arno] had to learn the hard way...)
760
761   Notes:  First, Bacula could (and even does, to some limited extent)
762           record tape and drive usage.  For tapes, the number of mounts,
763           the amount of data, and the time the tape has actually been
764           running could be recorded.  Data fields for Read and Write
765           time and Number of mounts already exist in the catalog (I'm
766           not sure if VolBytes is the sum of all bytes ever written to
767           that volume by Bacula).  This information can be important
768           when determining which media to replace.  The ability to mark
769           Volumes as "used up" after a given number of write cycles
770           should also be implemented so that a tape is never actually
771           worn out.  For the tape drives known to Bacula, similar
772           information is interesting to determine the device status and
773           expected life time: Time it's been Reading and Writing, number
774           of tape Loads / Unloads / Errors.  This information is not yet
775           recorded as far as I [Arno] know.  A new volume status would
776           be necessary for the new state, like "Used up" or "Worn out".
777           Volumes with this state could be used for restores, but not
778           for writing. These volumes should be migrated first (assuming
779           migration is implemented) and, once they are no longer needed,
780           could be moved to a Trash pool.
781
782           The next step would be to implement a drive cleaning setup.
783           Bacula already has knowledge about cleaning tapes.  Once it
784           has some information about cleaning cycles (measured in drive
785           run time, number of tapes used, or calender days, for example)
786           it can automatically execute tape cleaning (with an
787           autochanger, obviously) or ask for operator assistance loading
788           a cleaning tape.
789
790           The final step would be to implement TAPEALERT checks not only
791           when changing tapes and only sending the information to the
792           administrator, but rather checking after each tape error,
793           checking on a regular basis (for example after each tape
794           file), and also before unloading and after loading a new tape.
795           Then, depending on the drives TAPEALERT state and the known
796           drive cleaning state Bacula could automatically schedule later
797           cleaning, clean immediately, or inform the operator.
798
799           Implementing this would perhaps require another catalog change
800           and perhaps major changes in SD code and the DIR-SD protocol,
801           so I'd only consider this worth implementing if it would
802           actually be used or even needed by many people.
803
804           Implementation of these projects could happen in three distinct
805           sub-projects: Measuring Tape and Drive usage, retiring
806           volumes, and handling drive cleaning and TAPEALERTs.
807
808 Item 24:  Multiple threads in file daemon for the same job
809   Date:   27 November 2005
810   Origin: Ove Risberg (Ove.Risberg at octocode dot com)
811   Status:
812
813   What:   I want the file daemon to start multiple threads for a backup
814           job so the fastest possible backup can be made.
815
816           The file daemon could parse the FileSet information and start
817           one thread for each File entry located on a separate
818           filesystem.
819
820           A confiuration option in the job section should be used to
821           enable or disable this feature. The confgutration option could
822           specify the maximum number of threads in the file daemon.
823
824           If the theads could spool the data to separate spool files
825           the restore process will not be much slower.
826
827   Why:    Multiple concurrent backups of a large fileserver with many
828           disks and controllers will be much faster.
829
830 Item 25:  Archival (removal) of User Files to Tape
831   Date:   Nov. 24/2005 
832   Origin: Ray Pengelly [ray at biomed dot queensu dot ca
833   Status: 
834
835   What:   The ability to archive data to storage based on certain parameters
836           such as age, size, or location.  Once the data has been written to
837           storage and logged it is then pruned from the originating
838           filesystem. Note! We are talking about user's files and not
839           Bacula Volumes.
840
841   Why:    This would allow fully automatic storage management which becomes
842           useful for large datastores.  It would also allow for auto-staging
843           from one media type to another.
844
845           Example 1) Medical imaging needs to store large amounts of data.
846           They decide to keep data on their servers for 6 months and then put
847           it away for long term storage.  The server then finds all files
848           older than 6 months writes them to tape.  The files are then removed
849           from the server.
850
851           Example 2) All data that hasn't been accessed in 2 months could be
852           moved from high-cost, fibre-channel disk storage to a low-cost
853           large-capacity SATA disk storage pool which doesn't have as quick of
854           access time.  Then after another 6 months (or possibly as one
855           storage pool gets full) data is migrated to Tape.
856
857
858 Item 26: Store and restore extended attributes, especially selinux file contexts
859    Date: 28 December 2007
860    Origin: Frank Sweetser <fs@wpi.edu>
861    Status: Done
862    What: The ability to store and restore extended attributes on
863          filesystems that support them, such as ext3.
864
865    Why: Security Enhanced Linux (SELinux) enabled systems make extensive
866         use of extended attributes.  In addition to the standard user,
867         group, and permission, each file has an associated SELinux context
868         stored as an extended attribute.  This context is used to define
869         which operations a given program is permitted to perform on that
870         file.  Storing contexts on an SELinux system is as critical as
871         storing ownership and permissions.  In the case of a full system
872         restore, the system will not even be able to boot until all
873         critical system files have been properly relabeled.
874
875  Notes: Fedora ships with a version of tar that has been patched to handle
876         extended attributes.  The patch has not been integrated upstream
877         yet, so could serve as a good starting point.
878
879         http://linux.die.net/man/2/getxattr
880         http://linux.die.net/man/2/setxattr
881         http://linux.die.net/man/2/listxattr
882         ===
883         http://linux.die.net/man/3/getfilecon
884         http://linux.die.net/man/3/setfilecon
885
886 Item 27:  make changing "spooldata=yes|no" possible for
887           manual/interactive jobs
888   Origin: Marc Schiffbauer <marc@schiffbauer.net>
889   Date:   12 April 2007)
890   Status: Done
891
892   What:   Make it possible to modify the spooldata option
893           for a job when being run from within the console.
894           Currently it is possible to modify the backup level
895           and the spooldata setting in a Schedule resource.
896           It is also possible to modify the backup level when using
897           the "run" command in the console. 
898           But it is currently not possible to to the same 
899           with "spooldata=yes|no" like:
900
901           run job=MyJob level=incremental spooldata=yes
902
903   Why:    In some situations it would be handy to be able to switch
904           spooldata on or off for interactive/manual jobs based on
905           which data the admin expects or how fast the LAN/WAN
906           connection currently is.
907
908   Notes:  ./.
909
910 Item 28:  Implement an option to modify the last written date for volumes
911 Date:     16 September 2008
912 Origin:   Franck (xeoslaenor at gmail dot com)
913 Status:   Done
914 What:     The ability to modify the last written date for a volume
915 Why:      It's sometime necessary to jump a volume when you have a pool of volume
916           which recycles the oldest volume at each backup.
917           Sometime, it needs to cancel a set of backup (one day
918           backup, completely) and we want to avoid that bacula
919           choose the volume (which is not written at all) from
920           the cancelled backup (It has to jump to next volume).
921           in this case, we just need to update the written date
922           manually to avoir the "oldest volume" purge.
923 Notes:    An option can be add to "update volume" command (like 'written date'
924           choice for example)
925
926
927 ========= New Items since the last vote =================
928
929 Item 26: Add a new directive to bacula-dir.conf which permits inclusion of all subconfiguration files in a given directory
930 Date:   18 October 2008
931 Origin: Database, Lda. Maputo, Mozambique
932 Contact:Cameron Smith / cameron.ord@database.co.mz 
933 Status: New request
934
935 What: A directive something like "IncludeConf = /etc/bacula/subconfs" Every
936       time Bacula Director restarts or reloads, it will walk the given
937       directory (non-recursively) and include the contents of any files
938       therein, as though they were appended to bacula-dir.conf
939
940 Why: Permits simplified and safer configuration for larger installations with
941       many client PCs.  Currently, through judicious use of JobDefs and
942       similar directives, it is possible to reduce the client-specific part of
943       a configuration to a minimum.  The client-specific directives can be
944       prepared according to a standard template and dropped into a known
945       directory.  However it is still necessary to add a line to the "master"
946       (bacula-dir.conf) referencing each new file.  This exposes the master to
947       unnecessary risk of accidental mistakes and makes automation of adding
948       new client-confs, more difficult (it is easier to automate dropping a
949       file into a dir, than rewriting an existing file).  Ken has previously
950       made a convincing argument for NOT including Bacula's core configuration
951       in an RDBMS, but I believe that the present request is a reasonable
952       extension to the current "flat-file-based" configuration philosophy.
953  
954 Notes: There is NO need for any special syntax to these files.  They should
955        contain standard directives which are simply "inlined" to the parent
956        file as already happens when you explicitly reference an external file.
957
958  Item n: List inChanger flag when doing restore.
959  Origin: Jesper Krogh<jesper@krogh.cc>
960    Date:   17 oct. 2008
961  Status:
962
963    What: When doing a restore the restore selection dialog ends by telling stuff 
964       like this:
965   The job will require the following
966    Volume(s)                 Storage(s)                SD Device(s)
967    ===========================================================================
968     000741L3                  LTO-4                     LTO3 
969     000866L3                  LTO-4                     LTO3 
970     000765L3                  LTO-4                     LTO3 
971     000764L3                  LTO-4                     LTO3 
972     000756L3                  LTO-4                     LTO3 
973     001759L3                  LTO-4                     LTO3 
974     001763L3                  LTO-4                     LTO3 
975     001762L3                  LTO-4                     LTO3 
976     001767L3                  LTO-4                     LTO3 
977
978    When having an autochanger, it would be really nice with an inChanger 
979    column so the operator knew if this restore job would stop waiting for 
980    operator intervention. This is done just by selecting the inChanger flag 
981    from the catalog and printing it in a seperate column.
982
983
984    Why:    This would help getting large restores through minimizing the 
985       time spent waiting for operator to drop by and change tapes in the library.
986
987   Notes: [Kern] I think it would also be good to have the Slot as well,
988       or some indication that Bacula thinks the volume is in the autochanger
989       because it depends on both the InChanger flag and the Slot being
990       valid.
991
992
993 Item 1:   Implement an interface between Bacula and Amazon's S3.
994   Date:   25 August 2008
995   Origin: Soren Hansen <soren@ubuntu.com>
996   Status: Not started.
997   What:   Enable the storage daemon to store backup data on Amazon's
998           S3 service.
999
1000   Why:    Amazon's S3 is a cheap way to store data off-site. Current
1001           ways to integrate Bacula and S3 involve storing all the data
1002           locally and syncing them to S3, and manually fetching them
1003           again when they're needed. This is very cumbersome.
1004
1005
1006 Item 1:   enable/disable compression depending on storage device (disk/tape)
1007   Origin: Ralf Gross ralf-lists@ralfgross.de
1008   Date:   2008-01-11
1009   Status: Initial Request
1010
1011   What: Add a new option to the storage resource of the director.  Depending
1012           on this option, compression will be enabled/disabled for a device.
1013
1014   Why: If different devices (disks/tapes) are used for full/diff/incr
1015           backups, software compression will be enabled for all backups
1016           because of the FileSet compression option.  For backup to tapes
1017           wich are able to do hardware compression this is not desired.
1018           
1019
1020   Notes:
1021          http://news.gmane.org/gmane.comp.sysutils.backup.bacula.devel/cutoff=11124
1022          It must be clear to the user, that the FileSet compression option
1023          must still be enabled use compression for a backup job at all.
1024          Thus a name for the new option in the director must be
1025          well-defined.
1026
1027   Notes: KES I think the Storage definition should probably override what
1028          is in the Job definition or vice-versa, but in any case, it must
1029          be well defined.
1030
1031
1032 Item 1: Backup and Restore of Windows Encrypted Files through raw encryption
1033         functions
1034
1035   Origin: Michael Mohr, SAG  Mohr.External@infineon.com
1036   
1037   Date:   22 February 2008
1038   
1039   Status:
1040
1041   What: Make it possible to backup and restore Encypted Files from and to
1042           Windows systems without the need to decrypt it by using the raw
1043           encryption functions API (see:
1044           http://msdn2.microsoft.com/en-us/library/aa363783.aspx)
1045
1046           that is provided for that reason by Microsoft.
1047           If a file ist encrypted could be examined by evaluating the 
1048           FILE_ATTRIBUTE_ENCRYTED flag of the GetFileAttributes
1049           function.
1050
1051   Why:    Without the usage of this interface the fd-daemon running
1052           under the system account can't read encypted Files because
1053           the key needed for the decrytion is missed by them. As a result 
1054           actually encrypted files are not backed up
1055           by bacula and also no error is shown while missing these files.
1056
1057   Notes:  ./.
1058
1059    Item 1: Possibilty to schedule Jobs on last Friday of the month
1060    Origin: Carsten Menke <bootsy52 at gmx dot net>
1061    Date:   02 March 2008
1062    Status:
1063
1064    What: Currently if you want to run your monthly Backups on the last
1065            Friday of each month this is only possible with workarounds (e.g
1066            scripting) (As some months got 4 Fridays and some got 5 Fridays)
1067            The same is true if you plan to run your yearly Backups on the
1068            last Friday of the year.  It would be nice to have the ability to
1069            use the builtin scheduler for this.
1070
1071    Why:    In many companies the last working day of the week is Friday (or 
1072            Saturday), so to get the most data of the month onto the monthly
1073            tape, the employees are advised to insert the tape for the
1074            monthly backups on the last friday of the month.
1075
1076    Notes: To give this a complete functionality it would be nice if the
1077            "first" and "last" Keywords could be implemented in the
1078            scheduler, so it is also possible to run monthy backups at the
1079            first friday of the month and many things more.  So if the syntax
1080            would expand to this {first|last} {Month|Week|Day|Mo-Fri} of the
1081            {Year|Month|Week} you would be able to run really flexible jobs.
1082
1083            To got a certain Job run on the last Friday of the Month for example one could 
1084            then write
1085
1086               Run = pool=Monthly last Fri of the Month at 23:50
1087
1088               ## Yearly Backup
1089
1090               Run = pool=Yearly last Fri of the Year at 23:50
1091
1092               ## Certain Jobs the last Week of a Month
1093
1094               Run = pool=LastWeek last Week of the Month at 23:50
1095
1096               ## Monthly Backup on the last day of the month
1097
1098               Run = pool=Monthly last Day of the Month at 23:50
1099
1100    Date: 20 March 2008
1101
1102    Origin: Frank Sweetser <fs@wpi.edu>
1103
1104    What: Add a new SD directive, "minimum spool size" (or similar).  This
1105          directive would specify a minimum level of free space available for
1106          spooling.  If the unused spool space is less than this level, any
1107          new spooling requests would be blocked as if the "maximum spool
1108          size" threshold had bee reached.  Already spooling jobs would be
1109          unaffected by this directive.
1110
1111    Why: I've been bitten by this scenario a couple of times:
1112
1113         Assume a maximum spool size of 100M. Two concurrent jobs, A and B,
1114         are both running.  Due to timing quirks and previously running jobs,
1115         job A has used 99.9M of space in the spool directory.  While A is
1116         busy despooling to disk, B is happily using the remaining 0.1M of
1117         spool space.  This ends up in a spool/despool sequence every 0.1M of
1118         data.  In addition to fragmenting the data on the volume far more
1119         than was necessary, in larger data sets (ie, tens or hundreds of
1120         gigabytes) it can easily produce multi-megabyte report emails!
1121
1122    Item n?: Expand the Verify Job capability to verify Jobs older than the 
1123    last one. For VolumeToCatalog Jobs
1124    Date: 17 Januar 2008
1125    Origin: portrix.net Hamburg, Germany.
1126    Contact: Christian Sabelmann
1127    Status: 70% of the required Code is part of the Verify function since v. 2.x
1128
1129    What:
1130    The ability to tell Bacula which Job should verify instead of 
1131    automatically verify just the last one.
1132
1133    Why: 
1134    It is sad that such a powerfull feature like Verify Jobs
1135    (VolumeToCatalog) is restricted to be used only with the last backup Job
1136    of a client.  Actual users who have to do daily Backups are forced to
1137    also do daily Verify Jobs in order to take advantage of this useful
1138    feature.  This Daily Verify after Backup conduct is not always desired
1139    and Verify Jobs have to be sometimes scheduled.  (Not necessarily
1140    scheduled in Bacula).  With this feature Admins can verify Jobs once a
1141    Week or less per month, selecting the Jobs they want to verify.  This
1142    feature is also not to difficult to implement taking in account older bug
1143    reports about this feature and the selection of the Job to be verified.
1144           
1145    Notes: For the verify Job, the user could select the Job to be verified 
1146    from a List of the latest Jobs of a client. It would also be possible to 
1147    verify a certain volume.  All of these would naturaly apply only for 
1148    Jobs whose file information are still in the catalog.
1149
1150 Item X:   Add EFS support on Windows
1151    Origin: Alex Ehrlich (Alex.Ehrlich-at-mail.ee)
1152    Date:   05 August 2008
1153    Status:
1154
1155    What:   For each file backed up or restored by FD on Windows, check if
1156            the file is encrypted; if so then use OpenEncryptedFileRaw,
1157            ReadEncryptedFileRaw, WriteEncryptedFileRaw,
1158            CloseEncryptedFileRaw instead of BackupRead and BackupWrite
1159            API calls.
1160
1161    Why:    Many laptop users utilize the EFS functionality today; so do.
1162            some non-laptop ones, too.
1163            Currently files encrypted by means of EFS cannot be backed up.
1164            It means a Windows boutique cannot rely on Bacula as its
1165            backup solution, at least when using Windows 2K, XPP,
1166            "better" Vista etc on workstations, unless EFS is
1167            forbidden by policies.
1168            The current situation might result into "false sense of
1169            security" among the end-users.
1170
1171    Notes:  Using xxxEncryptedFileRaw API would allow to backup and
1172            restore EFS-encrypted files without decrypting their data.
1173            Note that such files cannot be restored "portably" (at least,
1174            easily) but they would be restoreable to a different (or
1175            reinstalled) Win32 machine; the restore would require setup
1176            of a EFS recovery agent in advance, of course, and this shall
1177            be clearly reflected in the documentation, but this is the
1178            normal Windows SysAdmin's business.
1179            When "portable" backup is requested the EFS-encrypted files
1180            shall be clearly reported as errors.
1181            See MSDN on the "Backup and Restore of Encrypted Files" topic:
1182            http://msdn.microsoft.com/en-us/library/aa363783.aspx
1183            Maybe the EFS support requires a new flag in the database for
1184            each file, too?
1185            Unfortunately, the implementation is not as straightforward as
1186            1-to-1 replacement of BackupRead with ReadEncryptedFileRaw,
1187            requiring some FD code rewrite to work with
1188            encrypted-file-related callback functions.
1189
1190                                                                                                                                                                                               encrypted-file-related callback functions.
1191 ========== Already implemented ================================
1192
1193
1194 ============= Empty Feature Request form ===========
1195 Item  n:  One line summary ...
1196   Date:   Date submitted 
1197   Origin: Name and email of originator.
1198   Status: 
1199
1200   What:   More detailed explanation ...
1201
1202   Why:    Why it is important ...
1203
1204   Notes:  Additional notes or features (omit if not used)
1205 ============== End Feature Request form ==============
1206
1207 ========== Items on put hold by Kern ============================
1208
1209 Item h1:  Split documentation
1210   Origin: Maxx <maxxatworkat gmail dot com>
1211   Date:   27th July 2006
1212   Status: Approved, awaiting implementation
1213
1214   What:   Split documentation in several books
1215
1216   Why:    Bacula manual has now more than 600 pages, and looking for
1217           implementation details is getting complicated.  I think
1218           it would be good to split the single volume in two or
1219           maybe three parts:
1220
1221           1) Introduction, requirements and tutorial, typically
1222              are useful only until first installation time
1223
1224           2) Basic installation and configuration, with all the
1225              gory details about the directives supported 3)
1226              Advanced Bacula: testing, troubleshooting, GUI and
1227              ancillary programs, security managements, scripting,
1228              etc.
1229
1230   Notes:  This is a project that needs to be done, and will be implemented,
1231           but it is really a developer issue of timing, and does not 
1232           needed to be included in the voting.
1233
1234
1235 Item h2:  Implement support for stacking arbitrary stream filters, sinks.
1236 Date:     23 November 2006
1237 Origin:   Landon Fuller <landonf@threerings.net>
1238 Status:   Planning. Assigned to landonf.
1239
1240   What:   Implement support for the following:
1241           - Stacking arbitrary stream filters (eg, encryption, compression,  
1242             sparse data handling))
1243           - Attaching file sinks to terminate stream filters (ie, write out  
1244             the resultant data to a file)
1245           - Refactor the restoration state machine accordingly
1246
1247    Why: The existing stream implementation suffers from the following: - All
1248            state (compression, encryption, stream restoration), is
1249              global across the entire restore process, for all streams. There are  
1250              multiple entry and exit points in the restoration state machine, and  
1251              thus multiple places where state must be allocated, deallocated,  
1252              initialized, or reinitialized. This results in exceptional complexity  
1253              for the author of a stream filter.
1254            - The developer must enumerate all possible combinations of filters  
1255              and stream types (ie, win32 data with encryption, without encryption,  
1256              with encryption AND compression, etc).
1257
1258   Notes: This feature request only covers implementing the stream filters/
1259           sinks, and refactoring the file daemon's restoration
1260           implementation accordingly.  If I have extra time, I will also
1261           rewrite the backup implementation.  My intent in implementing the
1262           restoration first is to solve pressing bugs in the restoration
1263           handling, and to ensure that the new restore implementation
1264           handles existing backups correctly.
1265
1266           I do not plan on changing the network or tape data structures to  
1267           support defining arbitrary stream filters, but supporting that  
1268           functionality is the ultimate goal.
1269
1270           Assistance with either code or testing would be fantastic.
1271
1272   Notes:  Kern: this project has a lot of merit, and we need to do it, but
1273           it is really an issue for developers rather than a new feature
1274           for users, so I have removed it from the voting list, but kept it
1275           here, but at some point, it will be implemented.
1276
1277 Item h3:  Filesystem watch triggered backup.
1278   Date:   31 August 2006
1279   Origin: Jesper Krogh <jesper@krogh.cc>
1280   Status: 
1281
1282   What:   With inotify and similar filesystem triggeret notification
1283           systems is it possible to have the file-daemon to monitor
1284           filesystem changes and initiate backup.
1285
1286   Why:    There are 2 situations where this is nice to have.
1287           1) It is possible to get a much finer-grained backup than
1288              the fixed schedules used now.. A file created and deleted
1289              a few hours later, can automatically be caught.
1290
1291           2) The introduced load on the system will probably be
1292              distributed more even on the system.
1293
1294   Notes:  This can be combined with configration that specifies
1295           something like: "at most every 15 minutes or when changes
1296           consumed XX MB".
1297
1298 Kern Notes: I would rather see this implemented by an external program
1299           that monitors the Filesystem changes, then uses the console
1300
1301
1302 Item h4:  Directive/mode to backup only file changes, not entire file
1303   Date:   11 November 2005
1304   Origin: Joshua Kugler <joshua dot kugler at uaf dot edu>
1305           Marek Bajon <mbajon at bimsplus dot com dot pl>
1306   Status: 
1307
1308   What:   Currently when a file changes, the entire file will be backed up in
1309           the next incremental or full backup.  To save space on the tapes
1310           it would be nice to have a mode whereby only the changes to the
1311           file would be backed up when it is changed.
1312
1313   Why:    This would save lots of space when backing up large files such as 
1314           logs, mbox files, Outlook PST files and the like.
1315
1316   Notes:  This would require the usage of disk-based volumes as comparing 
1317           files would not be feasible using a tape drive.
1318
1319   Notes:  Kern: I don't know how to implement this. Put on hold until someone
1320           provides a detailed implementation plan.
1321
1322
1323 Item h5:  Implement multiple numeric backup levels as supported by dump
1324 Date:     3 April 2006
1325 Origin:   Daniel Rich <drich@employees.org>
1326 Status:
1327 What: Dump allows specification of backup levels numerically instead of just
1328           "full", "incr", and "diff".  In this system, at any given level,
1329           all files are backed up that were were modified since the last
1330           backup of a higher level (with 0 being the highest and 9 being the
1331           lowest).  A level 0 is therefore equivalent to a full, level 9 an
1332           incremental, and the levels 1 through 8 are varying levels of
1333           differentials.  For bacula's sake, these could be represented as
1334           "full", "incr", and "diff1", "diff2", etc.
1335
1336 Why: Support of multiple backup levels would provide for more advanced
1337           backup rotation schemes such as "Towers of Hanoi".  This would
1338           allow better flexibility in performing backups, and can lead to
1339           shorter recover times.
1340
1341 Notes:    Legato Networker supports a similar system with full, incr, and 1-9 as
1342           levels.
1343
1344 Notes:    Kern: I don't see the utility of this, and it would be a *huge* 
1345           modification to existing code.
1346
1347 Item h6:  Implement NDMP protocol support
1348   Origin: Alan Davis
1349   Date:   06 March 2007
1350   Status: 
1351
1352   What:   Network Data Management Protocol is implemented by a number of
1353           NAS filer vendors to enable backups using third-party
1354           software.
1355
1356   Why:    This would allow NAS filer backups in Bacula without incurring
1357           the overhead of NFS or SBM/CIFS.
1358
1359   Notes:  Further information is available:
1360           http://www.ndmp.org
1361           http://www.ndmp.org/wp/wp.shtml
1362           http://www.traakan.com/ndmjob/index.html
1363
1364           There are currently no viable open-source NDMP
1365           implementations.  There is a reference SDK and example
1366           app available from ndmp.org but it has problems
1367           compiling on recent Linux and Solaris OS'.  The ndmjob
1368           reference implementation from Traakan is known to
1369           compile on Solaris 10.
1370
1371   Notes:  Kern: I am not at all in favor of this until NDMP becomes
1372           an Open Standard or until there are Open Source libraries
1373           that interface to it.
1374
1375 Item h7:  Commercial database support
1376   Origin: Russell Howe <russell_howe dot wreckage dot org>
1377   Date:   26 July 2006
1378   Status:
1379
1380   What: It would be nice for the database backend to support more databases.
1381           I'm thinking of SQL Server at the moment, but I guess Oracle, DB2,
1382           MaxDB, etc are all candidates.  SQL Server would presumably be
1383           implemented using FreeTDS or maybe an ODBC library?
1384
1385   Why: We only really have one database server, which is MS SQL Server 2000.
1386           Maintaining a second one for the backup software (we grew out of
1387           SQLite, which I liked, but which didn't work so well with our
1388           database size).  We don't really have a machine with the resources
1389           to run postgres, and would rather only maintain a single DBMS.
1390           We're stuck with SQL Server because pretty much all the company's
1391           custom applications (written by consultants) are locked into SQL
1392           Server 2000.  I can imagine this scenario is fairly common, and it
1393           would be nice to use the existing properly specced database server
1394           for storing Bacula's catalog, rather than having to run a second
1395           DBMS.
1396
1397   Notes: This might be nice, but someone other than me will probably need to
1398           implement it, and at the moment, proprietary code cannot legally
1399           be mixed with Bacula GPLed code.  This would be possible only
1400           providing the vendors provide GPLed (or OpenSource) interface
1401           code.
1402
1403 Item h8:  Incorporation of XACML2/SAML2 parsing
1404    Date:   19 January 2006
1405    Origin: Adam Thornton <athornton@sinenomine.net>
1406    Status: Blue sky
1407
1408    What: XACML is "eXtensible Access Control Markup Language" and "SAML is
1409           the "Security Assertion Markup Language"--an XML standard for
1410           making statements about identity and authorization.  Having these
1411           would give us a framework to approach ACLs in a generic manner,
1412           and in a way flexible enough to support the four major sorts of
1413           ACLs I see as a concern to Bacula at this point, as well as
1414           (probably) to deal with new sorts of ACLs that may appear in the
1415           future.
1416
1417    Why: Bacula is beginning to need to back up systems with ACLs that do not
1418           map cleanly onto traditional Unix permissions.  I see four sets of
1419           ACLs--in general, mutually incompatible with one another--that
1420           we're going to need to deal with.  These are: NTFS ACLs, POSIX
1421           ACLs, NFSv4 ACLS, and AFS ACLS. (Some may question the relevance
1422           of AFS; AFS is one of Sine Nomine's core consulting businesses,
1423           and having a reputable file-level backup and restore technology
1424           for it (as Tivoli is probably going to drop AFS support soon since
1425           IBM no longer supports AFS) would be of huge benefit to our
1426           customers; we'd most likely create the AFS support at Sine Nomine
1427           for inclusion into the Bacula (and perhaps some changes to the
1428           OpenAFS volserver) core code.)
1429
1430           Now, obviously, Bacula already handles NTFS just fine.  However, I
1431           think there's a lot of value in implementing a generic ACL model,
1432           so that it's easy to support whatever particular instances of ACLs
1433           come down the pike: POSIX ACLS (think SELinux) and NFSv4 are the
1434           obvious things arriving in the Linux world in a big way in the
1435           near future.  XACML, although overcomplicated for our needs,
1436           provides this framework, and we should be able to leverage other
1437           people's implementations to minimize the amount of work *we* have
1438           to do to get a generic ACL framework.  Basically, the costs of
1439           implementation are high, but they're largely both external to
1440           Bacula and already sunk.
1441
1442    Notes: As you indicate this is a bit of "blue sky" or in other words,
1443           at the moment, it is a bit esoteric to consider for Bacula.
1444
1445 Item h9:  Archive data
1446   Date:   15/5/2006
1447   Origin: calvin streeting calvin at absentdream dot com
1448   Status:
1449
1450   What:   The abilty to archive to media (dvd/cd) in a uncompressed format
1451           for dead filing (archiving not backing up)
1452
1453     Why: At work when jobs are finished and moved off of the main
1454           file servers (raid based systems) onto a simple Linux
1455           file server (ide based system) so users can find old
1456           information without contacting the IT dept.
1457
1458           So this data dosn't realy change it only gets added to,
1459           But it also needs backing up.  At the moment it takes
1460           about 8 hours to back up our servers (working data) so
1461           rather than add more time to existing backups i am trying
1462           to implement a system where we backup the acrhive data to
1463           cd/dvd these disks would only need to be appended to
1464           (burn only new/changed files to new disks for off site
1465           storage).  basialy understand the differnce between
1466           achive data and live data.
1467
1468   Notes:  Scan the data and email me when it needs burning divide
1469           into predefined chunks keep a recored of what is on what
1470           disk make me a label (simple php->mysql=>pdf stuff) i
1471           could do this bit ability to save data uncompresed so
1472           it can be read in any other system (future proof data)
1473           save the catalog with the disk as some kind of menu
1474           system 
1475
1476    Notes: Kern: I don't understand this item, and in any case, if it
1477           is specific to DVD/CDs, which we do not recommend using, 
1478           it is unlikely to be implemented except as a user 
1479           submitted patch.
1480
1481
1482 Item h10: Clustered file-daemons
1483   Origin: Alan Brown ajb2 at mssl dot ucl dot ac dot uk
1484   Date:   24 July 2006
1485   Status:
1486   What:   A "virtual" filedaemon, which is actually a cluster of real ones.
1487
1488   Why:    In the case of clustered filesystems (SAN setups, GFS, or OCFS2, etc)
1489           multiple machines may have access to the same set of filesystems
1490
1491           For performance reasons, one may wish to initate backups from
1492           several of these machines simultaneously, instead of just using
1493           one backup source for the common clustered filesystem.
1494
1495           For obvious reasons, normally backups of $A-FD/$PATH and
1496           B-FD/$PATH are treated as different backup sets. In this case
1497           they are the same communal set.
1498
1499           Likewise when restoring, it would be easier to just specify
1500           one of the cluster machines and let bacula decide which to use.
1501
1502           This can be faked to some extent using DNS round robin entries
1503           and a virtual IP address, however it means "status client" will
1504           always give bogus answers. Additionally there is no way of
1505           spreading the load evenly among the servers.
1506
1507           What is required is something similar to the storage daemon
1508           autochanger directives, so that Bacula can keep track of
1509           operating backups/restores and direct new jobs to a "free"
1510           client.
1511
1512    Notes: Kern: I don't understand the request enough to be able to
1513           implement it. A lot more design detail should be presented
1514           before voting on this project.
1515
1516       Feature Request Form
1517
1518 Item n:   Data encryption on storage daemon
1519   Origin: Tobias Barth <tobias.barth at web-arts.com>
1520   Date:   04 February 2009
1521   Status: new
1522
1523   What:   The storage demon should be able to do the data encryption that can currently be done by the file daemon.
1524
1525   Why:    This would have 2 advantages: 1) one could encrypt the data of unencrypted tapes by doing a migration job, and 2) the storage daemon would be the only machine that would have to keep the encryption keys.
1526
1527
1528 Item 1:   "Maximum Concurrent Jobs" for drives when used with changer device
1529   Origin: Ralf Gross ralf-lists <at> ralfgross.de
1530   Date:   2008-12-12
1531   Status: Initial Request
1532
1533   What:   respect the "Maximum Concurrent Jobs" directive in the _drives_
1534           Storage section in addition to the changer section
1535
1536   Why:    I have a 3 drive changer where I want to be able to let 3 concurrent
1537           jobs run in parallel. But only one job per drive at the same time.
1538           Right now I don't see how I could limit the number of concurrent jobs
1539           per drive in this situation.
1540
1541   Notes:  Using different priorities for these jobs lead to problems that other
1542           jobs are blocked. On the user list I got the advice to use the "Prefer Mounted
1543           Volumes" directive, but Kern advised against using "Prefer Mounted
1544           Volumes" in an other thread:
1545           http://article.gmane.org/gmane.comp.sysutils.backup.bacula.devel/11876/
1546
1547           In addition I'm not sure if this would be the same as respecting the
1548           drive's "Maximum Concurrent Jobs" setting.
1549
1550           Example:
1551
1552           Storage {
1553             Name = Neo4100
1554             Address = ....
1555             SDPort = 9103
1556             Password = "wiped"
1557             Device = Neo4100
1558             Media Type = LTO4
1559             Autochanger = yes
1560             Maximum Concurrent Jobs = 3
1561           }
1562           
1563           Storage {
1564             Name = Neo4100-LTO4-D1
1565             Address = ....
1566             SDPort = 9103
1567             Password = "wiped"
1568             Device = ULTRIUM-TD4-D1
1569             Media Type = LTO4
1570             Maximum Concurrent Jobs = 1
1571           }
1572           
1573           [2 more drives] 
1574
1575           The "Maximum Concurrent Jobs = 1" directive in the drive's section is ignored.
1576
1577  Item n:   Add MaxVolumeSize/MaxVolumeBytes statement to Storage resource
1578    Origin: Bastian Friedrich <bastian.friedrich@collax.com>
1579    Date:   2008-07-09
1580    Status: -
1581
1582    What:   SD has a "Maximum Volume Size" statement, which is deprecated
1583  and superseded by the Pool resource statement "Maximum Volume Bytes". It
1584  would be good if either statement could be used in Storage resources.
1585
1586    Why:    Pools do not have to be restricted to a single storage
1587  type/device; thus, it may be impossible to define Maximum Volume Bytes in
1588  the Pool resource. The old MaxVolSize statement is deprecated, as it is
1589  SD side only.
1590            I am using the same pool for different devices.
1591
1592    Notes:  State of idea currently unknown. Storage resources in the dir
1593  config currently translate to very slim catalog entries; these entries
1594  would require extensions to implement what is described here. Quite
1595  possibly, numerous other statements that are currently available in Pool
1596  resources could be used in Storage resources too quite well.
1597
1598 Item 1:   Start spooling even when waiting on tape
1599   Origin: Tobias Barth <tobias.barth@web-arts.com>
1600   Date:   25 April 2008
1601   Status:
1602
1603   What:   If a job can be spooled to disk before writing it to tape, it
1604 should be spooled immediately.
1605           Currently, bacula waits until the correct tape is inserted
1606 into the drive.
1607
1608   Why:    It could save hours. When bacula waits on the operator who
1609 must insert the correct tape (e.g. a new
1610           tape or a tape from another media pool), bacula could already
1611 prepare the spooled data in the
1612           spooling directory and immediately start despooling when the
1613 tape was inserted by the operator.
1614          
1615   2nd step: Use 2 or more spooling directories. When one directory is
1616 currently despooling, the next (on different
1617             disk drives) could already be spooling the next data.
1618
1619   Notes:  I am using bacula 2.2.8, which has none of those features
1620 implemented.
1621
1622 Item  1:  enable persistent naming/number of SQL queries
1623
1624   Date:   24 Jan, 2007 
1625   Origin: Mark Bergman 
1626   Status: 
1627
1628   What:  
1629         Change the parsing of the query.sql file and the query command so that
1630         queries are named/numbered by a fixed value, not their order in the
1631         file.
1632
1633
1634   Why:   
1635         One of the real strengths of bacula is the ability to query the
1636         database, and the fact that complex queries can be saved and
1637         referenced from a file is very powerful. However, the choice
1638         of query (both for interactive use, and by scripting input
1639         to the bconsole command) is completely dependent on the order
1640         within the query.sql file. The descriptve labels are helpful for
1641         interactive use, but users become used to calling a particular
1642         query "by number", or may use scripts to execute queries. This
1643         presents a problem if the number or order of queries in the file
1644         changes.
1645
1646         If the query.sql file used the numeric tags as a real value (rather
1647         than a comment), then users could have a higher confidence that they
1648         are executing the intended query, that their local changes wouldn't
1649         conflict with future bacula upgrades.
1650
1651         For scripting, it's very important that the intended query is
1652         what's actually executed. The current method of parsing the
1653         query.sql file discourages scripting because the addition or
1654         deletion of queries within the file will require corresponding
1655         changes to scripts. It may not be obvious to users that deleting
1656         query "17" in the query.sql file will require changing all
1657         references to higher numbered queries. Similarly, when new
1658         bacula distributions change the number of "official" queries,
1659         user-developed queries cannot simply be appended to the file
1660         without also changing any references to those queries in scripts
1661         or procedural documentation, etc.
1662
1663         In addition, using fixed numbers for queries would encourage more
1664         user-initiated development of queries, by supporting conventions
1665         such as:
1666
1667                 queries numbered 1-50 are supported/developed/distributed by
1668                         with official bacula releases
1669                         
1670                 queries numbered 100-200 are community contributed, and are
1671                 related to media management
1672
1673                 queries numbered 201-300 are community contributed, and are
1674                 related to checksums, finding duplicated files across
1675                 different backups, etc.
1676
1677                 queries numbered 301-400 are community contributed, and are
1678                 related to backup statistics (average file size, size per
1679                 client per backup level, time for all clients by backup level,
1680                 storage capacity by media type, etc.)
1681
1682                 queries numbered 500-999 are locally created
1683
1684   Notes:
1685         Alternatively, queries could be called by keyword (tag), rather
1686         than by number.
1687
1688
1689 Item n: List inChanger flag when doing restore.
1690    Origin: Jesper Krogh<jesper@krogh.cc>
1691    Date:   17 oct. 2008
1692    Status:
1693
1694    What:
1695         When doing a restore the restore selection dialog ends by telling stuff 
1696 like this:
1697 The job will require the following
1698     Volume(s)                 Storage(s)                SD Device(s)
1699 ===========================================================================
1700
1701     000741L3                  LTO-4                     LTO3 
1702
1703     000866L3                  LTO-4                     LTO3 
1704
1705     000765L3                  LTO-4                     LTO3 
1706
1707     000764L3                  LTO-4                     LTO3 
1708
1709     000756L3                  LTO-4                     LTO3 
1710
1711     001759L3                  LTO-4                     LTO3 
1712
1713     001763L3                  LTO-4                     LTO3 
1714
1715     001762L3                  LTO-4                     LTO3 
1716
1717     001767L3                  LTO-4                     LTO3 
1718
1719
1720 Item 26: Add a new directive to bacula-dir.conf which permits inclusion of all subconfiguration files in a given directory
1721 Date:   18 October 2008
1722 Origin: Database, Lda. Maputo, Mozambique
1723 Contact:Cameron Smith / cameron.ord@database.co.mz 
1724 Status: New request
1725
1726 What: A directive something like "IncludeConf  = /etc/bacula/subconfs"
1727       Every time Bacula Director restarts or reloads, it will walk the given directory (non-recursively) and include the contents of any files therein, as though they were appended to bacula-dir.conf
1728
1729 Why: Permits simplified and safer configuration for larger installations with many client PCs.  
1730       Currently, through judicious use of JobDefs and similar directives, it is possible to reduce the client-specific part of a configuration to a minimum.
1731       The client-specific directives can be prepared according to a standard template and dropped into a known directory.  However it is still necessary to 
1732       add a line to the "master" (bacula-dir.conf) referencing each new file.  
1733       This exposes the master to unnecessary risk of accidental mistakes and makes automation of adding new client-confs, more difficult 
1734       (it is easier to automate dropping a file into a dir, than rewriting an existing file).
1735       Ken has previously made a convincing argument for NOT including Bacula's core configuration in an RDBMS, but I believe that the present request is a reasonable
1736       extension to the current "flat-file-based" configuration philosophy.
1737  
1738 Notes: There is NO need for any special syntax to these files.  
1739        They should contain standard directives which are  simply "inlined" to the parent file as already happens when you explicitly reference an external file.
1740
1741 Notes: (kes) this can already be done with scripting
1742      From: John Jorgensen <jorgnsn@lcd.uregina.ca>
1743      The bacula-dir.conf at our site contains these lines:
1744
1745    #
1746    # Include subfiles associated with configuration of clients.
1747    # They define the bulk of the Clients, Jobs, and FileSets.
1748    #
1749    @|"sh -c 'for f in /etc/bacula/clientdefs/*.conf ; do echo @${f} ; done'"
1750
1751     and when we get a new client, we just put its configuration into
1752     a new file called something like:
1753
1754     /etc/bacula/clientdefs/clientname.conf
1755
1756