]> git.sur5r.net Git - bacula/bacula/blob - bacula/projects
Corrected cp commands in rpm spec file to preserve permissions.
[bacula/bacula] / bacula / projects
1                 
2 Projects:
3                      Bacula Projects Roadmap 
4                        22 February 2004
5
6 Item 1:   Implement Base jobs.
7
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 unlikely
10           to change in the future (i.e. a snapshot of most of your
11           system after installing it). After the base job has been run,
12           when you are doing a Full save, you specify one or more
13           Base jobs to be used. All files that have been backed up in  
14           the Base job/jobs but not modified will then be excluded from
15           the backup.  During a restore, the Base jobs will be
16           automatically pulled in where necessary.
17
18   Why:    This is something none of the competition does, as far as we
19 know
20           (except BackupPC, which is a Perl program that saves to disk
21           only).  It is big win for the user, it makes Bacula stand out
22           as offering a unique optimization that immediately saves time
23           and money. Basically, imagine that you have 100 nearly
24 identical
25           Windows or Linux machine containing the OS and user files.
26           Now for the OS part, a Base job will be backed up once, and 
27           rather than making 100 copies of the OS, there will be only
28           one. If one or more of the systems have some files updated,
29           no problem, they will be automatically restored.
30
31   Notes: Huge savings in tape usage even for a single machine.  Will
32           require more resources because the DIR must send FD a list of
33           files/attribs, and the FD must search the list and compare it
34           for each file to be saved.
35
36
37 Item 2:   Job Data Spooling.
38
39   What:   Make the Storage daemon use intermediate file storage to
40 buffer
41           the data to disk before writing it to the tape. 
42
43   Why:    This would be a nice project and is the most requested
44 feature.
45           Even though you may finish a client job quicker by spooling to
46           disk, you still have to eventually get it onto tape.  If
47           intermediate disk buffering allows us to improve write
48           bandwidth to tape, it may make sense. In addition, you can
49           run multiple simultaneous jobs all spool to disk, then the
50           data can be written one job at a time to the tape at full
51           tape speed. This keeps the tape running smoothly and prevents
52           blocks from different simultaneous jobs from being intermixed
53           on the tape, which is very inefficient for restores.
54
55   Notes:  Need multiple spool directories. Should possibly be able
56           to spool by Job type, ... Possibly need high and low spool
57           data levels.
58
59
60 Item 3:   GUI for interactive restore
61 Item 4:   GUI for interactive backup
62
63   What:   The current interactive restore is implemented with a tty
64           interface. It would be much nicer to be able to "see" the
65           list of files backed up in typical GUI tree format.
66           The same mechanism could also be used for creating 
67           ad-hoc backup FileSets (item 8).
68
69   Why:    Ease of use -- especially for the end user.
70
71   Notes:  Rather than implementing in Gtk, we probably should go
72 directly
73           for a Browser implementation, even if doing so meant the
74           capability wouldn't be available until much later.  Not only
75           is there the question of Windows sites, most
76           Solaris/HP/IRIX, etc,  shops can't currently run Gtk programs
77           without installing lots of stuff admins are very wary about.
78           Real sysadmins will always use the command line anyway, and
79           the user who's doing an interactive restore or backup of his
80           own files will in most cases be on a Windows machine running
81           Exploder.
82
83
84 Item 5:   Implement a Migration job type that will move the job
85           data from one device to another.
86
87   What:   The ability to copy, move, or archive data that is on a
88           device to another device is very important. 
89
90   Why:    An ISP might want to backup to disk, but after 30 days 
91           migrate the data to tape backup and delete it from disk.
92           Bacula should be able to handle this automatically. It needs
93 to
94           know what was put where, and when, and what to migrate -- it
95           is a bit like retention periods. Doing so would allow space to
96           be freed up for current backups while maintaining older data
97 on
98           tape drives.
99
100   Notes:  Migration could be triggered by:
101            Number of Jobs
102            Number of Volumes
103            Age of Jobs
104            Highwater size (keep total size)
105            Lowwater mark
106
107
108 Item 6:   Embedded Perl Scripting (precursor to 7).
109
110   What:   On a configuration parameter, embed the Perl language in
111           Bacula.
112
113   Why:    The embedded Perl scripting can be called to implement
114           Events such as "Volume Name needed", "End of Tape",
115           "Tape at x% of rated capacity", "Job started", 
116           "Job Ended", "Job error", ...
117
118   Notes:  This needs Events.
119
120
121 Item 7:   Implement Events (requires 6).
122
123   What:   When a particular user defined Event occurs, call the
124           embedded Perl interpreter.
125
126   Why:    This will provide the ultimate in user customization for
127           Bacula. Almost anything imaginable can be done if Events
128           are called at the appropriate place.
129
130   Notes:  There is a certain amount of work to be done on how
131           the user defines or "registers" events.
132
133
134 Item 8:   Multiple Storage Devices for a Single Job
135
136   What:   Allow any Job to use more than one Storage device.
137
138   Why:    With two devices, for example, the second device could
139           have the next backup tape pre-mounted reducing operator
140           intervention in the middle of the night.
141
142
143 Item  9:  Backup a Single Job Simultaneously to Multiple Storage 
144           Devices
145
146   What:   Make two copies of the backup data at the same time.
147
148   Why:    Large shops typically do this and then take one set of
149           backups off-site.  Some design work it needed in how to
150           specify the type of backup (backup, archive, ...) for each
151           Device.
152
153
154 Item 10:  Break the one-to-one Relationship between a Job and a
155           Specific Storage Device (or Devices if #10 is implemented).
156
157   What:   Allow a Job to simply specify one or more MediaType, and the
158           Storage daemon will select a device for it.  In fact, the user
159           should be able to specify one or more MediaType, Storage
160           daemon, and/or device to be used.
161
162   Why:    To allow more flexibility in large shops that have multiple 
163           drives and/or multiple drives of different types.
164
165
166 Item 11:  Add Regular Expression Matching and Plug-ins to the
167           FileSet Include statements.
168
169   What:   Allow users to specify wild-card and/or regular expressions
170           to be matched in both the Include and Exclude directives
171           in a FileSet. At the same time, allow users to define plug-ins
172           to be called (based on regular expression/wild-card matching).
173
174   Why:    This would give the users the ultimate ability to control how
175           files are backed up/restored. A user could write a plug-in 
176           knows how to backup his Oracle database without
177           stopping/starting it, for example.
178
179
180 Item 12:  Implement data encryption (as opposed to communications
181           encryption)
182
183   What:   Currently the data that is stored on the Volume is not
184           encrypted. For confidentiality, encryption of data at
185           the File daemon level is essential. Note, communications
186           encryption encrypts the data when leaving the File daemon,
187           then decrypts the data on entry to the Storage daemon.
188           Data encryption encrypts the data in the File daemon and
189           decrypts the data in the File daemon during a restore.
190
191   Why:    Large sites require this.
192
193   Notes:  The only algorithm that is needed is AES.
194           http://csrc.nist.gov/CryptoToolkit/aes/
195
196
197 Item 13:  New daemon communication protocol.
198
199   What:   The current daemon to daemon protocol is basically an ASCII
200           printf() and sending the buffer. On the receiving end, the
201           buffer is sscanf()ed to unpack it. The new scheme would
202           retain the current ASCII sending, but would add an 
203           argc, argv like table driven scanner to replace sscanf.
204
205   Why:    Named fields will permit error checking to ensure that what is
206           sent is what the receiver really wants. The fields can be in
207           any order and additional fields can be ignored allowing better
208           upward compatibility. Much better checking of the types and
209           values passed can be done.
210
211   Notes:  These are internal improvements in the interest of the
212           long-term stability and evolution of the program.  On the one
213           hand, the sooner they're done, the less code we have to rip
214           up when the time comes to install them.  On the other hand,
215           they don't bring an immediately perceptible benefit to
216           potential users. 
217
218
219 Completed items from last year's list:
220 Item 1:   Multiple simultaneous Jobs. (done)
221 Item 3:   Write the bscan program -- also write a bcopy program (done).
222 Item 5:   Implement Label templates (done).
223 Item 6:   Write a regression script (done)
224 Item 9:   Add SSL to daemon communications (For now, implement with
225 stunnel)
226 Item 10:  Define definitive tape format (done)