- What: Implement an interface for Python scripts to access
- the catalog through Bacula.
-
- Why: This will permit users to customize Bacula through
- Python scripts.
-
-Item 20: Archive data
- Date: 15/5/2006
- Origin: calvin streeting calvin at absentdream dot com
- Status:
-
- 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
- Status:
-
- What: Allow Python scripts to be called at more places
- within Bacula and provide additional access to Bacula
- internal variables.