- What: Network Data Management Protocol is implemented by a number of
- NAS filer vendors to enable backups using third-party
- software.
-
- Why: This would allow NAS filer backups in Bacula without incurring
- the overhead of NFS or SBM/CIFS.
-
- Notes: Further information is available:
- http://www.ndmp.org
- http://www.ndmp.org/wp/wp.shtml
- http://www.traakan.com/ndmjob/index.html
-
- There are currently no viable open-source NDMP
- implementations. There is a reference SDK and example
- app available from ndmp.org but it has problems
- compiling on recent Linux and Solaris OS'. The ndmjob
- reference implementation from Traakan is known to
- compile on Solaris 10.
-
- Notes: Kern: I am not at all in favor of this until NDMP becomes
- an Open Standard or until there are Open Source libraries
- that interface to it.
-
-Item h7: Commercial database support
- Origin: Russell Howe <russell_howe dot wreckage dot org>
- 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
- 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.
-
-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
- 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.
-
- 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.
-
-Item h9: 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 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
- 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 predefined 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
-
- Notes: Kern: I don't understand this item, and in any case, if it
- is specific to DVD/CDs, which we do not recommend using,
- it is unlikely to be implemented except as a user
- submitted patch.
-
-
-Item h10: Clustered file-daemons
- Origin: Alan Brown ajb2 at mssl dot ucl dot ac dot uk
- Date: 24 July 2006
- Status:
- What: A "virtual" filedaemon, which is actually a cluster of real ones.
-
- Why: In the case of clustered filesystems (SAN setups, GFS, or OCFS2, etc)
- multiple machines may have access to the same set of filesystems
-
- For performance reasons, one may wish to initate backups from
- several of these machines simultaneously, instead of just using
- one backup source for the common clustered filesystem.
-
- For obvious reasons, normally backups of $A-FD/$PATH and
- B-FD/$PATH are treated as different backup sets. In this case
- they are the same communal set.
-
- Likewise when restoring, it would be easier to just specify
- one of the cluster machines and let bacula decide which to use.
-
- This can be faked to some extent using DNS round robin entries
- and a virtual IP address, however it means "status client" will
- always give bogus answers. Additionally there is no way of
- spreading the load evenly among the servers.
-
- What is required is something similar to the storage daemon
- autochanger directives, so that Bacula can keep track of
- operating backups/restores and direct new jobs to a "free"
- client.
-
- Notes: Kern: I don't understand the request enough to be able to
- 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.
-