X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=bacula%2Fprojects;h=3da15a6a3275083664935f2379979e008531a21c;hb=6f6aaa5a1ab969a158abb2c6698a440585ae94c4;hp=69b1a556d82f80c09071903ade0225966276d2ee;hpb=d08d3642c66b931918accc895e1440389408fe95;p=bacula%2Fbacula diff --git a/bacula/projects b/bacula/projects index 69b1a556d8..3da15a6a32 100644 --- a/bacula/projects +++ b/bacula/projects @@ -1022,3 +1022,134 @@ Notes: Legato Networker supports a similar system with full, incr, and 1-9 as 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'.