]> git.sur5r.net Git - bacula/docs/blob - docs/home-page/en/pages/projects.php
tweak blog entries
[bacula/docs] / docs / home-page / en / pages / projects.php
1 <? require_once("inc/header.php"); ?>
2 <table>
3 </tr>
4 <tr>
5         <td class="content">
6
7 <pre>
8                 
9                 
10                 
11 Projects:
12                      Bacula Projects Roadmap 
13                     Status updated 7 July 2007
14                    After re-ordering in vote priority
15
16 Items Completed:
17 Item:   2   Implement a Bacula GUI/management tool.
18 Item:  18   Quick release of FD-SD connection after backup.
19 Item:  23   Implement from-client and to-client on restore command line.
20 Item:  25   Implement huge exclude list support using dlist   
21 Item:  41   Enable to relocate files and directories when restoring
22 Item:  42   Batch attribute inserts (ten times faster)
23 Item:  43   More concurrency in SD using micro-locking
24 Item:  44   Performance enhancements (POSIX/Win32 OS file access hints).
25 Item:  40   Include JobID in spool file name
26
27 Summary:
28 Item:   1   Accurate restoration of renamed/deleted files
29 Item:   2*  Implement a Bacula GUI/management tool.
30 Item:   3   Allow FD to initiate a backup
31 Item:   4   Merge multiple backups (Synthetic Backup or Consolidation).
32 Item:   5   Deletion of Disk-Based Bacula Volumes
33 Item:   6   Implement Base jobs.
34 Item:   7   Implement creation and maintenance of copy pools
35 Item:   8   Directive/mode to backup only file changes, not entire file
36 Item:   9   Implement a server-side compression feature
37 Item:  10   Improve Bacula's tape and drive usage and cleaning management.
38 Item:  11   Allow skipping execution of Jobs
39 Item:  12   Add a scheduling syntax that permits weekly rotations
40 Item:  13   Archival (removal) of User Files to Tape
41 Item:  14   Cause daemons to use a specific IP address to source communications
42 Item:  15   Multiple threads in file daemon for the same job
43 Item:  16   Add Plug-ins to the FileSet Include statements.
44 Item:  17   Restore only file attributes (permissions, ACL, owner, group...)
45 Item:  18*  Quick release of FD-SD connection after backup.
46 Item:  19   Implement a Python interface to the Bacula catalog.
47 Item:  20   Archive data
48 Item:  21   Split documentation
49 Item:  22   Implement support for stacking arbitrary stream filters, sinks.
50 Item:  23*  Implement from-client and to-client on restore command line.
51 Item:  24   Add an override in Schedule for Pools based on backup types.
52 Item:  25*  Implement huge exclude list support using hashing.
53 Item:  26   Implement more Python events in Bacula.
54 Item:  27   Incorporation of XACML2/SAML2 parsing
55 Item:  28   Filesystem watch triggered backup.
56 Item:  29   Allow inclusion/exclusion of files in a fileset by creation/mod times
57 Item:  30   Tray monitor window cleanups
58 Item:  31   Implement multiple numeric backup levels as supported by dump
59 Item:  32   Automatic promotion of backup levels
60 Item:  33   Clustered file-daemons
61 Item:  34   Commercial database support
62 Item:  35   Automatic disabling of devices
63 Item:  36   An option to operate on all pools with update vol parameters
64 Item:  37   Add an item to the restore option where you can select a pool
65 Item:  38   Include timestamp of job launch in "stat clients" output
66 Item:  39   Message mailing based on backup types
67 Item:  40*  Include JobID in spool file name
68 Item:  41*  Enable to relocate files and directories when restoring
69 Item:  42*  Batch attribute inserts (ten times faster)
70 Item:  43*  More concurrency in SD using micro-locking
71 Item:  44*  Performance enhancements (POSIX/Win32 OS file access hints).
72
73 Item  1:  Accurate restoration of renamed/deleted files
74   Date:   28 November 2005
75   Origin: Martin Simmons (martin at lispworks dot com)
76   Status: Robert Nelson will implement this
77
78   What:   When restoring a fileset for a specified date (including "most
79           recent"), Bacula should give you exactly the files and directories
80           that existed at the time of the last backup prior to that date.
81
82           Currently this only works if the last backup was a Full backup.
83           When the last backup was Incremental/Differential, files and
84           directories that have been renamed or deleted since the last Full
85           backup are not currently restored correctly.  Ditto for files with
86           extra/fewer hard links than at the time of the last Full backup.
87
88   Why:    Incremental/Differential would be much more useful if this worked.
89
90   Notes:  Merging of multiple backups into a single one seems to
91           rely on this working, otherwise the merged backups will not be
92           truly equivalent to a Full backup.  
93
94           Kern: notes shortened. This can be done without the need for 
95           inodes. It is essentially the same as the current Verify job,
96           but one additional database record must be written, which does 
97           not need any database change.
98
99           Kern: see if we can correct restoration of directories if
100           replace=ifnewer is set.  Currently, if the directory does not
101           exist, a "dummy" directory is created, then when all the files
102           are updated, the dummy directory is newer so the real values
103           are not updated.
104
105 Item  2:  Implement a Bacula GUI/management tool.
106   Origin: Kern
107   Date:   28 October 2005
108   Status: In progress
109
110   What:   Implement a Bacula console, and management tools
111           probably using Qt3 and C++.
112
113   Why:    Don't we already have a wxWidgets GUI?  Yes, but
114           it is written in C++ and changes to the user interface
115           must be hand tailored using C++ code. By developing
116           the user interface using Qt designer, the interface
117           can be very easily updated and most of the new Python       
118           code will be automatically created.  The user interface
119           changes become very simple, and only the new features
120           must be implement.  In addition, the code will be in
121           Python, which will give many more users easy (or easier)
122           access to making additions or modifications.
123
124  Notes:   There is a partial Python-GTK implementation
125           Lucas Di Pentima <lucas at lunix dot com dot ar> but
126           it is no longer being developed.
127
128 Item  3:  Allow FD to initiate a backup
129   Origin: Frank Volf (frank at deze dot org)
130   Date:   17 November 2005
131   Status:
132
133    What:  Provide some means, possibly by a restricted console that
134           allows a FD to initiate a backup, and that uses the connection
135           established by the FD to the Director for the backup so that
136           a Director that is firewalled can do the backup.
137
138    Why:   Makes backup of laptops much easier.
139
140
141 Item  4:  Merge multiple backups (Synthetic Backup or Consolidation).
142   Origin: Marc Cousin and Eric Bollengier 
143   Date:   15 November 2005
144   Status: Waiting implementation. Depends on first implementing 
145           project Item 2 (Migration) which is now done.
146
147   What:   A merged backup is a backup made without connecting to the Client.
148           It would be a Merge of existing backups into a single backup.
149           In effect, it is like a restore but to the backup medium.
150
151           For instance, say that last Sunday we made a full backup.  Then
152           all week long, we created incremental backups, in order to do
153           them fast.  Now comes Sunday again, and we need another full.
154           The merged backup makes it possible to do instead an incremental
155           backup (during the night for instance), and then create a merged
156           backup during the day, by using the full and incrementals from
157           the week.  The merged backup will be exactly like a full made
158           Sunday night on the tape, but the production interruption on the
159           Client will be minimal, as the Client will only have to send
160           incrementals.
161
162           In fact, if it's done correctly, you could merge all the
163           Incrementals into single Incremental, or all the Incrementals
164           and the last Differential into a new Differential, or the Full,
165           last differential and all the Incrementals into a new Full
166           backup.  And there is no need to involve the Client.
167
168   Why:    The benefit is that :
169           - the Client just does an incremental ;
170           - the merged backup on tape is just as a single full backup,
171             and can be restored very fast.
172
173           This is also a way of reducing the backup data since the old
174           data can then be pruned (or not) from the catalog, possibly
175           allowing older volumes to be recycled
176
177 Item  5:  Deletion of Disk-Based Bacula Volumes
178   Date:   Nov 25, 2005
179   Origin: Ross Boylan <RossBoylan at stanfordalumni dot org> (edited
180           by Kern)
181   Status:         
182
183    What:  Provide a way for Bacula to automatically remove Volumes
184           from the filesystem, or optionally to truncate them.
185           Obviously, the Volume must be pruned prior removal.
186
187   Why:    This would allow users more control over their Volumes and
188           prevent disk based volumes from consuming too much space.
189
190   Notes:  The following two directives might do the trick:
191
192           Volume Data Retention = <time period>
193           Remove Volume After = <time period>
194
195           The migration project should also remove a Volume that is
196           migrated. This might also work for tape Volumes.
197
198 Item  6:  Implement Base jobs.
199   Date:   28 October 2005
200   Origin: Kern
201   Status: 
202   
203   What:   A base job is sort of like a Full save except that you 
204           will want the FileSet to contain only files that are
205           unlikely to change in the future (i.e.  a snapshot of
206           most of your system after installing it).  After the
207           base job has been run, when you are doing a Full save,
208           you specify one or more Base jobs to be used.  All
209           files that have been backed up in the Base job/jobs but
210           not modified will then be excluded from the backup.
211           During a restore, the Base jobs will be automatically
212           pulled in where necessary.
213
214   Why:    This is something none of the competition does, as far as
215           we know (except perhaps BackupPC, which is a Perl program that
216           saves to disk only).  It is big win for the user, it
217           makes Bacula stand out as offering a unique
218           optimization that immediately saves time and money.
219           Basically, imagine that you have 100 nearly identical
220           Windows or Linux machine containing the OS and user
221           files.  Now for the OS part, a Base job will be backed
222           up once, and rather than making 100 copies of the OS,
223           there will be only one.  If one or more of the systems
224           have some files updated, no problem, they will be
225           automatically restored.
226
227   Notes:  Huge savings in tape usage even for a single machine.
228           Will require more resources because the DIR must send
229           FD a list of files/attribs, and the FD must search the
230           list and compare it for each file to be saved.
231
232 Item  7:  Implement creation and maintenance of copy pools
233   Date:   27 November 2005
234   Origin: David Boyes (dboyes at sinenomine dot net)
235   Status:
236
237   What:   I would like Bacula to have the capability to write copies
238           of backed-up data on multiple physical volumes selected
239           from different pools without transferring the data
240           multiple times, and to accept any of the copy volumes
241           as valid for restore.
242
243   Why:    In many cases, businesses are required to keep offsite
244           copies of backup volumes, or just wish for simple
245           protection against a human operator dropping a storage
246           volume and damaging it. The ability to generate multiple
247           volumes in the course of a single backup job allows
248           customers to simple check out one copy and send it
249           offsite, marking it as out of changer or otherwise
250           unavailable. Currently, the library and magazine
251           management capability in Bacula does not make this process
252           simple.
253
254           Restores would use the copy of the data on the first
255           available volume, in order of copy pool chain definition.
256
257           This is also a major scalability issue -- as the number of
258           clients increases beyond several thousand, and the volume
259           of data increases, transferring the data multiple times to
260           produce additional copies of the backups will become
261           physically impossible due to transfer speed
262           issues. Generating multiple copies at server side will
263           become the only practical option. 
264
265   How:    I suspect that this will require adding a multiplexing
266           SD that appears to be a SD to a specific FD, but 1-n FDs
267           to the specific back end SDs managing the primary and copy
268           pools.  Storage pools will also need to acquire parameters
269           to define the pools to be used for copies. 
270
271   Notes:  I would commit some of my developers' time if we can agree
272           on the design and behavior. 
273
274 Item  8:  Directive/mode to backup only file changes, not entire file
275   Date:   11 November 2005
276   Origin: Joshua Kugler <joshua dot kugler at uaf dot edu>
277           Marek Bajon <mbajon at bimsplus dot com dot pl>
278   Status: 
279
280   What:   Currently when a file changes, the entire file will be backed up in
281           the next incremental or full backup.  To save space on the tapes
282           it would be nice to have a mode whereby only the changes to the
283           file would be backed up when it is changed.
284
285   Why:    This would save lots of space when backing up large files such as 
286           logs, mbox files, Outlook PST files and the like.
287
288   Notes:  This would require the usage of disk-based volumes as comparing 
289           files would not be feasible using a tape drive.
290
291 Item  9:  Implement a server-side compression feature
292   Date:   18 December 2006
293   Origin: Vadim A. Umanski , e-mail umanski@ext.ru
294   Status:
295   What:   The ability to compress backup data on server receiving data
296           instead of doing that on client sending data.
297   Why:    The need is practical. I've got some machines that can send
298           data to the network 4 or 5 times faster than compressing
299           them (I've measured that). They're using fast enough SCSI/FC
300           disk subsystems but rather slow CPUs (ex. UltraSPARC II).
301           And the backup server has got a quite fast CPUs (ex. Dual P4
302           Xeons) and quite a low load. When you have 20, 50 or 100 GB
303           of raw data - running a job 4 to 5 times faster - that
304           really matters. On the other hand, the data can be
305           compressed 50% or better - so losing twice more space for
306           disk backup is not good at all. And the network is all mine
307           (I have a dedicated management/provisioning network) and I
308           can get as high bandwidth as I need - 100Mbps, 1000Mbps...
309           That's why the server-side compression feature is needed!
310   Notes:
311
312 Item 10:  Improve Bacula's tape and drive usage and cleaning management.
313   Date:   8 November 2005, November 11, 2005
314   Origin: Adam Thornton <athornton at sinenomine dot net>,
315           Arno Lehmann <al at its-lehmann dot de>
316   Status:
317
318   What:   Make Bacula manage tape life cycle information, tape reuse
319           times and drive cleaning cycles.
320
321   Why:    All three parts of this project are important when operating
322           backups.
323           We need to know which tapes need replacement, and we need to
324           make sure the drives are cleaned when necessary.  While many
325           tape libraries and even autoloaders can handle all this
326           automatically, support by Bacula can be helpful for smaller
327           (older) libraries and single drives.  Limiting the number of
328           times a tape is used might prevent tape errors when using
329           tapes until the drives can't read it any more.  Also, checking
330           drive status during operation can prevent some failures (as I
331           [Arno] had to learn the hard way...)
332
333   Notes:  First, Bacula could (and even does, to some limited extent)
334           record tape and drive usage.  For tapes, the number of mounts,
335           the amount of data, and the time the tape has actually been
336           running could be recorded.  Data fields for Read and Write
337           time and Number of mounts already exist in the catalog (I'm
338           not sure if VolBytes is the sum of all bytes ever written to
339           that volume by Bacula).  This information can be important
340           when determining which media to replace.  The ability to mark
341           Volumes as "used up" after a given number of write cycles
342           should also be implemented so that a tape is never actually
343           worn out.  For the tape drives known to Bacula, similar
344           information is interesting to determine the device status and
345           expected life time: Time it's been Reading and Writing, number
346           of tape Loads / Unloads / Errors.  This information is not yet
347           recorded as far as I [Arno] know.  A new volume status would
348           be necessary for the new state, like "Used up" or "Worn out".
349           Volumes with this state could be used for restores, but not
350           for writing. These volumes should be migrated first (assuming
351           migration is implemented) and, once they are no longer needed,
352           could be moved to a Trash pool.
353
354           The next step would be to implement a drive cleaning setup.
355           Bacula already has knowledge about cleaning tapes.  Once it
356           has some information about cleaning cycles (measured in drive
357           run time, number of tapes used, or calender days, for example)
358           it can automatically execute tape cleaning (with an
359           autochanger, obviously) or ask for operator assistance loading
360           a cleaning tape.
361
362           The final step would be to implement TAPEALERT checks not only
363           when changing tapes and only sending the information to the
364           administrator, but rather checking after each tape error,
365           checking on a regular basis (for example after each tape
366           file), and also before unloading and after loading a new tape.
367           Then, depending on the drives TAPEALERT state and the known
368           drive cleaning state Bacula could automatically schedule later
369           cleaning, clean immediately, or inform the operator.
370
371           Implementing this would perhaps require another catalog change
372           and perhaps major changes in SD code and the DIR-SD protocol,
373           so I'd only consider this worth implementing if it would
374           actually be used or even needed by many people.
375
376           Implementation of these projects could happen in three distinct
377           sub-projects: Measuring Tape and Drive usage, retiring
378           volumes, and handling drive cleaning and TAPEALERTs.
379
380 Item 11:  Allow skipping execution of Jobs
381   Date:   29 November 2005
382   Origin: Florian Schnabel <florian.schnabel at docufy dot de>
383   Status:
384
385     What: An easy option to skip a certain job  on a certain date.
386      Why: You could then easily skip tape backups on holidays.  Especially
387           if you got no autochanger and can only fit one backup on a tape
388           that would be really handy, other jobs could proceed normally
389           and you won't get errors that way.
390
391 Item 12:  Add a scheduling syntax that permits weekly rotations
392    Date:  15 December 2006
393   Origin: Gregory Brauer (greg at wildbrain dot com)
394   Status:
395
396    What:  Currently, Bacula only understands how to deal with weeks of the
397           month or weeks of the year in schedules.  This makes it impossible
398           to do a true weekly rotation of tapes.  There will always be a
399           discontinuity that will require disruptive manual intervention at
400           least monthly or yearly because week boundaries never align with
401           month or year boundaries.
402
403           A solution would be to add a new syntax that defines (at least)
404           a start timestamp, and repetition period.
405
406    Why:   Rotated backups done at weekly intervals are useful, and Bacula
407           cannot currently do them without extensive hacking.
408
409    Notes: Here is an example syntax showing a 3-week rotation where full
410           Backups would be performed every week on Saturday, and an
411           incremental would be performed every week on Tuesday.  Each
412           set of tapes could be removed from the loader for the following
413           two cycles before coming back and being reused on the third
414           week.  Since the execution times are determined by intervals
415           from a given point in time, there will never be any issues with
416           having to adjust to any sort of arbitrary time boundary.  In
417           the example provided, I even define the starting schedule
418           as crossing both a year and a month boundary, but the run times
419           would be based on the "Repeat" value and would therefore happen
420           weekly as desired.
421
422
423           Schedule {
424               Name = "Week 1 Rotation"
425               #Saturday.  Would run Dec 30, Jan 20, Feb 10, etc.
426               Run {
427                   Options {
428                       Type   = Full
429                       Start  = 2006-12-30 01:00
430                       Repeat = 3w
431                   }
432               }
433               #Tuesday.  Would run Jan 2, Jan 23, Feb 13, etc.
434               Run {
435                   Options {
436                       Type   = Incremental
437                       Start  = 2007-01-02 01:00
438                       Repeat = 3w
439                   }
440               }
441           }
442
443           Schedule {
444               Name = "Week 2 Rotation"
445               #Saturday.  Would run Jan 6, Jan 27, Feb 17, etc.
446               Run {
447                   Options {
448                       Type   = Full
449                       Start  = 2007-01-06 01:00
450                       Repeat = 3w
451                   }
452               }
453               #Tuesday.  Would run Jan 9, Jan 30, Feb 20, etc.
454               Run {
455                   Options {
456                       Type   = Incremental
457                       Start  = 2007-01-09 01:00
458                       Repeat = 3w
459                   }
460               }
461           }
462
463           Schedule {
464               Name = "Week 3 Rotation"
465               #Saturday.  Would run Jan 13, Feb 3, Feb 24, etc.
466               Run {
467                   Options {
468                       Type   = Full
469                       Start  = 2007-01-13 01:00
470                       Repeat = 3w
471                   }
472               }
473               #Tuesday.  Would run Jan 16, Feb 6, Feb 27, etc.
474               Run {
475                   Options {
476                       Type   = Incremental
477                       Start  = 2007-01-16 01:00
478                       Repeat = 3w
479                   }
480               }
481           }
482
483 Item 13:  Archival (removal) of User Files to Tape
484   Date:   Nov. 24/2005 
485   Origin: Ray Pengelly [ray at biomed dot queensu dot ca
486   Status: 
487
488   What:   The ability to archive data to storage based on certain parameters
489           such as age, size, or location.  Once the data has been written to
490           storage and logged it is then pruned from the originating
491           filesystem. Note! We are talking about user's files and not
492           Bacula Volumes.
493
494   Why:    This would allow fully automatic storage management which becomes
495           useful for large datastores.  It would also allow for auto-staging
496           from one media type to another.
497
498           Example 1) Medical imaging needs to store large amounts of data.
499           They decide to keep data on their servers for 6 months and then put
500           it away for long term storage.  The server then finds all files
501           older than 6 months writes them to tape.  The files are then removed
502           from the server.
503
504           Example 2) All data that hasn't been accessed in 2 months could be
505           moved from high-cost, fibre-channel disk storage to a low-cost
506           large-capacity SATA disk storage pool which doesn't have as quick of
507           access time.  Then after another 6 months (or possibly as one
508           storage pool gets full) data is migrated to Tape.
509
510 Item 14:  Cause daemons to use a specific IP address to source communications
511  Origin:  Bill Moran <wmoran@collaborativefusion.com>
512  Date:    18 Dec 2006
513  Status:
514  What:    Cause Bacula daemons (dir, fd, sd) to always use the ip address
515           specified in the [DIR|DF|SD]Addr directive as the source IP
516           for initiating communication.
517  Why:     On complex networks, as well as extremely secure networks, it's
518           not unusual to have multiple possible routes through the network.
519           Often, each of these routes is secured by different policies
520           (effectively, firewalls allow or deny different traffic depending
521           on the source address)
522           Unfortunately, it can sometimes be difficult or impossible to
523           represent this in a system routing table, as the result is
524           excessive subnetting that quickly exhausts available IP space.
525           The best available workaround is to provide multiple IPs to
526           a single machine that are all on the same subnet.  In order
527           for this to work properly, applications must support the ability
528           to bind outgoing connections to a specified address, otherwise
529           the operating system will always choose the first IP that
530           matches the required route.
531  Notes:   Many other programs support this.  For example, the following
532           can be configured in BIND:
533           query-source address 10.0.0.1;
534           transfer-source 10.0.0.2;
535           Which means queries from this server will always come from
536           10.0.0.1 and zone transfers will always originate from
537           10.0.0.2.
538
539 Item 15:  Multiple threads in file daemon for the same job
540   Date:   27 November 2005
541   Origin: Ove Risberg (Ove.Risberg at octocode dot com)
542   Status:
543
544   What:   I want the file daemon to start multiple threads for a backup
545           job so the fastest possible backup can be made.
546
547           The file daemon could parse the FileSet information and start
548           one thread for each File entry located on a separate
549           filesystem.
550
551           A confiuration option in the job section should be used to
552           enable or disable this feature. The confgutration option could
553           specify the maximum number of threads in the file daemon.
554
555           If the theads could spool the data to separate spool files
556           the restore process will not be much slower.
557
558   Why:    Multiple concurrent backups of a large fileserver with many
559           disks and controllers will be much faster.
560
561 Item 16:  Add Plug-ins to the FileSet Include statements.
562   Date:   28 October 2005
563   Origin:
564   Status: Partially coded in 1.37 -- much more to do.
565
566   What:   Allow users to specify wild-card and/or regular
567           expressions to be matched in both the Include and
568           Exclude directives in a FileSet.  At the same time,
569           allow users to define plug-ins to be called (based on
570           regular expression/wild-card matching).
571
572   Why:    This would give the users the ultimate ability to control
573           how files are backed up/restored.  A user could write a
574           plug-in knows how to backup his Oracle database without
575           stopping/starting it, for example.
576
577 Item 17:  Restore only file attributes (permissions, ACL, owner, group...)
578   Origin: Eric Bollengier
579   Date:   30/12/2006
580   Status:
581
582   What:   The goal of this project is to be able to restore only rights
583           and attributes of files without crushing them.
584
585   Why:    Who have never had to repair a chmod -R 777, or a wild update
586           of recursive right under Windows? At this time, you must have
587           enough space to restore data, dump attributes (easy with acl,
588           more complex with unix/windows rights) and apply them to your 
589           broken tree. With this options, it will be very easy to compare
590           right or ACL over the time.
591
592   Notes:  If the file is here, we skip restore and we change rights.
593           If the file isn't here, we can create an empty one and apply
594           rights or do nothing.
595
596 Item 18:  Quick release of FD-SD connection after backup.
597   Origin: Frank Volf (frank at deze dot org)
598   Date:   17 November 2005
599   Status: Done -- implemented by Kern -- in CVS 26Jan07
600
601    What:  In the Bacula implementation a backup is finished after all data
602           and attributes are successfully written to storage.  When using a
603           tape backup it is very annoying that a backup can take a day,
604           simply because the current tape (or whatever) is full and the
605           administrator has not put a new one in.  During that time the
606           system cannot be taken off-line, because there is still an open
607           session between the storage daemon and the file daemon on the
608           client.
609
610           Although this is a very good strategy for making "safe backups"
611           This can be annoying for e.g.  laptops, that must remain
612           connected until the backup is completed.
613
614           Using a new feature called "migration" it will be possible to
615           spool first to harddisk (using a special 'spool' migration
616           scheme) and then migrate the backup to tape.
617
618           There is still the problem of getting the attributes committed.
619           If it takes a very long time to do, with the current code, the
620           job has not terminated, and the File daemon is not freed up.  The
621           Storage daemon should release the File daemon as soon as all the
622           file data and all the attributes have been sent to it (the SD).
623           Currently the SD waits until everything is on tape and all the
624           attributes are transmitted to the Director before signaling
625           completion to the FD. I don't think I would have any problem
626           changing this.  The reason is that even if the FD reports back to
627           the Dir that all is OK, the job will not terminate until the SD
628           has done the same thing -- so in a way keeping the SD-FD link
629           open to the very end is not really very productive ...
630
631    Why:   Makes backup of laptops much faster.
632
633 Item 19:  Implement a Python interface to the Bacula catalog.
634   Date:   28 October 2005
635   Origin: Kern
636   Status: 
637
638   What:   Implement an interface for Python scripts to access
639           the catalog through Bacula.
640
641   Why:    This will permit users to customize Bacula through
642           Python scripts.
643
644 Item 20:  Archive data
645   Date:   15/5/2006
646   Origin: calvin streeting calvin at absentdream dot com
647   Status:
648
649   What:   The abilty to archive to media (dvd/cd) in a uncompressed format
650           for dead filing (archiving not backing up)
651
652     Why:  At my works when jobs are finished and moved off of the main file
653           servers (raid based systems) onto a simple linux file server (ide based
654           system) so users can find old information without contacting the IT
655           dept.
656
657           So this data dosn't realy change it only gets added to,
658           But it also needs backing up.  At the moment it takes
659           about 8 hours to back up our servers (working data) so
660           rather than add more time to existing backups i am trying
661           to implement a system where we backup the acrhive data to
662           cd/dvd these disks would only need to be appended to
663           (burn only new/changed files to new disks for off site
664           storage).  basialy understand the differnce between
665           achive data and live data.
666
667   Notes:  Scan the data and email me when it needs burning divide
668           into predifind chunks keep a recored of what is on what
669           disk make me a label (simple php->mysql=>pdf stuff) i
670           could do this bit ability to save data uncompresed so
671           it can be read in any other system (future proof data)
672           save the catalog with the disk as some kind of menu
673           system 
674
675 Item 21:  Split documentation
676   Origin: Maxx <maxxatworkat gmail dot com>
677   Date:   27th July 2006
678   Status:
679
680   What:   Split documentation in several books
681
682   Why:    Bacula manual has now more than 600 pages, and looking for
683           implementation details is getting complicated.  I think
684           it would be good to split the single volume in two or
685           maybe three parts:
686
687           1) Introduction, requirements and tutorial, typically
688              are useful only until first installation time
689
690           2) Basic installation and configuration, with all the
691              gory details about the directives supported 3)
692              Advanced Bacula: testing, troubleshooting, GUI and
693              ancillary programs, security managements, scripting,
694              etc.
695
696
697 Item 22:  Implement support for stacking arbitrary stream filters, sinks.
698 Date:     23 November 2006
699 Origin:   Landon Fuller <landonf@threerings.net>
700 Status:   Planning. Assigned to landonf.
701
702   What:   Implement support for the following:
703           - Stacking arbitrary stream filters (eg, encryption, compression,  
704             sparse data handling))
705           - Attaching file sinks to terminate stream filters (ie, write out  
706             the resultant data to a file)
707           - Refactor the restoration state machine accordingly
708
709    Why:   The existing stream implementation suffers from the following:
710            - All state (compression, encryption, stream restoration), is  
711              global across the entire restore process, for all streams. There are  
712              multiple entry and exit points in the restoration state machine, and  
713              thus multiple places where state must be allocated, deallocated,  
714              initialized, or reinitialized. This results in exceptional complexity  
715              for the author of a stream filter.
716            - The developer must enumerate all possible combinations of filters  
717              and stream types (ie, win32 data with encryption, without encryption,  
718              with encryption AND compression, etc).
719
720   Notes:  This feature request only covers implementing the stream filters/ 
721           sinks, and refactoring the file daemon's restoration implementation  
722           accordingly. If I have extra time, I will also rewrite the backup  
723           implementation. My intent in implementing the restoration first is to  
724           solve pressing bugs in the restoration handling, and to ensure that  
725           the new restore implementation handles existing backups correctly.
726
727           I do not plan on changing the network or tape data structures to  
728           support defining arbitrary stream filters, but supporting that  
729           functionality is the ultimate goal.
730
731           Assistance with either code or testing would be fantastic.
732
733 Item 23:  Implement from-client and to-client on restore command line.
734    Date:  11 December 2006
735   Origin: Discussion on Bacula-users entitled 'Scripted restores to
736           different clients', December 2006 
737   Status: New feature request
738  
739   What:   While using bconsole interactively, you can specify the client
740           that a backup job is to be restored for, and then you can
741           specify later a different client to send the restored files
742           back to. However, using the 'restore' command with all options
743           on the command line, this cannot be done, due to the ambiguous
744           'client' parameter. Additionally, this parameter means different
745           things depending on if it's specified on the command line or
746           afterwards, in the Modify Job screens.
747  
748      Why: This feature would enable restore jobs to be more completely
749           automated, for example by a web or GUI front-end.
750  
751    Notes: client can also be implied by specifying the jobid on the command
752           line
753
754 Item 24:  Add an override in Schedule for Pools based on backup types.
755 Date:     19 Jan 2005
756 Origin:   Chad Slater <chad.slater@clickfox.com>
757 Status: 
758                                                 
759   What:   Adding a FullStorage=BigTapeLibrary in the Schedule resource
760           would help those of us who use different storage devices for different
761           backup levels cope with the "auto-upgrade" of a backup.
762
763   Why:    Assume I add several new device to be backed up, i.e. several
764           hosts with 1TB RAID.  To avoid tape switching hassles, incrementals are
765           stored in a disk set on a 2TB RAID.  If you add these devices in the
766           middle of the month, the incrementals are upgraded to "full" backups,
767           but they try to use the same storage device as requested in the
768           incremental job, filling up the RAID holding the differentials.  If we
769           could override the Storage parameter for full and/or differential
770           backups, then the Full job would use the proper Storage device, which
771           has more capacity (i.e. a 8TB tape library.
772
773 Item 25:  Implement huge exclude list support using hashing (dlists).
774   Date:   28 October 2005
775   Origin: Kern
776   Status: Done in 2.1.2 but was done with dlists (doubly linked lists
777           since hashing will not help. The huge list also supports
778           large include lists).
779
780   What:   Allow users to specify very large exclude list (currently
781           more than about 1000 files is too many).
782
783   Why:    This would give the users the ability to exclude all
784           files that are loaded with the OS (e.g. using rpms
785           or debs). If the user can restore the base OS from
786           CDs, there is no need to backup all those files. A
787           complete restore would be to restore the base OS, then
788           do a Bacula restore. By excluding the base OS files, the
789           backup set will be *much* smaller.
790
791 Item 26:  Implement more Python events in Bacula.
792   Date:   28 October 2005
793   Origin: Kern
794   Status: 
795
796   What:   Allow Python scripts to be called at more places 
797           within Bacula and provide additional access to Bacula
798           internal variables.
799
800   Why:    This will permit users to customize Bacula through
801           Python scripts.
802
803   Notes:  Recycle event
804           Scratch pool event
805           NeedVolume event
806           MediaFull event
807            
808           Also add a way to get a listing of currently running
809           jobs (possibly also scheduled jobs).
810
811
812 Item 27:  Incorporation of XACML2/SAML2 parsing
813    Date:   19 January 2006
814    Origin: Adam Thornton <athornton@sinenomine.net>
815    Status: Blue sky
816
817    What:   XACML is "eXtensible Access Control Markup Language" and  
818           "SAML is the "Security Assertion Markup Language"--an XML standard  
819           for making statements about identity and authorization.  Having these  
820           would give us a framework to approach ACLs in a generic manner, and  
821           in a way flexible enough to support the four major sorts of ACLs I  
822           see as a concern to Bacula at this point, as well as (probably) to  
823           deal with new sorts of ACLs that may appear in the future.
824
825    Why:    Bacula is beginning to need to back up systems with ACLs  
826           that do not map cleanly onto traditional Unix permissions.  I see  
827           four sets of ACLs--in general, mutually incompatible with one  
828           another--that we're going to need to deal with.  These are: NTFS  
829           ACLs, POSIX ACLs, NFSv4 ACLS, and AFS ACLS.  (Some may question the  
830           relevance of AFS; AFS is one of Sine Nomine's core consulting  
831           businesses, and having a reputable file-level backup and restore  
832           technology for it (as Tivoli is probably going to drop AFS support  
833           soon since IBM no longer supports AFS) would be of huge benefit to  
834           our customers; we'd most likely create the AFS support at Sine Nomine  
835           for inclusion into the Bacula (and perhaps some changes to the  
836           OpenAFS volserver) core code.)
837
838           Now, obviously, Bacula already handles NTFS just fine.  However, I  
839           think there's a lot of value in implementing a generic ACL model, so  
840           that it's easy to support whatever particular instances of ACLs come  
841           down the pike: POSIX ACLS (think SELinux) and NFSv4 are the obvious  
842           things arriving in the Linux world in a big way in the near future.   
843           XACML, although overcomplicated for our needs, provides this  
844           framework, and we should be able to leverage other people's  
845           implementations to minimize the amount of work *we* have to do to get  
846           a generic ACL framework.  Basically, the costs of implementation are  
847           high, but they're largely both external to Bacula and already sunk.
848
849 Item 28:  Filesystem watch triggered backup.
850   Date:   31 August 2006
851   Origin: Jesper Krogh <jesper@krogh.cc>
852   Status: Unimplemented, depends probably on "client initiated backups"
853
854   What:   With inotify and similar filesystem triggeret notification
855           systems is it possible to have the file-daemon to monitor
856           filesystem changes and initiate backup.
857
858   Why:    There are 2 situations where this is nice to have.
859           1) It is possible to get a much finer-grained backup than
860              the fixed schedules used now.. A file created and deleted
861              a few hours later, can automatically be caught.
862
863           2) The introduced load on the system will probably be
864              distributed more even on the system.
865
866   Notes:  This can be combined with configration that specifies
867           something like: "at most every 15 minutes or when changes
868           consumed XX MB".
869
870 Kern Notes: I would rather see this implemented by an external program
871           that monitors the Filesystem changes, then uses the console
872           to start the appropriate job.
873
874 Item 29:  Allow inclusion/exclusion of files in a fileset by creation/mod times
875   Origin: Evan Kaufman <evan.kaufman@gmail.com>
876   Date:   January 11, 2006
877   Status:
878
879   What:   In the vein of the Wild and Regex directives in a Fileset's
880           Options, it would be helpful to allow a user to include or exclude
881           files and directories by creation or modification times.
882
883           You could factor the Exclude=yes|no option in much the same way it
884           affects the Wild and Regex directives.  For example, you could exclude
885           all files modified before a certain date:
886
887    Options {
888      Exclude = yes
889      Modified Before = ####
890    }
891
892            Or you could exclude all files created/modified since a certain date:
893
894    Options {
895       Exclude = yes
896      Created Modified Since = ####
897    }
898
899            The format of the time/date could be done several ways, say the number
900            of seconds since the epoch:
901            1137008553 = Jan 11 2006, 1:42:33PM   # result of `date +%s`
902
903            Or a human readable date in a cryptic form:
904            20060111134233 = Jan 11 2006, 1:42:33PM   # YYYYMMDDhhmmss
905
906   Why:    I imagine a feature like this could have many uses. It would
907           allow a user to do a full backup while excluding the base operating
908           system files, so if I installed a Linux snapshot from a CD yesterday,
909           I'll *exclude* all files modified *before* today.  If I need to
910           recover the system, I use the CD I already have, plus the tape backup.
911           Or if, say, a Windows client is hit by a particularly corrosive
912           virus, and I need to *exclude* any files created/modified *since* the
913           time of infection.
914
915   Notes:  Of course, this feature would work in concert with other
916           in/exclude rules, and wouldnt override them (or each other).
917
918   Notes:  The directives I'd imagine would be along the lines of
919           "[Created] [Modified] [Before|Since] = <date>".
920           So one could compare against 'ctime' and/or 'mtime', but ONLY 'before'
921            or 'since'.
922
923
924 Item 30:  Tray monitor window cleanups
925   Origin: Alan Brown ajb2 at mssl dot ucl dot ac dot uk
926   Date:   24 July 2006
927   Status:
928   What:   Resizeable and scrollable windows in the tray monitor.
929
930   Why:    With multiple clients, or with many jobs running, the displayed
931           window often ends up larger than the available screen, making
932           the trailing items difficult to read.
933
934
935 Item 31:  Implement multiple numeric backup levels as supported by dump
936 Date:     3 April 2006
937 Origin:   Daniel Rich <drich@employees.org>
938 Status:
939 What:     Dump allows specification of backup levels numerically instead of just
940           "full", "incr", and "diff".  In this system, at any given level, all
941           files are backed up that were were modified since the last backup of a
942           higher level (with 0 being the highest and 9 being the lowest).  A
943           level 0 is therefore equivalent to a full, level 9 an incremental, and
944           the levels 1 through 8 are varying levels of differentials.  For
945           bacula's sake, these could be represented as "full", "incr", and
946           "diff1", "diff2", etc.
947
948 Why:      Support of multiple backup levels would provide for more advanced backup
949           rotation schemes such as "Towers of Hanoi".  This would allow better
950           flexibility in performing backups, and can lead to shorter recover
951           times.
952
953 Notes:    Legato Networker supports a similar system with full, incr, and 1-9 as
954           levels.
955         
956 Item 32:  Automatic promotion of backup levels
957    Date:  19 January 2006
958   Origin: Adam Thornton <athornton@sinenomine.net>
959   Status: 
960
961     What: Amanda has a feature whereby it estimates the space that a  
962           differential, incremental, and full backup would take.  If the  
963           difference in space required between the scheduled level and the next  
964           level up is beneath some user-defined critical threshold, the backup  
965           level is bumped to the next type.  Doing this minimizes the number of  
966           volumes necessary during a restore, with a fairly minimal cost in  
967           backup media space.
968
969     Why:  I know at least one (quite sophisticated and smart) user  
970           for whom the absence of this feature is a deal-breaker in terms of  
971           using Bacula; if we had it it would eliminate the one cool thing  
972           Amanda can do and we can't (at least, the one cool thing I know of).
973
974 Item 33:  Clustered file-daemons
975   Origin: Alan Brown ajb2 at mssl dot ucl dot ac dot uk
976   Date:   24 July 2006
977   Status:
978   What:   A "virtual" filedaemon, which is actually a cluster of real ones.
979
980   Why:    In the case of clustered filesystems (SAN setups, GFS, or OCFS2, etc)
981           multiple machines may have access to the same set of filesystems
982
983           For performance reasons, one may wish to initate backups from
984           several of these machines simultaneously, instead of just using
985           one backup source for the common clustered filesystem.
986
987           For obvious reasons, normally backups of $A-FD/$PATH and
988           B-FD/$PATH are treated as different backup sets. In this case
989           they are the same communal set.
990
991           Likewise when restoring, it would be easier to just specify
992           one of the cluster machines and let bacula decide which to use.
993
994           This can be faked to some extent using DNS round robin entries
995           and a virtual IP address, however it means "status client" will
996           always give bogus answers. Additionally there is no way of
997           spreading the load evenly among the servers.
998
999           What is required is something similar to the storage daemon
1000           autochanger directives, so that Bacula can keep track of
1001           operating backups/restores and direct new jobs to a "free"
1002           client.
1003
1004    Notes:
1005
1006 Item 34:  Commercial database support
1007   Origin: Russell Howe <russell_howe dot wreckage dot org>
1008   Date:   26 July 2006
1009   Status:
1010
1011   What:   It would be nice for the database backend to support more 
1012           databases. I'm thinking of SQL Server at the moment, but I guess Oracle, 
1013           DB2, MaxDB, etc are all candidates. SQL Server would presumably be 
1014           implemented using FreeTDS or maybe an ODBC library?
1015
1016   Why:    We only really have one database server, which is MS SQL Server 
1017           2000. Maintaining a second one for the backup software (we grew out of 
1018           SQLite, which I liked, but which didn't work so well with our database 
1019           size). We don't really have a machine with the resources to run 
1020           postgres, and would rather only maintain a single DBMS. We're stuck with 
1021           SQL Server because pretty much all the company's custom applications 
1022           (written by consultants) are locked into SQL Server 2000. I can imagine 
1023           this scenario is fairly common, and it would be nice to use the existing 
1024           properly specced database server for storing Bacula's catalog, rather 
1025           than having to run a second DBMS.
1026
1027 Item 35:  Automatic disabling of devices
1028    Date:  2005-11-11
1029   Origin: Peter Eriksson <peter at ifm.liu dot se>
1030   Status:
1031
1032    What:  After a configurable amount of fatal errors with a tape drive
1033           Bacula should automatically disable further use of a certain
1034           tape drive. There should also be "disable"/"enable" commands in
1035           the "bconsole" tool.
1036
1037    Why:   On a multi-drive jukebox there is a possibility of tape drives
1038           going bad during large backups (needing a cleaning tape run,
1039           tapes getting stuck). It would be advantageous if Bacula would
1040           automatically disable further use of a problematic tape drive
1041           after a configurable amount of errors has occurred.
1042
1043           An example: I have a multi-drive jukebox (6 drives, 380+ slots)
1044           where tapes occasionally get stuck inside the drive. Bacula will
1045           notice that the "mtx-changer" command will fail and then fail
1046           any backup jobs trying to use that drive. However, it will still
1047           keep on trying to run new jobs using that drive and fail -
1048           forever, and thus failing lots and lots of jobs... Since we have
1049           many drives Bacula could have just automatically disabled
1050           further use of that drive and used one of the other ones
1051           instead.
1052
1053 Item 36:  An option to operate on all pools with update vol parameters
1054   Origin: Dmitriy Pinchukov <absh@bossdev.kiev.ua>
1055    Date:  16 August 2006
1056   Status:
1057
1058    What:  When I do update -> Volume parameters -> All Volumes
1059           from Pool, then I have to select pools one by one.  I'd like
1060           console to have an option like "0: All Pools" in the list of
1061           defined pools.
1062
1063    Why:   I have many pools and therefore unhappy with manually
1064           updating each of them using update -> Volume parameters -> All
1065           Volumes from Pool -> pool #.
1066
1067 Item 37:  Add an item to the restore option where you can select a pool
1068   Origin: kshatriyak at gmail dot com
1069     Date: 1/1/2006
1070   Status:
1071
1072     What: In the restore option (Select the most recent backup for a
1073           client) it would be useful to add an option where you can limit
1074           the selection to a certain pool.
1075
1076      Why: When using cloned jobs, most of the time you have 2 pools - a
1077           disk pool and a tape pool.  People who have 2 pools would like to
1078           select the most recent backup from disk, not from tape (tape
1079           would be only needed in emergency).  However, the most recent
1080           backup (which may just differ a second from the disk backup) may
1081           be on tape and would be selected.  The problem becomes bigger if
1082           you have a full and differential - the most "recent" full backup
1083           may be on disk, while the most recent differential may be on tape
1084           (though the differential on disk may differ even only a second or
1085           so).  Bacula will complain that the backups reside on different
1086           media then.  For now the only solution now when restoring things
1087           when you have 2 pools is to manually search for the right
1088           job-id's and enter them by hand, which is a bit fault tolerant.
1089
1090 Item 38:  Include timestamp of job launch in "stat clients" output
1091   Origin: Mark Bergman <mark.bergman@uphs.upenn.edu>
1092   Date:   Tue Aug 22 17:13:39 EDT 2006
1093   Status:
1094
1095   What:   The "stat clients" command doesn't include any detail on when
1096           the active backup jobs were launched.
1097
1098   Why:    Including the timestamp would make it much easier to decide whether
1099           a job is running properly. 
1100
1101   Notes:  It may be helpful to have the output from "stat clients" formatted 
1102           more like that from "stat dir" (and other commands), in a column
1103           format. The per-client information that's currently shown (level,
1104           client name, JobId, Volume, pool, device, Files, etc.) is good, but
1105           somewhat hard to parse (both programmatically and visually), 
1106           particularly when there are many active clients.
1107
1108
1109 Item 39:  Message mailing based on backup types
1110  Origin:  Evan Kaufman <evan.kaufman@gmail.com>
1111    Date:  January 6, 2006
1112  Status:
1113
1114    What:  In the "Messages" resource definitions, allowing messages
1115           to be mailed based on the type (backup, restore, etc.) and level
1116           (full, differential, etc) of job that created the originating
1117           message(s).
1118
1119  Why:     It would, for example, allow someone's boss to be emailed
1120           automatically only when a Full Backup job runs, so he can
1121           retrieve the tapes for offsite storage, even if the IT dept.
1122           doesn't (or can't) explicitly notify him.  At the same time, his
1123           mailbox wouldnt be filled by notifications of Verifies, Restores,
1124           or Incremental/Differential Backups (which would likely be kept
1125           onsite).
1126
1127  Notes:   One way this could be done is through additional message types, for example:
1128
1129    Messages {
1130      # email the boss only on full system backups
1131      Mail = boss@mycompany.com = full, !incremental, !differential, !restore, 
1132             !verify, !admin
1133      # email us only when something breaks
1134      MailOnError = itdept@mycompany.com = all
1135    }
1136
1137
1138 Item 40:  Include JobID in spool file name ****DONE****
1139   Origin: Mark Bergman <mark.bergman@uphs.upenn.edu>
1140   Date:   Tue Aug 22 17:13:39 EDT 2006
1141   Status: Done. (patches/testing/project-include-jobid-in-spool-name.patch)
1142           No need to vote for this item.
1143
1144   What:   Change the name of the spool file to include the JobID
1145
1146   Why:    JobIDs are the common key used to refer to jobs, yet the 
1147           spoolfile name doesn't include that information. The date/time
1148           stamp is useful (and should be retained).
1149
1150 ============= New Freature Requests after vote of 26 Jan 2007 ========
1151 Item  41: Enable to relocate files and directories when restoring
1152   Date:   2007-03-01
1153   Origin: Eric Bollengier <eric@eb.homelinux.org>
1154   Status: Done.
1155
1156   What:   The where= option is not powerful enough. It will be
1157           a great feature if bacula can restore a file in the
1158           same directory, but with a different name, or in 
1159           an other directory without recreating the full path.
1160
1161   Why:    When i want to restore a production environment to a
1162           development environment, i just want change the first
1163           directory. ie restore /prod/data/file.dat to /rect/data/file.dat.
1164           At this time, i have to move by hand files. You must have a big
1165           dump space to restore and move data after.
1166
1167           When i use Linux or SAN snapshot, i mount them to /mnt/snap_xxx
1168           so, when a restore a file, i have to move by hand
1169           from /mnt/snap_xxx/file to /xxx/file. I can't replace a file
1170           easily.
1171
1172           When a user ask me to restore a file in its personal folder,
1173           (without replace the existing one), i can't restore from
1174           my_file.txt to my_file.txt.old witch is very practical.
1175
1176           
1177   Notes:  I think we can enhance the where= option very easily by
1178           allowing regexp expression. 
1179
1180           Since, many users think that regexp are not user friendly, i think
1181           that bat, bconsole or brestore must provide a simple way to
1182           configure where= option (i think to something like in
1183           openoffice "search and replace").
1184
1185           Ie, if user uses where=/tmp/bacula-restore, we keep the old
1186           fashion.
1187
1188           If user uses something like where=s!/prod!/test!, files will
1189           be restored from /prod/xxx to /test/xxx.
1190
1191           If user uses something like where=s/$/.old/, files will
1192           be restored from /prod/xxx.txt to /prod/xxx.txt.old.
1193
1194           If user uses something like where=s/txt$/old.txt/, files will
1195           be restored from /prod/xxx.txt to /prod/xxx.old.txt
1196
1197           if user uses something like where=s/([a-z]+)$/old.$1/, files will
1198           be restored from /prod/xxx.ext to /prod/xxx.old.ext
1199
1200 Item n:   Implement Catalog directive for Pool resource in Director
1201 configuration 
1202   Origin: Alan Davis adavis@ruckus.com
1203   Date:   6 March 2007
1204   Status: Submitted
1205  
1206   What:   The current behavior is for the director to create all pools
1207           found in the configuration file in all catalogs.  Add a
1208           Catalog directive to the Pool resource to specify which
1209           catalog to use for each pool definition.
1210  
1211   Why:    This allows different catalogs to have different pool
1212           attributes and eliminates the side-effect of adding
1213           pools to catalogs that don't need/use them.
1214  
1215   Notes:  
1216
1217
1218 Item n:   Implement NDMP protocol support
1219   Origin: Alan Davis
1220   Date:   06 March 2007
1221   Status: Submitted
1222
1223   What:   Network Data Management Protocol is implemented by a number of
1224           NAS filer vendors to enable backups using third-party
1225           software.
1226
1227   Why:    This would allow NAS filer backups in Bacula without incurring
1228           the overhead of NFS or SBM/CIFS.
1229
1230   Notes:  Further information is available:
1231           http://www.ndmp.org
1232           http://www.ndmp.org/wp/wp.shtml
1233           http://www.traakan.com/ndmjob/index.html
1234
1235           There are currently no viable open-source NDMP
1236           implementations.  There is a reference SDK and example
1237           app available from ndmp.org but it has problems
1238           compiling on recent Linux and Solaris OS'.  The ndmjob
1239           reference implementation from Traakan is known to
1240           compile on Solaris 10.
1241
1242   Notes (Kern): I am not at all in favor of this until NDMP becomes
1243           an Open Standard or until there are Open Source libraries
1244           that interface to it.
1245
1246 Item n: make changing "spooldata=yes|no" possible for
1247         manual/interactive jobs
1248
1249 Origin: Marc Schiffbauer <marc@schiffbauer.net>
1250
1251 Date:   12 April 2007)
1252
1253 Status: NEW
1254
1255 What:   Make it possible to modify the spooldata option
1256         for a job when being run from within the console.
1257         Currently it is possible to modify the backup level
1258         and the spooldata setting in a Schedule resource.
1259         It is also possible to modify the backup level when using
1260         the "run" command in the console. 
1261         But it is currently not possible to to the same 
1262         with "spooldata=yes|no" like:
1263
1264         run job=MyJob level=incremental spooldata=yes
1265
1266 Why:    In some situations it would be handy to be able to switch
1267         spooldata on or off for interactive/manual jobs based on
1268         which data the admin expects or how fast the LAN/WAN
1269         connection currently is.
1270
1271 Notes:  ./.
1272
1273 ============= Empty Feature Request form ===========
1274 Item  n:  One line summary ...
1275   Date:   Date submitted 
1276   Origin: Name and email of originator.
1277   Status: 
1278
1279   What:   More detailed explanation ...
1280
1281   Why:    Why it is important ...
1282
1283   Notes:  Additional notes or features (omit if not used)
1284 ============== End Feature Request form ==============
1285
1286 </pre>
1287
1288         </td>
1289 </tr>
1290 </table>
1291
1292 <? require_once("inc/footer.php"); ?>