- Notes: I am willing to try to implement this but I will probably
- need some help and advice. (No problem -- Kern)
-
-Item 14: Implement red/black binary tree routines.
- Date: 28 October 2005
- Origin: Kern
- Status: Class code is complete. Code needs to be integrated into
- restore tree code.
-
- What: Implement a red/black binary tree class. This could
- then replace the current binary insert/search routines
- used in the restore in memory tree. This could significantly
- speed up the creation of the in memory restore tree.
-
- Why: Performance enhancement.
-
-Item 15: Add support for FileSets in user directories CACHEDIR.TAG
- Origin: Norbert Kiesel <nkiesel at tbdnetworks dot com>
- Date: 21 November 2005
- Status: (I think this is better done using a Python event that I
- will implement in version 1.39.x).
-
- What: CACHDIR.TAG is a proposal for identifying directories which
- should be ignored for archiving/backup. It works by ignoring
- directory trees which have a file named CACHEDIR.TAG with a
- specific content. See
- http://www.brynosaurus.com/cachedir/spec.html
- for details.
-
- From Peter Eriksson:
- I suggest that if this is implemented (I've also asked for this
- feature some year ago) that it is made compatible with Legato
- Networkers ".nsr" files where you can specify a lot of options on
- how to handle files/directories (including denying further
- parsing of .nsr files lower down into the directory trees). A
- PDF version of the .nsr man page can be viewed at:
-
- http://www.ifm.liu.se/~peter/nsr.pdf
-
- Why: It's a nice alternative to "exclude" patterns for directories
- which don't have regular pathnames. Also, it allows users to
- control backup for themselves. Implementation should be pretty
- simple. GNU tar >= 1.14 or so supports it, too.
-
- Notes: I envision this as an optional feature to a fileset
- specification.
-
-
-Item 16: Implement extraction of Win32 BackupWrite data.
- Origin: Thorsten Engel <thorsten.engel at matrix-computer dot com>
- Date: 28 October 2005
- Status: Done. Assigned to Thorsten. Implemented in current CVS
-
- What: This provides the Bacula File daemon with code that
- can pick apart the stream output that Microsoft writes
- for BackupWrite data, and thus the data can be read
- and restored on non-Win32 machines.
-
- Why: BackupWrite data is the portable=no option in Win32
- FileSets, and in previous Baculas, this data could
- only be extracted using a Win32 FD. With this new code,
- the Windows data can be extracted and restored on
- any OS.
-
-
-Item 18: Implement a Python interface to the Bacula catalog.
- Date: 28 October 2005
- Origin: Kern
+ 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
+ }
+
+ Notes: Kern: This should be rather trivial to implement.
+
+
+Item 19: Handle Windows Encrypted Files using Win raw encryption
+ Origin: Michael Mohr, SAG Mohr.External@infineon.com
+ Date: 22 February 2008
+ Origin: Alex Ehrlich (Alex.Ehrlich-at-mail.ee)
+ Date: 05 August 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.
+ 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: 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: 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.
+
+Item 20: Job migration between different SDs
+Origin: Mariusz Czulada <manieq AT wp DOT eu>
+Date: 07 May 2007
+Status: NEW
+
+What: Allow to specify in migration job devices on Storage Daemon other then
+ the one used for migrated jobs (possibly on different/distant host)
+
+Why: Sometimes we have more then one system which requires backup
+ implementation. Often, these systems are functionally unrelated and
+ placed in different locations. Having a big backup device (a tape
+ library) in each location is not cost-effective. It would be much
+ better to have one powerful enough tape library which could handle
+ backups from all systems, assuming relatively fast and reliable WAN
+ connections. In such architecture backups are done in service windows
+ on local bacula servers, then migrated to central storage off the peak
+ hours.
+
+Notes: If migration to different SD is working, migration to the same SD, as
+ now, could be done the same way (i mean 'localhost') to unify the
+ whole process
+
+Item 19. Allow FD to initiate a backup
+Origin: Frank Volf (frank at deze dot org)
+Date: 17 November 2005
+Status:
+
+What: Provide some means, possibly by a restricted console that
+ allows a FD to initiate a backup, and that uses the connection
+ established by the FD to the Director for the backup so that
+ a Director that is firewalled can do the backup.
+Why: Makes backup of laptops much easier.
+Notes: - The FD already has code for the monitor interface
+ - It could be nice to have a .job command that lists authorized
+ jobs.
+ - Commands need to be restricted on the Director side
+ (for example by re-using the runscript flag)
+ - The Client resource can be used to authorize the connection
+ - In a first time, the client can't modify job parameters
+ - We need a way to run a status command to follow job progression
+
+ This project consists of the following points
+ 1. Modify the FD to have a "mini-console" interface that
+ permits it to connect to the Director and start a
+ backup job of itself.
+ 2. The list of jobs that can be started by the FD are
+ defined in the Director (possibly via a restricted
+ console).
+ 3. Modify the existing tray monitor code in the Win32 FD
+ so that it is a separate program from the FD.
+ 4. The tray monitor program should be extended to permit
+ initiating a backup.
+ 5. No new Director directives should be added without
+ prior consultation with the Bacula developers.
+ 6. The comm line used by the FD to connect to the Director
+ should be re-used by the Director to do the backup.
+ This feature is partially implemented in the Director.
+ 7. The FD may have a new directive that allows it to start
+ a backup when the FD starts.
+ 8. The console interface to the FD should be extended to
+ permit a properly authorized console to initiate a
+ backup via the FD.
+
+
+Item 21: Implement Storage daemon compression
+ Date: 18 December 2006
+ Origin: Vadim A. Umanski , e-mail umanski@ext.ru
+ Status:
+ What: The ability to compress backup data on the SD 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 22: Ability to import/export Bacula database entities
+ Date: 26 April 2009
+ Origin: Eric
+ Status:
+
+ What: Create a Bacula ASCII SQL database independent format that permits
+ importing and exporting database catalog Job entities.
+
+ Why: For achival, database clustering, tranfer to other databases
+ of any SQL engine.
+
+ Notes: Job selection should be by Job, time, Volume, Client, Pool and possibly
+ other criteria.
+
+
+Item 23: Implementation of running Job speed limit.
+Origin: Alex F, alexxzell at yahoo dot com
+Date: 29 January 2009
+
+What: I noticed the need for an integrated bandwidth limiter for
+ running jobs. It would be very useful just to specify another
+ field in bacula-dir.conf, like speed = how much speed you wish
+ for that specific job to run at
+
+Why: Because of a couple of reasons. First, it's very hard to implement a
+ traffic shaping utility and also make it reliable. Second, it is very
+ uncomfortable to have to implement these apps to, let's say 50 clients
+ (including desktops, servers). This would also be unreliable because you
+ have to make sure that the apps are properly working when needed; users
+ could also disable them (accidentally or not). It would be very useful
+ to provide Bacula this ability. All information would be centralized,
+ you would not have to go to 50 different clients in 10 different
+ locations for configuration; eliminating 3rd party additions help in
+ establishing efficiency. Would also avoid bandwidth congestion,
+ especially where there is little available.
+
+
+Item 24: Add an override in Schedule for Pools based on backup types
+Date: 19 Jan 2005
+Origin: Chad Slater <chad.slater@clickfox.com>
+Status:
+
+ What: Adding a FullStorage=BigTapeLibrary in the Schedule resource
+ would help those of us who use different storage devices for different
+ backup levels cope with the "auto-upgrade" of a backup.
+
+ Why: Assume I add several new devices to be backed up, i.e. several
+ hosts with 1TB RAID. To avoid tape switching hassles, incrementals are
+ stored in a disk set on a 2TB RAID. If you add these devices in the
+ middle of the month, the incrementals are upgraded to "full" backups,
+ but they try to use the same storage device as requested in the
+ incremental job, filling up the RAID holding the differentials. If we
+ could override the Storage parameter for full and/or differential
+ backups, then the Full job would use the proper Storage device, which
+ has more capacity (i.e. a 8TB tape library.
+
+
+Item 25: Automatic promotion of backup levels based on backup size
+ Date: 19 January 2006
+ Origin: Adam Thornton <athornton@sinenomine.net>