From 7abb9e4dd42195b8c4e5b0e3e80c1fbb664553de Mon Sep 17 00:00:00 2001 From: Kern Sibbald Date: Thu, 29 Jul 2010 09:07:29 +0200 Subject: [PATCH] Remove some old files --- bacula/Patchnotes | 8 - bacula/projects.old | 1756 ------------------------------------------- 2 files changed, 1764 deletions(-) delete mode 100644 bacula/Patchnotes delete mode 100644 bacula/projects.old diff --git a/bacula/Patchnotes b/bacula/Patchnotes deleted file mode 100644 index 76ea7bb5ca..0000000000 --- a/bacula/Patchnotes +++ /dev/null @@ -1,8 +0,0 @@ - Patch notes for version 3.0 - - -Patches Committed: -14Apr09 -3.0.0-maxruntime.patch -11Apr09 -3.0.0-read-vol-list.patch diff --git a/bacula/projects.old b/bacula/projects.old deleted file mode 100644 index 2fa4790434..0000000000 --- a/bacula/projects.old +++ /dev/null @@ -1,1756 +0,0 @@ - -Projects: - Bacula Projects Roadmap - Status updated 04 February 2009 - -Items Completed for version 3.0.0: -Item 1: Accurate restoration of renamed/deleted files -Item 3: Merge multiple backups (Synthetic Backup or Consolidation) -Item 4: Implement Catalog directive for Pool resource in Director -Item 5: Add an item to the restore option where you can select a Pool -Item 8: Implement Copy pools -Item 12: Add Plug-ins to the FileSet Include statements. -Item 13: Restore only file attributes (permissions, ACL, owner, group...) -Item 18: Better control over Job execution -Item 26: Store and restore extended attributes, especially selinux file contexts -Item 27: make changing "spooldata=yes|no" possible for -Item 28: Implement an option to modify the last written date for volumes - -Summary: -Item 2: Allow FD to initiate a backup -Item 6: Deletion of disk Volumes when pruned -Item 7: Implement Base jobs -Item 9: Scheduling syntax that permits more flexibility and options -Item 10: Message mailing based on backup types -Item 11: Cause daemons to use a specific IP address to source communications -Item 14: Add an override in Schedule for Pools based on backup types -Item 15: Implement more Python events and functions --- Abandoned for plugins -Item 16: Allow inclusion/exclusion of files in a fileset by creation/mod times -Item 17: Automatic promotion of backup levels based on backup size -Item 19: Automatic disabling of devices -Item 20: An option to operate on all pools with update vol parameters -Item 21: Include timestamp of job launch in "stat clients" output -Item 22: Implement Storage daemon compression -Item 23: Improve Bacula's tape and drive usage and cleaning management -Item 24: Multiple threads in file daemon for the same job -Item 25: Archival (removal) of User Files to Tape - - -Item 1: Accurate restoration of renamed/deleted files - Date: 28 November 2005 - Origin: Martin Simmons (martin at lispworks dot com) - Status: Done - - What: When restoring a fileset for a specified date (including "most - recent"), Bacula should give you exactly the files and directories - that existed at the time of the last backup prior to that date. - - Currently this only works if the last backup was a Full backup. - When the last backup was Incremental/Differential, files and - directories that have been renamed or deleted since the last Full - backup are not currently restored correctly. Ditto for files with - extra/fewer hard links than at the time of the last Full backup. - - Why: Incremental/Differential would be much more useful if this worked. - - Notes: Merging of multiple backups into a single one seems to - rely on this working, otherwise the merged backups will not be - truly equivalent to a Full backup. - - Note: Kern: notes shortened. This can be done without the need for - inodes. It is essentially the same as the current Verify job, - but one additional database record must be written, which does - not need any database change. - - Notes: Kern: see if we can correct restoration of directories if - replace=ifnewer is set. Currently, if the directory does not - exist, a "dummy" directory is created, then when all the files - are updated, the dummy directory is newer so the real values - are not updated. - -Item 2: Allow FD to initiate a backup - Origin: Frank Volf (frank at deze dot org) - Date: 17 November 2005 - Status: - - What: Provide some means, possibly by a restricted console that - allows a FD to initiate a backup, and that uses the connection - established by the FD to the Director for the backup so that - a Director that is firewalled can do the backup. - - Why: Makes backup of laptops much easier. - - -Item 3: Merge multiple backups (Synthetic Backup or Consolidation) - Origin: Marc Cousin and Eric Bollengier - Date: 15 November 2005 - Status: Done - - What: A merged backup is a backup made without connecting to the Client. - It would be a Merge of existing backups into a single backup. - In effect, it is like a restore but to the backup medium. - - For instance, say that last Sunday we made a full backup. Then - all week long, we created incremental backups, in order to do - them fast. Now comes Sunday again, and we need another full. - The merged backup makes it possible to do instead an incremental - backup (during the night for instance), and then create a merged - backup during the day, by using the full and incrementals from - the week. The merged backup will be exactly like a full made - Sunday night on the tape, but the production interruption on the - Client will be minimal, as the Client will only have to send - incrementals. - - In fact, if it's done correctly, you could merge all the - Incrementals into single Incremental, or all the Incrementals - and the last Differential into a new Differential, or the Full, - last differential and all the Incrementals into a new Full - backup. And there is no need to involve the Client. - - Why: The benefit is that : - - the Client just does an incremental ; - - the merged backup on tape is just as a single full backup, - and can be restored very fast. - - This is also a way of reducing the backup data since the old - data can then be pruned (or not) from the catalog, possibly - allowing older volumes to be recycled - -Item 4: Implement Catalog directive for Pool resource in Director - Origin: Alan Davis adavis@ruckus.com - Date: 6 March 2007 - Status: Done, but not tested, and possibly not fully implemented. - - What: The current behavior is for the director to create all pools - found in the configuration file in all catalogs. Add a - Catalog directive to the Pool resource to specify which - catalog to use for each pool definition. - - Why: This allows different catalogs to have different pool - attributes and eliminates the side-effect of adding - pools to catalogs that don't need/use them. - - Notes: Kern: I think this is relatively easy to do, and it is really - a pre-requisite to a number of the Copy pool, ... projects - that are listed here. - -Item 5: Add an item to the restore option where you can select a Pool - Origin: kshatriyak at gmail dot com - Date: 1/1/2006 - Status: Done at least via command line - - What: In the restore option (Select the most recent backup for a - client) it would be useful to add an option where you can limit - the selection to a certain pool. - - Why: When using cloned jobs, most of the time you have 2 pools - a - disk pool and a tape pool. People who have 2 pools would like to - select the most recent backup from disk, not from tape (tape - would be only needed in emergency). However, the most recent - backup (which may just differ a second from the disk backup) may - be on tape and would be selected. The problem becomes bigger if - you have a full and differential - the most "recent" full backup - may be on disk, while the most recent differential may be on tape - (though the differential on disk may differ even only a second or - so). Bacula will complain that the backups reside on different - media then. For now the only solution now when restoring things - when you have 2 pools is to manually search for the right - job-id's and enter them by hand, which is a bit fault tolerant. - - Notes: Kern: This is a nice idea. It could also be the way to support - Jobs that have been Copied (similar to migration, but not yet - implemented). - - - -Item 6: Deletion of disk Volumes when pruned - Date: Nov 25, 2005 - Origin: Ross Boylan (edited - by Kern) - Status: - - 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: 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: - - Volume Data Retention =