git.sur5r.net Git - bacula/bacula/blob - bacula/projects

   1
   2 Projects:
   3                      Bacula Projects Roadmap
   4                        23 April 2005
   5
   6 The following major projects are scheduled for 1.37:
   7 #3   Migration (Move, Copy, Archive Jobs)
   8 #4   Embedded Python Scripting (implemented in all Daemons)
   9 #5   Events that call a Python program (Implemented in all
  10        daemons, but more cleanup work to be done).
  11 #6   Select one from among Multiple Storage Devices for Job.
  12        This is already implemented in 1.37.
  13 #7   Single Job Writing to Multiple Storage Devices. This is
  14        currently implemented with a Clone feature.
  15 #-   Full multiple drive Autochanger support (mostly implemented).
  16 #-   We will have built in support for communications
  17        encryption (TLS) done by Landon Fuller.
  18 #    We will most likely have support for Unicode characters
  19        (via UTF-8) on Win32 machines thanks to Thorsten Engle.
  20
  21
  22 Below, you will find more information on those projects as
  23 well of other projects planned at a future time.
  24
  25 Item 1:   Implement Base jobs.
  26   Status: Voted by users not to be implemented in 1.37
  27
  28   What:   A base job is sort of like a Full save except that you
  29           will want the FileSet to contain only files that are
  30           unlikely to change in the future (i.e.  a snapshot of
  31           most of your system after installing it).  After the
  32           base job has been run, when you are doing a Full save,
  33           you specify one or more Base jobs to be used.  All
  34           files that have been backed up in the Base job/jobs but
  35           not modified will then be excluded from the backup.
  36           During a restore, the Base jobs will be automatically
  37           pulled in where necessary.
  38
  39   Why:    This is something none of the competition does, as far as
  40           we know (except BackupPC, which is a Perl program that
  41           saves to disk only).  It is big win for the user, it
  42           makes Bacula stand out as offering a unique
  43           optimization that immediately saves time and money.
  44           Basically, imagine that you have 100 nearly identical
  45           Windows or Linux machine containing the OS and user
  46           files.  Now for the OS part, a Base job will be backed
  47           up once, and rather than making 100 copies of the OS,
  48           there will be only one.  If one or more of the systems
  49           have some files updated, no problem, they will be
  50           automatically restored.
  51
  52   Notes:  Huge savings in tape usage even for a single machine.
  53           Will require more resources because the DIR must send
  54           FD a list of files/attribs, and the FD must search the
  55           list and compare it for each file to be saved.
  56
  57 Item 2:   Add Plug-ins to the FileSet Include statements.
  58   Status: In progress in 1.37 using Python scripting.
  59
  60   What:   Allow users to specify wild-card and/or regular
  61           expressions to be matched in both the Include and
  62           Exclude directives in a FileSet.  At the same time,
  63           allow users to define plug-ins to be called (based on
  64           regular expression/wild-card matching).
  65
  66   Why:    This would give the users the ultimate ability to control
  67           how files are backed up/restored.  A user could write a
  68           plug-in knows how to backup his Oracle database without
  69           stopping/starting it, for example.
  70
  71 Item 3:   Implement a Migration job type that will move the job
  72           data from one device to another.
  73   Status: Partially coded in 1.37 -- much more to do.
  74
  75   What:   The ability to copy, move, or archive data that is on a
  76           device to another device is very important.
  77
  78   Why:    An ISP might want to backup to disk, but after 30 days
  79           migrate the data to tape backup and delete it from
  80           disk.  Bacula should be able to handle this
  81           automatically.  It needs to know what was put where,
  82           and when, and what to migrate -- it is a bit like
  83           retention periods.  Doing so would allow space to be
  84           freed up for current backups while maintaining older
  85           data on tape drives.
  86
  87   Notes:  Migration could be triggered by:
  88            Number of Jobs
  89            Number of Volumes
  90            Age of Jobs
  91            Highwater size (keep total size)
  92            Lowwater mark
  93
  94
  95 Item 4:   Embedded Python Scripting (precursor to 5).
  96   Status: Implemented in 1.37 in all 3 daemons.
  97
  98   What:   On a configuration parameter, embed the Python language in
  99           Bacula.
 100
 101   Why:    The embedded Python scripting can be called to implement
 102           Events such as "Volume Name needed", "End of Tape",
 103           "Tape at x% of rated capacity", "Job started",
 104           "Job Ended", "Job error", ...
 105
 106   Notes:  This needs Events.
 107
 108
 109 Item 5:   Implement Events that call the scripting language.
 110   Status: Implemented in 1.37, but more events to complete and
 111           more work to be done to cleanup the implementation.
 112
 113   What:   When a particular user defined Event occurs, call the
 114           embedded Python interpreter.
 115
 116   Why:    This will provide the ultimate in user customization for
 117           Bacula. Almost anything imaginable can be done if Events
 118           are called at the appropriate place.
 119
 120   Notes:  There is a certain amount of work to be done on how
 121           the user defines or "registers" events.
 122
 123
 124 Item 6:   Multiple Storage Devices for a Single Job
 125   Status: This is already implemented in 1.37 (at least the
 126             initial selection of one from a number of storage
 127                         devices.
 128
 129   What:   Allow any Job to specify a number of storage devices,
 130           from which one will be used.
 131
 132   Why:    With two devices, for example, the second device could
 133           have the next backup tape pre-mounted reducing operator
 134           intervention in the middle of the night.
 135
 136
 137 Item 7:   Backup a Single Job Simultaneously to Multiple Storage Devices
 138   Status: This will probably not be done in 1.37. However, version
 139           1.37 has a job Cloning feature, which permits essentially
 140                   the same thing.
 141
 142   What:   Make two copies of the backup data at the same time.
 143
 144   Why:    Large shops typically do this and then take one set of
 145           backups off-site.  Some design work it needed in how to
 146           specify the type of backup (backup, archive, ...) for
 147           each Device.
 148
 149
 150
 151 Item  8:  Break the one-to-one Relationship between a Job and a
 152           Specific Storage Device (or Devices if #10 is implemented).
 153   Status: Mostly done in 1.37.
 154
 155   What:   Allow a Job to simply specify one or more MediaType, and
 156           the Storage daemon will select a device for it.  In
 157           fact, the user should be able to specify one or more
 158           MediaType, Storage daemon, and/or device to be used.
 159
 160   Why:    To allow more flexibility in large shops that have multiple
 161           drives and/or multiple drives of different types.
 162
 163
 164 Item  9:  Implement data encryption (as opposed to communications
 165           encryption)
 166   Status: Abel Menos expressed interest in this, but he is busy
 167           at work.
 168
 169   What:   Currently the data that is stored on the Volume is not
 170           encrypted. For confidentiality, encryption of data at
 171           the File daemon level is essential. Note, communications
 172           encryption encrypts the data when leaving the File daemon,
 173           then decrypts the data on entry to the Storage daemon.
 174           Data encryption encrypts the data in the File daemon and
 175           decrypts the data in the File daemon during a restore.
 176
 177   Why:    Large sites require this.
 178
 179   Notes:  The only algorithm that is needed is AES.
 180           http://csrc.nist.gov/CryptoToolkit/aes/
 181
 182
 183
 184 Completed items from last year's list:
 185 Item 1:   Multiple simultaneous Jobs. (done)
 186 Item 3:   Write the bscan program -- also write a bcopy program (done).
 187 Item 5:   Implement Label templates (done).
 188 Item 6:   Write a regression script (done)
 189 Item 9:   Add SSL to daemon communications (For now, implement with
 190           stunnel)
 191 Item 10:  Define definitive tape format (done)
 192 Item 3:   GUI for interactive restore. Partially Implemented in 1.34
 193           Note, there is now a complete Webmin plugin, a partial
 194           GNOME console, and an excellent wx-console GUI.
 195 Item 4:   GUI for interactive backup
 196 Item 2:   Job Data Spooling.
 197     Done: Regular expression matching.
 198 Item 10:  New daemon communication protocol (this has been dropped).