Item 1: Accurate restoration of renamed/deleted files
Date: 28 November 2005
Origin: Martin Simmons (martin at lispworks dot com)
- Status: Robert Nelson will implement this
+ Status:
What: When restoring a fileset for a specified date (including "most
recent"), Bacula should give you exactly the files and directories
Notes: I would commit some of my developers' time if we can agree
on the design and behavior.
- Notes: I get the idea, but would like more details on the precise
- syntax of the necessary directives and what they would do.
+ 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).
+
+ 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 {
+ Name = Primary
+ Pool Type = Backup
+ Copypool = Copy1
+ Copypool = OffsiteCopy2
+ }
+
+ 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.
Item 9: Scheduling syntax that permits more flexibility and options
Item 13: Restore only file attributes (permissions, ACL, owner, group...)
Origin: Eric Bollengier
Date: 30/12/2006
- Status:
+ Status: Implemented by Eric, see project-restore-attributes-only.patch
What: The goal of this project is to be able to restore only rights
and attributes of files without crushing them.
If the file isn't here, we can create an empty one and apply
rights or do nothing.
-
+ This will not work with win32 stream, because it seems that we
+ can't split the WriteBackup stream to get only ACL and ownerchip.
Item 14: Add an override in Schedule for Pools based on backup types
Date: 19 Jan 2005
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:
+ Status: Patch made by Nigel Stepp
What: When I do update -> Volume parameters -> All Volumes
from Pool, then I have to select pools one by one. I'd like
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
+
+
+
========== Already implemented ================================
manual/interactive jobs
Origin: Marc Schiffbauer <marc@schiffbauer.net>
Date: 12 April 2007)
- Status: Already implemented by Eric
+ Status:
What: Make it possible to modify the spooldata option
for a job when being run from within the console.