]> git.sur5r.net Git - bacula/bacula/blob - bacula/projects
Move bat from bacula.spec to bacula-bat.spec
[bacula/bacula] / bacula / projects
1                 
2 Projects:
3                      Bacula Projects Roadmap 
4                     Status updated 14 Jun 2009
5
6 Summary:
7 * => item complete
8
9  Item  1: Ability to restart failed jobs
10 *Item  2: 'restore' menu: enter a JobId, automatically select dependents
11  Item  3: Scheduling syntax that permits more flexibility and options
12  Item  4: Data encryption on storage daemon
13  Item  5: Deletion of disk Volumes when pruned
14  Item  6: Implement Base jobs
15  Item  7: Add ability to Verify any specified Job.
16  Item  8: Improve Bacula's tape and drive usage and cleaning management
17  Item  9: Allow FD to initiate a backup
18  Item 10: Restore from volumes on multiple storage daemons
19  Item 11: Implement Storage daemon compression
20  Item 12: Reduction of communications bandwidth for a backup
21  Item 13: Ability to reconnect a disconnected comm line
22  Item 14: Start spooling even when waiting on tape
23  Item 15: Enable/disable compression depending on storage device (disk/tape)
24  Item 16: Include all conf files in specified directory
25  Item 17: Multiple threads in file daemon for the same job
26  Item 18: Possibilty to schedule Jobs on last Friday of the month
27  Item 19: Include timestamp of job launch in "stat clients" output
28  Item 20: Cause daemons to use a specific IP address to source communications
29  Item 21: Message mailing based on backup types
30  Item 22: Ability to import/export Bacula database entities
31  Item 23: "Maximum Concurrent Jobs" for drives when used with changer device
32  Item 24: Implementation of running Job speed limit.
33  Item 25: Add an override in Schedule for Pools based on backup types
34  Item 26: Automatic promotion of backup levels based on backup size
35  Item 27: Allow inclusion/exclusion of files in a fileset by creation/mod times
36  Item 28: Archival (removal) of User Files to Tape
37  Item 29: An option to operate on all pools with update vol parameters
38  Item 30: Automatic disabling of devices
39 *Item 31: List InChanger flag when doing restore.
40  Item 32: Ability to defer Batch Insert to a later time
41  Item 33: Add MaxVolumeSize/MaxVolumeBytes statement to Storage resource
42  Item 34: Enable persistent naming/number of SQL queries
43  Item 35: Port bat to Win32
44  Item 36: Bacula Dir, FD and SD to support proxies
45  Item 37: Add Minumum Spool Size directive
46  Item 38: Backup and Restore of Windows Encrypted Files using Win raw encryption
47  Item 39: Implement an interface between Bacula and Amazon's S3.
48  Item 40: Convert Bacula existing tray monitor on Windows to a stand alone program
49
50 Item  1: Ability to restart failed jobs
51    Date: 26 April 2009
52  Origin: Kern/Eric
53  Status: 
54
55   What:  Often jobs fail because of a communications line drop or max run time,
56           cancel, or some other non-critical problem.  Currrently any data
57           saved is lost.  This implementation should modify the Storage daemon
58           so that it saves all the files that it knows are completely backed
59           up to the Volume
60
61           The jobs should then be marked as incomplete and a subsequent
62           Incremental Accurate backup will then take into account all the
63           previously saved job.
64
65   Why:   Avoids backuping data already saved.
66
67   Notes: Requires Accurate to restart correctly.  Must completed have a minimum
68           volume of data or files stored on Volume before enabling.
69
70
71 Item  2: 'restore' menu: enter a JobId, automatically select dependents 
72 Origin: Graham Keeling (graham@equiinet.com)
73 Date:  13 March 2009
74 Status: Done in 3.0.2
75
76 What:   Add to the bconsole 'restore' menu the ability to select a job
77         by JobId, and have bacula automatically select all the
78         dependent jobs.
79
80         Why: Currently, you either have to...
81         a) laboriously type in a date that is greater than the date of the backup that
82         you want and is less than the subsequent backup (bacula then figures out the
83         dependent jobs), or
84         b) manually figure out all the JobIds that you want and laboriously type them
85         all in.
86         It would be extremely useful (in a programmatical sense, as well as for humans)
87         to be able to just give it a single JobId and let bacula do the hard work (work
88         that it already knows how to do).
89
90         Notes (Kern): I think this should either be modified to have Bacula print
91         a list of dates that the user can choose from as is done in bwx-console and
92         bat or the name of this command must be carefully chosen so that the user
93         clearly understands that the JobId is being used to specify what Job and the
94         date to which he wishes the restore to happen.
95
96
97 Item  3: Scheduling syntax that permits more flexibility and options
98    Date: 15 December 2006
99   Origin: Gregory Brauer (greg at wildbrain dot com) and
100           Florian Schnabel <florian.schnabel at docufy dot de>
101   Status:
102
103    What: Currently, Bacula only understands how to deal with weeks of the
104           month or weeks of the year in schedules.  This makes it impossible
105           to do a true weekly rotation of tapes.  There will always be a
106           discontinuity that will require disruptive manual intervention at
107           least monthly or yearly because week boundaries never align with
108           month or year boundaries.
109
110           A solution would be to add a new syntax that defines (at least)
111           a start timestamp, and repetition period.
112
113           An easy option to skip a certain job  on a certain date.
114    
115
116      Why: Rotated backups done at weekly intervals are useful, and Bacula
117           cannot currently do them without extensive hacking.
118
119           You could then easily skip tape backups on holidays.  Especially
120           if you got no autochanger and can only fit one backup on a tape
121           that would be really handy, other jobs could proceed normally
122           and you won't get errors that way.
123
124
125    Notes: Here is an example syntax showing a 3-week rotation where full
126           Backups would be performed every week on Saturday, and an
127           incremental would be performed every week on Tuesday.  Each
128           set of tapes could be removed from the loader for the following
129           two cycles before coming back and being reused on the third
130           week.  Since the execution times are determined by intervals
131           from a given point in time, there will never be any issues with
132           having to adjust to any sort of arbitrary time boundary.  In
133           the example provided, I even define the starting schedule
134           as crossing both a year and a month boundary, but the run times
135           would be based on the "Repeat" value and would therefore happen
136           weekly as desired.
137
138
139           Schedule {
140               Name = "Week 1 Rotation"
141               #Saturday.  Would run Dec 30, Jan 20, Feb 10, etc.
142               Run {
143                   Options {
144                       Type   = Full
145                       Start  = 2006-12-30 01:00
146                       Repeat = 3w
147                   }
148               }
149               #Tuesday.  Would run Jan 2, Jan 23, Feb 13, etc.
150               Run {
151                   Options {
152                       Type   = Incremental
153                       Start  = 2007-01-02 01:00
154                       Repeat = 3w
155                   }
156               }
157           }
158
159           Schedule {
160               Name = "Week 2 Rotation"
161               #Saturday.  Would run Jan 6, Jan 27, Feb 17, etc.
162               Run {
163                   Options {
164                       Type   = Full
165                       Start  = 2007-01-06 01:00
166                       Repeat = 3w
167                   }
168               }
169               #Tuesday.  Would run Jan 9, Jan 30, Feb 20, etc.
170               Run {
171                   Options {
172                       Type   = Incremental
173                       Start  = 2007-01-09 01:00
174                       Repeat = 3w
175                   }
176               }
177           }
178
179           Schedule {
180               Name = "Week 3 Rotation"
181               #Saturday.  Would run Jan 13, Feb 3, Feb 24, etc.
182               Run {
183                   Options {
184                       Type   = Full
185                       Start  = 2007-01-13 01:00
186                       Repeat = 3w
187                   }
188               }
189               #Tuesday.  Would run Jan 16, Feb 6, Feb 27, etc.
190               Run {
191                   Options {
192                       Type   = Incremental
193                       Start  = 2007-01-16 01:00
194                       Repeat = 3w
195                   }
196               }
197           }
198
199    Notes: Kern: I have merged the previously separate project of skipping 
200           jobs (via Schedule syntax) into this.
201
202
203 Item  4: Data encryption on storage daemon
204   Origin: Tobias Barth <tobias.barth at web-arts.com>
205   Date:  04 February 2009
206   Status: new
207
208   What:  The storage demon should be able to do the data encryption that can currently be done by the file daemon.
209
210   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.
211
212   Notes from Landon:
213           As an addendum to the feature request, here are some crypto  
214           implementation details I wrote up regarding SD-encryption back in Jan  
215           2008:
216           http://www.mail-archive.com/bacula-users@lists.sourceforge.net/msg28860.html
217
218
219 Item  5: Deletion of disk Volumes when pruned
220   Date:  Nov 25, 2005
221   Origin: Ross Boylan <RossBoylan at stanfordalumni dot org> (edited
222           by Kern)
223   Status:        
224
225    What: Provide a way for Bacula to automatically remove Volumes
226           from the filesystem, or optionally to truncate them.
227           Obviously, the Volume must be pruned prior removal.
228
229   Why:   This would allow users more control over their Volumes and
230           prevent disk based volumes from consuming too much space.
231
232   Notes: The following two directives might do the trick:
233
234           Volume Data Retention = <time period>
235           Remove Volume After = <time period>
236
237           The migration project should also remove a Volume that is
238           migrated. This might also work for tape Volumes.
239
240   Notes: (Kern). The data fields to control this have been added
241           to the new 3.0.0 database table structure.
242
243
244 Item  6: Implement Base jobs 
245   Date:  28 October 2005
246   Origin: Kern
247   Status:
248   
249   What:  A base job is sort of like a Full save except that you 
250           will want the FileSet to contain only files that are
251           unlikely to change in the future (i.e.  a snapshot of
252           most of your system after installing it).  After the
253           base job has been run, when you are doing a Full save,
254           you specify one or more Base jobs to be used.  All
255           files that have been backed up in the Base job/jobs but
256           not modified will then be excluded from the backup.
257           During a restore, the Base jobs will be automatically
258           pulled in where necessary.
259
260   Why:   This is something none of the competition does, as far as
261           we know (except perhaps BackupPC, which is a Perl program that
262           saves to disk only).  It is big win for the user, it
263           makes Bacula stand out as offering a unique
264           optimization that immediately saves time and money.
265           Basically, imagine that you have 100 nearly identical
266           Windows or Linux machine containing the OS and user
267           files.  Now for the OS part, a Base job will be backed
268           up once, and rather than making 100 copies of the OS,
269           there will be only one.  If one or more of the systems
270           have some files updated, no problem, they will be
271           automatically restored.
272
273   Notes: Huge savings in tape usage even for a single machine.
274           Will require more resources because the DIR must send
275           FD a list of files/attribs, and the FD must search the
276           list and compare it for each file to be saved.
277
278
279 Item  7: Add ability to Verify any specified Job.
280 Date: 17 January 2008
281 Origin: portrix.net Hamburg, Germany.
282 Contact: Christian Sabelmann
283 Status: 70% of the required Code is part of the Verify function since v. 2.x
284
285    What:
286    The ability to tell Bacula which Job should verify instead of 
287    automatically verify just the last one.
288
289    Why: 
290    It is sad that such a powerfull feature like Verify Jobs
291    (VolumeToCatalog) is restricted to be used only with the last backup Job
292    of a client.  Actual users who have to do daily Backups are forced to
293    also do daily Verify Jobs in order to take advantage of this useful
294    feature.  This Daily Verify after Backup conduct is not always desired
295    and Verify Jobs have to be sometimes scheduled.  (Not necessarily
296    scheduled in Bacula).  With this feature Admins can verify Jobs once a
297    Week or less per month, selecting the Jobs they want to verify.  This
298    feature is also not to difficult to implement taking in account older bug
299    reports about this feature and the selection of the Job to be verified.
300           
301    Notes: For the verify Job, the user could select the Job to be verified 
302    from a List of the latest Jobs of a client. It would also be possible to 
303    verify a certain volume.  All of these would naturaly apply only for 
304    Jobs whose file information are still in the catalog.
305
306
307 Item  8: Improve Bacula's tape and drive usage and cleaning management 
308   Date:  8 November 2005, November 11, 2005
309   Origin: Adam Thornton <athornton at sinenomine dot net>,
310           Arno Lehmann <al at its-lehmann dot de>
311   Status:
312
313   What:  Make Bacula manage tape life cycle information, tape reuse
314           times and drive cleaning cycles.
315
316   Why:   All three parts of this project are important when operating
317           backups.
318           We need to know which tapes need replacement, and we need to
319           make sure the drives are cleaned when necessary.  While many
320           tape libraries and even autoloaders can handle all this
321           automatically, support by Bacula can be helpful for smaller
322           (older) libraries and single drives.  Limiting the number of
323           times a tape is used might prevent tape errors when using
324           tapes until the drives can't read it any more.  Also, checking
325           drive status during operation can prevent some failures (as I
326           [Arno] had to learn the hard way...)
327
328   Notes: First, Bacula could (and even does, to some limited extent)
329           record tape and drive usage.  For tapes, the number of mounts,
330           the amount of data, and the time the tape has actually been
331           running could be recorded.  Data fields for Read and Write
332           time and Number of mounts already exist in the catalog (I'm
333           not sure if VolBytes is the sum of all bytes ever written to
334           that volume by Bacula).  This information can be important
335           when determining which media to replace.  The ability to mark
336           Volumes as "used up" after a given number of write cycles
337           should also be implemented so that a tape is never actually
338           worn out.  For the tape drives known to Bacula, similar
339           information is interesting to determine the device status and
340           expected life time: Time it's been Reading and Writing, number
341           of tape Loads / Unloads / Errors.  This information is not yet
342           recorded as far as I [Arno] know.  A new volume status would
343           be necessary for the new state, like "Used up" or "Worn out".
344           Volumes with this state could be used for restores, but not
345           for writing. These volumes should be migrated first (assuming
346           migration is implemented) and, once they are no longer needed,
347           could be moved to a Trash pool.
348
349           The next step would be to implement a drive cleaning setup.
350           Bacula already has knowledge about cleaning tapes.  Once it
351           has some information about cleaning cycles (measured in drive
352           run time, number of tapes used, or calender days, for example)
353           it can automatically execute tape cleaning (with an
354           autochanger, obviously) or ask for operator assistance loading
355           a cleaning tape.
356
357           The final step would be to implement TAPEALERT checks not only
358           when changing tapes and only sending the information to the
359           administrator, but rather checking after each tape error,
360           checking on a regular basis (for example after each tape
361           file), and also before unloading and after loading a new tape.
362           Then, depending on the drives TAPEALERT state and the known
363           drive cleaning state Bacula could automatically schedule later
364           cleaning, clean immediately, or inform the operator.
365
366           Implementing this would perhaps require another catalog change
367           and perhaps major changes in SD code and the DIR-SD protocol,
368           so I'd only consider this worth implementing if it would
369           actually be used or even needed by many people.
370
371           Implementation of these projects could happen in three distinct
372           sub-projects: Measuring Tape and Drive usage, retiring
373           volumes, and handling drive cleaning and TAPEALERTs.
374
375
376 Item  9: Allow FD to initiate a backup
377 Origin:  Frank Volf (frank at deze dot org)
378 Date:    17 November 2005
379 Status: 
380
381 What: Provide some means, possibly by a restricted console that
382        allows a FD to initiate a backup, and that uses the connection
383        established by the FD to the Director for the backup so that
384        a Director that is firewalled can do the backup.
385 Why:  Makes backup of laptops much easier.
386
387
388 Item 10: Restore from volumes on multiple storage daemons
389 Origin: Graham Keeling (graham@equiinet.com)
390 Date:  12 March 2009
391 Status: Proposing
392
393 What:  The ability to restore from volumes held by multiple storage daemons
394         would be very useful.
395
396 Why:   It is useful to be able to backup to any number of different storage
397         daemons. For example, your first storage daemon may run out of space, so you
398         switch to your second and carry on. Bacula will currently let you do this.
399         However, once you come to restore, bacula cannot cope when volumes on different
400         storage daemons are required.
401
402         Notes: The director knows that more than one storage daemon is needed, as
403         bconsole outputs something like the following table.
404
405         The job will require the following
406            Volume(s)                 Storage(s)                SD Device(s)
407         ===========================================================================
408            
409            backup-0001               Disk 1                    Disk 1.0                 
410            backup-0002               Disk 2                    Disk 2.0             
411
412         However, the bootstrap file that it creates gets sent to the first storage
413         daemon only, which then stalls for a long time, 'waiting for a mount request'
414         for the volume that it doesn't have.
415         The bootstrap file contains no knowledge of the storage daemon.
416         Under the current design:
417
418                 The director connects to the storage daemon, and gets an sd_auth_key.
419                 The director then connects to the file daemon, and gives it the
420                         sd_auth_key with the 'jobcmd'.
421                 (restoring of files happens)
422                 The director does a 'wait_for_storage_daemon_termination()'.
423                 The director waits for the file daemon to indicate the end of the job.
424
425         With my idea:
426
427         The director connects to the file daemon.
428         Then, for each storage daemon in the .bsr file...  {
429                 The director connects to the storage daemon, and gets an sd_auth_key.
430                 The director then connects to the file daemon, and gives it the
431                         sd_auth_key with the 'storaddr' command.
432                 (restoring of files happens)
433                 The director does a 'wait_for_storage_daemon_termination()'.
434                 The director waits for the file daemon to indicate the end of the
435                         work on this storage.
436         }
437         The director tells the file daemon that there are no more storages to contact.
438         The director waits for the file daemon to indicate the end of the job.
439
440         As you can see, each restore between the file daemon and storage daemon is
441         handled in the same way that it is currently handled, using the same method
442         for authentication, except that the sd_auth_key is moved from the 'jobcmd' to
443         the 'storaddr' command - where it logically belongs.
444
445
446 Item 11: Implement Storage daemon compression
447   Date:  18 December 2006
448   Origin: Vadim A. Umanski , e-mail umanski@ext.ru
449   Status:
450   What:  The ability to compress backup data on the SD receiving data
451           instead of doing that on client sending data.
452   Why:   The need is practical. I've got some machines that can send
453           data to the network 4 or 5 times faster than compressing
454           them (I've measured that). They're using fast enough SCSI/FC
455           disk subsystems but rather slow CPUs (ex. UltraSPARC II).
456           And the backup server has got a quite fast CPUs (ex. Dual P4
457           Xeons) and quite a low load. When you have 20, 50 or 100 GB
458           of raw data - running a job 4 to 5 times faster - that
459           really matters. On the other hand, the data can be
460           compressed 50% or better - so losing twice more space for
461           disk backup is not good at all. And the network is all mine
462           (I have a dedicated management/provisioning network) and I
463           can get as high bandwidth as I need - 100Mbps, 1000Mbps...
464           That's why the server-side compression feature is needed!
465   Notes:
466
467
468 Item 12: Reduction of communications bandwidth for a backup
469    Date: 14 October 2008
470  Origin: Robin O'Leary (Equiinet)
471  Status: 
472
473   What:  Using rdiff techniques, Bacula could significantly reduce
474           the network data transfer volume to do a backup.
475
476   Why:   Faster backup across the Internet
477
478   Notes: This requires retaining certain data on the client during a Full
479           backup that will speed up subsequent backups.
480      
481      
482 Item 13: Ability to reconnect a disconnected comm line
483   Date:  26 April 2009
484   Origin: Kern/Eric
485   Status: 
486
487   What:  Often jobs fail because of a communications line drop. In that 
488           case, Bacula should be able to reconnect to the other daemon and
489           resume the job.
490
491   Why:   Avoids backuping data already saved.
492
493   Notes: *Very* complicated from a design point of view because of authenication.
494
495 Item 14: Start spooling even when waiting on tape
496   Origin: Tobias Barth <tobias.barth@web-arts.com>
497   Date:  25 April 2008
498   Status:
499
500   What: If a job can be spooled to disk before writing it to tape, it should
501           be spooled immediately.  Currently, bacula waits until the correct
502           tape is inserted into the drive.
503
504   Why:   It could save hours.  When bacula waits on the operator who must insert
505           the correct tape (e.g.  a new tape or a tape from another media
506           pool), bacula could already prepare the spooled data in the spooling
507           directory and immediately start despooling when the tape was
508           inserted by the operator.
509          
510           2nd step: Use 2 or more spooling directories.  When one directory is
511           currently despooling, the next (on different disk drives) could
512           already be spooling the next data.
513
514   Notes: I am using bacula 2.2.8, which has none of those features
515          implemented.
516
517
518 Item 15: Enable/disable compression depending on storage device (disk/tape)
519   Origin: Ralf Gross ralf-lists@ralfgross.de
520   Date:  2008-01-11
521   Status: Initial Request
522
523   What: Add a new option to the storage resource of the director.  Depending
524           on this option, compression will be enabled/disabled for a device.
525
526   Why: If different devices (disks/tapes) are used for full/diff/incr
527           backups, software compression will be enabled for all backups
528           because of the FileSet compression option.  For backup to tapes
529           wich are able to do hardware compression this is not desired.
530           
531
532   Notes:
533          http://news.gmane.org/gmane.comp.sysutils.backup.bacula.devel/cutoff=11124
534          It must be clear to the user, that the FileSet compression option
535          must still be enabled use compression for a backup job at all.
536          Thus a name for the new option in the director must be
537          well-defined.
538
539   Notes: KES I think the Storage definition should probably override what
540          is in the Job definition or vice-versa, but in any case, it must
541          be well defined.
542
543
544 Item 16: Include all conf files in specified directory
545 Date:  18 October 2008
546 Origin: Database, Lda. Maputo, Mozambique
547 Contact:Cameron Smith / cameron.ord@database.co.mz 
548 Status: New request
549
550 What: A directive something like "IncludeConf = /etc/bacula/subconfs" Every
551       time Bacula Director restarts or reloads, it will walk the given
552       directory (non-recursively) and include the contents of any files
553       therein, as though they were appended to bacula-dir.conf
554
555 Why: Permits simplified and safer configuration for larger installations with
556       many client PCs.  Currently, through judicious use of JobDefs and
557       similar directives, it is possible to reduce the client-specific part of
558       a configuration to a minimum.  The client-specific directives can be
559       prepared according to a standard template and dropped into a known
560       directory.  However it is still necessary to add a line to the "master"
561       (bacula-dir.conf) referencing each new file.  This exposes the master to
562       unnecessary risk of accidental mistakes and makes automation of adding
563       new client-confs, more difficult (it is easier to automate dropping a
564       file into a dir, than rewriting an existing file).  Ken has previously
565       made a convincing argument for NOT including Bacula's core configuration
566       in an RDBMS, but I believe that the present request is a reasonable
567       extension to the current "flat-file-based" configuration philosophy.
568  
569 Notes: There is NO need for any special syntax to these files.  They should
570        contain standard directives which are simply "inlined" to the parent
571        file as already happens when you explicitly reference an external file.
572
573 Notes: (kes) this can already be done with scripting
574      From: John Jorgensen <jorgnsn@lcd.uregina.ca>
575      The bacula-dir.conf at our site contains these lines:
576
577    #
578    # Include subfiles associated with configuration of clients.
579    # They define the bulk of the Clients, Jobs, and FileSets.
580    #
581    @|"sh -c 'for f in /etc/bacula/clientdefs/*.conf ; do echo @${f} ; done'"
582
583     and when we get a new client, we just put its configuration into
584     a new file called something like:
585
586     /etc/bacula/clientdefs/clientname.conf
587
588
589 Item 17: Multiple threads in file daemon for the same job
590   Date:  27 November 2005
591   Origin: Ove Risberg (Ove.Risberg at octocode dot com)
592   Status:
593
594   What:  I want the file daemon to start multiple threads for a backup
595           job so the fastest possible backup can be made.
596
597           The file daemon could parse the FileSet information and start
598           one thread for each File entry located on a separate
599           filesystem.
600
601           A confiuration option in the job section should be used to
602           enable or disable this feature. The confgutration option could
603           specify the maximum number of threads in the file daemon.
604
605           If the theads could spool the data to separate spool files
606           the restore process will not be much slower.
607
608   Why:   Multiple concurrent backups of a large fileserver with many
609           disks and controllers will be much faster.
610
611
612 Item 18: Possibilty to schedule Jobs on last Friday of the month
613 Origin: Carsten Menke <bootsy52 at gmx dot net>
614 Date:   02 March 2008
615 Status:
616
617    What: Currently if you want to run your monthly Backups on the last
618            Friday of each month this is only possible with workarounds (e.g
619            scripting) (As some months got 4 Fridays and some got 5 Fridays)
620            The same is true if you plan to run your yearly Backups on the
621            last Friday of the year.  It would be nice to have the ability to
622            use the builtin scheduler for this.
623
624    Why:   In many companies the last working day of the week is Friday (or 
625            Saturday), so to get the most data of the month onto the monthly
626            tape, the employees are advised to insert the tape for the
627            monthly backups on the last friday of the month.
628
629    Notes: To give this a complete functionality it would be nice if the
630            "first" and "last" Keywords could be implemented in the
631            scheduler, so it is also possible to run monthy backups at the
632            first friday of the month and many things more.  So if the syntax
633            would expand to this {first|last} {Month|Week|Day|Mo-Fri} of the
634            {Year|Month|Week} you would be able to run really flexible jobs.
635
636            To got a certain Job run on the last Friday of the Month for example one could 
637            then write
638
639               Run = pool=Monthly last Fri of the Month at 23:50
640
641               ## Yearly Backup
642
643               Run = pool=Yearly last Fri of the Year at 23:50
644
645               ## Certain Jobs the last Week of a Month
646
647               Run = pool=LastWeek last Week of the Month at 23:50
648
649               ## Monthly Backup on the last day of the month
650
651               Run = pool=Monthly last Day of the Month at 23:50
652
653
654 Item 19: Include timestamp of job launch in "stat clients" output
655   Origin: Mark Bergman <mark.bergman@uphs.upenn.edu>
656   Date:  Tue Aug 22 17:13:39 EDT 2006
657   Status:
658
659   What:  The "stat clients" command doesn't include any detail on when
660           the active backup jobs were launched.
661
662   Why:   Including the timestamp would make it much easier to decide whether
663           a job is running properly. 
664
665   Notes: It may be helpful to have the output from "stat clients" formatted 
666           more like that from "stat dir" (and other commands), in a column
667           format. The per-client information that's currently shown (level,
668           client name, JobId, Volume, pool, device, Files, etc.) is good, but
669           somewhat hard to parse (both programmatically and visually), 
670           particularly when there are many active clients.
671
672
673 Item 20: Cause daemons to use a specific IP address to source communications
674  Origin: Bill Moran <wmoran@collaborativefusion.com>
675  Date:   18 Dec 2006
676  Status: Done
677  What:   Cause Bacula daemons (dir, fd, sd) to always use the ip address
678           specified in the [DIR|DF|SD]Addr directive as the source IP
679           for initiating communication.
680  Why:    On complex networks, as well as extremely secure networks, it's
681           not unusual to have multiple possible routes through the network.
682           Often, each of these routes is secured by different policies
683           (effectively, firewalls allow or deny different traffic depending
684           on the source address)
685           Unfortunately, it can sometimes be difficult or impossible to
686           represent this in a system routing table, as the result is
687           excessive subnetting that quickly exhausts available IP space.
688           The best available workaround is to provide multiple IPs to
689           a single machine that are all on the same subnet.  In order
690           for this to work properly, applications must support the ability
691           to bind outgoing connections to a specified address, otherwise
692           the operating system will always choose the first IP that
693           matches the required route.
694  Notes:  Many other programs support this.  For example, the following
695           can be configured in BIND:
696           query-source address 10.0.0.1;
697           transfer-source 10.0.0.2;
698           Which means queries from this server will always come from
699           10.0.0.1 and zone transfers will always originate from
700           10.0.0.2.
701
702
703 Item 21: Message mailing based on backup types
704  Origin: Evan Kaufman <evan.kaufman@gmail.com>
705    Date: January 6, 2006
706  Status:
707
708    What: In the "Messages" resource definitions, allowing messages
709           to be mailed based on the type (backup, restore, etc.) and level
710           (full, differential, etc) of job that created the originating
711           message(s).
712
713  Why:    It would, for example, allow someone's boss to be emailed
714           automatically only when a Full Backup job runs, so he can
715           retrieve the tapes for offsite storage, even if the IT dept.
716           doesn't (or can't) explicitly notify him.  At the same time, his
717           mailbox wouldnt be filled by notifications of Verifies, Restores,
718           or Incremental/Differential Backups (which would likely be kept
719           onsite).
720
721  Notes:  One way this could be done is through additional message types, for example:
722
723    Messages {
724      # email the boss only on full system backups
725      Mail = boss@mycompany.com = full, !incremental, !differential, !restore, 
726             !verify, !admin
727      # email us only when something breaks
728      MailOnError = itdept@mycompany.com = all
729    }
730
731    Notes: Kern: This should be rather trivial to implement.
732
733
734 Item 22: Ability to import/export Bacula database entities
735    Date: 26 April 2009
736  Origin: Eric
737  Status: 
738
739   What:  Create a Bacula ASCII SQL database independent format that permits
740           importing and exporting database catalog Job entities.
741
742   Why:   For achival, database clustering, tranfer to other databases
743           of any SQL engine.
744
745   Notes: Job selection should be by Job, time, Volume, Client, Pool and possibly
746           other criteria.
747
748
749 Item 23: "Maximum Concurrent Jobs" for drives when used with changer device
750   Origin: Ralf Gross ralf-lists <at> ralfgross.de
751   Date:  2008-12-12
752   Status: Initial Request
753
754   What:  respect the "Maximum Concurrent Jobs" directive in the _drives_
755           Storage section in addition to the changer section
756
757   Why:   I have a 3 drive changer where I want to be able to let 3 concurrent
758           jobs run in parallel. But only one job per drive at the same time.
759           Right now I don't see how I could limit the number of concurrent jobs
760           per drive in this situation.
761
762   Notes: Using different priorities for these jobs lead to problems that other
763           jobs are blocked. On the user list I got the advice to use the "Prefer Mounted
764           Volumes" directive, but Kern advised against using "Prefer Mounted
765           Volumes" in an other thread:
766           http://article.gmane.org/gmane.comp.sysutils.backup.bacula.devel/11876/
767
768           In addition I'm not sure if this would be the same as respecting the
769           drive's "Maximum Concurrent Jobs" setting.
770
771           Example:
772
773           Storage {
774             Name = Neo4100
775             Address = ....
776             SDPort = 9103
777             Password = "wiped"
778             Device = Neo4100
779             Media Type = LTO4
780             Autochanger = yes
781             Maximum Concurrent Jobs = 3
782           }
783           
784           Storage {
785             Name = Neo4100-LTO4-D1
786             Address = ....
787             SDPort = 9103
788             Password = "wiped"
789             Device = ULTRIUM-TD4-D1
790             Media Type = LTO4
791             Maximum Concurrent Jobs = 1
792           }
793           
794           [2 more drives] 
795
796           The "Maximum Concurrent Jobs = 1" directive in the drive's section is ignored.
797
798
799 Item 24: Implementation of running Job speed limit.
800 Origin: Alex F, alexxzell at yahoo dot com
801 Date: 29 January 2009
802
803 What: I noticed the need for an integrated bandwidth limiter for
804       running jobs.  It would be very useful just to specify another
805       field in bacula-dir.conf, like speed = how much speed you wish
806       for that specific job to run at
807
808 Why: Because of a couple of reasons.  First, it's very hard to implement a
809      traffic shaping utility and also make it reliable.  Second, it is very
810      uncomfortable to have to implement these apps to, let's say 50 clients
811      (including desktops, servers).  This would also be unreliable because you
812      have to make sure that the apps are properly working when needed; users
813      could also disable them (accidentally or not).  It would be very useful
814      to provide Bacula this ability.  All information would be centralized,
815      you would not have to go to 50 different clients in 10 different
816      locations for configuration; eliminating 3rd party additions help in
817      establishing efficiency.  Would also avoid bandwidth congestion,
818      especially where there is little available.
819
820
821 Item 25: Add an override in Schedule for Pools based on backup types
822 Date:    19 Jan 2005
823 Origin:  Chad Slater <chad.slater@clickfox.com>
824 Status: 
825                                                 
826   What:  Adding a FullStorage=BigTapeLibrary in the Schedule resource
827           would help those of us who use different storage devices for different
828           backup levels cope with the "auto-upgrade" of a backup.
829
830   Why:   Assume I add several new devices to be backed up, i.e. several
831           hosts with 1TB RAID.  To avoid tape switching hassles, incrementals are
832           stored in a disk set on a 2TB RAID.  If you add these devices in the
833           middle of the month, the incrementals are upgraded to "full" backups,
834           but they try to use the same storage device as requested in the
835           incremental job, filling up the RAID holding the differentials.  If we
836           could override the Storage parameter for full and/or differential
837           backups, then the Full job would use the proper Storage device, which
838           has more capacity (i.e. a 8TB tape library.
839
840
841 Item 26: Automatic promotion of backup levels based on backup size
842    Date: 19 January 2006
843   Origin: Adam Thornton <athornton@sinenomine.net>
844   Status: 
845
846     What: Other backup programs have a feature whereby it estimates the space
847           that a differential, incremental, and full backup would take.  If
848           the difference in space required between the scheduled level and the
849           next level up is beneath some user-defined critical threshold, the
850           backup level is bumped to the next type.  Doing this minimizes the
851           number of volumes necessary during a restore, with a fairly minimal
852           cost in backup media space.
853
854     Why: I know at least one (quite sophisticated and smart) user for whom the
855           absence of this feature is a deal-breaker in terms of using Bacula;
856           if we had it it would eliminate the one cool thing other backup
857           programs can do and we can't (at least, the one cool thing I know
858           of).
859
860
861 Item 27: Allow inclusion/exclusion of files in a fileset by creation/mod times
862   Origin: Evan Kaufman <evan.kaufman@gmail.com>
863   Date:  January 11, 2006
864   Status:
865
866   What:  In the vein of the Wild and Regex directives in a Fileset's
867           Options, it would be helpful to allow a user to include or exclude
868           files and directories by creation or modification times.
869
870           You could factor the Exclude=yes|no option in much the same way it
871           affects the Wild and Regex directives.  For example, you could exclude
872           all files modified before a certain date:
873
874    Options {
875      Exclude = yes
876      Modified Before = ####
877    }
878
879            Or you could exclude all files created/modified since a certain date:
880
881    Options {
882       Exclude = yes
883      Created Modified Since = ####
884    }
885
886            The format of the time/date could be done several ways, say the number
887            of seconds since the epoch:
888            1137008553 = Jan 11 2006, 1:42:33PM   # result of `date +%s`
889
890            Or a human readable date in a cryptic form:
891            20060111134233 = Jan 11 2006, 1:42:33PM   # YYYYMMDDhhmmss
892
893   Why:   I imagine a feature like this could have many uses. It would
894           allow a user to do a full backup while excluding the base operating
895           system files, so if I installed a Linux snapshot from a CD yesterday,
896           I'll *exclude* all files modified *before* today.  If I need to
897           recover the system, I use the CD I already have, plus the tape backup.
898           Or if, say, a Windows client is hit by a particularly corrosive
899           virus, and I need to *exclude* any files created/modified *since* the
900           time of infection.
901
902   Notes: Of course, this feature would work in concert with other
903           in/exclude rules, and wouldnt override them (or each other).
904
905   Notes: The directives I'd imagine would be along the lines of
906           "[Created] [Modified] [Before|Since] = <date>".
907           So one could compare against 'ctime' and/or 'mtime', but ONLY 'before'
908            or 'since'.
909
910
911 Item 28: Archival (removal) of User Files to Tape
912   Date:  Nov. 24/2005 
913   Origin: Ray Pengelly [ray at biomed dot queensu dot ca
914   Status: 
915
916   What:  The ability to archive data to storage based on certain parameters
917           such as age, size, or location.  Once the data has been written to
918           storage and logged it is then pruned from the originating
919           filesystem. Note! We are talking about user's files and not
920           Bacula Volumes.
921
922   Why:   This would allow fully automatic storage management which becomes
923           useful for large datastores.  It would also allow for auto-staging
924           from one media type to another.
925
926           Example 1) Medical imaging needs to store large amounts of data.
927           They decide to keep data on their servers for 6 months and then put
928           it away for long term storage.  The server then finds all files
929           older than 6 months writes them to tape.  The files are then removed
930           from the server.
931
932           Example 2) All data that hasn't been accessed in 2 months could be
933           moved from high-cost, fibre-channel disk storage to a low-cost
934           large-capacity SATA disk storage pool which doesn't have as quick of
935           access time.  Then after another 6 months (or possibly as one
936           storage pool gets full) data is migrated to Tape.
937
938
939 Item 29: An option to operate on all pools with update vol parameters
940   Origin: Dmitriy Pinchukov <absh@bossdev.kiev.ua>
941    Date: 16 August 2006
942   Status: Patch made by  Nigel Stepp
943
944    What: When I do update -> Volume parameters -> All Volumes
945           from Pool, then I have to select pools one by one.  I'd like
946           console to have an option like "0: All Pools" in the list of
947           defined pools.
948
949    Why:  I have many pools and therefore unhappy with manually
950           updating each of them using update -> Volume parameters -> All
951           Volumes from Pool -> pool #.
952
953
954 Item 30: Automatic disabling of devices
955    Date: 2005-11-11
956   Origin: Peter Eriksson <peter at ifm.liu dot se>
957   Status:
958
959    What: After a configurable amount of fatal errors with a tape drive
960           Bacula should automatically disable further use of a certain
961           tape drive. There should also be "disable"/"enable" commands in
962           the "bconsole" tool.
963
964    Why:  On a multi-drive jukebox there is a possibility of tape drives
965           going bad during large backups (needing a cleaning tape run,
966           tapes getting stuck). It would be advantageous if Bacula would
967           automatically disable further use of a problematic tape drive
968           after a configurable amount of errors has occurred.
969
970           An example: I have a multi-drive jukebox (6 drives, 380+ slots)
971           where tapes occasionally get stuck inside the drive. Bacula will
972           notice that the "mtx-changer" command will fail and then fail
973           any backup jobs trying to use that drive. However, it will still
974           keep on trying to run new jobs using that drive and fail -
975           forever, and thus failing lots and lots of jobs... Since we have
976           many drives Bacula could have just automatically disabled
977           further use of that drive and used one of the other ones
978           instead.
979
980
981 Item 31: List InChanger flag when doing restore.
982  Origin: Jesper Krogh<jesper@krogh.cc>
983    Date: 17 Oct 2008
984  Status: Done in version 3.0.2
985
986    What: When doing a restore the restore selection dialog ends by telling stuff 
987       like this:
988   The job will require the following
989    Volume(s)                 Storage(s)                SD Device(s)
990    ===========================================================================
991     000741L3                  LTO-4                     LTO3 
992     000866L3                  LTO-4                     LTO3 
993     000765L3                  LTO-4                     LTO3 
994     000764L3                  LTO-4                     LTO3 
995     000756L3                  LTO-4                     LTO3 
996     001759L3                  LTO-4                     LTO3 
997     001763L3                  LTO-4                     LTO3 
998     001762L3                  LTO-4                     LTO3 
999     001767L3                  LTO-4                     LTO3 
1000
1001    When having an autochanger, it would be really nice with an inChanger 
1002    column so the operator knew if this restore job would stop waiting for 
1003    operator intervention. This is done just by selecting the inChanger flag 
1004    from the catalog and printing it in a seperate column.
1005
1006
1007    Why:   This would help getting large restores through minimizing the 
1008       time spent waiting for operator to drop by and change tapes in the library.
1009
1010   Notes: [Kern] I think it would also be good to have the Slot as well,
1011       or some indication that Bacula thinks the volume is in the autochanger
1012       because it depends on both the InChanger flag and the Slot being
1013       valid.
1014
1015
1016 Item 32: Ability to defer Batch Insert to a later time
1017    Date: 26 April 2009
1018  Origin: Eric
1019  Status: 
1020
1021   What:  Instead of doing a Job Batch Insert at the end of the Job
1022           which might create resource contention with lots of Job,
1023           defer the insert to a later time.
1024
1025   Why:   Permits to focus on getting the data on the Volume and
1026           putting the metadata into the Catalog outside the backup
1027           window.
1028
1029   Notes: Will use the proposed Bacula ASCII database import/export
1030           format (i.e. dependent on the import/export entities project).
1031
1032
1033 Item 33: Add MaxVolumeSize/MaxVolumeBytes statement to Storage resource
1034    Origin: Bastian Friedrich <bastian.friedrich@collax.com>
1035    Date:  2008-07-09
1036    Status: -
1037
1038    What:  SD has a "Maximum Volume Size" statement, which is deprecated and
1039            superseded by the Pool resource statement "Maximum Volume Bytes".
1040            It would be good if either statement could be used in Storage
1041            resources.
1042
1043    Why:   Pools do not have to be restricted to a single storage type/device;
1044            thus, it may be impossible to define Maximum Volume Bytes in the
1045            Pool resource.  The old MaxVolSize statement is deprecated, as it
1046            is SD side only.  I am using the same pool for different devices.
1047
1048    Notes: State of idea currently unknown.  Storage resources in the dir
1049            config currently translate to very slim catalog entries; these
1050            entries would require extensions to implement what is described
1051            here.  Quite possibly, numerous other statements that are currently
1052            available in Pool resources could be used in Storage resources too
1053            quite well.
1054
1055
1056 Item 34: Enable persistent naming/number of SQL queries
1057   Date:  24 Jan, 2007 
1058   Origin: Mark Bergman 
1059   Status: 
1060
1061   What: 
1062         Change the parsing of the query.sql file and the query command so that
1063         queries are named/numbered by a fixed value, not their order in the
1064         file.
1065
1066
1067   Why:  
1068         One of the real strengths of bacula is the ability to query the
1069         database, and the fact that complex queries can be saved and
1070         referenced from a file is very powerful. However, the choice
1071         of query (both for interactive use, and by scripting input
1072         to the bconsole command) is completely dependent on the order
1073         within the query.sql file. The descriptve labels are helpful for
1074         interactive use, but users become used to calling a particular
1075         query "by number", or may use scripts to execute queries. This
1076         presents a problem if the number or order of queries in the file
1077         changes.
1078
1079         If the query.sql file used the numeric tags as a real value (rather
1080         than a comment), then users could have a higher confidence that they
1081         are executing the intended query, that their local changes wouldn't
1082         conflict with future bacula upgrades.
1083
1084         For scripting, it's very important that the intended query is
1085         what's actually executed. The current method of parsing the
1086         query.sql file discourages scripting because the addition or
1087         deletion of queries within the file will require corresponding
1088         changes to scripts. It may not be obvious to users that deleting
1089         query "17" in the query.sql file will require changing all
1090         references to higher numbered queries. Similarly, when new
1091         bacula distributions change the number of "official" queries,
1092         user-developed queries cannot simply be appended to the file
1093         without also changing any references to those queries in scripts
1094         or procedural documentation, etc.
1095
1096         In addition, using fixed numbers for queries would encourage more
1097         user-initiated development of queries, by supporting conventions
1098         such as:
1099
1100                 queries numbered 1-50 are supported/developed/distributed by
1101                         with official bacula releases
1102                         
1103                 queries numbered 100-200 are community contributed, and are
1104                 related to media management
1105
1106                 queries numbered 201-300 are community contributed, and are
1107                 related to checksums, finding duplicated files across
1108                 different backups, etc.
1109
1110                 queries numbered 301-400 are community contributed, and are
1111                 related to backup statistics (average file size, size per
1112                 client per backup level, time for all clients by backup level,
1113                 storage capacity by media type, etc.)
1114
1115                 queries numbered 500-999 are locally created
1116
1117   Notes:
1118         Alternatively, queries could be called by keyword (tag), rather
1119         than by number.
1120
1121
1122 Item 35: Port bat to Win32
1123    Date: 26 April 2009
1124  Origin: Kern/Eric
1125  Status: 
1126
1127   What:  Make bat run on Win32/64.
1128
1129   Why:   To have GUI on Windows
1130
1131   Notes: 
1132
1133
1134 Item 36: Bacula Dir, FD and SD to support proxies
1135 Origin: Karl Grindley @ MIT Lincoln Laboratory <kgrindley at ll dot mit dot edu>
1136 Date:  25 March 2009
1137 Status: proposed
1138
1139 What:  Support alternate methods for nailing up a TCP session such
1140         as SOCKS5, SOCKS4 and HTTP (CONNECT) proxies.  Such a feature
1141         would allow tunneling of bacula traffic in and out of proxied
1142         networks.
1143
1144 Why:   Currently, bacula is architected to only function on a flat network, with
1145         no barriers or limitations.  Due to the large configuration states of
1146         any network and the infinite configuration where file daemons and
1147         storage daemons may sit in relation to one another, bacula often is
1148         not usable on a network where filtered or air-gaped networks exist.
1149         While often solutions such as ACL modifications to firewalls or port
1150         redirection via SNAT or DNAT will solve the issue, often however,
1151         these solutions are not adequate or not allowed by hard policy.
1152
1153         In an air-gapped network with only a highly locked down proxy services
1154         are provided (SOCKS4/5 and/or HTTP and/or SSH outbound) ACLs or
1155         iptable rules will not work.
1156
1157 Notes: Director resource tunneling: This configuration option to utilize a
1158         proxy to connect to a client should be specified in the client
1159         resource Client resource tunneling: should be configured in the client
1160         resource in the director config file?  Or configured on the bacula-fd
1161         configuration file on the fd host itself?  If the ladder, this would
1162         allow only certain clients to use a proxy, where others do not when
1163         establishing the TCP connection to the storage server. 
1164
1165         Also worth noting, there are other 3rd party, light weight apps that
1166         could be utilized to bootstrap this.  Instead of sockifing bacula
1167         itself, use an external program to broker proxy authentication, and
1168         connection to the remote host.  OpenSSH does this by using the
1169         "ProxyCommand" syntax in the client configuration and uses stdin and
1170         stdout to the command.  Connect.c is a very popular one.
1171         (http://bent.latency.net/bent/darcs/goto-san-connect-1.85/src/connect.html).
1172         One could also possibly use stunnel, netcat, etc.
1173
1174
1175 Item 37: Add Minumum Spool Size directive
1176 Date: 20 March 2008
1177 Origin: Frank Sweetser <fs@wpi.edu>
1178
1179    What: Add a new SD directive, "minimum spool size" (or similar).  This
1180          directive would specify a minimum level of free space available for
1181          spooling.  If the unused spool space is less than this level, any
1182          new spooling requests would be blocked as if the "maximum spool
1183          size" threshold had bee reached.  Already spooling jobs would be
1184          unaffected by this directive.
1185
1186    Why: I've been bitten by this scenario a couple of times:
1187
1188         Assume a maximum spool size of 100M. Two concurrent jobs, A and B,
1189         are both running.  Due to timing quirks and previously running jobs,
1190         job A has used 99.9M of space in the spool directory.  While A is
1191         busy despooling to disk, B is happily using the remaining 0.1M of
1192         spool space.  This ends up in a spool/despool sequence every 0.1M of
1193         data.  In addition to fragmenting the data on the volume far more
1194         than was necessary, in larger data sets (ie, tens or hundreds of
1195         gigabytes) it can easily produce multi-megabyte report emails!
1196
1197
1198 Item 38: Backup and Restore of Windows Encrypted Files using Win raw encryption
1199   Origin: Michael Mohr, SAG  Mohr.External@infineon.com
1200   Date:  22 February 2008
1201   Origin: Alex Ehrlich (Alex.Ehrlich-at-mail.ee)
1202   Date:  05 August 2008
1203   Status:
1204
1205   What: Make it possible to backup and restore Encypted Files from and to
1206           Windows systems without the need to decrypt it by using the raw
1207           encryption functions API (see:
1208           http://msdn2.microsoft.com/en-us/library/aa363783.aspx)
1209           that is provided for that reason by Microsoft.
1210           If a file ist encrypted could be examined by evaluating the 
1211           FILE_ATTRIBUTE_ENCRYTED flag of the GetFileAttributes
1212           function.
1213           For each file backed up or restored by FD on Windows, check if
1214           the file is encrypted; if so then use OpenEncryptedFileRaw,
1215           ReadEncryptedFileRaw, WriteEncryptedFileRaw,
1216           CloseEncryptedFileRaw instead of BackupRead and BackupWrite
1217           API calls.
1218
1219   Why:   Without the usage of this interface the fd-daemon running
1220           under the system account can't read encypted Files because
1221           the key needed for the decrytion is missed by them. As a result 
1222           actually encrypted files are not backed up
1223           by bacula and also no error is shown while missing these files.
1224
1225    Notes: Using xxxEncryptedFileRaw API would allow to backup and
1226            restore EFS-encrypted files without decrypting their data.
1227            Note that such files cannot be restored "portably" (at least,
1228            easily) but they would be restoreable to a different (or
1229            reinstalled) Win32 machine; the restore would require setup
1230            of a EFS recovery agent in advance, of course, and this shall
1231            be clearly reflected in the documentation, but this is the
1232            normal Windows SysAdmin's business.
1233            When "portable" backup is requested the EFS-encrypted files
1234            shall be clearly reported as errors.
1235            See MSDN on the "Backup and Restore of Encrypted Files" topic:
1236            http://msdn.microsoft.com/en-us/library/aa363783.aspx
1237            Maybe the EFS support requires a new flag in the database for
1238            each file, too?
1239            Unfortunately, the implementation is not as straightforward as
1240            1-to-1 replacement of BackupRead with ReadEncryptedFileRaw,
1241            requiring some FD code rewrite to work with
1242            encrypted-file-related callback functions.
1243
1244
1245 Item 39: Implement an interface between Bacula and Storage clould like Amazon's S3.
1246   Date:  25 August 2008
1247   Origin: Soren Hansen <soren@ubuntu.com>
1248   Status: Not started.
1249   What:  Enable the storage daemon to store backup data on Amazon's
1250           S3 service.
1251
1252   Why:   Amazon's S3 is a cheap way to store data off-site. 
1253
1254   Notes: If we configure the Pool to put only one job per volume (they don't
1255          support append operation), and the volume size isn't to big (100MB?),
1256          it should be easy to adapt the disk-changer script to add get/put
1257          procedure with curl. So, the data would be safetly copied during the
1258          Job. 
1259
1260          Cloud should be only used with Copy jobs, users should always have
1261          a copy of their data on their site.
1262
1263          We should also think to have our own cache, trying always to have
1264          cloud volume on the local disk. (I don't know if users want to store
1265          100GB on cloud, so it shouldn't be a disk size problem). For example,
1266          if bacula want to recycle a volume, it will start by downloading the
1267          file to truncate it few seconds later, if we can avoid that...
1268
1269 Item 40: Convert Bacula existing tray monitor on Windows to a stand alone program
1270    Date: 26 April 2009
1271  Origin: Kern/Eric
1272  Status: 
1273
1274   What:  Separate Win32 tray monitor to be a separate program.
1275
1276   Why:   Vista does not allow SYSTEM services to interact with the 
1277           desktop, so the current tray monitor does not work on Vista
1278           machines.  
1279
1280   Notes: Requires communicating with the FD via the network (simulate
1281           a console connection).
1282
1283
1284
1285 ========= End items voted on May 2009 ==================
1286
1287 ========= New items after last vote ====================
1288
1289 Item 1:   Relabel disk volume after recycling
1290   Origin: Pasi Kärkkäinen <pasik@iki.fi>
1291   Date:   07 May 2009.
1292   Status: Not implemented yet, no code written.
1293
1294   What:   The ability to relabel the disk volume (and thus rename the file on the disk) 
1295           after it has been recycled. Useful when you have a single job per disk volume, 
1296           and you use a custom Label format, for example: 
1297           Label Format = "${Client}-${Level}-${NumVols:p/4/0/r}-${Year}_${Month}_${Day}-${Hour}_${Minute}"
1298
1299   Why:    Disk volumes in Bacula get the label/filename when they are used for the first time.
1300           If you use recycling and custom label format like above, the disk
1301           volume name doesn't match the contents after it has been recycled.
1302           This feature makes it possible to keep the label/filename in sync
1303           with the content and thus makes it easy to check/monitor the backups
1304           from the shell and/or normal file management tools, because the filenames 
1305           of the disk volumes match the content.
1306
1307   Notes:  The configuration option could be "Relabel after Recycling = Yes".
1308
1309
1310 ========= Add new items above this line =================
1311
1312
1313 ============= Empty Feature Request form ===========
1314 Item  n: One line summary ...
1315   Date:  Date submitted 
1316   Origin: Name and email of originator.
1317   Status: 
1318
1319   What:  More detailed explanation ...
1320
1321   Why:   Why it is important ...
1322
1323   Notes: Additional notes or features (omit if not used)
1324 ============== End Feature Request form ==============
1325
1326
1327 ========== Items put on hold by Kern ============================