- Why: It would be a significant change to the structure of the
- directives, but allows for a lot more flexibility, including
- RunAfter commands that will run regardless of whether the job
- succeeds, or RunBefore tasks that still allow the job to run even
- if that specific RunBefore fails.
-
- Notes: (More notes from Phil, Kern, David and Eric)
- I would prefer to have a single new Resource called
- RunScript.
-
- RunsWhen = After|Before|Always
- RunsAtJobLevels = All|Full|Diff|Inc # not yet implemented
-
- The AbortJobOnError, RunsOnSuccess and RunsOnFailure directives
- could be optional, and possibly RunWhen as well.
-
- AbortJobOnError would be ignored unless RunsWhen was set to Before
- and would default to Yes if omitted.
- If AbortJobOnError was set to No, failure of the script
- would still generate a warning.
-
- RunsOnSuccess would be ignored unless RunsWhen was set to After
- (or RunsBeforeJob set to No), and default to Yes.
-
- RunsOnFailure would be ignored unless RunsWhen was set to After,
- and default to No.
-
- Allow having the before/after status on the script command
- line so that the same script can be used both before/after.
-
-Item 10: Merge multiple backups (Synthetic Backup or Consolidation).
- Origin: Marc Cousin and Eric Bollengier
- Date: 15 November 2005
- Status: Waiting implementation. Depends on first implementing
- project Item 2 (Migration).
-
- 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 11: Deletion of Disk-Based Bacula Volumes
- Date: Nov 25, 2005
- Origin: Ross Boylan <RossBoylan at stanfordalumni dot org> (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 = <time period>
- Remove Volume After = <time period>
-
- The migration project should also remove a Volume that is
- migrated. This might also work for tape Volumes.
-
-Item 12: Directive/mode to backup only file changes, not entire file
- Date: 11 November 2005
- Origin: Joshua Kugler <joshua dot kugler at uaf dot edu>
- Marek Bajon <mbajon at bimsplus dot com dot pl>
- Status:
-
- What: Currently when a file changes, the entire file will be backed up in
- the next incremental or full backup. To save space on the tapes
- it would be nice to have a mode whereby only the changes to the
- file would be backed up when it is changed.
-
- Why: This would save lots of space when backing up large files such as
- logs, mbox files, Outlook PST files and the like.
-
- Notes: This would require the usage of disk-based volumes as comparing
- files would not be feasible using a tape drive.
-
-Item 13: Multiple threads in file daemon for the same job
- Date: 27 November 2005
- Origin: Ove Risberg (Ove.Risberg at octocode dot com)
- Status:
-
- What: I want the file daemon to start multiple threads for a backup
- job so the fastest possible backup can be made.
-
- The file daemon could parse the FileSet information and start
- one thread for each File entry located on a separate
- filesystem.
-
- A configuration option in the job section should be used to
- enable or disable this feature. The configuration option could
- specify the maximum number of threads in the file daemon.
-
- If the theads could spool the data to separate spool files
- the restore process will not be much slower.
-
- Why: Multiple concurrent backups of a large fileserver with many
- disks and controllers will be much faster.
-
- Notes: I am willing to try to implement this but I will probably
- need some help and advice. (No problem -- Kern)
-
-Item 14: Implement red/black binary tree routines.
- Date: 28 October 2005
- Origin: Kern
- Status: Class code is complete. Code needs to be integrated into
- restore tree code.
-
- What: Implement a red/black binary tree class. This could
- then replace the current binary insert/search routines
- used in the restore in memory tree. This could significantly
- speed up the creation of the in memory restore tree.
-
- Why: Performance enhancement.
-
-Item 15: Add support for FileSets in user directories CACHEDIR.TAG
- Origin: Norbert Kiesel <nkiesel at tbdnetworks dot com>
- Date: 21 November 2005
- Status: (I think this is better done using a Python event that I
- will implement in version 1.39.x).
-
- What: CACHDIR.TAG is a proposal for identifying directories which
- should be ignored for archiving/backup. It works by ignoring
- directory trees which have a file named CACHEDIR.TAG with a
- specific content. See
- http://www.brynosaurus.com/cachedir/spec.html
- for details.
-
- From Peter Eriksson:
- I suggest that if this is implemented (I've also asked for this
- feature some year ago) that it is made compatible with Legato
- Networkers ".nsr" files where you can specify a lot of options on
- how to handle files/directories (including denying further
- parsing of .nsr files lower down into the directory trees). A
- PDF version of the .nsr man page can be viewed at:
-
- http://www.ifm.liu.se/~peter/nsr.pdf
-
- Why: It's a nice alternative to "exclude" patterns for directories
- which don't have regular pathnames. Also, it allows users to
- control backup for themselves. Implementation should be pretty
- simple. GNU tar >= 1.14 or so supports it, too.
-
- Notes: I envision this as an optional feature to a fileset
- specification.
-
-
-Item 16: Implement extraction of Win32 BackupWrite data.
- Origin: Thorsten Engel <thorsten.engel at matrix-computer dot com>
- Date: 28 October 2005
- Status: Done. Assigned to Thorsten. Implemented in current CVS
-
- What: This provides the Bacula File daemon with code that
- can pick apart the stream output that Microsoft writes
- for BackupWrite data, and thus the data can be read
- and restored on non-Win32 machines.
-
- Why: BackupWrite data is the portable=no option in Win32
- FileSets, and in previous Baculas, this data could
- only be extracted using a Win32 FD. With this new code,
- the Windows data can be extracted and restored on
- any OS.
-
-
-Item 18: Implement a Python interface to the Bacula catalog.
- Date: 28 October 2005
- Origin: Kern
- Status:
-
- What: Implement an interface for Python scripts to access
- the catalog through Bacula.
-
- Why: This will permit users to customize Bacula through
- Python scripts.
-
-Item 18: Archival (removal) of User Files to Tape
-