3 Bacula Projects Roadmap
4 Status updated 26 April 2009
7 Item 1: Allow FD to initiate a backup
8 Item 2: Ability to restart failed jobs
9 Item 3: Port bat to Win32
10 Item 4: Convert Bacula existing tray monitor on Windows to a stand alone program
11 Item 5: Ability to import/export Bacula database entities
12 Item 6: Ability to defer Batch Insert to a later time
13 Item 7: List InChanger flag when doing restore.
14 Item 8: Deletion of disk Volumes when pruned
15 Item 9: Implement Base jobs
16 Item 10: Scheduling syntax that permits more flexibility and options
17 Item 11: Reduction of communications bandwidth for a backup
18 Item 12: Bacula Dir, FD and SD to support proxies
19 Item 13: Message mailing based on backup types
20 Item 14: Ability to reconnect a disconnected comm line
21 Item 15: Include timestamp of job launch in "stat clients" output
22 Item 16: Add an override in Schedule for Pools based on backup types
23 Item 17: Automatic promotion of backup levels based on backup size
24 Item 18: Allow inclusion/exclusion of files in a fileset by creation/mod times
25 Item 19: Archival (removal) of User Files to Tape
26 Item 20: Include all conf files in specified directory
27 Item 21: Implement an interface between Bacula and Amazon's S3.
28 Item 22: Enable/disable compression depending on storage device (disk/tape)
29 Item 23: Add EFS support on Windows
30 Item 24: Data encryption on storage daemon
31 Item 25: "Maximum Concurrent Jobs" for drives when used with changer device
32 Item 26: Add MaxVolumeSize/MaxVolumeBytes statement to Storage resource
33 Item 27: Start spooling even when waiting on tape
34 Item 28: Enable persistent naming/number of SQL queries
35 Item 29: Implementation of running Job speed limit.
36 Item 30: Restore from volumes on multiple storage daemons
37 Item 28:'restore' menu: enter a JobId, automatically select dependents
38 Item 31: Backup and Restore of Windows Encrypted Files using Win raw encryption
39 Item 32: Possibilty to schedule Jobs on last Friday of the month
40 Item 33: Add Minumum Spool Size directive
41 Item 34: Cause daemons to use a specific IP address to source communications
42 Item 35: Add ability to Verify any specified Job.
43 Item 36: Automatic disabling of devices
44 Item 37: An option to operate on all pools with update vol parameters
45 Item 38: Implement Storage daemon compression
46 Item 39: Improve Bacula's tape and drive usage and cleaning management
47 Item 40: Multiple threads in file daemon for the same job
50 Item 1: Allow FD to initiate a backup
51 Origin: Frank Volf (frank at deze dot org)
52 Date: 17 November 2005
55 What: Provide some means, possibly by a restricted console that
56 allows a FD to initiate a backup, and that uses the connection
57 established by the FD to the Director for the backup so that
58 a Director that is firewalled can do the backup.
59 Why: Makes backup of laptops much easier.
61 Item 2: Ability to restart failed jobs
66 What: Often jobs fail because of a communications line drop or max run time,
67 cancel, or some other non-critical problem. Currrently any data
68 saved is lost. This implementation should modify the Storage daemon
69 so that it saves all the files that it knows are completely backed
72 The jobs should then be marked as incomplete and a subsequent
73 Incremental Accurate backup will then take into account all the
76 Why: Avoids backuping data already saved.
78 Notes: Requires Accurate to restart correctly. Must completed have a minimum
79 volume of data or files stored on Volume before enabling.
81 Item 3: Port bat to Win32
86 What: Make bat run on Win32/64.
88 Why: To have GUI on Windows
92 Item 4: Convert Bacula existing tray monitor on Windows to a stand alone program
97 What: Separate Win32 tray monitor to be a separate program.
99 Why: Vista does not allow SYSTEM services to interact with the
100 desktop, so the current tray monitor does not work on Vista
103 Notes: Requires communicating with the FD via the network (simulate
104 a console connection).
108 Item 5: Ability to import/export Bacula database entities
113 What: Create a Bacula ASCII SQL database independent format that permits
114 importing and exporting database catalog Job entities.
116 Why: For achival, database clustering, tranfer to other databases
119 Notes: Job selection should be by Job, time, Volume, Client, Pool and possibly
123 Item 6: Ability to defer Batch Insert to a later time
128 What: Instead of doing a Job Batch Insert at the end of the Job
129 which might create resource contention with lots of Job,
130 defer the insert to a later time.
132 Why: Permits to focus on getting the data on the Volume and
133 putting the metadata into the Catalog outside the backup
136 Notes: Will use the proposed Bacula ASCII database import/export
137 format (i.e. dependent on the import/export entities project).
140 Item 7: List InChanger flag when doing restore.
141 Origin: Jesper Krogh<jesper@krogh.cc>
145 What: When doing a restore the restore selection dialog ends by telling stuff
147 The job will require the following
148 Volume(s) Storage(s) SD Device(s)
149 ===========================================================================
160 When having an autochanger, it would be really nice with an inChanger
161 column so the operator knew if this restore job would stop waiting for
162 operator intervention. This is done just by selecting the inChanger flag
163 from the catalog and printing it in a seperate column.
166 Why: This would help getting large restores through minimizing the
167 time spent waiting for operator to drop by and change tapes in the library.
169 Notes: [Kern] I think it would also be good to have the Slot as well,
170 or some indication that Bacula thinks the volume is in the autochanger
171 because it depends on both the InChanger flag and the Slot being
175 Item 8: Deletion of disk Volumes when pruned
177 Origin: Ross Boylan <RossBoylan at stanfordalumni dot org> (edited
181 What: Provide a way for Bacula to automatically remove Volumes
182 from the filesystem, or optionally to truncate them.
183 Obviously, the Volume must be pruned prior removal.
185 Why: This would allow users more control over their Volumes and
186 prevent disk based volumes from consuming too much space.
188 Notes: The following two directives might do the trick:
190 Volume Data Retention = <time period>
191 Remove Volume After = <time period>
193 The migration project should also remove a Volume that is
194 migrated. This might also work for tape Volumes.
196 Notes: (Kern). The data fields to control this have been added
197 to the new 3.0.0 database table structure.
201 Item 9: Implement Base jobs
202 Date: 28 October 2005
206 What: A base job is sort of like a Full save except that you
207 will want the FileSet to contain only files that are
208 unlikely to change in the future (i.e. a snapshot of
209 most of your system after installing it). After the
210 base job has been run, when you are doing a Full save,
211 you specify one or more Base jobs to be used. All
212 files that have been backed up in the Base job/jobs but
213 not modified will then be excluded from the backup.
214 During a restore, the Base jobs will be automatically
215 pulled in where necessary.
217 Why: This is something none of the competition does, as far as
218 we know (except perhaps BackupPC, which is a Perl program that
219 saves to disk only). It is big win for the user, it
220 makes Bacula stand out as offering a unique
221 optimization that immediately saves time and money.
222 Basically, imagine that you have 100 nearly identical
223 Windows or Linux machine containing the OS and user
224 files. Now for the OS part, a Base job will be backed
225 up once, and rather than making 100 copies of the OS,
226 there will be only one. If one or more of the systems
227 have some files updated, no problem, they will be
228 automatically restored.
230 Notes: Huge savings in tape usage even for a single machine.
231 Will require more resources because the DIR must send
232 FD a list of files/attribs, and the FD must search the
233 list and compare it for each file to be saved.
236 Item 10: Scheduling syntax that permits more flexibility and options
237 Date: 15 December 2006
238 Origin: Gregory Brauer (greg at wildbrain dot com) and
239 Florian Schnabel <florian.schnabel at docufy dot de>
242 What: Currently, Bacula only understands how to deal with weeks of the
243 month or weeks of the year in schedules. This makes it impossible
244 to do a true weekly rotation of tapes. There will always be a
245 discontinuity that will require disruptive manual intervention at
246 least monthly or yearly because week boundaries never align with
247 month or year boundaries.
249 A solution would be to add a new syntax that defines (at least)
250 a start timestamp, and repetition period.
252 An easy option to skip a certain job on a certain date.
255 Why: Rotated backups done at weekly intervals are useful, and Bacula
256 cannot currently do them without extensive hacking.
258 You could then easily skip tape backups on holidays. Especially
259 if you got no autochanger and can only fit one backup on a tape
260 that would be really handy, other jobs could proceed normally
261 and you won't get errors that way.
264 Notes: Here is an example syntax showing a 3-week rotation where full
265 Backups would be performed every week on Saturday, and an
266 incremental would be performed every week on Tuesday. Each
267 set of tapes could be removed from the loader for the following
268 two cycles before coming back and being reused on the third
269 week. Since the execution times are determined by intervals
270 from a given point in time, there will never be any issues with
271 having to adjust to any sort of arbitrary time boundary. In
272 the example provided, I even define the starting schedule
273 as crossing both a year and a month boundary, but the run times
274 would be based on the "Repeat" value and would therefore happen
279 Name = "Week 1 Rotation"
280 #Saturday. Would run Dec 30, Jan 20, Feb 10, etc.
284 Start = 2006-12-30 01:00
288 #Tuesday. Would run Jan 2, Jan 23, Feb 13, etc.
292 Start = 2007-01-02 01:00
299 Name = "Week 2 Rotation"
300 #Saturday. Would run Jan 6, Jan 27, Feb 17, etc.
304 Start = 2007-01-06 01:00
308 #Tuesday. Would run Jan 9, Jan 30, Feb 20, etc.
312 Start = 2007-01-09 01:00
319 Name = "Week 3 Rotation"
320 #Saturday. Would run Jan 13, Feb 3, Feb 24, etc.
324 Start = 2007-01-13 01:00
328 #Tuesday. Would run Jan 16, Feb 6, Feb 27, etc.
332 Start = 2007-01-16 01:00
338 Notes: Kern: I have merged the previously separate project of skipping
339 jobs (via Schedule syntax) into this.
341 Item 11: Reduction of communications bandwidth for a backup
342 Date: 14 October 2008
343 Origin: Robin O'Leary (Equiinet)
346 What: Using rdiff techniques, Bacula could significantly reduce
347 the network data transfer volume to do a backup.
349 Why: Faster backup across the Internet
351 Notes: This requires retaining certain data on the client during a Full
352 backup that will speed up subsequent backups.
355 Item 12: Bacula Dir, FD and SD to support proxies
356 Origin: Karl Grindley @ MIT Lincoln Laboratory <kgrindley at ll dot mit dot edu>
360 What: Support alternate methods for nailing up a TCP session such
361 as SOCKS5, SOCKS4 and HTTP (CONNECT) proxies. Such a feature
362 would allow tunneling of bacula traffic in and out of proxied
365 Why: Currently, bacula is architected to only function on a flat network, with
366 no barriers or limitations. Due to the large configuration states of
367 any network and the infinite configuration where file daemons and
368 storage daemons may sit in relation to one another, bacula often is
369 not usable on a network where filtered or air-gaped networks exist.
370 While often solutions such as ACL modifications to firewalls or port
371 redirection via SNAT or DNAT will solve the issue, often however,
372 these solutions are not adequate or not allowed by hard policy.
374 In an air-gapped network with only a highly locked down proxy services
375 are provided (SOCKS4/5 and/or HTTP and/or SSH outbound) ACLs or
376 iptable rules will not work.
378 Notes: Director resource tunneling: This configuration option to utilize a
379 proxy to connect to a client should be specified in the client
380 resource Client resource tunneling: should be configured in the client
381 resource in the director config file? Or configured on the bacula-fd
382 configuration file on the fd host itself? If the ladder, this would
383 allow only certain clients to use a proxy, where others do not when
384 establishing the TCP connection to the storage server.
386 Also worth noting, there are other 3rd party, light weight apps that
387 could be utilized to bootstrap this. Instead of sockifing bacula
388 itself, use an external program to broker proxy authentication, and
389 connection to the remote host. OpenSSH does this by using the
390 "ProxyCommand" syntax in the client configuration and uses stdin and
391 stdout to the command. Connect.c is a very popular one.
392 (http://bent.latency.net/bent/darcs/goto-san-connect-1.85/src/connect.html).
393 One could also possibly use stunnel, netcat, etc.
396 Item 13: Message mailing based on backup types
397 Origin: Evan Kaufman <evan.kaufman@gmail.com>
398 Date: January 6, 2006
401 What: In the "Messages" resource definitions, allowing messages
402 to be mailed based on the type (backup, restore, etc.) and level
403 (full, differential, etc) of job that created the originating
406 Why: It would, for example, allow someone's boss to be emailed
407 automatically only when a Full Backup job runs, so he can
408 retrieve the tapes for offsite storage, even if the IT dept.
409 doesn't (or can't) explicitly notify him. At the same time, his
410 mailbox wouldnt be filled by notifications of Verifies, Restores,
411 or Incremental/Differential Backups (which would likely be kept
414 Notes: One way this could be done is through additional message types, for example:
417 # email the boss only on full system backups
418 Mail = boss@mycompany.com = full, !incremental, !differential, !restore,
420 # email us only when something breaks
421 MailOnError = itdept@mycompany.com = all
424 Notes: Kern: This should be rather trivial to implement.
426 Item 14: Ability to reconnect a disconnected comm line
431 What: Often jobs fail because of a communications line drop. In that
432 case, Bacula should be able to reconnect to the other daemon and
435 Why: Avoids backuping data already saved.
437 Notes: *Very* complicated from a design point of view because of authenication.
440 Item 15: Include timestamp of job launch in "stat clients" output
441 Origin: Mark Bergman <mark.bergman@uphs.upenn.edu>
442 Date: Tue Aug 22 17:13:39 EDT 2006
445 What: The "stat clients" command doesn't include any detail on when
446 the active backup jobs were launched.
448 Why: Including the timestamp would make it much easier to decide whether
449 a job is running properly.
451 Notes: It may be helpful to have the output from "stat clients" formatted
452 more like that from "stat dir" (and other commands), in a column
453 format. The per-client information that's currently shown (level,
454 client name, JobId, Volume, pool, device, Files, etc.) is good, but
455 somewhat hard to parse (both programmatically and visually),
456 particularly when there are many active clients.
461 Item 16: Add an override in Schedule for Pools based on backup types
463 Origin: Chad Slater <chad.slater@clickfox.com>
466 What: Adding a FullStorage=BigTapeLibrary in the Schedule resource
467 would help those of us who use different storage devices for different
468 backup levels cope with the "auto-upgrade" of a backup.
470 Why: Assume I add several new devices to be backed up, i.e. several
471 hosts with 1TB RAID. To avoid tape switching hassles, incrementals are
472 stored in a disk set on a 2TB RAID. If you add these devices in the
473 middle of the month, the incrementals are upgraded to "full" backups,
474 but they try to use the same storage device as requested in the
475 incremental job, filling up the RAID holding the differentials. If we
476 could override the Storage parameter for full and/or differential
477 backups, then the Full job would use the proper Storage device, which
478 has more capacity (i.e. a 8TB tape library.
480 Item 17: Automatic promotion of backup levels based on backup size
481 Date: 19 January 2006
482 Origin: Adam Thornton <athornton@sinenomine.net>
485 What: Other backup programs have a feature whereby it estimates the space
486 that a differential, incremental, and full backup would take. If
487 the difference in space required between the scheduled level and the
488 next level up is beneath some user-defined critical threshold, the
489 backup level is bumped to the next type. Doing this minimizes the
490 number of volumes necessary during a restore, with a fairly minimal
491 cost in backup media space.
493 Why: I know at least one (quite sophisticated and smart) user for whom the
494 absence of this feature is a deal-breaker in terms of using Bacula;
495 if we had it it would eliminate the one cool thing other backup
496 programs can do and we can't (at least, the one cool thing I know
499 Item 18: Allow inclusion/exclusion of files in a fileset by creation/mod times
500 Origin: Evan Kaufman <evan.kaufman@gmail.com>
501 Date: January 11, 2006
504 What: In the vein of the Wild and Regex directives in a Fileset's
505 Options, it would be helpful to allow a user to include or exclude
506 files and directories by creation or modification times.
508 You could factor the Exclude=yes|no option in much the same way it
509 affects the Wild and Regex directives. For example, you could exclude
510 all files modified before a certain date:
514 Modified Before = ####
517 Or you could exclude all files created/modified since a certain date:
521 Created Modified Since = ####
524 The format of the time/date could be done several ways, say the number
525 of seconds since the epoch:
526 1137008553 = Jan 11 2006, 1:42:33PM # result of `date +%s`
528 Or a human readable date in a cryptic form:
529 20060111134233 = Jan 11 2006, 1:42:33PM # YYYYMMDDhhmmss
531 Why: I imagine a feature like this could have many uses. It would
532 allow a user to do a full backup while excluding the base operating
533 system files, so if I installed a Linux snapshot from a CD yesterday,
534 I'll *exclude* all files modified *before* today. If I need to
535 recover the system, I use the CD I already have, plus the tape backup.
536 Or if, say, a Windows client is hit by a particularly corrosive
537 virus, and I need to *exclude* any files created/modified *since* the
540 Notes: Of course, this feature would work in concert with other
541 in/exclude rules, and wouldnt override them (or each other).
543 Notes: The directives I'd imagine would be along the lines of
544 "[Created] [Modified] [Before|Since] = <date>".
545 So one could compare against 'ctime' and/or 'mtime', but ONLY 'before'
550 Item 19: Archival (removal) of User Files to Tape
552 Origin: Ray Pengelly [ray at biomed dot queensu dot ca
555 What: The ability to archive data to storage based on certain parameters
556 such as age, size, or location. Once the data has been written to
557 storage and logged it is then pruned from the originating
558 filesystem. Note! We are talking about user's files and not
561 Why: This would allow fully automatic storage management which becomes
562 useful for large datastores. It would also allow for auto-staging
563 from one media type to another.
565 Example 1) Medical imaging needs to store large amounts of data.
566 They decide to keep data on their servers for 6 months and then put
567 it away for long term storage. The server then finds all files
568 older than 6 months writes them to tape. The files are then removed
571 Example 2) All data that hasn't been accessed in 2 months could be
572 moved from high-cost, fibre-channel disk storage to a low-cost
573 large-capacity SATA disk storage pool which doesn't have as quick of
574 access time. Then after another 6 months (or possibly as one
575 storage pool gets full) data is migrated to Tape.
578 Item 20: Include all conf files in specified directory
579 Date: 18 October 2008
580 Origin: Database, Lda. Maputo, Mozambique
581 Contact:Cameron Smith / cameron.ord@database.co.mz
584 What: A directive something like "IncludeConf = /etc/bacula/subconfs" Every
585 time Bacula Director restarts or reloads, it will walk the given
586 directory (non-recursively) and include the contents of any files
587 therein, as though they were appended to bacula-dir.conf
589 Why: Permits simplified and safer configuration for larger installations with
590 many client PCs. Currently, through judicious use of JobDefs and
591 similar directives, it is possible to reduce the client-specific part of
592 a configuration to a minimum. The client-specific directives can be
593 prepared according to a standard template and dropped into a known
594 directory. However it is still necessary to add a line to the "master"
595 (bacula-dir.conf) referencing each new file. This exposes the master to
596 unnecessary risk of accidental mistakes and makes automation of adding
597 new client-confs, more difficult (it is easier to automate dropping a
598 file into a dir, than rewriting an existing file). Ken has previously
599 made a convincing argument for NOT including Bacula's core configuration
600 in an RDBMS, but I believe that the present request is a reasonable
601 extension to the current "flat-file-based" configuration philosophy.
603 Notes: There is NO need for any special syntax to these files. They should
604 contain standard directives which are simply "inlined" to the parent
605 file as already happens when you explicitly reference an external file.
607 Notes: (kes) this can already be done with scripting
608 From: John Jorgensen <jorgnsn@lcd.uregina.ca>
609 The bacula-dir.conf at our site contains these lines:
612 # Include subfiles associated with configuration of clients.
613 # They define the bulk of the Clients, Jobs, and FileSets.
615 @|"sh -c 'for f in /etc/bacula/clientdefs/*.conf ; do echo @${f} ; done'"
617 and when we get a new client, we just put its configuration into
618 a new file called something like:
620 /etc/bacula/clientdefs/clientname.conf
625 Item 21: Implement an interface between Bacula and Amazon's S3.
627 Origin: Soren Hansen <soren@ubuntu.com>
629 What: Enable the storage daemon to store backup data on Amazon's
632 Why: Amazon's S3 is a cheap way to store data off-site. Current
633 ways to integrate Bacula and S3 involve storing all the data
634 locally and syncing them to S3, and manually fetching them
635 again when they're needed. This is very cumbersome.
638 Item 22: Enable/disable compression depending on storage device (disk/tape)
639 Origin: Ralf Gross ralf-lists@ralfgross.de
641 Status: Initial Request
643 What: Add a new option to the storage resource of the director. Depending
644 on this option, compression will be enabled/disabled for a device.
646 Why: If different devices (disks/tapes) are used for full/diff/incr
647 backups, software compression will be enabled for all backups
648 because of the FileSet compression option. For backup to tapes
649 wich are able to do hardware compression this is not desired.
653 http://news.gmane.org/gmane.comp.sysutils.backup.bacula.devel/cutoff=11124
654 It must be clear to the user, that the FileSet compression option
655 must still be enabled use compression for a backup job at all.
656 Thus a name for the new option in the director must be
659 Notes: KES I think the Storage definition should probably override what
660 is in the Job definition or vice-versa, but in any case, it must
665 Item 23: Add EFS support on Windows
666 Origin: Alex Ehrlich (Alex.Ehrlich-at-mail.ee)
670 What: For each file backed up or restored by FD on Windows, check if
671 the file is encrypted; if so then use OpenEncryptedFileRaw,
672 ReadEncryptedFileRaw, WriteEncryptedFileRaw,
673 CloseEncryptedFileRaw instead of BackupRead and BackupWrite
676 Why: Many laptop users utilize the EFS functionality today; so do.
677 some non-laptop ones, too.
678 Currently files encrypted by means of EFS cannot be backed up.
679 It means a Windows boutique cannot rely on Bacula as its
680 backup solution, at least when using Windows 2K, XPP,
681 "better" Vista etc on workstations, unless EFS is
682 forbidden by policies.
683 The current situation might result into "false sense of
684 security" among the end-users.
686 Notes: Using xxxEncryptedFileRaw API would allow to backup and
687 restore EFS-encrypted files without decrypting their data.
688 Note that such files cannot be restored "portably" (at least,
689 easily) but they would be restoreable to a different (or
690 reinstalled) Win32 machine; the restore would require setup
691 of a EFS recovery agent in advance, of course, and this shall
692 be clearly reflected in the documentation, but this is the
693 normal Windows SysAdmin's business.
694 When "portable" backup is requested the EFS-encrypted files
695 shall be clearly reported as errors.
696 See MSDN on the "Backup and Restore of Encrypted Files" topic:
697 http://msdn.microsoft.com/en-us/library/aa363783.aspx
698 Maybe the EFS support requires a new flag in the database for
700 Unfortunately, the implementation is not as straightforward as
701 1-to-1 replacement of BackupRead with ReadEncryptedFileRaw,
702 requiring some FD code rewrite to work with
703 encrypted-file-related callback functions.
705 Item 24: Data encryption on storage daemon
706 Origin: Tobias Barth <tobias.barth at web-arts.com>
707 Date: 04 February 2009
710 What: The storage demon should be able to do the data encryption that can currently be done by the file daemon.
712 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.
715 As an addendum to the feature request, here are some crypto
716 implementation details I wrote up regarding SD-encryption back in Jan
718 http://www.mail-archive.com/bacula-users@lists.sourceforge.net/msg28860.html
722 Item 25: "Maximum Concurrent Jobs" for drives when used with changer device
723 Origin: Ralf Gross ralf-lists <at> ralfgross.de
725 Status: Initial Request
727 What: respect the "Maximum Concurrent Jobs" directive in the _drives_
728 Storage section in addition to the changer section
730 Why: I have a 3 drive changer where I want to be able to let 3 concurrent
731 jobs run in parallel. But only one job per drive at the same time.
732 Right now I don't see how I could limit the number of concurrent jobs
733 per drive in this situation.
735 Notes: Using different priorities for these jobs lead to problems that other
736 jobs are blocked. On the user list I got the advice to use the "Prefer Mounted
737 Volumes" directive, but Kern advised against using "Prefer Mounted
738 Volumes" in an other thread:
739 http://article.gmane.org/gmane.comp.sysutils.backup.bacula.devel/11876/
741 In addition I'm not sure if this would be the same as respecting the
742 drive's "Maximum Concurrent Jobs" setting.
754 Maximum Concurrent Jobs = 3
758 Name = Neo4100-LTO4-D1
762 Device = ULTRIUM-TD4-D1
764 Maximum Concurrent Jobs = 1
769 The "Maximum Concurrent Jobs = 1" directive in the drive's section is ignored.
771 Item 26: Add MaxVolumeSize/MaxVolumeBytes statement to Storage resource
772 Origin: Bastian Friedrich <bastian.friedrich@collax.com>
776 What: SD has a "Maximum Volume Size" statement, which is deprecated and
777 superseded by the Pool resource statement "Maximum Volume Bytes".
778 It would be good if either statement could be used in Storage
781 Why: Pools do not have to be restricted to a single storage type/device;
782 thus, it may be impossible to define Maximum Volume Bytes in the
783 Pool resource. The old MaxVolSize statement is deprecated, as it
784 is SD side only. I am using the same pool for different devices.
786 Notes: State of idea currently unknown. Storage resources in the dir
787 config currently translate to very slim catalog entries; these
788 entries would require extensions to implement what is described
789 here. Quite possibly, numerous other statements that are currently
790 available in Pool resources could be used in Storage resources too
793 Item 27: Start spooling even when waiting on tape
794 Origin: Tobias Barth <tobias.barth@web-arts.com>
798 What: If a job can be spooled to disk before writing it to tape, it should
799 be spooled immediately. Currently, bacula waits until the correct
800 tape is inserted into the drive.
802 Why: It could save hours. When bacula waits on the operator who must insert
803 the correct tape (e.g. a new tape or a tape from another media
804 pool), bacula could already prepare the spooled data in the spooling
805 directory and immediately start despooling when the tape was
806 inserted by the operator.
808 2nd step: Use 2 or more spooling directories. When one directory is
809 currently despooling, the next (on different disk drives) could
810 already be spooling the next data.
812 Notes: I am using bacula 2.2.8, which has none of those features
815 Item 28: Enable persistent naming/number of SQL queries
821 Change the parsing of the query.sql file and the query command so that
822 queries are named/numbered by a fixed value, not their order in the
827 One of the real strengths of bacula is the ability to query the
828 database, and the fact that complex queries can be saved and
829 referenced from a file is very powerful. However, the choice
830 of query (both for interactive use, and by scripting input
831 to the bconsole command) is completely dependent on the order
832 within the query.sql file. The descriptve labels are helpful for
833 interactive use, but users become used to calling a particular
834 query "by number", or may use scripts to execute queries. This
835 presents a problem if the number or order of queries in the file
838 If the query.sql file used the numeric tags as a real value (rather
839 than a comment), then users could have a higher confidence that they
840 are executing the intended query, that their local changes wouldn't
841 conflict with future bacula upgrades.
843 For scripting, it's very important that the intended query is
844 what's actually executed. The current method of parsing the
845 query.sql file discourages scripting because the addition or
846 deletion of queries within the file will require corresponding
847 changes to scripts. It may not be obvious to users that deleting
848 query "17" in the query.sql file will require changing all
849 references to higher numbered queries. Similarly, when new
850 bacula distributions change the number of "official" queries,
851 user-developed queries cannot simply be appended to the file
852 without also changing any references to those queries in scripts
853 or procedural documentation, etc.
855 In addition, using fixed numbers for queries would encourage more
856 user-initiated development of queries, by supporting conventions
859 queries numbered 1-50 are supported/developed/distributed by
860 with official bacula releases
862 queries numbered 100-200 are community contributed, and are
863 related to media management
865 queries numbered 201-300 are community contributed, and are
866 related to checksums, finding duplicated files across
867 different backups, etc.
869 queries numbered 301-400 are community contributed, and are
870 related to backup statistics (average file size, size per
871 client per backup level, time for all clients by backup level,
872 storage capacity by media type, etc.)
874 queries numbered 500-999 are locally created
877 Alternatively, queries could be called by keyword (tag), rather
880 Item 29: Implementation of running Job speed limit.
881 Origin: Alex F, alexxzell at yahoo dot com
882 Date: 29 January 2009
884 What: I noticed the need for an integrated bandwidth limiter for
885 running jobs. It would be very useful just to specify another
886 field in bacula-dir.conf, like speed = how much speed you wish
887 for that specific job to run at
889 Why: Because of a couple of reasons. First, it's very hard to implement a
890 traffic shaping utility and also make it reliable. Second, it is very
891 uncomfortable to have to implement these apps to, let's say 50 clients
892 (including desktops, servers). This would also be unreliable because you
893 have to make sure that the apps are properly working when needed; users
894 could also disable them (accidentally or not). It would be very useful
895 to provide Bacula this ability. All information would be centralized,
896 you would not have to go to 50 different clients in 10 different
897 locations for configuration; eliminating 3rd party additions help in
898 establishing efficiency. Would also avoid bandwidth congestion,
899 especially where there is little available.
901 Item 30: Restore from volumes on multiple storage daemons
902 Origin: Graham Keeling (graham@equiinet.com)
906 What: The ability to restore from volumes held by multiple storage daemons
907 would be very useful.
909 Why: It is useful to be able to backup to any number of different storage
910 daemons. For example, your first storage daemon may run out of space, so you
911 switch to your second and carry on. Bacula will currently let you do this.
912 However, once you come to restore, bacula cannot cope when volumes on different
913 storage daemons are required.
915 Notes: The director knows that more than one storage daemon is needed, as
916 bconsole outputs something like the following table.
918 The job will require the following
919 Volume(s) Storage(s) SD Device(s)
920 ===========================================================================
922 backup-0001 Disk 1 Disk 1.0
923 backup-0002 Disk 2 Disk 2.0
925 However, the bootstrap file that it creates gets sent to the first storage
926 daemon only, which then stalls for a long time, 'waiting for a mount request'
927 for the volume that it doesn't have.
928 The bootstrap file contains no knowledge of the storage daemon.
929 Under the current design:
931 The director connects to the storage daemon, and gets an sd_auth_key.
932 The director then connects to the file daemon, and gives it the
933 sd_auth_key with the 'jobcmd'.
934 (restoring of files happens)
935 The director does a 'wait_for_storage_daemon_termination()'.
936 The director waits for the file daemon to indicate the end of the job.
940 The director connects to the file daemon.
941 Then, for each storage daemon in the .bsr file... {
942 The director connects to the storage daemon, and gets an sd_auth_key.
943 The director then connects to the file daemon, and gives it the
944 sd_auth_key with the 'storaddr' command.
945 (restoring of files happens)
946 The director does a 'wait_for_storage_daemon_termination()'.
947 The director waits for the file daemon to indicate the end of the
948 work on this storage.
950 The director tells the file daemon that there are no more storages to contact.
951 The director waits for the file daemon to indicate the end of the job.
953 As you can see, each restore between the file daemon and storage daemon is
954 handled in the same way that it is currently handled, using the same method
955 for authentication, except that the sd_auth_key is moved from the 'jobcmd' to
956 the 'storaddr' command - where it logically belongs.
959 Item 28:'restore' menu: enter a JobId, automatically select dependents
960 Origin: Graham Keeling (graham@equiinet.com)
965 What: Add to the bconsole 'restore' menu the ability to select a job
966 by JobId, and have bacula automatically select all the dependent jobs.
968 Why: Currently, you either have to...
969 a) laboriously type in a date that is greater than the date of the backup that
970 you want and is less than the subsequent backup (bacula then figures out the
972 b) manually figure out all the JobIds that you want and laboriously type them
974 It would be extremely useful (in a programmatical sense, as well as for humans)
975 to be able to just give it a single JobId and let bacula do the hard work (work
976 that it already knows how to do).
978 Notes (Kern): I think this should either be modified to have Bacula print
979 a list of dates that the user can choose from as is done in bwx-console and
980 bat or the name of this command must be carefully chosen so that the user
981 clearly understands that the JobId is being used to specify what Job and the
982 date to which he wishes the restore to happen.
985 Item 31: Backup and Restore of Windows Encrypted Files using Win raw encryption
986 Origin: Michael Mohr, SAG Mohr.External@infineon.com
987 Date: 22 February 2008
990 What: Make it possible to backup and restore Encypted Files from and to
991 Windows systems without the need to decrypt it by using the raw
992 encryption functions API (see:
993 http://msdn2.microsoft.com/en-us/library/aa363783.aspx)
995 that is provided for that reason by Microsoft.
996 If a file ist encrypted could be examined by evaluating the
997 FILE_ATTRIBUTE_ENCRYTED flag of the GetFileAttributes
1000 Why: Without the usage of this interface the fd-daemon running
1001 under the system account can't read encypted Files because
1002 the key needed for the decrytion is missed by them. As a result
1003 actually encrypted files are not backed up
1004 by bacula and also no error is shown while missing these files.
1008 Item 32: Possibilty to schedule Jobs on last Friday of the month
1009 Origin: Carsten Menke <bootsy52 at gmx dot net>
1013 What: Currently if you want to run your monthly Backups on the last
1014 Friday of each month this is only possible with workarounds (e.g
1015 scripting) (As some months got 4 Fridays and some got 5 Fridays)
1016 The same is true if you plan to run your yearly Backups on the
1017 last Friday of the year. It would be nice to have the ability to
1018 use the builtin scheduler for this.
1020 Why: In many companies the last working day of the week is Friday (or
1021 Saturday), so to get the most data of the month onto the monthly
1022 tape, the employees are advised to insert the tape for the
1023 monthly backups on the last friday of the month.
1025 Notes: To give this a complete functionality it would be nice if the
1026 "first" and "last" Keywords could be implemented in the
1027 scheduler, so it is also possible to run monthy backups at the
1028 first friday of the month and many things more. So if the syntax
1029 would expand to this {first|last} {Month|Week|Day|Mo-Fri} of the
1030 {Year|Month|Week} you would be able to run really flexible jobs.
1032 To got a certain Job run on the last Friday of the Month for example one could
1035 Run = pool=Monthly last Fri of the Month at 23:50
1039 Run = pool=Yearly last Fri of the Year at 23:50
1041 ## Certain Jobs the last Week of a Month
1043 Run = pool=LastWeek last Week of the Month at 23:50
1045 ## Monthly Backup on the last day of the month
1047 Run = pool=Monthly last Day of the Month at 23:50
1049 Item 33: Add Minumum Spool Size directive
1051 Origin: Frank Sweetser <fs@wpi.edu>
1053 What: Add a new SD directive, "minimum spool size" (or similar). This
1054 directive would specify a minimum level of free space available for
1055 spooling. If the unused spool space is less than this level, any
1056 new spooling requests would be blocked as if the "maximum spool
1057 size" threshold had bee reached. Already spooling jobs would be
1058 unaffected by this directive.
1060 Why: I've been bitten by this scenario a couple of times:
1062 Assume a maximum spool size of 100M. Two concurrent jobs, A and B,
1063 are both running. Due to timing quirks and previously running jobs,
1064 job A has used 99.9M of space in the spool directory. While A is
1065 busy despooling to disk, B is happily using the remaining 0.1M of
1066 spool space. This ends up in a spool/despool sequence every 0.1M of
1067 data. In addition to fragmenting the data on the volume far more
1068 than was necessary, in larger data sets (ie, tens or hundreds of
1069 gigabytes) it can easily produce multi-megabyte report emails!
1072 Item 34: Cause daemons to use a specific IP address to source communications
1073 Origin: Bill Moran <wmoran@collaborativefusion.com>
1076 What: Cause Bacula daemons (dir, fd, sd) to always use the ip address
1077 specified in the [DIR|DF|SD]Addr directive as the source IP
1078 for initiating communication.
1079 Why: On complex networks, as well as extremely secure networks, it's
1080 not unusual to have multiple possible routes through the network.
1081 Often, each of these routes is secured by different policies
1082 (effectively, firewalls allow or deny different traffic depending
1083 on the source address)
1084 Unfortunately, it can sometimes be difficult or impossible to
1085 represent this in a system routing table, as the result is
1086 excessive subnetting that quickly exhausts available IP space.
1087 The best available workaround is to provide multiple IPs to
1088 a single machine that are all on the same subnet. In order
1089 for this to work properly, applications must support the ability
1090 to bind outgoing connections to a specified address, otherwise
1091 the operating system will always choose the first IP that
1092 matches the required route.
1093 Notes: Many other programs support this. For example, the following
1094 can be configured in BIND:
1095 query-source address 10.0.0.1;
1096 transfer-source 10.0.0.2;
1097 Which means queries from this server will always come from
1098 10.0.0.1 and zone transfers will always originate from
1103 Item 35: Add ability to Verify any specified Job.
1104 Date: 17 January 2008
1105 Origin: portrix.net Hamburg, Germany.
1106 Contact: Christian Sabelmann
1107 Status: 70% of the required Code is part of the Verify function since v. 2.x
1110 The ability to tell Bacula which Job should verify instead of
1111 automatically verify just the last one.
1114 It is sad that such a powerfull feature like Verify Jobs
1115 (VolumeToCatalog) is restricted to be used only with the last backup Job
1116 of a client. Actual users who have to do daily Backups are forced to
1117 also do daily Verify Jobs in order to take advantage of this useful
1118 feature. This Daily Verify after Backup conduct is not always desired
1119 and Verify Jobs have to be sometimes scheduled. (Not necessarily
1120 scheduled in Bacula). With this feature Admins can verify Jobs once a
1121 Week or less per month, selecting the Jobs they want to verify. This
1122 feature is also not to difficult to implement taking in account older bug
1123 reports about this feature and the selection of the Job to be verified.
1125 Notes: For the verify Job, the user could select the Job to be verified
1126 from a List of the latest Jobs of a client. It would also be possible to
1127 verify a certain volume. All of these would naturaly apply only for
1128 Jobs whose file information are still in the catalog.
1130 Item 36: Automatic disabling of devices
1132 Origin: Peter Eriksson <peter at ifm.liu dot se>
1135 What: After a configurable amount of fatal errors with a tape drive
1136 Bacula should automatically disable further use of a certain
1137 tape drive. There should also be "disable"/"enable" commands in
1138 the "bconsole" tool.
1140 Why: On a multi-drive jukebox there is a possibility of tape drives
1141 going bad during large backups (needing a cleaning tape run,
1142 tapes getting stuck). It would be advantageous if Bacula would
1143 automatically disable further use of a problematic tape drive
1144 after a configurable amount of errors has occurred.
1146 An example: I have a multi-drive jukebox (6 drives, 380+ slots)
1147 where tapes occasionally get stuck inside the drive. Bacula will
1148 notice that the "mtx-changer" command will fail and then fail
1149 any backup jobs trying to use that drive. However, it will still
1150 keep on trying to run new jobs using that drive and fail -
1151 forever, and thus failing lots and lots of jobs... Since we have
1152 many drives Bacula could have just automatically disabled
1153 further use of that drive and used one of the other ones
1156 Item 37: An option to operate on all pools with update vol parameters
1157 Origin: Dmitriy Pinchukov <absh@bossdev.kiev.ua>
1158 Date: 16 August 2006
1159 Status: Patch made by Nigel Stepp
1161 What: When I do update -> Volume parameters -> All Volumes
1162 from Pool, then I have to select pools one by one. I'd like
1163 console to have an option like "0: All Pools" in the list of
1166 Why: I have many pools and therefore unhappy with manually
1167 updating each of them using update -> Volume parameters -> All
1168 Volumes from Pool -> pool #.
1170 Item 38: Implement Storage daemon compression
1171 Date: 18 December 2006
1172 Origin: Vadim A. Umanski , e-mail umanski@ext.ru
1174 What: The ability to compress backup data on the SD receiving data
1175 instead of doing that on client sending data.
1176 Why: The need is practical. I've got some machines that can send
1177 data to the network 4 or 5 times faster than compressing
1178 them (I've measured that). They're using fast enough SCSI/FC
1179 disk subsystems but rather slow CPUs (ex. UltraSPARC II).
1180 And the backup server has got a quite fast CPUs (ex. Dual P4
1181 Xeons) and quite a low load. When you have 20, 50 or 100 GB
1182 of raw data - running a job 4 to 5 times faster - that
1183 really matters. On the other hand, the data can be
1184 compressed 50% or better - so losing twice more space for
1185 disk backup is not good at all. And the network is all mine
1186 (I have a dedicated management/provisioning network) and I
1187 can get as high bandwidth as I need - 100Mbps, 1000Mbps...
1188 That's why the server-side compression feature is needed!
1191 Item 39: Improve Bacula's tape and drive usage and cleaning management
1192 Date: 8 November 2005, November 11, 2005
1193 Origin: Adam Thornton <athornton at sinenomine dot net>,
1194 Arno Lehmann <al at its-lehmann dot de>
1197 What: Make Bacula manage tape life cycle information, tape reuse
1198 times and drive cleaning cycles.
1200 Why: All three parts of this project are important when operating
1202 We need to know which tapes need replacement, and we need to
1203 make sure the drives are cleaned when necessary. While many
1204 tape libraries and even autoloaders can handle all this
1205 automatically, support by Bacula can be helpful for smaller
1206 (older) libraries and single drives. Limiting the number of
1207 times a tape is used might prevent tape errors when using
1208 tapes until the drives can't read it any more. Also, checking
1209 drive status during operation can prevent some failures (as I
1210 [Arno] had to learn the hard way...)
1212 Notes: First, Bacula could (and even does, to some limited extent)
1213 record tape and drive usage. For tapes, the number of mounts,
1214 the amount of data, and the time the tape has actually been
1215 running could be recorded. Data fields for Read and Write
1216 time and Number of mounts already exist in the catalog (I'm
1217 not sure if VolBytes is the sum of all bytes ever written to
1218 that volume by Bacula). This information can be important
1219 when determining which media to replace. The ability to mark
1220 Volumes as "used up" after a given number of write cycles
1221 should also be implemented so that a tape is never actually
1222 worn out. For the tape drives known to Bacula, similar
1223 information is interesting to determine the device status and
1224 expected life time: Time it's been Reading and Writing, number
1225 of tape Loads / Unloads / Errors. This information is not yet
1226 recorded as far as I [Arno] know. A new volume status would
1227 be necessary for the new state, like "Used up" or "Worn out".
1228 Volumes with this state could be used for restores, but not
1229 for writing. These volumes should be migrated first (assuming
1230 migration is implemented) and, once they are no longer needed,
1231 could be moved to a Trash pool.
1233 The next step would be to implement a drive cleaning setup.
1234 Bacula already has knowledge about cleaning tapes. Once it
1235 has some information about cleaning cycles (measured in drive
1236 run time, number of tapes used, or calender days, for example)
1237 it can automatically execute tape cleaning (with an
1238 autochanger, obviously) or ask for operator assistance loading
1241 The final step would be to implement TAPEALERT checks not only
1242 when changing tapes and only sending the information to the
1243 administrator, but rather checking after each tape error,
1244 checking on a regular basis (for example after each tape
1245 file), and also before unloading and after loading a new tape.
1246 Then, depending on the drives TAPEALERT state and the known
1247 drive cleaning state Bacula could automatically schedule later
1248 cleaning, clean immediately, or inform the operator.
1250 Implementing this would perhaps require another catalog change
1251 and perhaps major changes in SD code and the DIR-SD protocol,
1252 so I'd only consider this worth implementing if it would
1253 actually be used or even needed by many people.
1255 Implementation of these projects could happen in three distinct
1256 sub-projects: Measuring Tape and Drive usage, retiring
1257 volumes, and handling drive cleaning and TAPEALERTs.
1259 Item 40: Multiple threads in file daemon for the same job
1260 Date: 27 November 2005
1261 Origin: Ove Risberg (Ove.Risberg at octocode dot com)
1264 What: I want the file daemon to start multiple threads for a backup
1265 job so the fastest possible backup can be made.
1267 The file daemon could parse the FileSet information and start
1268 one thread for each File entry located on a separate
1271 A confiuration option in the job section should be used to
1272 enable or disable this feature. The confgutration option could
1273 specify the maximum number of threads in the file daemon.
1275 If the theads could spool the data to separate spool files
1276 the restore process will not be much slower.
1278 Why: Multiple concurrent backups of a large fileserver with many
1279 disks and controllers will be much faster.
1281 ========= Add new items above this line =================
1284 ============= Empty Feature Request form ===========
1285 Item n: One line summary ...
1286 Date: Date submitted
1287 Origin: Name and email of originator.
1290 What: More detailed explanation ...
1292 Why: Why it is important ...
1294 Notes: Additional notes or features (omit if not used)
1295 ============== End Feature Request form ==============
1298 ========== Items put on hold by Kern ============================
1300 Item h2: Implement support for stacking arbitrary stream filters, sinks.
1301 Date: 23 November 2006
1302 Origin: Landon Fuller <landonf@threerings.net>
1303 Status: Planning. Assigned to landonf.
1305 What: Implement support for the following:
1306 - Stacking arbitrary stream filters (eg, encryption, compression,
1307 sparse data handling))
1308 - Attaching file sinks to terminate stream filters (ie, write out
1309 the resultant data to a file)
1310 - Refactor the restoration state machine accordingly
1312 Why: The existing stream implementation suffers from the following: - All
1313 state (compression, encryption, stream restoration), is
1314 global across the entire restore process, for all streams. There are
1315 multiple entry and exit points in the restoration state machine, and
1316 thus multiple places where state must be allocated, deallocated,
1317 initialized, or reinitialized. This results in exceptional complexity
1318 for the author of a stream filter.
1319 - The developer must enumerate all possible combinations of filters
1320 and stream types (ie, win32 data with encryption, without encryption,
1321 with encryption AND compression, etc).
1323 Notes: This feature request only covers implementing the stream filters/
1324 sinks, and refactoring the file daemon's restoration
1325 implementation accordingly. If I have extra time, I will also
1326 rewrite the backup implementation. My intent in implementing the
1327 restoration first is to solve pressing bugs in the restoration
1328 handling, and to ensure that the new restore implementation
1329 handles existing backups correctly.
1331 I do not plan on changing the network or tape data structures to
1332 support defining arbitrary stream filters, but supporting that
1333 functionality is the ultimate goal.
1335 Assistance with either code or testing would be fantastic.
1337 Notes: Kern: this project has a lot of merit, and we need to do it, but
1338 it is really an issue for developers rather than a new feature
1339 for users, so I have removed it from the voting list, but kept it
1340 here, but at some point, it will be implemented.
1342 Item h3: Filesystem watch triggered backup.
1343 Date: 31 August 2006
1344 Origin: Jesper Krogh <jesper@krogh.cc>
1347 What: With inotify and similar filesystem triggeret notification
1348 systems is it possible to have the file-daemon to monitor
1349 filesystem changes and initiate backup.
1351 Why: There are 2 situations where this is nice to have.
1352 1) It is possible to get a much finer-grained backup than
1353 the fixed schedules used now.. A file created and deleted
1354 a few hours later, can automatically be caught.
1356 2) The introduced load on the system will probably be
1357 distributed more even on the system.
1359 Notes: This can be combined with configration that specifies
1360 something like: "at most every 15 minutes or when changes
1363 Kern Notes: I would rather see this implemented by an external program
1364 that monitors the Filesystem changes, then uses the console
1367 Item h4: Directive/mode to backup only file changes, not entire file
1368 Date: 11 November 2005
1369 Origin: Joshua Kugler <joshua dot kugler at uaf dot edu>
1370 Marek Bajon <mbajon at bimsplus dot com dot pl>
1373 What: Currently when a file changes, the entire file will be backed up in
1374 the next incremental or full backup. To save space on the tapes
1375 it would be nice to have a mode whereby only the changes to the
1376 file would be backed up when it is changed.
1378 Why: This would save lots of space when backing up large files such as
1379 logs, mbox files, Outlook PST files and the like.
1381 Notes: This would require the usage of disk-based volumes as comparing
1382 files would not be feasible using a tape drive.
1384 Notes: Kern: I don't know how to implement this. Put on hold until someone
1385 provides a detailed implementation plan.
1388 Item h5: Implement multiple numeric backup levels as supported by dump
1390 Origin: Daniel Rich <drich@employees.org>
1392 What: Dump allows specification of backup levels numerically instead of just
1393 "full", "incr", and "diff". In this system, at any given level,
1394 all files are backed up that were were modified since the last
1395 backup of a higher level (with 0 being the highest and 9 being the
1396 lowest). A level 0 is therefore equivalent to a full, level 9 an
1397 incremental, and the levels 1 through 8 are varying levels of
1398 differentials. For bacula's sake, these could be represented as
1399 "full", "incr", and "diff1", "diff2", etc.
1401 Why: Support of multiple backup levels would provide for more advanced
1402 backup rotation schemes such as "Towers of Hanoi". This would
1403 allow better flexibility in performing backups, and can lead to
1404 shorter recover times.
1406 Notes: Legato Networker supports a similar system with full, incr, and 1-9 as
1409 Notes: Kern: I don't see the utility of this, and it would be a *huge*
1410 modification to existing code.
1412 Item h6: Implement NDMP protocol support
1417 What: Network Data Management Protocol is implemented by a number of
1418 NAS filer vendors to enable backups using third-party
1421 Why: This would allow NAS filer backups in Bacula without incurring
1422 the overhead of NFS or SBM/CIFS.
1424 Notes: Further information is available:
1426 http://www.ndmp.org/wp/wp.shtml
1427 http://www.traakan.com/ndmjob/index.html
1429 There are currently no viable open-source NDMP
1430 implementations. There is a reference SDK and example
1431 app available from ndmp.org but it has problems
1432 compiling on recent Linux and Solaris OS'. The ndmjob
1433 reference implementation from Traakan is known to
1434 compile on Solaris 10.
1436 Notes: Kern: I am not at all in favor of this until NDMP becomes
1437 an Open Standard or until there are Open Source libraries
1438 that interface to it.
1440 Item h7: Commercial database support
1441 Origin: Russell Howe <russell_howe dot wreckage dot org>
1445 What: It would be nice for the database backend to support more databases.
1446 I'm thinking of SQL Server at the moment, but I guess Oracle, DB2,
1447 MaxDB, etc are all candidates. SQL Server would presumably be
1448 implemented using FreeTDS or maybe an ODBC library?
1450 Why: We only really have one database server, which is MS SQL Server 2000.
1451 Maintaining a second one for the backup software (we grew out of
1452 SQLite, which I liked, but which didn't work so well with our
1453 database size). We don't really have a machine with the resources
1454 to run postgres, and would rather only maintain a single DBMS.
1455 We're stuck with SQL Server because pretty much all the company's
1456 custom applications (written by consultants) are locked into SQL
1457 Server 2000. I can imagine this scenario is fairly common, and it
1458 would be nice to use the existing properly specced database server
1459 for storing Bacula's catalog, rather than having to run a second
1462 Notes: This might be nice, but someone other than me will probably need to
1463 implement it, and at the moment, proprietary code cannot legally
1464 be mixed with Bacula GPLed code. This would be possible only
1465 providing the vendors provide GPLed (or OpenSource) interface
1468 Item h8: Incorporation of XACML2/SAML2 parsing
1469 Date: 19 January 2006
1470 Origin: Adam Thornton <athornton@sinenomine.net>
1473 What: XACML is "eXtensible Access Control Markup Language" and "SAML is
1474 the "Security Assertion Markup Language"--an XML standard for
1475 making statements about identity and authorization. Having these
1476 would give us a framework to approach ACLs in a generic manner,
1477 and in a way flexible enough to support the four major sorts of
1478 ACLs I see as a concern to Bacula at this point, as well as
1479 (probably) to deal with new sorts of ACLs that may appear in the
1482 Why: Bacula is beginning to need to back up systems with ACLs that do not
1483 map cleanly onto traditional Unix permissions. I see four sets of
1484 ACLs--in general, mutually incompatible with one another--that
1485 we're going to need to deal with. These are: NTFS ACLs, POSIX
1486 ACLs, NFSv4 ACLS, and AFS ACLS. (Some may question the relevance
1487 of AFS; AFS is one of Sine Nomine's core consulting businesses,
1488 and having a reputable file-level backup and restore technology
1489 for it (as Tivoli is probably going to drop AFS support soon since
1490 IBM no longer supports AFS) would be of huge benefit to our
1491 customers; we'd most likely create the AFS support at Sine Nomine
1492 for inclusion into the Bacula (and perhaps some changes to the
1493 OpenAFS volserver) core code.)
1495 Now, obviously, Bacula already handles NTFS just fine. However, I
1496 think there's a lot of value in implementing a generic ACL model,
1497 so that it's easy to support whatever particular instances of ACLs
1498 come down the pike: POSIX ACLS (think SELinux) and NFSv4 are the
1499 obvious things arriving in the Linux world in a big way in the
1500 near future. XACML, although overcomplicated for our needs,
1501 provides this framework, and we should be able to leverage other
1502 people's implementations to minimize the amount of work *we* have
1503 to do to get a generic ACL framework. Basically, the costs of
1504 implementation are high, but they're largely both external to
1505 Bacula and already sunk.
1507 Notes: As you indicate this is a bit of "blue sky" or in other words,
1508 at the moment, it is a bit esoteric to consider for Bacula.
1510 Item h9: Archive data
1512 Origin: calvin streeting calvin at absentdream dot com
1515 What: The abilty to archive to media (dvd/cd) in a uncompressed format
1516 for dead filing (archiving not backing up)
1518 Why: At work when jobs are finished and moved off of the main
1519 file servers (raid based systems) onto a simple Linux
1520 file server (ide based system) so users can find old
1521 information without contacting the IT dept.
1523 So this data dosn't realy change it only gets added to,
1524 But it also needs backing up. At the moment it takes
1525 about 8 hours to back up our servers (working data) so
1526 rather than add more time to existing backups i am trying
1527 to implement a system where we backup the acrhive data to
1528 cd/dvd these disks would only need to be appended to
1529 (burn only new/changed files to new disks for off site
1530 storage). basialy understand the differnce between
1531 achive data and live data.
1533 Notes: Scan the data and email me when it needs burning divide
1534 into predefined chunks keep a recored of what is on what
1535 disk make me a label (simple php->mysql=>pdf stuff) i
1536 could do this bit ability to save data uncompresed so
1537 it can be read in any other system (future proof data)
1538 save the catalog with the disk as some kind of menu
1541 Notes: Kern: I don't understand this item, and in any case, if it
1542 is specific to DVD/CDs, which we do not recommend using,
1543 it is unlikely to be implemented except as a user
1547 Item h10: Clustered file-daemons
1548 Origin: Alan Brown ajb2 at mssl dot ucl dot ac dot uk
1551 What: A "virtual" filedaemon, which is actually a cluster of real ones.
1553 Why: In the case of clustered filesystems (SAN setups, GFS, or OCFS2, etc)
1554 multiple machines may have access to the same set of filesystems
1556 For performance reasons, one may wish to initate backups from
1557 several of these machines simultaneously, instead of just using
1558 one backup source for the common clustered filesystem.
1560 For obvious reasons, normally backups of $A-FD/$PATH and
1561 B-FD/$PATH are treated as different backup sets. In this case
1562 they are the same communal set.
1564 Likewise when restoring, it would be easier to just specify
1565 one of the cluster machines and let bacula decide which to use.
1567 This can be faked to some extent using DNS round robin entries
1568 and a virtual IP address, however it means "status client" will
1569 always give bogus answers. Additionally there is no way of
1570 spreading the load evenly among the servers.
1572 What is required is something similar to the storage daemon
1573 autochanger directives, so that Bacula can keep track of
1574 operating backups/restores and direct new jobs to a "free"
1577 Notes: Kern: I don't understand the request enough to be able to
1578 implement it. A lot more design detail should be presented
1579 before voting on this project.
1581 Feature Request Form