Projects: Bacula Projects Roadmap Status updated 14 Jun 2009 Summary: * => item complete Item 1: Ability to restart failed jobs *Item 2: 'restore' menu: enter a JobId, automatically select dependents Item 3: Scheduling syntax that permits more flexibility and options Item 4: Data encryption on storage daemon Item 5: Deletion of disk Volumes when pruned Item 6: Implement Base jobs Item 7: Add ability to Verify any specified Job. Item 8: Improve Bacula's tape and drive usage and cleaning management Item 9: Allow FD to initiate a backup *Item 10: Restore from volumes on multiple storage daemons Item 11: Implement Storage daemon compression Item 12: Reduction of communications bandwidth for a backup Item 13: Ability to reconnect a disconnected comm line Item 14: Start spooling even when waiting on tape Item 15: Enable/disable compression depending on storage device (disk/tape) Item 16: Include all conf files in specified directory Item 17: Multiple threads in file daemon for the same job Item 18: Possibilty to schedule Jobs on last Friday of the month Item 19: Include timestamp of job launch in "stat clients" output *Item 20: Cause daemons to use a specific IP address to source communications Item 21: Message mailing based on backup types Item 22: Ability to import/export Bacula database entities *Item 23: "Maximum Concurrent Jobs" for drives when used with changer device Item 24: Implementation of running Job speed limit. Item 25: Add an override in Schedule for Pools based on backup types Item 26: Automatic promotion of backup levels based on backup size Item 27: Allow inclusion/exclusion of files in a fileset by creation/mod times Item 28: Archival (removal) of User Files to Tape Item 29: An option to operate on all pools with update vol parameters Item 30: Automatic disabling of devices *Item 31: List InChanger flag when doing restore. Item 32: Ability to defer Batch Insert to a later time Item 33: Add MaxVolumeSize/MaxVolumeBytes statement to Storage resource Item 34: Enable persistent naming/number of SQL queries Item 35: Port bat to Win32 Item 36: Bacula Dir, FD and SD to support proxies Item 37: Add Minumum Spool Size directive Item 38: Backup and Restore of Windows Encrypted Files using Win raw encryption Item 39: Implement an interface between Bacula and Amazon's S3. Item 40: Convert Bacula existing tray monitor on Windows to a stand alone program Item 1: Ability to restart failed jobs Date: 26 April 2009 Origin: Kern/Eric Status: What: Often jobs fail because of a communications line drop or max run time, cancel, or some other non-critical problem. Currrently any data saved is lost. This implementation should modify the Storage daemon so that it saves all the files that it knows are completely backed up to the Volume The jobs should then be marked as incomplete and a subsequent Incremental Accurate backup will then take into account all the previously saved job. Why: Avoids backuping data already saved. Notes: Requires Accurate to restart correctly. Must completed have a minimum volume of data or files stored on Volume before enabling. Item 2: 'restore' menu: enter a JobId, automatically select dependents Origin: Graham Keeling (graham@equiinet.com) Date: 13 March 2009 Status: Done in 3.0.2 What: Add to the bconsole 'restore' menu the ability to select a job by JobId, and have bacula automatically select all the dependent jobs. Why: Currently, you either have to... a) laboriously type in a date that is greater than the date of the backup that you want and is less than the subsequent backup (bacula then figures out the dependent jobs), or b) manually figure out all the JobIds that you want and laboriously type them all in. It would be extremely useful (in a programmatical sense, as well as for humans) to be able to just give it a single JobId and let bacula do the hard work (work that it already knows how to do). Notes (Kern): I think this should either be modified to have Bacula print a list of dates that the user can choose from as is done in bwx-console and bat or the name of this command must be carefully chosen so that the user clearly understands that the JobId is being used to specify what Job and the date to which he wishes the restore to happen. Item 3: Scheduling syntax that permits more flexibility and options Date: 15 December 2006 Origin: Gregory Brauer (greg at wildbrain dot com) and Florian Schnabel Status: What: Currently, Bacula only understands how to deal with weeks of the month or weeks of the year in schedules. This makes it impossible to do a true weekly rotation of tapes. There will always be a discontinuity that will require disruptive manual intervention at least monthly or yearly because week boundaries never align with month or year boundaries. A solution would be to add a new syntax that defines (at least) a start timestamp, and repetition period. An easy option to skip a certain job on a certain date. Why: Rotated backups done at weekly intervals are useful, and Bacula cannot currently do them without extensive hacking. 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. Notes: Here is an example syntax showing a 3-week rotation where full Backups would be performed every week on Saturday, and an incremental would be performed every week on Tuesday. Each set of tapes could be removed from the loader for the following two cycles before coming back and being reused on the third week. Since the execution times are determined by intervals from a given point in time, there will never be any issues with having to adjust to any sort of arbitrary time boundary. In the example provided, I even define the starting schedule as crossing both a year and a month boundary, but the run times would be based on the "Repeat" value and would therefore happen weekly as desired. Schedule { Name = "Week 1 Rotation" #Saturday. Would run Dec 30, Jan 20, Feb 10, etc. Run { Options { Type = Full Start = 2006-12-30 01:00 Repeat = 3w } } #Tuesday. Would run Jan 2, Jan 23, Feb 13, etc. Run { Options { Type = Incremental Start = 2007-01-02 01:00 Repeat = 3w } } } Schedule { Name = "Week 2 Rotation" #Saturday. Would run Jan 6, Jan 27, Feb 17, etc. Run { Options { Type = Full Start = 2007-01-06 01:00 Repeat = 3w } } #Tuesday. Would run Jan 9, Jan 30, Feb 20, etc. Run { Options { Type = Incremental Start = 2007-01-09 01:00 Repeat = 3w } } } Schedule { Name = "Week 3 Rotation" #Saturday. Would run Jan 13, Feb 3, Feb 24, etc. Run { Options { Type = Full Start = 2007-01-13 01:00 Repeat = 3w } } #Tuesday. Would run Jan 16, Feb 6, Feb 27, etc. Run { Options { Type = Incremental Start = 2007-01-16 01:00 Repeat = 3w } } } Notes: Kern: I have merged the previously separate project of skipping jobs (via Schedule syntax) into this. Item 4: Data encryption on storage daemon Origin: Tobias Barth Date: 04 February 2009 Status: new What: The storage demon should be able to do the data encryption that can currently be done by the file daemon. Why: This would have 2 advantages: 1) one could encrypt the data of unencrypted tapes by doing a migration job 2) the storage daemon would be the only machine that would have to keep the encryption keys. Notes from Landon: As an addendum to the feature request, here are some crypto implementation details I wrote up regarding SD-encryption back in Jan 2008: http://www.mail-archive.com/bacula-users@lists.sourceforge.net/msg28860.html Item 5: Deletion of disk Volumes when pruned Date: Nov 25, 2005 Origin: Ross Boylan (edited by Kern) Status: Truncate operation implemented in 3.1.4 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 =