-Item 1: Accurate restoration of renamed/deleted files
-Item 2: Implement a Bacula GUI/management tool.
-Item 3: Implement Base jobs.
-Item 4: Implement from-client and to-client on restore command line.
-Item 5: Implement creation and maintenance of copy pools
-Item 6: Merge multiple backups (Synthetic Backup or Consolidation).
-Item 8: Deletion of Disk-Based Bacula Volumes
-Item 9: Implement a Python interface to the Bacula catalog.
-Item 10: Archival (removal) of User Files to Tape
-Item 11: Add Plug-ins to the FileSet Include statements.
-Item 12: Implement more Python events in Bacula.
-Item 13: Quick release of FD-SD connection after backup.
-Item 14: Implement huge exclude list support using hashing.
-Item 15: Allow skipping execution of Jobs
-Item 16: Tray monitor window cleanups
-Item 17: Split documentation
-Item 18: Automatic promotion of backup levels
-Item 19: Add an override in Schedule for Pools based on backup types.
-Item 20: An option to operate on all pools with update vol parameters
-Item 21: Include JobID in spool file name
-Item 22: Include timestamp of job launch in "stat clients" output
-Item 23: Message mailing based on backup types
-Item 24: Allow inclusion/exclusion of files in a fileset by creation/mod times
-Item 25: Add a scheduling syntax that permits weekly rotations
-Item 26: Improve Bacula's tape and drive usage and cleaning management.
-Item 27: Implement support for stacking arbitrary stream filters, sinks.
-Item 28: Allow FD to initiate a backup
-Item 29: Directive/mode to backup only file changes, not entire file
-Item 30: Automatic disabling of devices
-Item 31: Incorporation of XACML2/SAML2 parsing
-Item 32: Clustered file-daemons
-Item 33: Commercial database support
-Item 34: Archive data
-Item 35: Filesystem watch triggered backup.
-Item 36: Implement multiple numeric backup levels as supported by dump
-Item 37: Implement a server-side compression feature
-Item 38: Cause daemons to use a specific IP address to source communications
-Item 39: Multiple threads in file daemon for the same job
-Item 40: Restore only file attributes (permissions, ACL, owner, group...)
-Item 41: Add an item to the restore option where you can select a pool
-
-Below, you will find more information on future projects:
-
-Item 1: Accurate restoration of renamed/deleted files
- Date: 28 November 2005
- Origin: Martin Simmons (martin at lispworks dot com)
- Status: Robert Nelson will implement this
-
- What: When restoring a fileset for a specified date (including "most
- recent"), Bacula should give you exactly the files and directories
- that existed at the time of the last backup prior to that date.
-
- Currently this only works if the last backup was a Full backup.
- When the last backup was Incremental/Differential, files and
- directories that have been renamed or deleted since the last Full
- backup are not currently restored correctly. Ditto for files with
- extra/fewer hard links than at the time of the last Full backup.
-
- Why: Incremental/Differential would be much more useful if this worked.
-
- Notes: Merging of multiple backups into a single one seems to
- rely on this working, otherwise the merged backups will not be
- truly equivalent to a Full backup.
-
- Kern: notes shortened. This can be done without the need for
- inodes. It is essentially the same as the current Verify job,
- but one additional database record must be written, which does
- not need any database change.
-
- Kern: see if we can correct restoration of directories if
- replace=ifnewer is set. Currently, if the directory does not
- exist, a "dummy" directory is created, then when all the files
- are updated, the dummy directory is newer so the real values
- are not updated.
-
-Item 2: Implement a Bacula GUI/management tool.
- Origin: Kern
- Date: 28 October 2005
- Status:
-
- What: Implement a Bacula console, and management tools
- probably using Qt3 and C++.
-
- Why: Don't we already have a wxWidgets GUI? Yes, but
- it is written in C++ and changes to the user interface
- must be hand tailored using C++ code. By developing
- the user interface using Qt designer, the interface
- can be very easily updated and most of the new Python
- code will be automatically created. The user interface
- changes become very simple, and only the new features
- must be implement. In addition, the code will be in
- Python, which will give many more users easy (or easier)
- access to making additions or modifications.
-
- Notes: There is a partial Python-GTK implementation
- Lucas Di Pentima <lucas at lunix dot com dot ar> but
- it is no longer being developed.
-
-
-Item 3: Implement Base jobs.
- Date: 28 October 2005
- Origin: Kern
- Status:
-
- What: A base job is sort of like a Full save except that you
- will want the FileSet to contain only files that are
- unlikely to change in the future (i.e. a snapshot of
- most of your system after installing it). After the
- base job has been run, when you are doing a Full save,
- you specify one or more Base jobs to be used. All
- files that have been backed up in the Base job/jobs but
- not modified will then be excluded from the backup.
- During a restore, the Base jobs will be automatically
- pulled in where necessary.
-
- Why: This is something none of the competition does, as far as
- we know (except perhaps BackupPC, which is a Perl program that
- saves to disk only). It is big win for the user, it
- makes Bacula stand out as offering a unique
- optimization that immediately saves time and money.
- Basically, imagine that you have 100 nearly identical
- Windows or Linux machine containing the OS and user
- files. Now for the OS part, a Base job will be backed
- up once, and rather than making 100 copies of the OS,
- there will be only one. If one or more of the systems
- have some files updated, no problem, they will be
- automatically restored.
-
- Notes: Huge savings in tape usage even for a single machine.
- Will require more resources because the DIR must send
- FD a list of files/attribs, and the FD must search the
- list and compare it for each file to be saved.
-
-Item 4: 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 5: Implement creation and maintenance of copy pools
- Date: 27 November 2005
- Origin: David Boyes (dboyes at sinenomine dot net)
- Status:
-
- What: I would like Bacula to have the capability to write copies
- of backed-up data on multiple physical volumes selected
- from different pools without transferring the data
- multiple times, and to accept any of the copy volumes
- as valid for restore.
-
- Why: In many cases, businesses are required to keep offsite
- copies of backup volumes, or just wish for simple
- protection against a human operator dropping a storage
- volume and damaging it. The ability to generate multiple
- volumes in the course of a single backup job allows
- customers to simple check out one copy and send it
- offsite, marking it as out of changer or otherwise
- unavailable. Currently, the library and magazine
- management capability in Bacula does not make this process
- simple.
-
- Restores would use the copy of the data on the first
- available volume, in order of copy pool chain definition.
-
- This is also a major scalability issue -- as the number of
- clients increases beyond several thousand, and the volume
- of data increases, transferring the data multiple times to
- produce additional copies of the backups will become
- physically impossible due to transfer speed
- issues. Generating multiple copies at server side will
- become the only practical option.
-
- How: I suspect that this will require adding a multiplexing
- SD that appears to be a SD to a specific FD, but 1-n FDs
- to the specific back end SDs managing the primary and copy
- pools. Storage pools will also need to acquire parameters
- to define the pools to be used for copies.
-
- Notes: I would commit some of my developers' time if we can agree
- on the design and behavior.
-
-Item 6: Merge multiple backups (Synthetic Backup or Consolidation).
- Origin: Marc Cousin and Eric Bollengier
- Date: 15 November 2005
- Status: Waiting implementation. Depends on first implementing
- project Item 2 (Migration) which is now done.
-
- What: A merged backup is a backup made without connecting to the Client.
- It would be a Merge of existing backups into a single backup.
- In effect, it is like a restore but to the backup medium.
-
- For instance, say that last Sunday we made a full backup. Then
- all week long, we created incremental backups, in order to do
- them fast. Now comes Sunday again, and we need another full.
- The merged backup makes it possible to do instead an incremental
- backup (during the night for instance), and then create a merged
- backup during the day, by using the full and incrementals from
- the week. The merged backup will be exactly like a full made
- Sunday night on the tape, but the production interruption on the
- Client will be minimal, as the Client will only have to send
- incrementals.
-
- In fact, if it's done correctly, you could merge all the
- Incrementals into single Incremental, or all the Incrementals
- and the last Differential into a new Differential, or the Full,
- last differential and all the Incrementals into a new Full
- backup. And there is no need to involve the Client.
-
- Why: The benefit is that :
- - the Client just does an incremental ;
- - the merged backup on tape is just as a single full backup,
- and can be restored very fast.
-
- This is also a way of reducing the backup data since the old
- data can then be pruned (or not) from the catalog, possibly
- allowing older volumes to be recycled
-
-Item 8: Deletion of Disk-Based Bacula Volumes
- Date: Nov 25, 2005
- Origin: Ross Boylan <RossBoylan at stanfordalumni dot org> (edited
- by Kern)
- Status:
-
- What: Provide a way for Bacula to automatically remove Volumes
- from the filesystem, or optionally to truncate them.
- Obviously, the Volume must be pruned prior removal.
-
- Why: This would allow users more control over their Volumes and
- prevent disk based volumes from consuming too much space.
-
- Notes: The following two directives might do the trick:
-
- Volume Data Retention = <time period>
- Remove Volume After = <time period>
-
- The migration project should also remove a Volume that is
- migrated. This might also work for tape Volumes.
-
-Item 9: Implement a Python interface to the Bacula catalog.
- Date: 28 October 2005
- Origin: Kern
- Status:
-
- 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 10: Archival (removal) of User Files to Tape
-
- Date: Nov. 24/2005
-
- Origin: Ray Pengelly [ray at biomed dot queensu dot ca
- Status:
-
- What: The ability to archive data to storage based on certain parameters
- such as age, size, or location. Once the data has been written to
- storage and logged it is then pruned from the originating
- filesystem. Note! We are talking about user's files and not
- Bacula Volumes.
-
- Why: This would allow fully automatic storage management which becomes
- useful for large datastores. It would also allow for auto-staging
- from one media type to another.
-
- Example 1) Medical imaging needs to store large amounts of data.
- They decide to keep data on their servers for 6 months and then put
- it away for long term storage. The server then finds all files
- older than 6 months writes them to tape. The files are then removed
- from the server.
-
- Example 2) All data that hasn't been accessed in 2 months could be
- moved from high-cost, fibre-channel disk storage to a low-cost
- large-capacity SATA disk storage pool which doesn't have as quick of
- access time. Then after another 6 months (or possibly as one
- storage pool gets full) data is migrated to Tape.
-
-Item 11: Add Plug-ins to the FileSet Include statements.
- Date: 28 October 2005
- Origin:
- Status: Partially coded in 1.37 -- much more to do.
-
- What: Allow users to specify wild-card and/or regular
- expressions to be matched in both the Include and
- Exclude directives in a FileSet. At the same time,
- allow users to define plug-ins to be called (based on
- regular expression/wild-card matching).
-
- Why: This would give the users the ultimate ability to control
- how files are backed up/restored. A user could write a
- plug-in knows how to backup his Oracle database without
- stopping/starting it, for example.
-
-Item 12: 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.
-
- Why: This will permit users to customize Bacula through
- Python scripts.
-
- Notes: Recycle event
- Scratch pool event
- NeedVolume event
- MediaFull event
-
- Also add a way to get a listing of currently running
- jobs (possibly also scheduled jobs).
-
-
-Item 13: Quick release of FD-SD connection after backup.
- Origin: Frank Volf (frank at deze dot org)
- Date: 17 November 2005
- Status:
-
- What: In the Bacula implementation a backup is finished after all data
- and attributes are successfully written to storage. When using a
- tape backup it is very annoying that a backup can take a day,
- simply because the current tape (or whatever) is full and the
- administrator has not put a new one in. During that time the
- system cannot be taken off-line, because there is still an open
- session between the storage daemon and the file daemon on the
- client.
-
- Although this is a very good strategy for making "safe backups"
- This can be annoying for e.g. laptops, that must remain
- connected until the backup is completed.
-
- Using a new feature called "migration" it will be possible to
- spool first to harddisk (using a special 'spool' migration
- scheme) and then migrate the backup to tape.
-
- There is still the problem of getting the attributes committed.
- If it takes a very long time to do, with the current code, the
- job has not terminated, and the File daemon is not freed up. The
- Storage daemon should release the File daemon as soon as all the
- file data and all the attributes have been sent to it (the SD).
- Currently the SD waits until everything is on tape and all the
- attributes are transmitted to the Director before signaling
- completion to the FD. I don't think I would have any problem
- changing this. The reason is that even if the FD reports back to
- the Dir that all is OK, the job will not terminate until the SD
- has done the same thing -- so in a way keeping the SD-FD link
- open to the very end is not really very productive ...
-
- Why: Makes backup of laptops much faster.
-
-
-
-Item 14: Implement huge exclude list support using hashing.
- Date: 28 October 2005
- Origin: Kern
- Status:
-
- 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 15: Allow skipping execution of Jobs
- Date: 29 November 2005
- Origin: Florian Schnabel <florian.schnabel at docufy dot de>
- Status:
-
- What: An easy option to skip a certain job on a certain date.
- Why: You could then easily skip tape backups on holidays. Especially
- if you got no autochanger and can only fit one backup on a tape
- that would be really handy, other jobs could proceed normally
- and you won't get errors that way.
-
-
-Item 16: Tray monitor window cleanups
- Origin: Alan Brown ajb2 at mssl dot ucl dot ac dot uk
- Date: 24 July 2006
- Status:
- What: Resizeable and scrollable windows in the tray monitor.
-
- Why: With multiple clients, or with many jobs running, the displayed
- window often ends up larger than the available screen, making
- the trailing items difficult to read.
-
-
-Item 17: 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 18: Automatic promotion of backup levels
- Date: 19 January 2006
- Origin: Adam Thornton <athornton@sinenomine.net>
- Status:
-
- What: Amanda has a feature whereby it estimates the space that a
- differential, incremental, and full backup would take. If the
- difference in space required between the scheduled level and the next
- level up is beneath some user-defined critical threshold, the backup
- level is bumped to the next type. Doing this minimizes the number of
- volumes necessary during a restore, with a fairly minimal cost in
- backup media space.
-
- Why: I know at least one (quite sophisticated and smart) user
- for whom the absence of this feature is a deal-breaker in terms of
- using Bacula; if we had it it would eliminate the one cool thing
- Amanda can do and we can't (at least, the one cool thing I know of).
-
-
-Item 19: 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 20: An option to operate on all pools with update vol parameters
- Origin: Dmitriy Pinchukov <absh@bossdev.kiev.ua>
- Date: 16 August 2006
- Status:
-
- What: When I do update -> Volume parameters -> All Volumes
- from Pool, then I have to select pools one by one. I'd like
- console to have an option like "0: All Pools" in the list of
- defined pools.
-
- Why: I have many pools and therefore unhappy with manually
- updating each of them using update -> Volume parameters -> All
- Volumes from Pool -> pool #.
-
-
-
-Item 21: Include JobID in spool file name
- Origin: Mark Bergman <mark.bergman@uphs.upenn.edu>
- Date: Tue Aug 22 17:13:39 EDT 2006
- Status: Ok (patches/testing/project-include-jobid-in-spool-name.patch)
-
- What: Change the name of the spool file to include the JobID
-
- Why: JobIDs are the common key used to refer to jobs, yet the
- spoolfile name doesn't include that information. The date/time
- stamp is useful (and should be retained).
-
-
-
-Item 22: Include timestamp of job launch in "stat clients" output
- Origin: Mark Bergman <mark.bergman@uphs.upenn.edu>
- Date: Tue Aug 22 17:13:39 EDT 2006
- Status:
-
- What: The "stat clients" command doesn't include any detail on when
- the active backup jobs were launched.
-
- Why: Including the timestamp would make it much easier to decide whether
- a job is running properly.
-
- Notes: It may be helpful to have the output from "stat clients" formatted
- more like that from "stat dir" (and other commands), in a column
- format. The per-client information that's currently shown (level,
- client name, JobId, Volume, pool, device, Files, etc.) is good, but
- somewhat hard to parse (both programmatically and visually),
- particularly when there are many active clients.
-
-
-
-Item 23: Message mailing based on backup types
- Origin: Evan Kaufman <evan.kaufman@gmail.com>
- Date: January 6, 2006
- Status:
-
- What: In the "Messages" resource definitions, allowing messages
- to be mailed based on the type (backup, restore, etc.) and level
- (full, differential, etc) of job that created the originating
- message(s).
-
- Why: It would, for example, allow someone's boss to be emailed
- automatically only when a Full Backup job runs, so he can
- retrieve the tapes for offsite storage, even if the IT dept.
- doesn't (or can't) explicitly notify him. At the same time, his
- mailbox wouldnt be filled by notifications of Verifies, Restores,
- or Incremental/Differential Backups (which would likely be kept
- onsite).
-
- Notes: One way this could be done is through additional message types, for example:
-
- Messages {
- # email the boss only on full system backups
- Mail = boss@mycompany.com = full, !incremental, !differential, !restore,
- !verify, !admin
- # email us only when something breaks
- MailOnError = itdept@mycompany.com = all
- }
-
-
-Item 24: Allow inclusion/exclusion of files in a fileset by creation/mod times
- Origin: Evan Kaufman <evan.kaufman@gmail.com>
- Date: January 11, 2006