+ Notes:
+ Alternatively, queries could be called by keyword (tag), rather
+ than by number.
+
+
+Item 32: Bacula Dir, FD and SD to support proxies
+Origin: Karl Grindley @ MIT Lincoln Laboratory <kgrindley at ll dot mit dot edu>
+Date: 25 March 2009
+Status: proposed
+
+What: Support alternate methods for nailing up a TCP session such
+ as SOCKS5, SOCKS4 and HTTP (CONNECT) proxies. Such a feature
+ would allow tunneling of bacula traffic in and out of proxied
+ networks.
+
+Why: Currently, bacula is architected to only function on a flat network, with
+ no barriers or limitations. Due to the large configuration states of
+ any network and the infinite configuration where file daemons and
+ storage daemons may sit in relation to one another, bacula often is
+ not usable on a network where filtered or air-gaped networks exist.
+ While often solutions such as ACL modifications to firewalls or port
+ redirection via SNAT or DNAT will solve the issue, often however,
+ these solutions are not adequate or not allowed by hard policy.
+
+ In an air-gapped network with only a highly locked down proxy services
+ are provided (SOCKS4/5 and/or HTTP and/or SSH outbound) ACLs or
+ iptable rules will not work.
+
+Notes: Director resource tunneling: This configuration option to utilize a
+ proxy to connect to a client should be specified in the client
+ resource Client resource tunneling: should be configured in the client
+ resource in the director config file? Or configured on the bacula-fd
+ configuration file on the fd host itself? If the ladder, this would
+ allow only certain clients to use a proxy, where others do not when
+ establishing the TCP connection to the storage server.
+
+ Also worth noting, there are other 3rd party, light weight apps that
+ could be utilized to bootstrap this. Instead of sockifing bacula
+ itself, use an external program to broker proxy authentication, and
+ connection to the remote host. OpenSSH does this by using the
+ "ProxyCommand" syntax in the client configuration and uses stdin and
+ stdout to the command. Connect.c is a very popular one.
+ (http://bent.latency.net/bent/darcs/goto-san-connect-1.85/src/connect.html).
+ One could also possibly use stunnel, netcat, etc.
+
+
+Item 33: Add Minumum Spool Size directive
+Date: 20 March 2008
+Origin: Frank Sweetser <fs@wpi.edu>
+
+ What: Add a new SD directive, "minimum spool size" (or similar). This
+ directive would specify a minimum level of free space available for
+ spooling. If the unused spool space is less than this level, any
+ new spooling requests would be blocked as if the "maximum spool
+ size" threshold had bee reached. Already spooling jobs would be
+ unaffected by this directive.
+
+ Why: I've been bitten by this scenario a couple of times:
+
+ Assume a maximum spool size of 100M. Two concurrent jobs, A and B,
+ are both running. Due to timing quirks and previously running jobs,
+ job A has used 99.9M of space in the spool directory. While A is
+ busy despooling to disk, B is happily using the remaining 0.1M of
+ spool space. This ends up in a spool/despool sequence every 0.1M of
+ data. In addition to fragmenting the data on the volume far more
+ than was necessary, in larger data sets (ie, tens or hundreds of
+ gigabytes) it can easily produce multi-megabyte report emails!
+
+
+
+
+
+Item 34: Command that releases all drives in an autochanger
+ Origin: Blake Dunlap (blake@nxs.net)
+ Date: 10/07/2009
+ Status: Request
+
+ What: It would be nice if there was a release command that
+ would release all drives in an autochanger instead of having to
+ do each one in turn.
+
+ Why: It can take some time for a release to occur, and the
+ commands must be given for each drive in turn, which can quicky
+ scale if there are several drives in the library. (Having to
+ watch the console, to give each command can waste a good bit of
+ time when you start getting into the 16 drive range when the
+ tapes can take up to 3 minutes to eject each)
+
+ Notes: Due to the way some autochangers/libraries work, you
+ cannot assume that new tapes inserted will go into slots that are
+ not currently believed to be in use by bacula (the tape from that
+ slot is in a drive). This would make any changes in
+ configuration quicker/easier, as all drives need to be released
+ before any modifications to slots.
+
+Item 35: Run bscan on a remote storage daemon from within bconsole.
+ Date: 07 October 2009
+ Origin: Graham Keeling <graham@equiinet.com>
+ Status: Proposing
+
+ What: The ability to be able to run bscan on a remote storage daemon from
+ within bconsole in order to populate your catalog.
+
+ Why: Currently, it seems you have to:
+ a) log in to a console on the remote machine
+ b) figure out where the storage daemon config file is
+ c) figure out the storage device from the config file
+ d) figure out the catalog IP address
+ e) figure out the catalog port
+ f) open the port on the catalog firewall
+ g) configure the catalog database to accept connections from the
+ remote host
+ h) build a 'bscan' command from (b)-(e) above and run it
+ It would be much nicer to be able to type something like this into
+ bconsole:
+ *bscan storage=<storage> device=<device> volume=<volume>
+ or something like:
+ *bscan storage=<storage> all
+ It seems to me that the scan could also do a better job than the
+ external bscan program currently does. It would possibly be able to
+ deduce some extra details, such as the catalog StorageId for the
+ volumes.
+
+ Notes: (Kern). If you need to do a bscan, you have done something wrong,
+ so this functionality should not need to be integrated into the
+ the Storage daemon. However, I am not opposed to someone implementing
+ this feature providing that all the code is in a shared object (or dll)
+ and does not add significantly to the size of the Storage daemon. In
+ addition, the code should be written in a way such that the same source
+ code is used in both the bscan program and the Storage daemon to avoid
+ adding a lot of new code that must be maintained by the project.
+
+Item 36: Implement a Migration job type that will create a reverse
+ incremental (or decremental) backup from two existing full backups.
+ Date: 05 October 2009
+ Origin: Griffith College Dublin. Some sponsorship available.
+ Contact: Gavin McCullagh <gavin.mccullagh@gcd.ie>
+ Status:
+
+ What: The ability to take two full backup jobs and derive a reverse
+ incremental backup from them. The older full backup data may then
+ be discarded.
+
+ Why: Long-term backups based on keeping full backups can be expensive in
+ media. In many cases (eg a NAS), as the client accumulates files
+ over months and years, the same file will be duplicated unchanged,
+ across many media and datasets. Eg, Less than 10% (and
+ shrinking) of our monthly full mail server backup is new files,
+ the other 90% is also in the previous full backup.
+ Regularly converting the oldest full backup into a reverse
+ incremental backup allows the admin to keep access to old backup
+ jobs, but remove all of the duplicated files, freeing up media.
+
+ Notes: This feature was previously discussed on the bacula-devel list
+ here: http://www.mail-archive.com/bacula-devel@lists.sourceforge.net/msg04962.html
+
+Item 37: Separate "Storage" and "Device" in the bacula-dir.conf
+ Date: 29 April 2009
+ Origin: "James Harper" <james.harper@bendigoit.com.au>
+ Status: not implemented or documented
+
+ What: Separate "Storage" and "Device" in the bacula-dir.conf
+ The resulting config would looks something like:
+
+ Storage {
+ Name = name_of_server
+ Address = hostname/IP address
+ SDPort = 9103
+ Password = shh_its_a_secret
+ Maximum Concurrent Jobs = 7
+ }
+
+ Device {
+ Name = name_of_device
+ Storage = name_of_server
+ Device = name_of_device_on_sd
+ Media Type = media_type
+ Maximum Concurrent Jobs = 1
+ }
+
+ Maximum Concurrent Jobs would be specified with a server and a device
+ maximum, which would both be honoured by the director. Almost everything
+ that mentions a 'Storage' would need to be changed to 'Device', although
+ perhaps a 'Storage' would just be a synonym for 'Device' for backwards
+ compatibility...
+
+ Why: If you have multiple Storage definitions pointing to different
+ Devices in the same Storage daemon, the "status storage" command
+ prompts for each different device, but they all give the same
+ information.
+
+ Notes:
+
+Item 38: Least recently used device selection for tape drives in autochanger.
+Date: 12 October 2009
+Origin: Thomas Carter <tcarter@memc.com>
+Status: Proposal
+
+What: A better tape drive selection algorithm for multi-drive
+ autochangers. The AUTOCHANGER class contains an array list of tape
+ devices. When a tape drive is needed, this list is always searched in
+ order. This causes lower number drives (specifically drive 0) to do a
+ majority of the work with higher numbered drives possibly never being
+ used. When a drive in an autochanger is reserved for use, its entry should
+ be moved to the end of the list; this would give a rough LRU drive
+ selection.
+
+Why: The current implementation places a majority of use and wear on drive
+ 0 of a multi-drive autochanger.
+
+Notes:
+
+Item 39: Implement a Storage device like Amazon's S3.
+ Date: 25 August 2008
+ Origin: Soren Hansen <soren@ubuntu.com>
+ Status: Not started.
+ What: Enable the storage daemon to store backup data on Amazon's
+ S3 service.
+
+ Why: Amazon's S3 is a cheap way to store data off-site.
+
+ Notes: If we configure the Pool to put only one job per volume (they don't
+ support append operation), and the volume size isn't to big (100MB?),
+ it should be easy to adapt the disk-changer script to add get/put
+ procedure with curl. So, the data would be safetly copied during the
+ Job.
+
+ Cloud should be only used with Copy jobs, users should always have
+ a copy of their data on their site.
+
+ We should also think to have our own cache, trying always to have
+ cloud volume on the local disk. (I don't know if users want to store
+ 100GB on cloud, so it shouldn't be a disk size problem). For example,
+ if bacula want to recycle a volume, it will start by downloading the
+ file to truncate it few seconds later, if we can avoid that...
+
+Item 40: Convert tray monitor on Windows to a stand alone program
+ Date: 26 April 2009
+ Origin: Kern/Eric
+ Status:
+
+ What: Separate Win32 tray monitor to be a separate program.
+
+ Why: Vista does not allow SYSTEM services to interact with the
+ desktop, so the current tray monitor does not work on Vista
+ machines.
+
+ Notes: Requires communicating with the FD via the network (simulate
+ a console connection).
+
+Item 41: Improve Bacula's tape and drive usage and cleaning management
+ Date: 8 November 2005, November 11, 2005
+ Origin: Adam Thornton <athornton at sinenomine dot net>,
+ Arno Lehmann <al at its-lehmann dot de>