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

   1
   2 Projects:
   3                      Bacula Projects Roadmap
   4                        28 October 2005
   5
   6 Below, you will find more information on future projects:
   7
   8 Item 1:   Implement a Migration job type that will move the job
   9           data from one device to another.
  10   Origin: Sponsored by Riege Sofware International GmbH. Contact:
  11           Daniel Holtkamp <holtkamp at riege dot com>
  12   Status: Partially coded in 1.37 -- much more to do. Assigned to
  13           Kern.
  14
  15   What:   The ability to copy, move, or archive data that is on a
  16           device to another device is very important.
  17
  18   Why:    An ISP might want to backup to disk, but after 30 days
  19           migrate the data to tape backup and delete it from
  20           disk.  Bacula should be able to handle this
  21           automatically.  It needs to know what was put where,
  22           and when, and what to migrate -- it is a bit like
  23           retention periods.  Doing so would allow space to be
  24           freed up for current backups while maintaining older
  25           data on tape drives.
  26
  27   Notes:  Migration could be triggered by:
  28            Number of Jobs
  29            Number of Volumes
  30            Age of Jobs
  31            Highwater size (keep total size)
  32            Lowwater mark
  33
  34 Item 2:   Implement a Bacula GUI/management tool using Python
  35           and Qt.
  36
  37   Origin: Kern
  38   Status:
  39
  40   What:   Implement a Bacula console, and management tools
  41           using Python and Qt.
  42
  43   Why:    Don't we already have a wxWidgets GUI?  Yes, but
  44           it is written in C++ and changes to the user interface
  45           must be hand tailored using C++ code. By developing
  46           the user interface using Qt designer, the interface
  47           can be very easily updated and most of the new Python
  48           code will be automatically created.  The user interface
  49           changes become very simple, and only the new features
  50           must be implement.  In addition, the code will be in
  51           Python, which will give many more users easy (or easier)
  52           access to making additions or modifications.
  53
  54 Item 3:   Implement a Python interface to the Bacula catalog.
  55   Origin: Kern
  56   Status:
  57
  58   What:   Implement an interface for Python scripts to access
  59           the catalog through Bacula.
  60
  61   Why:    This will permit users to customize Bacula through
  62           Python scripts.
  63
  64 Item 4:   Implement more Python events in Bacula.
  65   Origin:
  66   Status:
  67
  68   What:   Allow Python scripts to be called at more places
  69           within Bacula and provide additional access to Bacula
  70           internal variables.
  71
  72   Why:    This will permit users to customize Bacula through
  73           Python scripts.
  74
  75   Notes:  Recycle event
  76           Scratch pool event
  77           NeedVolume event
  78
  79
  80 Item 5:   Implement Base jobs.
  81   Origin: Kern
  82   Status:
  83
  84   What:   A base job is sort of like a Full save except that you
  85           will want the FileSet to contain only files that are
  86           unlikely to change in the future (i.e.  a snapshot of
  87           most of your system after installing it).  After the
  88           base job has been run, when you are doing a Full save,
  89           you specify one or more Base jobs to be used.  All
  90           files that have been backed up in the Base job/jobs but
  91           not modified will then be excluded from the backup.
  92           During a restore, the Base jobs will be automatically
  93           pulled in where necessary.
  94
  95   Why:    This is something none of the competition does, as far as
  96           we know (except perhpas BackupPC, which is a Perl program that
  97           saves to disk only).  It is big win for the user, it
  98           makes Bacula stand out as offering a unique
  99           optimization that immediately saves time and money.
 100           Basically, imagine that you have 100 nearly identical
 101           Windows or Linux machine containing the OS and user
 102           files.  Now for the OS part, a Base job will be backed
 103           up once, and rather than making 100 copies of the OS,
 104           there will be only one.  If one or more of the systems
 105           have some files updated, no problem, they will be
 106           automatically restored.
 107
 108   Notes:  Huge savings in tape usage even for a single machine.
 109           Will require more resources because the DIR must send
 110           FD a list of files/attribs, and the FD must search the
 111           list and compare it for each file to be saved.
 112
 113 Item 6:   Add Plug-ins to the FileSet Include statements.
 114   Origin:
 115   Status: Partially coded in 1.37 -- much more to do.
 116
 117   What:   Allow users to specify wild-card and/or regular
 118           expressions to be matched in both the Include and
 119           Exclude directives in a FileSet.  At the same time,
 120           allow users to define plug-ins to be called (based on
 121           regular expression/wild-card matching).
 122
 123   Why:    This would give the users the ultimate ability to control
 124           how files are backed up/restored.  A user could write a
 125           plug-in knows how to backup his Oracle database without
 126           stopping/starting it, for example.
 127
 128 Item 7:   Implement huge exclude list support using hashing.
 129   Origin: Kern
 130   Status:
 131
 132   What:   Allow users to specify very large exclude list (currently
 133           more than about 1000 files is too many).
 134
 135   Why:    This would give the users the ability to exclude all
 136           files that are loaded with the OS (e.g. using rpms
 137           or debs). If the user can restore the base OS from
 138           CDs, there is no need to backup all those files. A
 139           complete restore would be to restore the base OS, then
 140           do a Bacula restore. By excluding the base OS files, the
 141           backup set will be *much* smaller.
 142
 143
 144 Item  8:  Implement data encryption (as opposed to communications
 145           encryption)
 146   Origin: Sponsored by Landon and 13 contributors to EFF.
 147   Status: Landon Fuller is currently implementing this.
 148
 149   What:   Currently the data that is stored on the Volume is not
 150           encrypted. For confidentiality, encryption of data at
 151           the File daemon level is essential.
 152           Data encryption encrypts the data in the File daemon and
 153           decrypts the data in the File daemon during a restore.
 154
 155   Why:    Large sites require this.
 156
 157 Item 9:   Permit multiple Media Types in an Autochanger
 158   Origin:
 159   Status:
 160
 161   What:   Modify the Storage daemon so that multiple Media Types
 162           can be specified in an autochanger. This would be somewhat
 163           of a simplistic implementation in that each drive would
 164           still be allowed to have only one Media Type.  However,
 165           the Storage daemon will ensure that only a drive with
 166           the Media Type that matches what the Director specifies
 167           is chosen.
 168
 169   Why:    This will permit user with several different drive types
 170           to make full use of their autochangers.
 171
 172 Item 10:  Allow two different autochanger definitions that refer
 173           to the same autochanger.
 174   Origin: Kern
 175   Status:
 176
 177   What:   Currently, the autochanger script is locked based on
 178           the autochanger. That is, if multiple drives are being
 179           simultaneously used, the Storage daemon ensures that only
 180           one drive at a time can access the mtx-changer script.
 181           This change would base the locking on the control device,
 182           rather than the autochanger. It would then permit two autochanger
 183           definitions for the same autochanger, but with different
 184           drives. Logically, the autochanger could then be "partitioned"
 185           for different jobs, clients, or class of jobs, and if the locking
 186           is based on the control device (e.g. /dev/sg0) the mtx-changer
 187           script will be locked appropriately.
 188
 189   Why:    This will permit users to partition autochangers for specific
 190           use. It would also permit implementation of multiple Media
 191           Types with no changes to the Storage daemon.
 192
 193 Item 11:  Implement red/black binary tree routines.
 194   Origin: Kern
 195   Status:
 196
 197   What:   Implement a red/black binary tree class. This could
 198           then replace the current binary insert/search routines
 199           used in the restore in memory tree.  This could significantly
 200           speed up the creation of the in memory restore tree.
 201
 202   Why:    Performance enhancement.
 203
 204
 205
 206
 207 ============= Empty RFC form ===========
 208 Item n:   One line summary ...
 209   Origin: Name and email of originator.
 210   Status:
 211
 212   What:   More detailed explanation ...
 213
 214   Why:    Why it is important ...
 215
 216   Notes:  Additional notes or features ...
 217 ============== End RFC form ==============
 218
 219
 220 Items completed for release 1.38.0:
 221 #4   Embedded Python Scripting (implemented in all Daemons)
 222 #5   Events that call a Python program (Implemented in all
 223        daemons, but more cleanup work to be done).
 224 #6   Select one from among Multiple Storage Devices for Job.
 225        This is already implemented in 1.37.
 226 #7   Single Job Writing to Multiple Storage Devices. This is
 227        currently implemented with a Clone feature.
 228 #-   Full multiple drive Autochanger support (done in 1.37)
 229 #-   Built in support for communications encryption (TLS)
 230        done by Landon Fuller.
 231 #    Support for Unicode characters
 232        (via UTF-8) on Win32 machines thanks to Thorsten Engel.
 233 Item  8:  Break the one-to-one Relationship between a Job and a
 234           Specific Storage Device (or Devices if #10 is implemented).
 235
 236 Completed items from last year's list:
 237 Item 1:   Multiple simultaneous Jobs. (done)
 238 Item 3:   Write the bscan program -- also write a bcopy program (done).
 239 Item 5:   Implement Label templates (done).
 240 Item 6:   Write a regression script (done)
 241 Item 9:   Add SSL to daemon communications (done by Landon Fuller)
 242 Item 10:  Define definitive tape format (done)
 243 Item 3:   GUI for interactive restore. Partially Implemented in 1.34
 244           Note, there is now a complete Webmin plugin, a partial
 245           GNOME console, and an excellent wx-console GUI.
 246 Item 4:   GUI for interactive backup
 247 Item 2:   Job Data Spooling.
 248     Done: Regular expression matching.
 249 Item 10:  New daemon communication protocol (this has been dropped).