3 Bacula Projects Roadmap
5 (prioritized by user vote)
8 Item 1: Implement data encryption (as opposed to comm encryption)
9 Item 2: Implement Migration that moves Jobs from one Pool to another.
10 Item 3: Accurate restoration of renamed/deleted files from
11 Item 4: Implement a Bacula GUI/management tool using Python.
12 Item 5: Implement Base jobs.
13 Item 6: Allow FD to initiate a backup
14 Item 7: Improve Bacula's tape and drive usage and cleaning management.
15 Item 8: Implement creation and maintenance of copy pools
16 Item 9: Implement new {Client}Run{Before|After}Job feature.
17 Item 10: Merge multiple backups (Synthetic Backup or Consolidation).
18 Item 11: Deletion of Disk-Based Bacula Volumes
19 Item 12: Directive/mode to backup only file changes, not entire file
20 Item 13: Multiple threads in file daemon for the same job
21 Item 14: Implement red/black binary tree routines.
22 Item 15: Add support for FileSets in user directories CACHEDIR.TAG
23 Item 16: Implement extraction of Win32 BackupWrite data.
24 Item 17: Implement a Python interface to the Bacula catalog.
25 Item 18: Archival (removal) of User Files to Tape
26 Item 19: Add Plug-ins to the FileSet Include statements.
27 Item 20: Implement more Python events in Bacula.
28 Item 21: Quick release of FD-SD connection after backup.
29 Item 22: Permit multiple Media Types in an Autochanger
30 Item 23: Allow different autochanger definitions for one autochanger.
31 Item 24: Automatic disabling of devices
32 Item 25: Implement huge exclude list support using hashing.
35 Below, you will find more information on future projects:
37 Item 1: Implement data encryption (as opposed to comm encryption)
39 Origin: Sponsored by Landon and 13 contributors to EFF.
40 Status: Landon Fuller is currently implementing this.
42 What: Currently the data that is stored on the Volume is not
43 encrypted. For confidentiality, encryption of data at
44 the File daemon level is essential.
45 Data encryption encrypts the data in the File daemon and
46 decrypts the data in the File daemon during a restore.
48 Why: Large sites require this.
50 Item 2: Implement Migration that moves Jobs from one Pool to another.
51 Origin: Sponsored by Riege Software International GmbH. Contact:
52 Daniel Holtkamp <holtkamp at riege dot com>
54 Status: Partially coded in 1.37 -- much more to do. Assigned to
57 What: The ability to copy, move, or archive data that is on a
58 device to another device is very important.
60 Why: An ISP might want to backup to disk, but after 30 days
61 migrate the data to tape backup and delete it from
62 disk. Bacula should be able to handle this
63 automatically. It needs to know what was put where,
64 and when, and what to migrate -- it is a bit like
65 retention periods. Doing so would allow space to be
66 freed up for current backups while maintaining older
69 Notes: Riege Software have asked for the following migration
72 Highwater mark (stopped by Lowwater mark?)
74 Notes: Migration could be additionally triggered by:
78 Item 3: Accurate restoration of renamed/deleted files from
79 Incremental/Differential backups
80 Date: 28 November 2005
81 Origin: Martin Simmons (martin at lispworks dot com)
84 What: When restoring a fileset for a specified date (including "most
85 recent"), Bacula should give you exactly the files and directories
86 that existed at the time of the last backup prior to that date.
88 Currently this only works if the last backup was a Full backup.
89 When the last backup was Incremental/Differential, files and
90 directories that have been renamed or deleted since the last Full
91 backup are not currently restored correctly. Ditto for files with
92 extra/fewer hard links than at the time of the last Full backup.
94 Why: Incremental/Differential would be much more useful if this worked.
96 Notes: Item 14 (Merging of multiple backups into a single one) seems to
97 rely on this working, otherwise the merged backups will not be
98 truly equivalent to a Full backup.
100 Kern: notes shortened. This can be done without the need for
101 inodes. It is essentially the same as the current Verify job,
102 but one additional database record must be written, which does
103 not need any database change.
105 Item 4: Implement a Bacula GUI/management tool using Python.
107 Date: 28 October 2005
110 What: Implement a Bacula console, and management tools
111 using Python and Qt or GTK.
113 Why: Don't we already have a wxWidgets GUI? Yes, but
114 it is written in C++ and changes to the user interface
115 must be hand tailored using C++ code. By developing
116 the user interface using Qt designer, the interface
117 can be very easily updated and most of the new Python
118 code will be automatically created. The user interface
119 changes become very simple, and only the new features
120 must be implement. In addition, the code will be in
121 Python, which will give many more users easy (or easier)
122 access to making additions or modifications.
124 Notes: This is currently being implemented using Python-GTK by
125 Lucas Di Pentima <lucas at lunix dot com dot ar>
127 Item 5: Implement Base jobs.
128 Date: 28 October 2005
132 What: A base job is sort of like a Full save except that you
133 will want the FileSet to contain only files that are
134 unlikely to change in the future (i.e. a snapshot of
135 most of your system after installing it). After the
136 base job has been run, when you are doing a Full save,
137 you specify one or more Base jobs to be used. All
138 files that have been backed up in the Base job/jobs but
139 not modified will then be excluded from the backup.
140 During a restore, the Base jobs will be automatically
141 pulled in where necessary.
143 Why: This is something none of the competition does, as far as
144 we know (except perhaps BackupPC, which is a Perl program that
145 saves to disk only). It is big win for the user, it
146 makes Bacula stand out as offering a unique
147 optimization that immediately saves time and money.
148 Basically, imagine that you have 100 nearly identical
149 Windows or Linux machine containing the OS and user
150 files. Now for the OS part, a Base job will be backed
151 up once, and rather than making 100 copies of the OS,
152 there will be only one. If one or more of the systems
153 have some files updated, no problem, they will be
154 automatically restored.
156 Notes: Huge savings in tape usage even for a single machine.
157 Will require more resources because the DIR must send
158 FD a list of files/attribs, and the FD must search the
159 list and compare it for each file to be saved.
161 Item 6: Allow FD to initiate a backup
162 Origin: Frank Volf (frank at deze dot org)
163 Date: 17 November 2005
166 What: Provide some means, possibly by a restricted console that
167 allows a FD to initiate a backup, and that uses the connection
168 established by the FD to the Director for the backup so that
169 a Director that is firewalled can do the backup.
171 Why: Makes backup of laptops much easier.
173 Item 7: Improve Bacula's tape and drive usage and cleaning management.
174 Date: 8 November 2005, November 11, 2005
175 Origin: Adam Thornton <athornton at sinenomine dot net>,
176 Arno Lehmann <al at its-lehmann dot de>
179 What: Make Bacula manage tape life cycle information, tape reuse
180 times and drive cleaning cycles.
182 Why: All three parts of this project are important when operating
184 We need to know which tapes need replacement, and we need to
185 make sure the drives are cleaned when necessary. While many
186 tape libraries and even autoloaders can handle all this
187 automatically, support by Bacula can be helpful for smaller
188 (older) libraries and single drives. Limiting the number of
189 times a tape is used might prevent tape errors when using
190 tapes until the drives can't read it any more. Also, checking
191 drive status during operation can prevent some failures (as I
192 [Arno] had to learn the hard way...)
194 Notes: First, Bacula could (and even does, to some limited extent)
195 record tape and drive usage. For tapes, the number of mounts,
196 the amount of data, and the time the tape has actually been
197 running could be recorded. Data fields for Read and Write
198 time and Number of mounts already exist in the catalog (I'm
199 not sure if VolBytes is the sum of all bytes ever written to
200 that volume by Bacula). This information can be important
201 when determining which media to replace. The ability to mark
202 Volumes as "used up" after a given number of write cycles
203 should also be implemented so that a tape is never actually
204 worn out. For the tape drives known to Bacula, similar
205 information is interesting to determine the device status and
206 expected life time: Time it's been Reading and Writing, number
207 of tape Loads / Unloads / Errors. This information is not yet
208 recorded as far as I [Arno] know. A new volume status would
209 be necessary for the new state, like "Used up" or "Worn out".
210 Volumes with this state could be used for restores, but not
211 for writing. These volumes should be migrated first (assuming
212 migration is implemented) and, once they are no longer needed,
213 could be moved to a Trash pool.
215 The next step would be to implement a drive cleaning setup.
216 Bacula already has knowledge about cleaning tapes. Once it
217 has some information about cleaning cycles (measured in drive
218 run time, number of tapes used, or calender days, for example)
219 it can automatically execute tape cleaning (with an
220 autochanger, obviously) or ask for operator assistance loading
223 The final step would be to implement TAPEALERT checks not only
224 when changing tapes and only sending the information to the
225 administrator, but rather checking after each tape error,
226 checking on a regular basis (for example after each tape
227 file), and also before unloading and after loading a new tape.
228 Then, depending on the drives TAPEALERT state and the known
229 drive cleaning state Bacula could automatically schedule later
230 cleaning, clean immediately, or inform the operator.
232 Implementing this would perhaps require another catalog change
233 and perhaps major changes in SD code and the DIR-SD protocol,
234 so I'd only consider this worth implementing if it would
235 actually be used or even needed by many people.
237 Implementation of these projects could happen in three distinct
238 sub-projects: Measuring Tape and Drive usage, retiring
239 volumes, and handling drive cleaning and TAPEALERTs.
241 Item 8: Implement creation and maintenance of copy pools
242 Date: 27 November 2005
243 Origin: David Boyes (dboyes at sinenomine dot net)
246 What: I would like Bacula to have the capability to write copies
247 of backed-up data on multiple physical volumes selected
248 from different pools without transferring the data
249 multiple times, and to accept any of the copy volumes
250 as valid for restore.
252 Why: In many cases, businesses are required to keep offsite
253 copies of backup volumes, or just wish for simple
254 protection against a human operator dropping a storage
255 volume and damaging it. The ability to generate multiple
256 volumes in the course of a single backup job allows
257 customers to simple check out one copy and send it
258 offsite, marking it as out of changer or otherwise
259 unavailable. Currently, the library and magazine
260 management capability in Bacula does not make this process
263 Restores would use the copy of the data on the first
264 available volume, in order of copy pool chain definition.
266 This is also a major scalability issue -- as the number of
267 clients increases beyond several thousand, and the volume
268 of data increases, transferring the data multiple times to
269 produce additional copies of the backups will become
270 physically impossible due to transfer speed
271 issues. Generating multiple copies at server side will
272 become the only practical option.
274 How: I suspect that this will require adding a multiplexing
275 SD that appears to be a SD to a specific FD, but 1-n FDs
276 to the specific back end SDs managing the primary and copy
277 pools. Storage pools will also need to acquire parameters
278 to define the pools to be used for copies.
280 Notes: I would commit some of my developers' time if we can agree
281 on the design and behavior.
283 Item 9: Implement new {Client}Run{Before|After}Job feature.
284 Date: 26 September 2005
285 Origin: Phil Stracchino <phil.stracchino at speakeasy dot net>
288 What: Some time ago, there was a discussion of RunAfterJob and
289 ClientRunAfterJob, and the fact that they do not run after failed
290 jobs. At the time, there was a suggestion to add a
291 RunAfterFailedJob directive (and, presumably, a matching
292 ClientRunAfterFailedJob directive), but to my knowledge these
293 were never implemented.
295 An alternate way of approaching the problem has just occurred to
296 me. Suppose the RunBeforeJob and RunAfterJob directives were
297 expanded in a manner something like this example:
300 Command = "/opt/bacula/etc/checkhost %c"
302 RunsAtJobLevels = All # All, Full, Diff, Inc
303 AbortJobOnError = Yes
306 Command = c:/bacula/systemstate.bat
308 RunsAtJobLevels = All # All, Full, Diff, Inc
313 Command = c:/bacula/deletestatefile.bat
315 RunsAtJobLevels = All # All, Full, Diff, Inc
320 Command = c:/bacula/somethingelse.bat
322 RunsAtJobLevels = All
327 Command = "/opt/bacula/etc/checkhost -v %c"
329 RunsAtJobLevels = All
335 Why: It would be a significant change to the structure of the
336 directives, but allows for a lot more flexibility, including
337 RunAfter commands that will run regardless of whether the job
338 succeeds, or RunBefore tasks that still allow the job to run even
339 if that specific RunBefore fails.
341 Notes: By Kern: I would prefer to have a single new Resource called
342 RunScript. More notes from Phil:
344 RunBeforeJob = yes|no
346 RunsAtJobLevels = All|Full|Diff|Inc
348 The AbortJobOnError, RunsOnSuccess and RunsOnFailure directives
349 could be optional, and possibly RunsWhen as well.
351 AbortJobOnError would be ignored unless RunsWhen was set to Before
352 (or RunsBefore Job set to Yes), and would default to Yes if
353 omitted. If AbortJobOnError was set to No, failure of the script
354 would still generate a warning.
356 RunsOnSuccess would be ignored unless RunsWhen was set to After
357 (or RunsBeforeJob set to No), and default to Yes.
359 RunsOnFailure would be ignored unless RunsWhen was set to After,
362 Allow having the before/after status on the script command
363 line so that the same script can be used both before/after.
366 Item 10: Merge multiple backups (Synthetic Backup or Consolidation).
367 Origin: Marc Cousin and Eric Bollengier
368 Date: 15 November 2005
369 Status: Depends on first implementing project Item 1 (Migration).
371 What: A merged backup is a backup made without connecting to the Client.
372 It would be a Merge of existing backups into a single backup.
373 In effect, it is like a restore but to the backup medium.
375 For instance, say that last Sunday we made a full backup. Then
376 all week long, we created incremental backups, in order to do
377 them fast. Now comes Sunday again, and we need another full.
378 The merged backup makes it possible to do instead an incremental
379 backup (during the night for instance), and then create a merged
380 backup during the day, by using the full and incrementals from
381 the week. The merged backup will be exactly like a full made
382 Sunday night on the tape, but the production interruption on the
383 Client will be minimal, as the Client will only have to send
386 In fact, if it's done correctly, you could merge all the
387 Incrementals into single Incremental, or all the Incrementals
388 and the last Differential into a new Differential, or the Full,
389 last differential and all the Incrementals into a new Full
390 backup. And there is no need to involve the Client.
392 Why: The benefit is that :
393 - the Client just does an incremental ;
394 - the merged backup on tape is just as a single full backup,
395 and can be restored very fast.
397 This is also a way of reducing the backup data since the old
398 data can then be pruned (or not) from the catalog, possibly
399 allowing older volumes to be recycled
401 Item 11: Deletion of Disk-Based Bacula Volumes
403 Origin: Ross Boylan <RossBoylan at stanfordalumni dot org> (edited
407 What: Provide a way for Bacula to automatically remove Volumes
408 from the filesystem, or optionally to truncate them.
409 Obviously, the Volume must be pruned prior removal.
411 Why: This would allow users more control over their Volumes and
412 prevent disk based volumes from consuming too much space.
414 Notes: The following two directives might do the trick:
416 Volume Data Retention = <time period>
417 Remove Volume After = <time period>
419 The migration project should also remove a Volume that is
420 migrated. This might also work for tape Volumes.
422 Item 12: Directive/mode to backup only file changes, not entire file
423 Date: 11 November 2005
424 Origin: Joshua Kugler <joshua dot kugler at uaf dot edu>
425 Marek Bajon <mbajon at bimsplus dot com dot pl>
428 What: Currently when a file changes, the entire file will be backed up in
429 the next incremental or full backup. To save space on the tapes
430 it would be nice to have a mode whereby only the changes to the
431 file would be backed up when it is changed.
433 Why: This would save lots of space when backing up large files such as
434 logs, mbox files, Outlook PST files and the like.
436 Notes: This would require the usage of disk-based volumes as comparing
437 files would not be feasible using a tape drive.
439 Item 13: Multiple threads in file daemon for the same job
440 Date: 27 November 2005
441 Origin: Ove Risberg (Ove.Risberg at octocode dot com)
444 What: I want the file daemon to start multiple threads for a backup
445 job so the fastest possible backup can be made.
447 The file daemon could parse the FileSet information and start
448 one thread for each File entry located on a separate
451 A configuration option in the job section should be used to
452 enable or disable this feature. The configuration option could
453 specify the maximum number of threads in the file daemon.
455 If the theads could spool the data to separate spool files
456 the restore process will not be much slower.
458 Why: Multiple concurrent backups of a large fileserver with many
459 disks and controllers will be much faster.
461 Notes: I am willing to try to implement this but I will probably
462 need some help and advice. (No problem -- Kern)
464 Item 14: Implement red/black binary tree routines.
465 Date: 28 October 2005
469 What: Implement a red/black binary tree class. This could
470 then replace the current binary insert/search routines
471 used in the restore in memory tree. This could significantly
472 speed up the creation of the in memory restore tree.
474 Why: Performance enhancement.
476 Item 15: Add support for FileSets in user directories CACHEDIR.TAG
477 Origin: Norbert Kiesel <nkiesel at tbdnetworks dot com>
478 Date: 21 November 2005
481 What: CACHDIR.TAG is a proposal for identifying directories which
482 should be ignored for archiving/backup. It works by ignoring
483 directory trees which have a file named CACHEDIR.TAG with a
484 specific content. See
485 http://www.brynosaurus.com/cachedir/spec.html
489 I suggest that if this is implemented (I've also asked for this
490 feature some year ago) that it is made compatible with Legato
491 Networkers ".nsr" files where you can specify a lot of options on
492 how to handle files/directories (including denying further
493 parsing of .nsr files lower down into the directory trees). A
494 PDF version of the .nsr man page can be viewed at:
496 http://www.ifm.liu.se/~peter/nsr.pdf
498 Why: It's a nice alternative to "exclude" patterns for directories
499 which don't have regular pathnames. Also, it allows users to
500 control backup for themselves. Implementation should be pretty
501 simple. GNU tar >= 1.14 or so supports it, too.
503 Notes: I envision this as an optional feature to a fileset
507 Item 16: Implement extraction of Win32 BackupWrite data.
508 Origin: Thorsten Engel <thorsten.engel at matrix-computer dot com>
509 Date: 28 October 2005
510 Status: Assigned to Thorsten. Implemented in current CVS
512 What: This provides the Bacula File daemon with code that
513 can pick apart the stream output that Microsoft writes
514 for BackupWrite data, and thus the data can be read
515 and restored on non-Win32 machines.
517 Why: BackupWrite data is the portable=no option in Win32
518 FileSets, and in previous Baculas, this data could
519 only be extracted using a Win32 FD. With this new code,
520 the Windows data can be extracted and restored on
524 Item 18: Implement a Python interface to the Bacula catalog.
525 Date: 28 October 2005
529 What: Implement an interface for Python scripts to access
530 the catalog through Bacula.
532 Why: This will permit users to customize Bacula through
535 Item 18: Archival (removal) of User Files to Tape
539 Origin: Ray Pengelly [ray at biomed dot queensu dot ca
542 What: The ability to archive data to storage based on certain parameters
543 such as age, size, or location. Once the data has been written to
544 storage and logged it is then pruned from the originating
545 filesystem. Note! We are talking about user's files and not
548 Why: This would allow fully automatic storage management which becomes
549 useful for large datastores. It would also allow for auto-staging
550 from one media type to another.
552 Example 1) Medical imaging needs to store large amounts of data.
553 They decide to keep data on their servers for 6 months and then put
554 it away for long term storage. The server then finds all files
555 older than 6 months writes them to tape. The files are then removed
558 Example 2) All data that hasn't been accessed in 2 months could be
559 moved from high-cost, fibre-channel disk storage to a low-cost
560 large-capacity SATA disk storage pool which doesn't have as quick of
561 access time. Then after another 6 months (or possibly as one
562 storage pool gets full) data is migrated to Tape.
564 Item 19: Add Plug-ins to the FileSet Include statements.
565 Date: 28 October 2005
567 Status: Partially coded in 1.37 -- much more to do.
569 What: Allow users to specify wild-card and/or regular
570 expressions to be matched in both the Include and
571 Exclude directives in a FileSet. At the same time,
572 allow users to define plug-ins to be called (based on
573 regular expression/wild-card matching).
575 Why: This would give the users the ultimate ability to control
576 how files are backed up/restored. A user could write a
577 plug-in knows how to backup his Oracle database without
578 stopping/starting it, for example.
580 Item 20: Implement more Python events in Bacula.
581 Date: 28 October 2005
585 What: Allow Python scripts to be called at more places
586 within Bacula and provide additional access to Bacula
589 Why: This will permit users to customize Bacula through
597 Also add a way to get a listing of currently running
598 jobs (possibly also scheduled jobs).
601 Item 21: Quick release of FD-SD connection after backup.
602 Origin: Frank Volf (frank at deze dot org)
603 Date: 17 November 2005
606 What: In the Bacula implementation a backup is finished after all data
607 and attributes are successfully written to storage. When using a
608 tape backup it is very annoying that a backup can take a day,
609 simply because the current tape (or whatever) is full and the
610 administrator has not put a new one in. During that time the
611 system cannot be taken off-line, because there is still an open
612 session between the storage daemon and the file daemon on the
615 Although this is a very good strategy for making "safe backups"
616 This can be annoying for e.g. laptops, that must remain
617 connected until the backup is completed.
619 Using a new feature called "migration" it will be possible to
620 spool first to harddisk (using a special 'spool' migration
621 scheme) and then migrate the backup to tape.
623 There is still the problem of getting the attributes committed.
624 If it takes a very long time to do, with the current code, the
625 job has not terminated, and the File daemon is not freed up. The
626 Storage daemon should release the File daemon as soon as all the
627 file data and all the attributes have been sent to it (the SD).
628 Currently the SD waits until everything is on tape and all the
629 attributes are transmitted to the Director before signaling
630 completion to the FD. I don't think I would have any problem
631 changing this. The reason is that even if the FD reports back to
632 the Dir that all is OK, the job will not terminate until the SD
633 has done the same thing -- so in a way keeping the SD-FD link
634 open to the very end is not really very productive ...
636 Why: Makes backup of laptops much easier.
638 Item 22: Permit multiple Media Types in an Autochanger
640 Status: Now implemented
642 What: Modify the Storage daemon so that multiple Media Types
643 can be specified in an autochanger. This would be somewhat
644 of a simplistic implementation in that each drive would
645 still be allowed to have only one Media Type. However,
646 the Storage daemon will ensure that only a drive with
647 the Media Type that matches what the Director specifies
650 Why: This will permit user with several different drive types
651 to make full use of their autochangers.
653 Item 23: Allow different autochanger definitions for one autochanger.
654 Date: 28 October 2005
658 What: Currently, the autochanger script is locked based on
659 the autochanger. That is, if multiple drives are being
660 simultaneously used, the Storage daemon ensures that only
661 one drive at a time can access the mtx-changer script.
662 This change would base the locking on the control device,
663 rather than the autochanger. It would then permit two autochanger
664 definitions for the same autochanger, but with different
665 drives. Logically, the autochanger could then be "partitioned"
666 for different jobs, clients, or class of jobs, and if the locking
667 is based on the control device (e.g. /dev/sg0) the mtx-changer
668 script will be locked appropriately.
670 Why: This will permit users to partition autochangers for specific
671 use. It would also permit implementation of multiple Media
672 Types with no changes to the Storage daemon.
674 Item 24: Automatic disabling of devices
676 Origin: Peter Eriksson <peter at ifm.liu dot se>
679 What: After a configurable amount of fatal errors with a tape drive
680 Bacula should automatically disable further use of a certain
681 tape drive. There should also be "disable"/"enable" commands in
684 Why: On a multi-drive jukebox there is a possibility of tape drives
685 going bad during large backups (needing a cleaning tape run,
686 tapes getting stuck). It would be advantageous if Bacula would
687 automatically disable further use of a problematic tape drive
688 after a configurable amount of errors has occurred.
690 An example: I have a multi-drive jukebox (6 drives, 380+ slots)
691 where tapes occasionally get stuck inside the drive. Bacula will
692 notice that the "mtx-changer" command will fail and then fail
693 any backup jobs trying to use that drive. However, it will still
694 keep on trying to run new jobs using that drive and fail -
695 forever, and thus failing lots and lots of jobs... Since we have
696 many drives Bacula could have just automatically disabled
697 further use of that drive and used one of the other ones
700 Item 25: Implement huge exclude list support using hashing.
701 Date: 28 October 2005
705 What: Allow users to specify very large exclude list (currently
706 more than about 1000 files is too many).
708 Why: This would give the users the ability to exclude all
709 files that are loaded with the OS (e.g. using rpms
710 or debs). If the user can restore the base OS from
711 CDs, there is no need to backup all those files. A
712 complete restore would be to restore the base OS, then
713 do a Bacula restore. By excluding the base OS files, the
714 backup set will be *much* smaller.
716 ===============================================
717 Not in Dec 2005 Vote:
718 Item n: Allow skipping execution of Jobs
719 Date: 29 November 2005
720 Origin: Florian Schnabel <florian.schnabel at docufy dot de>
723 What: An easy option to skip a certain job on a certain date.
724 Why: You could then easily skip tape backups on holidays. Especially
725 if you got no autochanger and can only fit one backup on a tape
726 that would be really handy, other jobs could proceed normally
727 and you won't get errors that way.
729 ============= Empty Feature Request form ===========
730 Item n: One line summary ...
732 Origin: Name and email of originator.
735 What: More detailed explanation ...
737 Why: Why it is important ...
739 Notes: Additional notes or features (omit if not used)
740 ============== End Feature Request form ==============