+ What: The abilty to archive to media (dvd/cd) in a uncompressed format
+ for dead filing (archiving not backing up)
+
+ Why: At my works when jobs are finished and moved off of the main file
+ servers (raid based systems) onto a simple linux file server (ide based
+ system) so users can find old information without contacting the IT
+ dept.
+
+ So this data dosn't realy change it only gets added to,
+ But it also needs backing up. At the moment it takes
+ about 8 hours to back up our servers (working data) so
+ rather than add more time to existing backups i am trying
+ to implement a system where we backup the acrhive data to
+ cd/dvd these disks would only need to be appended to
+ (burn only new/changed files to new disks for off site
+ storage). basialy understand the differnce between
+ achive data and live data.
+
+ Notes: Scan the data and email me when it needs burning divide
+ into predifind chunks keep a recored of what is on what
+ disk make me a label (simple php->mysql=>pdf stuff) i
+ could do this bit ability to save data uncompresed so
+ it can be read in any other system (future proof data)
+ save the catalog with the disk as some kind of menu
+ system
+
+Item 21: Split documentation
+ Origin: Maxx <maxxatworkat gmail dot com>
+ Date: 27th July 2006
+ Status:
+
+ What: Split documentation in several books
+
+ Why: Bacula manual has now more than 600 pages, and looking for
+ implementation details is getting complicated. I think
+ it would be good to split the single volume in two or
+ maybe three parts:
+
+ 1) Introduction, requirements and tutorial, typically
+ are useful only until first installation time
+
+ 2) Basic installation and configuration, with all the
+ gory details about the directives supported 3)
+ Advanced Bacula: testing, troubleshooting, GUI and
+ ancillary programs, security managements, scripting,
+ etc.
+
+
+Item 22: Implement support for stacking arbitrary stream filters, sinks.
+Date: 23 November 2006
+Origin: Landon Fuller <landonf@threerings.net>
+Status: Planning. Assigned to landonf.
+
+ What: Implement support for the following:
+ - Stacking arbitrary stream filters (eg, encryption, compression,
+ sparse data handling))
+ - Attaching file sinks to terminate stream filters (ie, write out
+ the resultant data to a file)
+ - Refactor the restoration state machine accordingly
+
+ Why: The existing stream implementation suffers from the following:
+ - All state (compression, encryption, stream restoration), is
+ global across the entire restore process, for all streams. There are
+ multiple entry and exit points in the restoration state machine, and
+ thus multiple places where state must be allocated, deallocated,
+ initialized, or reinitialized. This results in exceptional complexity
+ for the author of a stream filter.
+ - The developer must enumerate all possible combinations of filters
+ and stream types (ie, win32 data with encryption, without encryption,
+ with encryption AND compression, etc).
+
+ Notes: This feature request only covers implementing the stream filters/
+ sinks, and refactoring the file daemon's restoration implementation
+ accordingly. If I have extra time, I will also rewrite the backup
+ implementation. My intent in implementing the restoration first is to
+ solve pressing bugs in the restoration handling, and to ensure that
+ the new restore implementation handles existing backups correctly.
+
+ I do not plan on changing the network or tape data structures to
+ support defining arbitrary stream filters, but supporting that
+ functionality is the ultimate goal.
+
+ Assistance with either code or testing would be fantastic.
+
+Item 23: Implement from-client and to-client on restore command line.
+ Date: 11 December 2006
+ Origin: Discussion on Bacula-users entitled 'Scripted restores to
+ different clients', December 2006
+ Status: New feature request
+
+ What: While using bconsole interactively, you can specify the client
+ that a backup job is to be restored for, and then you can
+ specify later a different client to send the restored files
+ back to. However, using the 'restore' command with all options
+ on the command line, this cannot be done, due to the ambiguous
+ 'client' parameter. Additionally, this parameter means different
+ things depending on if it's specified on the command line or
+ afterwards, in the Modify Job screens.
+
+ Why: This feature would enable restore jobs to be more completely
+ automated, for example by a web or GUI front-end.
+
+ Notes: client can also be implied by specifying the jobid on the command
+ line
+
+Item 24: Add an override in Schedule for Pools based on backup types.
+Date: 19 Jan 2005
+Origin: Chad Slater <chad.slater@clickfox.com>
+Status:
+
+ What: Adding a FullStorage=BigTapeLibrary in the Schedule resource
+ would help those of us who use different storage devices for different
+ backup levels cope with the "auto-upgrade" of a backup.
+
+ Why: Assume I add several new device to be backed up, i.e. several
+ hosts with 1TB RAID. To avoid tape switching hassles, incrementals are
+ stored in a disk set on a 2TB RAID. If you add these devices in the
+ middle of the month, the incrementals are upgraded to "full" backups,
+ but they try to use the same storage device as requested in the
+ incremental job, filling up the RAID holding the differentials. If we
+ could override the Storage parameter for full and/or differential
+ backups, then the Full job would use the proper Storage device, which
+ has more capacity (i.e. a 8TB tape library.
+
+Item 25: Implement huge exclude list support using hashing (dlists).
+ Date: 28 October 2005
+ Origin: Kern
+ Status: Done in 2.1.2 but was done with dlists (doubly linked lists
+ since hashing will not help. The huge list also supports
+ large include lists).
+
+ What: Allow users to specify very large exclude list (currently
+ more than about 1000 files is too many).
+
+ Why: This would give the users the ability to exclude all
+ files that are loaded with the OS (e.g. using rpms
+ or debs). If the user can restore the base OS from
+ CDs, there is no need to backup all those files. A
+ complete restore would be to restore the base OS, then
+ do a Bacula restore. By excluding the base OS files, the
+ backup set will be *much* smaller.
+
+Item 26: Implement more Python events in Bacula.
+ Date: 28 October 2005
+ Origin: Kern