X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=bacula%2Fprojects;h=e0382bf1a8bef92cdd307ba6a19f3e7ad77d7173;hb=eccf96b1068ae4c357c5f1e7095839a5e033acc4;hp=cc79273c48323f172b6691d8a42aa5d9a8ac18c5;hpb=96cf382bdff2d9b83a46bddc8367f0b8706d1b5f;p=bacula%2Fbacula diff --git a/bacula/projects b/bacula/projects index cc79273c48..e0382bf1a8 100644 --- a/bacula/projects +++ b/bacula/projects @@ -1,226 +1,1327 @@ Projects: Bacula Projects Roadmap - 22 February 2004 - -Item 1: Implement Base jobs. - - What: A base job is sort of like a Full save except that you - will want the FileSet to contain only files that are unlikely - to change in the future (i.e. a snapshot of most of your - system after installing it). After the base job has been run, - when you are doing a Full save, you specify one or more - Base jobs to be used. All files that have been backed up in - the Base job/jobs but not modified will then be excluded from - the backup. During a restore, the Base jobs will be - automatically pulled in where necessary. - - Why: This is something none of the competition does, as far as we -know - (except BackupPC, which is a Perl program that saves to disk - only). It is big win for the user, it makes Bacula stand out - as offering a unique optimization that immediately saves time - and money. Basically, imagine that you have 100 nearly -identical - Windows or Linux machine containing the OS and user files. - Now for the OS part, a Base job will be backed up once, and - rather than making 100 copies of the OS, there will be only - one. If one or more of the systems have some files updated, - no problem, they will be automatically restored. - - Notes: Huge savings in tape usage even for a single machine. Will - require more resources because the DIR must send FD a list of - files/attribs, and the FD must search the list and compare it - for each file to be saved. - - -Item 2: Job Data Spooling. + Status updated 14 Jun 2009 - What: Make the Storage daemon use intermediate file storage to -buffer - the data to disk before writing it to the tape. +Summary: +* => item complete - Why: This would be a nice project and is the most requested -feature. - Even though you may finish a client job quicker by spooling to - disk, you still have to eventually get it onto tape. If - intermediate disk buffering allows us to improve write - bandwidth to tape, it may make sense. In addition, you can - run multiple simultaneous jobs all spool to disk, then the - data can be written one job at a time to the tape at full - tape speed. This keeps the tape running smoothly and prevents - blocks from different simultaneous jobs from being intermixed - on the tape, which is very inefficient for restores. + Item 1: Ability to restart failed jobs +*Item 2: 'restore' menu: enter a JobId, automatically select dependents + Item 3: Scheduling syntax that permits more flexibility and options + Item 4: Data encryption on storage daemon + Item 5: Deletion of disk Volumes when pruned + Item 6: Implement Base jobs + Item 7: Add ability to Verify any specified Job. + Item 8: Improve Bacula's tape and drive usage and cleaning management + Item 9: Allow FD to initiate a backup +*Item 10: Restore from volumes on multiple storage daemons + Item 11: Implement Storage daemon compression + Item 12: Reduction of communications bandwidth for a backup + Item 13: Ability to reconnect a disconnected comm line + Item 14: Start spooling even when waiting on tape + Item 15: Enable/disable compression depending on storage device (disk/tape) + Item 16: Include all conf files in specified directory + Item 17: Multiple threads in file daemon for the same job + Item 18: Possibilty to schedule Jobs on last Friday of the month + Item 19: Include timestamp of job launch in "stat clients" output +*Item 20: Cause daemons to use a specific IP address to source communications + Item 21: Message mailing based on backup types + Item 22: Ability to import/export Bacula database entities +*Item 23: "Maximum Concurrent Jobs" for drives when used with changer device + Item 24: Implementation of running Job speed limit. + Item 25: Add an override in Schedule for Pools based on backup types + Item 26: Automatic promotion of backup levels based on backup size + Item 27: Allow inclusion/exclusion of files in a fileset by creation/mod times + Item 28: Archival (removal) of User Files to Tape + Item 29: An option to operate on all pools with update vol parameters + Item 30: Automatic disabling of devices +*Item 31: List InChanger flag when doing restore. + Item 32: Ability to defer Batch Insert to a later time + Item 33: Add MaxVolumeSize/MaxVolumeBytes statement to Storage resource + Item 34: Enable persistent naming/number of SQL queries + Item 35: Port bat to Win32 + Item 36: Bacula Dir, FD and SD to support proxies + Item 37: Add Minumum Spool Size directive + Item 38: Backup and Restore of Windows Encrypted Files using Win raw encryption + Item 39: Implement an interface between Bacula and Amazon's S3. + Item 40: Convert Bacula existing tray monitor on Windows to a stand alone program - Notes: Need multiple spool directories. Should possibly be able - to spool by Job type, ... Possibly need high and low spool - data levels. +Item 1: Ability to restart failed jobs + Date: 26 April 2009 + Origin: Kern/Eric + Status: + What: Often jobs fail because of a communications line drop or max run time, + cancel, or some other non-critical problem. Currrently any data + saved is lost. This implementation should modify the Storage daemon + so that it saves all the files that it knows are completely backed + up to the Volume -Item 3: GUI for interactive restore -Item 4: GUI for interactive backup + The jobs should then be marked as incomplete and a subsequent + Incremental Accurate backup will then take into account all the + previously saved job. - What: The current interactive restore is implemented with a tty - interface. It would be much nicer to be able to "see" the - list of files backed up in typical GUI tree format. - The same mechanism could also be used for creating - ad-hoc backup FileSets (item 8). + Why: Avoids backuping data already saved. - Why: Ease of use -- especially for the end user. + Notes: Requires Accurate to restart correctly. Must completed have a minimum + volume of data or files stored on Volume before enabling. - Notes: Rather than implementing in Gtk, we probably should go -directly - for a Browser implementation, even if doing so meant the - capability wouldn't be available until much later. Not only - is there the question of Windows sites, most - Solaris/HP/IRIX, etc, shops can't currently run Gtk programs - without installing lots of stuff admins are very wary about. - Real sysadmins will always use the command line anyway, and - the user who's doing an interactive restore or backup of his - own files will in most cases be on a Windows machine running - Exploder. +Item 2: 'restore' menu: enter a JobId, automatically select dependents +Origin: Graham Keeling (graham@equiinet.com) +Date: 13 March 2009 +Status: Done in 3.0.2 -Item 5: Implement a Migration job type that will move the job - data from one device to another. +What: Add to the bconsole 'restore' menu the ability to select a job + by JobId, and have bacula automatically select all the + dependent jobs. - What: The ability to copy, move, or archive data that is on a - device to another device is very important. + Why: Currently, you either have to... + a) laboriously type in a date that is greater than the date of the backup that + you want and is less than the subsequent backup (bacula then figures out the + dependent jobs), or + b) manually figure out all the JobIds that you want and laboriously type them + all in. + It would be extremely useful (in a programmatical sense, as well as for humans) + to be able to just give it a single JobId and let bacula do the hard work (work + that it already knows how to do). - Why: An ISP might want to backup to disk, but after 30 days - migrate the data to tape backup and delete it from disk. - Bacula should be able to handle this automatically. It needs -to - know what was put where, and when, and what to migrate -- it - is a bit like retention periods. Doing so would allow space to - be freed up for current backups while maintaining older data -on - tape drives. + Notes (Kern): I think this should either be modified to have Bacula print + a list of dates that the user can choose from as is done in bwx-console and + bat or the name of this command must be carefully chosen so that the user + clearly understands that the JobId is being used to specify what Job and the + date to which he wishes the restore to happen. - Notes: Migration could be triggered by: - Number of Jobs - Number of Volumes - Age of Jobs - Highwater size (keep total size) - Lowwater mark +Item 3: Scheduling syntax that permits more flexibility and options + Date: 15 December 2006 + Origin: Gregory Brauer (greg at wildbrain dot com) and + Florian Schnabel + Status: -Item 6: Embedded Perl Scripting (precursor to 7). + What: Currently, Bacula only understands how to deal with weeks of the + month or weeks of the year in schedules. This makes it impossible + to do a true weekly rotation of tapes. There will always be a + discontinuity that will require disruptive manual intervention at + least monthly or yearly because week boundaries never align with + month or year boundaries. - What: On a configuration parameter, embed the Perl language in - Bacula. + A solution would be to add a new syntax that defines (at least) + a start timestamp, and repetition period. - Why: The embedded Perl scripting can be called to implement - Events such as "Volume Name needed", "End of Tape", - "Tape at x% of rated capacity", "Job started", - "Job Ended", "Job error", ... + An easy option to skip a certain job on a certain date. + - Notes: This needs Events. + Why: Rotated backups done at weekly intervals are useful, and Bacula + cannot currently do them without extensive hacking. + You could then easily skip tape backups on holidays. Especially + if you got no autochanger and can only fit one backup on a tape + that would be really handy, other jobs could proceed normally + and you won't get errors that way. -Item 7: Implement Events (requires 6). - What: When a particular user defined Event occurs, call the - embedded Perl interpreter. + Notes: Here is an example syntax showing a 3-week rotation where full + Backups would be performed every week on Saturday, and an + incremental would be performed every week on Tuesday. Each + set of tapes could be removed from the loader for the following + two cycles before coming back and being reused on the third + week. Since the execution times are determined by intervals + from a given point in time, there will never be any issues with + having to adjust to any sort of arbitrary time boundary. In + the example provided, I even define the starting schedule + as crossing both a year and a month boundary, but the run times + would be based on the "Repeat" value and would therefore happen + weekly as desired. - Why: This will provide the ultimate in user customization for - Bacula. Almost anything imaginable can be done if Events - are called at the appropriate place. - Notes: There is a certain amount of work to be done on how - the user defines or "registers" events. + Schedule { + Name = "Week 1 Rotation" + #Saturday. Would run Dec 30, Jan 20, Feb 10, etc. + Run { + Options { + Type = Full + Start = 2006-12-30 01:00 + Repeat = 3w + } + } + #Tuesday. Would run Jan 2, Jan 23, Feb 13, etc. + Run { + Options { + Type = Incremental + Start = 2007-01-02 01:00 + Repeat = 3w + } + } + } + Schedule { + Name = "Week 2 Rotation" + #Saturday. Would run Jan 6, Jan 27, Feb 17, etc. + Run { + Options { + Type = Full + Start = 2007-01-06 01:00 + Repeat = 3w + } + } + #Tuesday. Would run Jan 9, Jan 30, Feb 20, etc. + Run { + Options { + Type = Incremental + Start = 2007-01-09 01:00 + Repeat = 3w + } + } + } -Item 8: Multiple Storage Devices for a Single Job + Schedule { + Name = "Week 3 Rotation" + #Saturday. Would run Jan 13, Feb 3, Feb 24, etc. + Run { + Options { + Type = Full + Start = 2007-01-13 01:00 + Repeat = 3w + } + } + #Tuesday. Would run Jan 16, Feb 6, Feb 27, etc. + Run { + Options { + Type = Incremental + Start = 2007-01-16 01:00 + Repeat = 3w + } + } + } - What: Allow any Job to use more than one Storage device. + Notes: Kern: I have merged the previously separate project of skipping + jobs (via Schedule syntax) into this. - Why: With two devices, for example, the second device could - have the next backup tape pre-mounted reducing operator - intervention in the middle of the night. +Item 4: Data encryption on storage daemon + Origin: Tobias Barth + Date: 04 February 2009 + Status: new -Item 9: Backup a Single Job Simultaneously to Multiple Storage - Devices + What: The storage demon should be able to do the data encryption that can currently be done by the file daemon. - What: Make two copies of the backup data at the same time. + Why: This would have 2 advantages: 1) one could encrypt the data of unencrypted tapes by doing a migration job, and 2) the storage daemon would be the only machine that would have to keep the encryption keys. - Why: Large shops typically do this and then take one set of - backups off-site. Some design work it needed in how to - specify the type of backup (backup, archive, ...) for each - Device. + Notes from Landon: + As an addendum to the feature request, here are some crypto + implementation details I wrote up regarding SD-encryption back in Jan + 2008: + http://www.mail-archive.com/bacula-users@lists.sourceforge.net/msg28860.html -Item 10: Break the one-to-one Relationship between a Job and a - Specific Storage Device (or Devices if #10 is implemented). +Item 5: Deletion of disk Volumes when pruned + Date: Nov 25, 2005 + Origin: Ross Boylan (edited + by Kern) + Status: - What: Allow a Job to simply specify one or more MediaType, and the - Storage daemon will select a device for it. In fact, the user - should be able to specify one or more MediaType, Storage - daemon, and/or device to be used. + What: Provide a way for Bacula to automatically remove Volumes + from the filesystem, or optionally to truncate them. + Obviously, the Volume must be pruned prior removal. - Why: To allow more flexibility in large shops that have multiple - drives and/or multiple drives of different types. + Why: This would allow users more control over their Volumes and + prevent disk based volumes from consuming too much space. + Notes: The following two directives might do the trick: -Item 11: Add Regular Expression Matching and Plug-ins to the - FileSet Include statements. + Volume Data Retention =