Projects:
Bacula Projects Roadmap
- Status updated 19 March 2008
+ Status updated 26 August 2008
Items Completed:
Notes: Additional notes from David:
I think there's two areas where new configuration would be needed.
- 1) Identify a "SD mux" SD (specify it in the config just like a normal
- SD. The SD configuration would need something like a "Daemon Type =
- Normal/Mux" keyword to identify it as a multiplexor. (The director code
- would need modification to add the ability to do the multiple session
- setup, but the impact of the change would be new code that was invoked
- only when a SDmux is needed).
+ 1) Identify a "SD mux" SD (specify it in the config just like a
+ normal SD. The SD configuration would need something like a
+ "Daemon Type = Normal/Mux" keyword to identify it as a
+ multiplexor. (The director code would need modification to add
+ the ability to do the multiple session setup, but the impact of
+ the change would be new code that was invoked only when a SDmux is
+ needed).
- 2) Additional keywords in the Pool definition to identify the need to
- create copies. Each pool would acquire a Copypool= attribute (may be
- repeated to generate more than one copy. 3 is about the practical limit,
- but no point in hardcoding that).
+ 2) Additional keywords in the Pool definition to identify the need
+ to create copies. Each pool would acquire a Copypool= attribute
+ (may be repeated to generate more than one copy. 3 is about the
+ practical limit, but no point in hardcoding that).
Example:
Pool {
where Copy1 and OffsiteCopy2 are valid pools.
- In terms of function (shorthand):
- Backup job X is defined normally, specifying pool Primary as the pool to
- use. Job gets scheduled, and Bacula starts scheduling resources.
- Scheduler looks at pool definition for Primary, sees that there are a
- non-zero number of copypool keywords. The director then connects to an
- available SDmux, passes it the pool ids for Primary, Copy1, and
- OffsiteCopy2 and waits. SDmux then goes out and reserves devices and
- volumes in the normal SDs that serve Primary, Copy1 and OffsiteCopy2.
- When all are ready, the SDmux signals ready back to the director, and
- the FD is given the address of the SDmux as the SD to communicate with.
- Backup proceeds normally, with the SDmux duplicating blocks to each
- connected normal SD, and returning ready when all defined copies have
- been written. At EOJ, FD shuts down connection with SDmux, which closes
- down the normal SD connections and goes back to an idle state.
- SDmux does not update database; normal SDs do (noting that file is
- present on each volume it has been written to).
-
- On restore, director looks for the volume containing the file in pool
- Primary first, then Copy1, then OffsiteCopy2. If the volume holding the
- file in pool Primary is missing or busy (being written in another job,
- etc), or one of the volumes from the copypool list that have the file in
- question is already mounted and ready for some reason, use it to do the
- restore, else mount one of the copypool volumes and proceed.
+ In terms of function (shorthand): Backup job X is defined
+ normally, specifying pool Primary as the pool to use. Job gets
+ scheduled, and Bacula starts scheduling resources. Scheduler
+ looks at pool definition for Primary, sees that there are a
+ non-zero number of copypool keywords. The director then connects
+ to an available SDmux, passes it the pool ids for Primary, Copy1,
+ and OffsiteCopy2 and waits. SDmux then goes out and reserves
+ devices and volumes in the normal SDs that serve Primary, Copy1
+ and OffsiteCopy2. When all are ready, the SDmux signals ready
+ back to the director, and the FD is given the address of the SDmux
+ as the SD to communicate with. Backup proceeds normally, with the
+ SDmux duplicating blocks to each connected normal SD, and
+ returning ready when all defined copies have been written. At
+ EOJ, FD shuts down connection with SDmux, which closes down the
+ normal SD connections and goes back to an idle state. SDmux does
+ not update database; normal SDs do (noting that file is present on
+ each volume it has been written to).
+
+ On restore, director looks for the volume containing the file in
+ pool Primary first, then Copy1, then OffsiteCopy2. If the volume
+ holding the file in pool Primary is missing or busy (being written
+ in another job, etc), or one of the volumes from the copypool list
+ that have the file in question is already mounted and ready for
+ some reason, use it to do the restore, else mount one of the
+ copypool volumes and proceed.
Item 9: Scheduling syntax that permits more flexibility and options
+
+========= Added since the last vote =================
+
+Item 1: Implement an interface between Bacula and 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. Current
+ ways to integrate Bacula and S3 involve storing all the data
+ locally and syncing them to S3, and manually fetching them
+ again when they're needed. This is very cumbersome.
+
+Item: Store and restore extended attributes, especially selinux file contexts
+ Date: 28 December 2007
+ Origin: Frank Sweetser <fs@wpi.edu>
+ What: The ability to store and restore extended attributes on
+ filesystems that support them, such as ext3.
+
+ Why: Security Enhanced Linux (SELinux) enabled systems make extensive
+ use of extended attributes. In addition to the standard user,
+ group, and permission, each file has an associated SELinux context
+ stored as an extended attribute. This context is used to define
+ which operations a given program is permitted to perform on that
+ file. Storing contexts on an SELinux system is as critical as
+ storing ownership and permissions. In the case of a full system
+ restore, the system will not even be able to boot until all
+ critical system files have been properly relabeled.
+
+ Notes: Fedora ships with a version of tar that has been patched to handle
+ extended attributes. The patch has not been integrated upstream
+ yet, so could serve as a good starting point.
+
+ http://linux.die.net/man/2/getxattr
+ http://linux.die.net/man/2/setxattr
+ http://linux.die.net/man/2/listxattr
+ ===
+ http://linux.die.net/man/3/getfilecon
+ http://linux.die.net/man/3/setfilecon
+
+Item 1: enable/disable compression depending on storage device (disk/tape)
+ Origin: Ralf Gross ralf-lists@ralfgross.de
+ Date: 2008-01-11
+ Status: Initial Request
+
+ What: Add a new option to the storage resource of the director. Depending
+ on this option, compression will be enabled/disabled for a device.
+
+ Why: If different devices (disks/tapes) are used for full/diff/incr
+ backups, software compression will be enabled for all backups
+ because of the FileSet compression option. For backup to tapes
+ wich are able to do hardware compression this is not desired.
+
+
+ Notes:
+ http://news.gmane.org/gmane.comp.sysutils.backup.bacula.devel/cutoff=11124
+ It must be clear to the user, that the FileSet compression option
+ must still be enabled use compression for a backup job at all.
+ Thus a name for the new option in the director must be
+ well-defined.
+
+ Notes: KES I think the Storage definition should probably override what
+ is in the Job definition or vice-versa, but in any case, it must
+ be well defined.
+
+
+Item 1: Backup and Restore of Windows Encrypted Files through raw encryption
+ functions
+
+ Origin: Michael Mohr, SAG Mohr.External@infineon.com
+
+ Date: 22 February 2008
+
+ Status:
+
+ What: Make it possible to backup and restore Encypted Files from and to
+ Windows systems without the need to decrypt it by using the raw
+ encryption functions API (see:
+ http://msdn2.microsoft.com/en-us/library/aa363783.aspx)
+
+ that is provided for that reason by Microsoft.
+ If a file ist encrypted could be examined by evaluating the
+ FILE_ATTRIBUTE_ENCRYTED flag of the GetFileAttributes
+ function.
+
+ Why: Without the usage of this interface the fd-daemon running
+ under the system account can't read encypted Files because
+ the key needed for the decrytion is missed by them. As a result
+ actually encrypted files are not backed up
+ by bacula and also no error is shown while missing these files.
+
+ Notes: ./.
+
+ Item 1: Possibilty to schedule Jobs on last Friday of the month
+ Origin: Carsten Menke <bootsy52 at gmx dot net>
+ Date: 02 March 2008
+ Status:
+
+ What: Currently if you want to run your monthly Backups on the last
+ Friday of each month this is only possible with workarounds (e.g
+ scripting) (As some months got 4 Fridays and some got 5 Fridays)
+ The same is true if you plan to run your yearly Backups on the
+ last Friday of the year. It would be nice to have the ability to
+ use the builtin scheduler for this.
+
+ Why: In many companies the last working day of the week is Friday (or
+ Saturday), so to get the most data of the month onto the monthly
+ tape, the employees are advised to insert the tape for the
+ monthly backups on the last friday of the month.
+
+ Notes: To give this a complete functionality it would be nice if the
+ "first" and "last" Keywords could be implemented in the
+ scheduler, so it is also possible to run monthy backups at the
+ first friday of the month and many things more. So if the syntax
+ would expand to this {first|last} {Month|Week|Day|Mo-Fri} of the
+ {Year|Month|Week} you would be able to run really flexible jobs.
+
+ To got a certain Job run on the last Friday of the Month for example one could
+ then write
+
+ Run = pool=Monthly last Fri of the Month at 23:50
+
+ ## Yearly Backup
+
+ Run = pool=Yearly last Fri of the Year at 23:50
+
+ ## Certain Jobs the last Week of a Month
+
+ Run = pool=LastWeek last Week of the Month at 23:50
+
+ ## Monthly Backup on the last day of the month
+
+ Run = pool=Monthly last Day of the Month at 23:50
+
+ 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 n?: Expand the Verify Job capability to verify Jobs older than the
+ last one. For VolumeToCatalog Jobs
+ Date: 17 Januar 2008
+ Origin: portrix.net Hamburg, Germany.
+ Contact: Christian Sabelmann
+ Status: 70% of the required Code is part of the Verify function since v. 2.x
+
+ What:
+ The ability to tell Bacula which Job should verify instead of
+ automatically verify just the last one.
+
+ Why:
+ It is sad that such a powerfull feature like Verify Jobs
+ (VolumeToCatalog) is restricted to be used only with the last backup Job
+ of a client. Actual users who have to do daily Backups are forced to
+ also do daily Verify Jobs in order to take advantage of this useful
+ feature. This Daily Verify after Backup conduct is not always desired
+ and Verify Jobs have to be sometimes scheduled. (Not necessarily
+ scheduled in Bacula). With this feature Admins can verify Jobs once a
+ Week or less per month, selecting the Jobs they want to verify. This
+ feature is also not to difficult to implement taking in account older bug
+ reports about this feature and the selection of the Job to be verified.
+
+ Notes: For the verify Job, the user could select the Job to be verified
+ from a List of the latest Jobs of a client. It would also be possible to
+ verify a certain volume. All of these would naturaly apply only for
+ Jobs whose file information are still in the catalog.
+
+Item X: Add EFS support on Windows
+ Origin: Alex Ehrlich (Alex.Ehrlich-at-mail.ee)
+ Date: 05 August 2008
+ Status:
+
+ What: For each file backed up or restored by FD on Windows, check if
+ the file is encrypted; if so then use OpenEncryptedFileRaw,
+ ReadEncryptedFileRaw, WriteEncryptedFileRaw,
+ CloseEncryptedFileRaw instead of BackupRead and BackupWrite
+ API calls.
+
+ Why: Many laptop users utilize the EFS functionality today; so do.
+ some non-laptop ones, too.
+ Currently files encrypted by means of EFS cannot be backed up.
+ It means a Windows boutique cannot rely on Bacula as its
+ backup solution, at least when using Windows 2K, XPP,
+ "better" Vista etc on workstations, unless EFS is
+ forbidden by policies.
+ The current situation might result into "false sense of
+ security" among the end-users.
+
+ Notes: Using xxxEncryptedFileRaw API would allow to backup and
+ restore EFS-encrypted files without decrypting their data.
+ Note that such files cannot be restored "portably" (at least,
+ easily) but they would be restoreable to a different (or
+ reinstalled) Win32 machine; the restore would require setup
+ of a EFS recovery agent in advance, of course, and this shall
+ be clearly reflected in the documentation, but this is the
+ normal Windows SysAdmin's business.
+ When "portable" backup is requested the EFS-encrypted files
+ shall be clearly reported as errors.
+ See MSDN on the "Backup and Restore of Encrypted Files" topic:
+ http://msdn.microsoft.com/en-us/library/aa363783.aspx
+ Maybe the EFS support requires a new flag in the database for
+ each file, too?
+ Unfortunately, the implementation is not as straightforward as
+ 1-to-1 replacement of BackupRead with ReadEncryptedFileRaw,
+ requiring some FD code rewrite to work with
+ encrypted-file-related callback functions.
+
+ encrypted-file-related callback functions.
+========== Already implemented ================================
+
+Item n: make changing "spooldata=yes|no" possible for
+ manual/interactive jobs
+ Origin: Marc Schiffbauer <marc@schiffbauer.net>
+ Date: 12 April 2007)
+ Status:
+
+ What: Make it possible to modify the spooldata option
+ for a job when being run from within the console.
+ Currently it is possible to modify the backup level
+ and the spooldata setting in a Schedule resource.
+ It is also possible to modify the backup level when using
+ the "run" command in the console.
+ But it is currently not possible to to the same
+ with "spooldata=yes|no" like:
+
+ run job=MyJob level=incremental spooldata=yes
+
+ Why: In some situations it would be handy to be able to switch
+ spooldata on or off for interactive/manual jobs based on
+ which data the admin expects or how fast the LAN/WAN
+ connection currently is.
+
+ Notes: ./.
+
+============= Empty Feature Request form ===========
+Item n: One line summary ...
+ Date: Date submitted
+ Origin: Name and email of originator.
+ Status:
+
+ What: More detailed explanation ...
+
+ Why: Why it is important ...
+
+ Notes: Additional notes or features (omit if not used)
+============== End Feature Request form ==============
+
========== Items on put hold by Kern ============================
Item h1: Split documentation
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
+ 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,
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.
+ 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
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.
+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.
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
+ 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.
-
- Notes: This might be nice, but someone other than me will probably need to
- implement it, and at the moment, proprietary code cannot legally be
- mixed with Bacula GPLed code. This would be possible only providing
- the vendors provide GPLed (or OpenSource) interface code.
+ 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.
+
+ Notes: This might be nice, but someone other than me will probably need to
+ implement it, and at the moment, proprietary code cannot legally
+ be mixed with Bacula GPLed code. This would be possible only
+ providing the vendors provide GPLed (or OpenSource) interface
+ code.
Item h8: Incorporation of XACML2/SAML2 parsing
Date: 19 January 2006
Origin: Adam Thornton <athornton@sinenomine.net>
Status: Blue sky
- What: XACML is "eXtensible Access Control Markup Language" and
- "SAML is the "Security Assertion Markup Language"--an XML standard
- for making statements about identity and authorization. Having these
- would give us a framework to approach ACLs in a generic manner, and
- in a way flexible enough to support the four major sorts of ACLs I
- see as a concern to Bacula at this point, as well as (probably) to
- deal with new sorts of ACLs that may appear in the future.
-
- Why: Bacula is beginning to need to back up systems with ACLs
- that do not map cleanly onto traditional Unix permissions. I see
- four sets of ACLs--in general, mutually incompatible with one
- another--that we're going to need to deal with. These are: NTFS
- ACLs, POSIX ACLs, NFSv4 ACLS, and AFS ACLS. (Some may question the
- relevance of AFS; AFS is one of Sine Nomine's core consulting
- businesses, and having a reputable file-level backup and restore
- technology for it (as Tivoli is probably going to drop AFS support
- soon since IBM no longer supports AFS) would be of huge benefit to
- our customers; we'd most likely create the AFS support at Sine Nomine
- for inclusion into the Bacula (and perhaps some changes to the
+ What: XACML is "eXtensible Access Control Markup Language" and "SAML is
+ the "Security Assertion Markup Language"--an XML standard for
+ making statements about identity and authorization. Having these
+ would give us a framework to approach ACLs in a generic manner,
+ and in a way flexible enough to support the four major sorts of
+ ACLs I see as a concern to Bacula at this point, as well as
+ (probably) to deal with new sorts of ACLs that may appear in the
+ future.
+
+ Why: Bacula is beginning to need to back up systems with ACLs that do not
+ map cleanly onto traditional Unix permissions. I see four sets of
+ ACLs--in general, mutually incompatible with one another--that
+ we're going to need to deal with. These are: NTFS ACLs, POSIX
+ ACLs, NFSv4 ACLS, and AFS ACLS. (Some may question the relevance
+ of AFS; AFS is one of Sine Nomine's core consulting businesses,
+ and having a reputable file-level backup and restore technology
+ for it (as Tivoli is probably going to drop AFS support soon since
+ IBM no longer supports AFS) would be of huge benefit to our
+ customers; we'd most likely create the AFS support at Sine Nomine
+ for inclusion into the Bacula (and perhaps some changes to the
OpenAFS volserver) core code.)
- Now, obviously, Bacula already handles NTFS just fine. However, I
- think there's a lot of value in implementing a generic ACL model, so
- that it's easy to support whatever particular instances of ACLs come
- down the pike: POSIX ACLS (think SELinux) and NFSv4 are the obvious
- things arriving in the Linux world in a big way in the near future.
- XACML, although overcomplicated for our needs, provides this
- framework, and we should be able to leverage other people's
- implementations to minimize the amount of work *we* have to do to get
- a generic ACL framework. Basically, the costs of implementation are
- high, but they're largely both external to Bacula and already sunk.
+ Now, obviously, Bacula already handles NTFS just fine. However, I
+ think there's a lot of value in implementing a generic ACL model,
+ so that it's easy to support whatever particular instances of ACLs
+ come down the pike: POSIX ACLS (think SELinux) and NFSv4 are the
+ obvious things arriving in the Linux world in a big way in the
+ near future. XACML, although overcomplicated for our needs,
+ provides this framework, and we should be able to leverage other
+ people's implementations to minimize the amount of work *we* have
+ to do to get a generic ACL framework. Basically, the costs of
+ implementation are high, but they're largely both external to
+ Bacula and already sunk.
Notes: As you indicate this is a bit of "blue sky" or in other words,
at the moment, it is a bit esoteric to consider for Bacula.
What: The abilty to archive to media (dvd/cd) in a uncompressed format
for dead filing (archiving not backing up)
- Why: At work 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.
+ Why: At work 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
implement it. A lot more design detail should be presented
before voting on this project.
-========= Added since the last vote =================
-
-Item: Store and restore extended attributes, especially selinux file contexts
- Date: 28 December 2007
- Origin: Frank Sweetser <fs@wpi.edu>
- What: The ability to store and restore extended attributes on
- filesystems that support them, such as ext3.
-
- Why: Security Enhanced Linux (SELinux) enabled systems make extensive
- use of extended attributes. In addition to the standard user,
- group, and permission, each file has an associated SELinux context
- stored as an extended attribute. This context is used to define
- which operations a given program is permitted to perform on that
- file. Storing contexts on an SELinux system is as critical as
- storing ownership and permissions. In the case of a full system
- restore, the system will not even be able to boot until all
- critical system files have been properly relabeled.
-
- Notes: Fedora ships with a version of tar that has been patched to handle
- extended attributes. The patch has not been integrated upstream
- yet, so could serve as a good starting point.
-
- http://linux.die.net/man/2/getxattr
- http://linux.die.net/man/2/setxattr
- http://linux.die.net/man/2/listxattr
- ===
- http://linux.die.net/man/3/getfilecon
- http://linux.die.net/man/3/setfilecon
-
-Item 1: enable/disable compression depending on storage device (disk/tape)
- Origin: Ralf Gross ralf-lists@ralfgross.de
- Date: 2008-01-11
- Status: Initial Request
-
- What: Add a new option to the storage resource of the director. Depending
- on this option, compression will be enabled/disabled for a device.
-
- Why: If different devices (disks/tapes) are used for full/diff/incr
- backups, software compression will be enabled for all backups
- because of the FileSet compression option. For backup to tapes wich
- are able to do hardware compression this is not desired.
-
-
- Notes: http://news.gmane.org/gmane.comp.sysutils.backup.bacula.devel/cutoff=11124
- It must be clear to the user, that the FileSet compression option must
- still be enabled use compression for a backup job at all. Thus a name
- for the new option in the director must be well-defined.
-
- Notes: KES I think the Storage definition should probably override what
- is in the Job definition or vice-versa, but in any case, it must
- be well defined.
-
-
-Item 1: Backup and Restore of Windows Encrypted Files through raw encryption functions
-
- Origin: Michael Mohr, SAG Mohr.External@infineon.com
-
- Date: 22 February 2008
-
- Status:
-
- What: Make it possible to backup and restore Encypted Files from and
- to Windows systems without the need to decrypt it by using the raw encryption
- functions API
- (see: http://msdn2.microsoft.com/en-us/library/aa363783.aspx)
-
- that is provided for that reason by Microsoft.
- If a file ist encrypted could be examined by evaluating the
- FILE_ATTRIBUTE_ENCRYTED flag of the GetFileAttributes
- function.
-
- Why: Without the usage of this interface the fd-daemon running
- under the system account can't read encypted Files because
- the key needed for the decrytion is missed by them. As a result
- actually encrypted files are not backed up
- by bacula and also no error is shown while missing these files.
-
- Notes: ./.
-
- Item 1: Possibilty to schedule Jobs on last Friday of the month
- Origin: Carsten Menke <bootsy52 at gmx dot net>
- Date: 02 March 2008
- Status:
-
- What: Currently if you want to run your monthly Backups on the last
- Friday of each month this is only possible with workarounds (e.g
- scripting) (As some months got 4 Fridays and some got 5 Fridays)
- The same is true if you plan to run your yearly Backups on the last
- Friday of the year. It would be nice to have the ability to use the builtin
- scheduler for this.
-
- Why: In many companies the last working day of the week is Friday (or
- Saturday), so to get the most data of the month onto the monthly tape, the
- employees are advised to insert the tape for the monthly backups on the last
- friday of the month.
-
- Notes: To give this a complete functionality it would be nice if the "first"
- and "last" Keywords could be implemented in the scheduler, so it is also
- possible to run monthy backups at the first friday of the month and many things
- more. So if the syntax would expand to this {first|last} {Month|Week|Day|Mo-Fri}
- of the {Year|Month|Week} you would be able to run really flexible jobs.
-
- To got a certain Job run on the last Friday of the Month for example one could
- then write
-
- Run = pool=Monthly last Fri of the Month at 23:50
-
- ## Yearly Backup
-
- Run = pool=Yearly last Fri of the Year at 23:50
-
- ## Certain Jobs the last Week of a Month
-
- Run = pool=LastWeek last Week of the Month at 23:50
-
- ## Monthly Backup on the last day of the month
-
- Run = pool=Monthly last Day of the Month at 23:50
-
- 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 n?: Expand the Verify Job capability to verify Jobs older than the
- last one. For VolumeToCatalog Jobs
- Date: 17 Januar 2008
- Origin: portrix.net Hamburg, Germany.
- Contact: Christian Sabelmann
- Status: 70% of the required Code is part of the Verify function since v. 2.x
-
- What:
- The ability to tell Bacula which Job should verify instead of
- automatically verify just the last one.
-
- Why:
- It is sad that such a powerfull feature like Verify Jobs
- (VolumeToCatalog) is restricted to be used only with the last backup Job
- of a client. Actual users who have to do daily Backups are forced to
- also do daily Verify Jobs in order to take advantage of this useful
- feature. This Daily Verify after Backup conduct is not always desired
- and Verify Jobs have to be sometimes scheduled. (Not necessarily
- scheduled in Bacula). With this feature Admins can verify Jobs once a
- Week or less per month, selecting the Jobs they want to verify. This
- feature is also not to difficult to implement taking in account older
- bug reports about this feature and the selection of the Job to be verified.
-
- Notes: For the verify Job, the user could select the Job to be verified
- from a List of the latest Jobs of a client. It would also be possible to
- verify a certain volume. All of these would naturaly apply only for
- Jobs whose file information are still in the catalog.
-
-Item X: Add EFS support on Windows
- Origin: Alex Ehrlich (Alex.Ehrlich-at-mail.ee)
- Date: 05 August 2008
- Status:
-
- What: For each file backed up or restored by FD on Windows, check if
- the file is encrypted; if so then use OpenEncryptedFileRaw,
- ReadEncryptedFileRaw, WriteEncryptedFileRaw,
- CloseEncryptedFileRaw instead of BackupRead and BackupWrite
- API calls.
-
- Why: Many laptop users utilize the EFS functionality today; so do.
- some non-laptop ones, too.
- Currently files encrypted by means of EFS cannot be backed up.
- It means a Windows boutique cannot rely on Bacula as its
- backup solution, at least when using Windows 2K, XPP,
- "better" Vista etc on workstations, unless EFS is
- forbidden by policies.
- The current situation might result into "false sense of
- security" among the end-users.
-
- Notes: Using xxxEncryptedFileRaw API would allow to backup and
- restore EFS-encrypted files without decrypting their data.
- Note that such files cannot be restored "portably" (at least,
- easily) but they would be restoreable to a different (or
- reinstalled) Win32 machine; the restore would require setup
- of a EFS recovery agent in advance, of course, and this shall
- be clearly reflected in the documentation, but this is the
- normal Windows SysAdmin's business.
- When "portable" backup is requested the EFS-encrypted files
- shall be clearly reported as errors.
- See MSDN on the "Backup and Restore of Encrypted Files" topic:
- http://msdn.microsoft.com/en-us/library/aa363783.aspx
- Maybe the EFS support requires a new flag in the database for
- each file, too?
- Unfortunately, the implementation is not as straightforward as
- 1-to-1 replacement of BackupRead with ReadEncryptedFileRaw,
- requiring some FD code rewrite to work with
- encrypted-file-related callback functions.
-
- encrypted-file-related callback functions.
-========== Already implemented ================================
-
-Item n: make changing "spooldata=yes|no" possible for
- manual/interactive jobs
- Origin: Marc Schiffbauer <marc@schiffbauer.net>
- Date: 12 April 2007)
- Status:
-
- What: Make it possible to modify the spooldata option
- for a job when being run from within the console.
- Currently it is possible to modify the backup level
- and the spooldata setting in a Schedule resource.
- It is also possible to modify the backup level when using
- the "run" command in the console.
- But it is currently not possible to to the same
- with "spooldata=yes|no" like:
-
- run job=MyJob level=incremental spooldata=yes
-
- Why: In some situations it would be handy to be able to switch
- spooldata on or off for interactive/manual jobs based on
- which data the admin expects or how fast the LAN/WAN
- connection currently is.
-
- Notes: ./.
-
-============= Empty Feature Request form ===========
-Item n: One line summary ...
- Date: Date submitted
- Origin: Name and email of originator.
- Status:
-
- What: More detailed explanation ...
-
- Why: Why it is important ...
-
- Notes: Additional notes or features (omit if not used)
-============== End Feature Request form ==============
projects / bacula / bacula / commitdiff