X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=bacula%2Fprojects;h=3da15a6a3275083664935f2379979e008531a21c;hb=6f6aaa5a1ab969a158abb2c6698a440585ae94c4;hp=6e126ec18697a8bf19f311767da1be92944fe595;hpb=e8c6cfbc0b69fc3ca6f4e89e72c1c18a785040a8;p=bacula%2Fbacula diff --git a/bacula/projects b/bacula/projects index 6e126ec186..3da15a6a32 100644 --- a/bacula/projects +++ b/bacula/projects @@ -903,3 +903,253 @@ Item n: Split documentation Notes: +Item n: Include an option to operate on all pools when doing + update vol parameters + + Origin: Dmitriy Pinchukov + 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 + console to have an option like "0: All Pools" in the list of + defined pools. + + Why: I have many pools and therefore unhappy with manually + updating each of them using update -> Volume parameters -> All + Volumes from Pool -> pool #. + +Item n: Automatic promotion of backup levels + Date: 19 January 2006 + Origin: Adam Thornton + Status: Blue sky + + 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). + + + + +Item n+1: Incorporation of XACML2/SAML2 parsing + Date: 19 January 2006 + Origin: Adam Thornton + 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. + +Item 1: Add an over-ride in the Schedule configuration to use a + different pool for different backup types. + +Date: 19 Jan 2005 +Origin: Chad Slater +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 device 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: Implement multiple numeric backup levels as supported by dump +Date: 3 April 2006 +Origin: Daniel Rich +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. + +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 1: include JobID in spool file name + Origin: Mark Bergman + Date: Tue Aug 22 17:13:39 EDT 2006 + Status: + + What: Change the name of the spool file to include the JobID + + Why: JobIDs are the common key used to refer to jobs, yet the + spoolfile name doesn't include that information. The date/time + stamp is useful (and should be retained). + + + +Item 2: include timestamp of job launch in "stat clients" output + Origin: Mark Bergman + Date: Tue Aug 22 17:13:39 EDT 2006 + Status: + + What: The "stat clients" command doesn't include any detail on when + the active backup jobs were launched. + + Why: Including the timestamp would make it much easier to decide whether + a job is running properly. + + Notes: It may be helpful to have the output from "stat clients" formatted + more like that from "stat dir" (and other commands), in a column + format. The per-client information that's currently shown (level, + client name, JobId, Volume, pool, device, Files, etc.) is good, but + somewhat hard to parse (both programmatically and visually), + particularly when there are many active clients. + +Item 1: Filesystemwatch triggered backup. + Date: 31 August 2006 + Origin: Jesper Krogh + Status: Unimplemented, depends probably on "client initiated backups" + + What: With inotify and similar filesystem triggeret notification + systems is it possible to have the file-daemon to monitor + filesystem changes and initiate backup. + + Why: There are 2 situations where this is nice to have. + 1) It is possible to get a much finer-grained backup than + the fixed schedules used now.. A file created and deleted + a few hours later, can automatically be caught. + + 2) The introduced load on the system will probably be + distributed more even on the system. + + Notes: This can be combined with configration that specifies + something like: "at most every 15 minutes or when changes + consumed XX MB". + +Item n: Message mailing based on backup types +Origin: Evan Kaufman + 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). + +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: + + 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 + } + + +Item n: Allow inclusion/exclusion of files in a fileset by creation/mod times + Origin: Evan Kaufman + Date: January 11, 2006 + Status: + + What: In the vein of the Wild and Regex directives in a Fileset's + Options, it would be helpful to allow a user to include or exclude + files and directories by creation or modification times. + + You could factor the Exclude=yes|no option in much the same way it + affects the Wild and Regex directives. For example, you could exclude + all files modified before a certain date: + + Options { + Exclude = yes + Modified Before = #### + } + + Or you could exclude all files created/modified since a certain date: + + Options { + Exclude = yes + Created Modified Since = #### + } + + The format of the time/date could be done several ways, say the number + of seconds since the epoch: + 1137008553 = Jan 11 2006, 1:42:33PM # result of `date +%s` + + Or a human readable date in a cryptic form: + 20060111134233 = Jan 11 2006, 1:42:33PM # YYYYMMDDhhmmss + + Why: I imagine a feature like this could have many uses. It would + allow a user to do a full backup while excluding the base operating + system files, so if I installed a Linux snapshot from a CD yesterday, + I'll *exclude* all files modified *before* today. If I need to + recover the system, I use the CD I already have, plus the tape backup. + Or if, say, a Windows client is hit by a particularly corrosive + virus, and I need to *exclude* any files created/modified *since* the + time of infection. + + Notes: Of course, this feature would work in concert with other + in/exclude rules, and wouldnt override them (or each other). + + Notes: The directives I'd imagine would be along the lines of + "[Created] [Modified] [Before|Since] = ". + So one could compare against 'ctime' and/or 'mtime', but ONLY 'before' + or 'since'.