Projects:
Bacula Projects Roadmap
- Status updated 15 December 2006
-
+ Status updated 12 January 2007
Summary:
-Item 1: Accurate restoration of renamed/deleted files from
+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 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 7: Deletion of Disk-Based Bacula Volumes
+Item 8: Implement a Python interface to the Bacula catalog.
+Item 9: Archival (removal) of User Files to Tape
+Item 10: Add Plug-ins to the FileSet Include statements.
+Item 11: Implement more Python events in Bacula.
+Item 12: Quick release of FD-SD connection after backup.
+Item 13: Implement huge exclude list support using hashing.
+Item 14: Allow skipping execution of Jobs
+Item 15: Tray monitor window cleanups
+Item 16: Split documentation
+Item 17: Automatic promotion of backup levels
+Item 18: Add an override in Schedule for Pools based on backup types.
+Item 10: An option to operate on all pools with update vol parameters
+Item 20: Include JobID in spool file name
+Item 21: Include timestamp of job launch in "stat clients" output
+Item 22: Message mailing based on backup types
+Item 23: Allow inclusion/exclusion of files in a fileset by creation/mod times
+Item 24: Add a scheduling syntax that permits weekly rotations
+Item 25: Improve Bacula's tape and drive usage and cleaning management.
+Item 26: Implement support for stacking arbitrary stream filters, sinks.
+Item 27: Allow FD to initiate a backup
+Item 28: Directive/mode to backup only file changes, not entire file
+Item 29: Automatic disabling of devices
+Item 30: Incorporation of XACML2/SAML2 parsing
+Item 31: Clustered file-daemons
+Item 32: Commercial database support
+Item 33: Archive data
+Item 34: Filesystem watch triggered backup.
+Item 35: Implement multiple numeric backup levels as supported by dump
+Item 36: Implement a server-side compression feature
+Item 37: Cause daemons to use a specific IP address to source communications
+Item 38: Multiple threads in file daemon for the same job
+Item 39: Restore only file attributes (permissions, ACL, owner, group...)
+Item 40: 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 from
- Incremental/Differential backups
+Item 1: Accurate restoration of renamed/deleted files
Date: 28 November 2005
Origin: Martin Simmons (martin at lispworks dot com)
- Status:
+ 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
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
+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.
+ 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.
+ 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
+ line
Item 5: Implement creation and maintenance of copy pools
Date: 27 November 2005
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
+Item 7: Deletion of Disk-Based Bacula Volumes
Date: Nov 25, 2005
Origin: Ross Boylan <RossBoylan at stanfordalumni dot org> (edited
by Kern)
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.
+Item 8: Implement a Python interface to the Bacula catalog.
Date: 28 October 2005
Origin: Kern
Status:
Why: This will permit users to customize Bacula through
Python scripts.
-Item 10: Archival (removal) of User Files to Tape
+Item 9: Archival (removal) of User Files to Tape
Date: Nov. 24/2005
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.
+Item 10: Add Plug-ins to the FileSet Include statements.
Date: 28 October 2005
Origin:
Status: Partially coded in 1.37 -- much more to do.
plug-in knows how to backup his Oracle database without
stopping/starting it, for example.
-Item 12: Implement more Python events in Bacula.
+Item 11: Implement more Python events in Bacula.
Date: 28 October 2005
Origin: Kern
Status:
jobs (possibly also scheduled jobs).
-Item 13: Quick release of FD-SD connection after backup.
+Item 12: Quick release of FD-SD connection after backup.
Origin: Frank Volf (frank at deze dot org)
Date: 17 November 2005
Status:
-Item 14: Implement huge exclude list support using hashing.
+Item 13: Implement huge exclude list support using hashing.
Date: 28 October 2005
Origin: Kern
Status:
backup set will be *much* smaller.
-Item 15: Allow skipping execution of Jobs
+Item 14: 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.
+ 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
+Item 15: Tray monitor window cleanups
Origin: Alan Brown ajb2 at mssl dot ucl dot ac dot uk
Date: 24 July 2006
Status:
the trailing items difficult to read.
-Item 17: Split documentation
+Item 16: Split documentation
Origin: Maxx <maxxatworkat gmail dot com>
Date: 27th July 2006
Status:
-Item 18: Automatic promotion of backup levels
- Date: 19 January 2006
-
Origin: Adam Thornton <athornton@sinenomine.net>
- Status: Blue sky
+Item 17: 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.
+ 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).
+ 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.
+Item 18: Add an override in Schedule for Pools based on backup types.
Date: 19 Jan 2005
Origin: Chad Slater <chad.slater@clickfox.com>
Status:
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:
+Item 19: 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
-Item 21: Include JobID in spool file name
+Item 20: 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:
+ 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
-Item 22: Include timestamp of job launch in "stat clients" output
+Item 21: 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:
-Item 23: Message mailing based on backup types
-Origin: Evan Kaufman <evan.kaufman@gmail.com>
- Date: January 6, 2006
-Status:
+Item 22: 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).
+ 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).
+ 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:
+ Notes: One way this could be done is through additional message types, for example:
Messages {
# email the boss only on full system backups
}
-Item 24: Allow inclusion/exclusion of files in a fileset by creation/mod times
+Item 23: Allow inclusion/exclusion of files in a fileset by creation/mod times
Origin: Evan Kaufman <evan.kaufman@gmail.com>
Date: January 11, 2006
Status:
or 'since'.
-Item 25: Add a scheduling syntax that permits weekly rotations
+Item 24: Add a scheduling syntax that permits weekly rotations
Date: 15 December 2006
Origin: Gregory Brauer (greg at wildbrain dot com)
Status:
}
-Item 26: Improve Bacula's tape and drive usage and cleaning management.
+Item 25: 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>
sub-projects: Measuring Tape and Drive usage, retiring
volumes, and handling drive cleaning and TAPEALERTs.
-Item 27: Implement support for stacking arbitrary stream filters, sinks.
+Item 26: 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 28: Allow FD to initiate a backup
+ 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 27: Allow FD to initiate a backup
Origin: Frank Volf (frank at deze dot org)
Date: 17 November 2005
Status:
Why: Makes backup of laptops much easier.
-Item 29: Directive/mode to backup only file changes, not entire file
+Item 28: Directive/mode to backup only file changes, not entire file
Date: 11 November 2005
Origin: Joshua Kugler <joshua dot kugler at uaf dot edu>
Marek Bajon <mbajon at bimsplus dot com dot pl>
Notes: This would require the usage of disk-based volumes as comparing
files would not be feasible using a tape drive.
-Item 30: Automatic disabling of devices
- Date: 2005-11-11
-
Origin: Peter Eriksson <peter at ifm.liu dot se>
- Status:
+Item 29: 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
further use of that drive and used one of the other ones
instead.
-Item 31: Incorporation of XACML2/SAML2 parsing
+Item 30: Incorporation of XACML2/SAML2 parsing
Date: 19 January 2006
Origin: Adam Thornton <athornton@sinenomine.net>
Status: Blue sky
high, but they're largely both external to Bacula and already sunk.
-Item 32: Clustered file-daemons
+Item 31: Clustered file-daemons
Origin: Alan Brown ajb2 at mssl dot ucl dot ac dot uk
Date: 24 July 2006
Status:
Notes:
-Item 33: Commercial database support
+Item 32: Commercial database support
Origin: Russell Howe <russell_howe dot wreckage dot org>
Date: 26 July 2006
Status:
than having to run a second DBMS.
-Item 34: Archive data
+Item 33: 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 35: Filesystem watch triggered backup.
+ 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 34: Filesystem watch triggered backup.
Date: 31 August 2006
Origin: Jesper Krogh <jesper@krogh.cc>
Status: Unimplemented, depends probably on "client initiated backups"
that monitors the Filesystem changes, then uses the console
to start the appropriate job.
-Item 36: Implement multiple numeric backup levels as supported by dump
+Item 35: Implement multiple numeric backup levels as supported by dump
Date: 3 April 2006
Origin: Daniel Rich <drich@employees.org>
Status:
Notes: Legato Networker supports a similar system with full, incr, and 1-9 as
levels.
-Kern notes: I think this would add very little functionality, but a *lot* of
- additional overhead to Bacula.
+Item 36: Implement a server-side compression feature
+ Date: 18 December 2006
+ Origin: Vadim A. Umanski , e-mail umanski@ext.ru
+ Status:
+ What: The ability to compress backup data on server receiving data
+ instead of doing that on client sending data.
+ Why: The need is practical. I've got some machines that can send
+ data to the network 4 or 5 times faster than compressing
+ them (I've measured that). They're using fast enough SCSI/FC
+ disk subsystems but rather slow CPUs (ex. UltraSPARC II).
+ And the backup server has got a quite fast CPUs (ex. Dual P4
+ Xeons) and quite a low load. When you have 20, 50 or 100 GB
+ of raw data - running a job 4 to 5 times faster - that
+ really matters. On the other hand, the data can be
+ compressed 50% or better - so losing twice more space for
+ disk backup is not good at all. And the network is all mine
+ (I have a dedicated management/provisioning network) and I
+ can get as high bandwidth as I need - 100Mbps, 1000Mbps...
+ That's why the server-side compression feature is needed!
+ Notes:
+
+Item 37: Cause daemons to use a specific IP address to source communications
+ Origin: Bill Moran <wmoran@collaborativefusion.com>
+ Date: 18 Dec 2006
+ Status:
+ What: Cause Bacula daemons (dir, fd, sd) to always use the ip address
+ specified in the [DIR|DF|SD]Addr directive as the source IP
+ for initiating communication.
+ Why: On complex networks, as well as extremely secure networks, it's
+ not unusual to have multiple possible routes through the network.
+ Often, each of these routes is secured by different policies
+ (effectively, firewalls allow or deny different traffic depending
+ on the source address)
+ Unfortunately, it can sometimes be difficult or impossible to
+ represent this in a system routing table, as the result is
+ excessive subnetting that quickly exhausts available IP space.
+ The best available workaround is to provide multiple IPs to
+ a single machine that are all on the same subnet. In order
+ for this to work properly, applications must support the ability
+ to bind outgoing connections to a specified address, otherwise
+ the operating system will always choose the first IP that
+ matches the required route.
+ Notes: Many other programs support this. For example, the following
+ can be configured in BIND:
+ query-source address 10.0.0.1;
+ transfer-source 10.0.0.2;
+ Which means queries from this server will always come from
+ 10.0.0.1 and zone transfers will always originate from
+ 10.0.0.2.
+
+Item 38: Multiple threads in file daemon for the same job
+ Date: 27 November 2005
+ Origin: Ove Risberg (Ove.Risberg at octocode dot com)
+ Status:
+
+ What: I want the file daemon to start multiple threads for a backup
+ job so the fastest possible backup can be made.
+
+ The file daemon could parse the FileSet information and start
+ one thread for each File entry located on a separate
+ filesystem.
+
+ A confiuration option in the job section should be used to
+ enable or disable this feature. The confgutration option could
+ specify the maximum number of threads in the file daemon.
+
+ If the theads could spool the data to separate spool files
+ the restore process will not be much slower.
+
+ Why: Multiple concurrent backups of a large fileserver with many
+ disks and controllers will be much faster.
+Item 39: Restore only file attributes (permissions, ACL, owner, group...)
+ Origin: Eric Bollengier
+ Date: 30/12/2006
+ Status:
+
+ What: The goal of this project is to be able to restore only rights
+ and attributes of files without crushing them.
+
+ Why: Who have never had to repair a chmod -R 777, or a wild update
+ of recursive right under Windows? At this time, you must have
+ enough space to restore data, dump attributes (easy with acl,
+ more complex with unix/windows rights) and apply them to your
+ broken tree. With this options, it will be very easy to compare
+ right or ACL over the time.
+
+ Notes: If the file is here, we skip restore and we change rights.
+ If the file isn't here, we can create an empty one and apply
+ rights or do nothing.
+
+Item 40: 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.
============= Empty Feature Request form ===========
Item n: One line summary ...
projects / bacula / bacula / blobdiff