3 Bacula Projects Roadmap
6 Item 1: Implement Base jobs.
8 What: A base job is sort of like a Full save except that you
9 will want the FileSet to contain only files that are
10 unlikely to change in the future (i.e. a snapshot of
11 most of your system after installing it). After the
12 base job has been run, when you are doing a Full save,
13 you specify one or more Base jobs to be used. All
14 files that have been backed up in the Base job/jobs but
15 not modified will then be excluded from the backup.
16 During a restore, the Base jobs will be automatically
17 pulled in where necessary.
19 Why: This is something none of the competition does, as far as
20 we know (except BackupPC, which is a Perl program that
21 saves to disk only). It is big win for the user, it
22 makes Bacula stand out as offering a unique
23 optimization that immediately saves time and money.
24 Basically, imagine that you have 100 nearly identical
25 Windows or Linux machine containing the OS and user
26 files. Now for the OS part, a Base job will be backed
27 up once, and rather than making 100 copies of the OS,
28 there will be only one. If one or more of the systems
29 have some files updated, no problem, they will be
30 automatically restored.
32 Notes: Huge savings in tape usage even for a single machine.
33 Will require more resources because the DIR must send
34 FD a list of files/attribs, and the FD must search the
35 list and compare it for each file to be saved.
37 Item 2: Add Regular Expression Matching and Plug-ins to the
38 FileSet Include statements.
40 What: Allow users to specify wild-card and/or regular
41 expressions to be matched in both the Include and
42 Exclude directives in a FileSet. At the same time,
43 allow users to define plug-ins to be called (based on
44 regular expression/wild-card matching).
46 Why: This would give the users the ultimate ability to control
47 how files are backed up/restored. A user could write a
48 plug-in knows how to backup his Oracle database without
49 stopping/starting it, for example.
51 Item 3: Implement a Migration job type that will move the job
52 data from one device to another.
54 What: The ability to copy, move, or archive data that is on a
55 device to another device is very important.
57 Why: An ISP might want to backup to disk, but after 30 days
58 migrate the data to tape backup and delete it from
59 disk. Bacula should be able to handle this
60 automatically. It needs to know what was put where,
61 and when, and what to migrate -- it is a bit like
62 retention periods. Doing so would allow space to be
63 freed up for current backups while maintaining older
66 Notes: Migration could be triggered by:
70 Highwater size (keep total size)
74 Item 4: Embedded Perl Scripting (precursor to 5).
76 What: On a configuration parameter, embed the Perl language in
79 Why: The embedded Perl scripting can be called to implement
80 Events such as "Volume Name needed", "End of Tape",
81 "Tape at x% of rated capacity", "Job started",
82 "Job Ended", "Job error", ...
84 Notes: This needs Events.
87 Item 5: Implement Events
89 What: When a particular user defined Event occurs, call the
90 embedded Perl interpreter.
92 Why: This will provide the ultimate in user customization for
93 Bacula. Almost anything imaginable can be done if Events
94 are called at the appropriate place.
96 Notes: There is a certain amount of work to be done on how
97 the user defines or "registers" events.
100 Item 6: Multiple Storage Devices for a Single Job
102 What: Allow any Job to use more than one Storage device.
104 Why: With two devices, for example, the second device could
105 have the next backup tape pre-mounted reducing operator
106 intervention in the middle of the night.
109 Item 7: Backup a Single Job Simultaneously to Multiple Storage
112 What: Make two copies of the backup data at the same time.
114 Why: Large shops typically do this and then take one set of
115 backups off-site. Some design work it needed in how to
116 specify the type of backup (backup, archive, ...) for
121 Item 8: Break the one-to-one Relationship between a Job and a
122 Specific Storage Device (or Devices if #10 is implemented).
124 What: Allow a Job to simply specify one or more MediaType, and
125 the Storage daemon will select a device for it. In
126 fact, the user should be able to specify one or more
127 MediaType, Storage daemon, and/or device to be used.
129 Why: To allow more flexibility in large shops that have multiple
130 drives and/or multiple drives of different types.
133 Item 9: Implement data encryption (as opposed to communications
136 What: Currently the data that is stored on the Volume is not
137 encrypted. For confidentiality, encryption of data at
138 the File daemon level is essential. Note, communications
139 encryption encrypts the data when leaving the File daemon,
140 then decrypts the data on entry to the Storage daemon.
141 Data encryption encrypts the data in the File daemon and
142 decrypts the data in the File daemon during a restore.
144 Why: Large sites require this.
146 Notes: The only algorithm that is needed is AES.
147 http://csrc.nist.gov/CryptoToolkit/aes/
150 Item 10: New daemon communication protocol.
152 What: The current daemon to daemon protocol is basically an ASCII
153 printf() and sending the buffer. On the receiving end, the
154 buffer is sscanf()ed to unpack it. The new scheme would
155 retain the current ASCII sending, but would add an
156 argc, argv like table driven scanner to replace sscanf.
158 Why: Named fields will permit error checking to ensure that
159 what is sent is what the receiver really wants. The
160 fields can be in any order and additional fields can be
161 ignored allowing better upward compatibility. Much
162 better checking of the types and values passed can be
165 Notes: These are internal improvements in the interest of the
166 long-term stability and evolution of the program. On
167 the one hand, the sooner they're done, the less code we
168 have to rip up when the time comes to install them. On
169 the other hand, they don't bring an immediately
170 perceptible benefit to potential users.
174 Completed items from last year's list:
175 Item 1: Multiple simultaneous Jobs. (done)
176 Item 3: Write the bscan program -- also write a bcopy program (done).
177 Item 5: Implement Label templates (done).
178 Item 6: Write a regression script (done)
179 Item 9: Add SSL to daemon communications (For now, implement with
181 Item 10: Define definitive tape format (done)
182 Item 3: GUI for interactive restore. Partially Implemented in 1.34
183 Note, there is now a complete Webmin plugin, a partial
184 GNOME console, and a partial wxWidgets console.
185 Item 4: GUI for interactive backup
186 Item 2: Job Data Spooling.