+Item 30: 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 31: Implement multiple numeric backup levels as supported by dump
+Date: 3 April 2006
+Origin: Daniel Rich <drich@employees.org>
+Status:
+What: Dump allows specification of backup levels numerically instead of just
+ "full", "incr", and "diff". In this system, at any given level, all
+ files are backed up that were were modified since the last backup of a
+ higher level (with 0 being the highest and 9 being the lowest). A
+ level 0 is therefore equivalent to a full, level 9 an incremental, and
+ the levels 1 through 8 are varying levels of differentials. For
+ bacula's sake, these could be represented as "full", "incr", and
+ "diff1", "diff2", etc.
+
+Why: Support of multiple backup levels would provide for more advanced backup
+ rotation schemes such as "Towers of Hanoi". This would allow better
+ flexibility in performing backups, and can lead to shorter recover
+ times.
+
+Notes: Legato Networker supports a similar system with full, incr, and 1-9 as
+ levels.
+
+Item 32: 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 33: Clustered file-daemons
+ Origin: Alan Brown ajb2 at mssl dot ucl dot ac dot uk
+ Date: 24 July 2006
+ Status:
+ What: A "virtual" filedaemon, which is actually a cluster of real ones.
+
+ Why: In the case of clustered filesystems (SAN setups, GFS, or OCFS2, etc)
+ multiple machines may have access to the same set of filesystems
+
+ For performance reasons, one may wish to initate backups from
+ several of these machines simultaneously, instead of just using
+ one backup source for the common clustered filesystem.
+
+ For obvious reasons, normally backups of $A-FD/$PATH and
+ B-FD/$PATH are treated as different backup sets. In this case
+ they are the same communal set.
+
+ Likewise when restoring, it would be easier to just specify
+ one of the cluster machines and let bacula decide which to use.
+
+ This can be faked to some extent using DNS round robin entries
+ and a virtual IP address, however it means "status client" will
+ always give bogus answers. Additionally there is no way of
+ spreading the load evenly among the servers.
+
+ What is required is something similar to the storage daemon
+ autochanger directives, so that Bacula can keep track of
+ operating backups/restores and direct new jobs to a "free"
+ client.
+
+ Notes:
+
+Item 34: Commercial database support
+ Origin: Russell Howe <russell_howe dot wreckage dot org>
+ Date: 26 July 2006
+ Status:
+
+ What: It would be nice for the database backend to support more
+ databases. I'm thinking of SQL Server at the moment, but I guess Oracle,
+ DB2, MaxDB, etc are all candidates. SQL Server would presumably be
+ implemented using FreeTDS or maybe an ODBC library?
+
+ Why: We only really have one database server, which is MS SQL Server
+ 2000. Maintaining a second one for the backup software (we grew out of
+ SQLite, which I liked, but which didn't work so well with our database
+ size). We don't really have a machine with the resources to run
+ postgres, and would rather only maintain a single DBMS. We're stuck with
+ SQL Server because pretty much all the company's custom applications
+ (written by consultants) are locked into SQL Server 2000. I can imagine
+ this scenario is fairly common, and it would be nice to use the existing
+ properly specced database server for storing Bacula's catalog, rather
+ than having to run a second DBMS.
+
+Item 35: Automatic disabling of devices
+ Date: 2005-11-11
+ Origin: Peter Eriksson <peter at ifm.liu dot se>
+ Status:
+
+ What: After a configurable amount of fatal errors with a tape drive
+ Bacula should automatically disable further use of a certain
+ tape drive. There should also be "disable"/"enable" commands in
+ the "bconsole" tool.
+
+ Why: On a multi-drive jukebox there is a possibility of tape drives
+ going bad during large backups (needing a cleaning tape run,
+ tapes getting stuck). It would be advantageous if Bacula would
+ automatically disable further use of a problematic tape drive
+ after a configurable amount of errors has occurred.
+
+ An example: I have a multi-drive jukebox (6 drives, 380+ slots)
+ where tapes occasionally get stuck inside the drive. Bacula will
+ notice that the "mtx-changer" command will fail and then fail
+ any backup jobs trying to use that drive. However, it will still
+ keep on trying to run new jobs using that drive and fail -
+ forever, and thus failing lots and lots of jobs... Since we have
+ many drives Bacula could have just automatically disabled
+ further use of that drive and used one of the other ones
+ instead.
+
+Item 36: 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 37: Add an item to the restore option where you can select a pool
+ Origin: kshatriyak at gmail dot com
+ Date: 1/1/2006
+ Status:
+
+ What: In the restore option (Select the most recent backup for a
+ client) it would be useful to add an option where you can limit
+ the selection to a certain pool.
+
+ Why: When using cloned jobs, most of the time you have 2 pools - a
+ disk pool and a tape pool. People who have 2 pools would like to
+ select the most recent backup from disk, not from tape (tape
+ would be only needed in emergency). However, the most recent
+ backup (which may just differ a second from the disk backup) may
+ be on tape and would be selected. The problem becomes bigger if
+ you have a full and differential - the most "recent" full backup
+ may be on disk, while the most recent differential may be on tape
+ (though the differential on disk may differ even only a second or
+ so). Bacula will complain that the backups reside on different
+ media then. For now the only solution now when restoring things
+ when you have 2 pools is to manually search for the right
+ job-id's and enter them by hand, which is a bit fault tolerant.
+
+Item 38: 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 39: 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 40: Include JobID in spool file name ****DONE****
+ Origin: Mark Bergman <mark.bergman@uphs.upenn.edu>
+ Date: Tue Aug 22 17:13:39 EDT 2006
+ Status: Done. (patches/testing/project-include-jobid-in-spool-name.patch)
+ No need to vote for this item.
+
+ 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).
+
+============= New Freature Requests after vote of 26 Jan 2007 ========
+Item 41: Enable to relocate files and directories when restoring
+ Date: 2007-03-01
+ Origin: Eric Bollengier <eric@eb.homelinux.org>
+ Status: Done.
+
+ What: The where= option is not powerful enough. It will be
+ a great feature if bacula can restore a file in the
+ same directory, but with a different name, or in
+ an other directory without recreating the full path.
+
+ Why: When i want to restore a production environment to a
+ development environment, i just want change the first
+ directory. ie restore /prod/data/file.dat to /rect/data/file.dat.
+ At this time, i have to move by hand files. You must have a big
+ dump space to restore and move data after.
+
+ When i use Linux or SAN snapshot, i mount them to /mnt/snap_xxx
+ so, when a restore a file, i have to move by hand
+ from /mnt/snap_xxx/file to /xxx/file. I can't replace a file
+ easily.
+
+ When a user ask me to restore a file in its personal folder,
+ (without replace the existing one), i can't restore from
+ my_file.txt to my_file.txt.old witch is very practical.
+
+
+ Notes: I think we can enhance the where= option very easily by
+ allowing regexp expression.
+
+ Since, many users think that regexp are not user friendly, i think
+ that bat, bconsole or brestore must provide a simple way to
+ configure where= option (i think to something like in
+ openoffice "search and replace").
+
+ Ie, if user uses where=/tmp/bacula-restore, we keep the old
+ fashion.
+
+ If user uses something like where=s!/prod!/test!, files will
+ be restored from /prod/xxx to /test/xxx.
+
+ If user uses something like where=s/$/.old/, files will
+ be restored from /prod/xxx.txt to /prod/xxx.txt.old.
+
+ If user uses something like where=s/txt$/old.txt/, files will
+ be restored from /prod/xxx.txt to /prod/xxx.old.txt
+
+ if user uses something like where=s/([a-z]+)$/old.$1/, files will
+ be restored from /prod/xxx.ext to /prod/xxx.old.ext
+
+Item n: Implement Catalog directive for Pool resource in Director
+configuration
+ Origin: Alan Davis adavis@ruckus.com
+ Date: 6 March 2007
+ Status: Submitted