Re: [Bacula-devel] On Project item 12: Add Plug-ins to the FileSet Include statements.

[Bastian F. <ba...@ba...>]

Hi,

On Sonntag 02 September 2007, Kern Sibbald wrote:
[...]
> > FIFOs. This feature is crucial for our needs: Backing up process
> > output instead of files.
[...]
>
> The big problems are that this project is currently rather ill
> defined, and it is rather low in user priority.=20

The votes obviously show this low priority; I frankly don't understand=20
that, though. Every organization/company/unit where a database is set=20
up (including, but not restricted to SQL DBMS) should need a database=20
backup system - something that is not currently available in Bacula,=20
and possibly the most significant difference from the commercial=20
competitors. YMMV.

> It suffers from some=20
> of the same problems that plugins face

The reason I used the subject I used is that I regard the two subjects=20
as potentially equivalent: A set of two executables (binary, shell=20
scripts, ...) in fact defines an interface for a plugin.

When I wrote my initial mail, I had not yet read James' posting on the=20
topic. His concerns about incremental and differential backups possibly=20
result in a third "boolean executable" for the decision on whether to=20
back up a file/fifo/item.

> -- that is how to make the=20
> Volume self contained after adding this kind of feature. The Volume
> format currently is totally self contained in that a restore requires
> only the FD -- it doesn't even need a current definition of a FileSet
> to work.

This of course is correct for all machines of interest; with a little=20
abstraction, though, it is only valid for systems that have a similar=20
semantics on their file systems. Adding plugins adds a level of=20
semantics.

Unfortunately, the current level of file system semantics as required by=20
Bacula is used by approximately 100% of the systems out there (side=20
note: the file system available on my PalmOS PDA would _not_ be=20
sufficient for a Bacula restore), while adding the plugins would lower=20
this level to, well, approximately 0% :-/

> 1. Some important design decisions that permit the Volume to remain
> self contained and independent of FileSet definitions.

In my oppinion, "if plugins (executables) are used during backup,=20
equivalent plugins need to be in place during restore, or else a=20
fallback (e.g. writing stdout to a certain file) jumps in" would be a=20
valid decision.

Independence of a FileSet definition can be achieved by storing the=20
fact "is plugin/executable based, and that plugin is..." along with the=20
data - e.g. by using a different file name schema, similarly to how=20
it's done in afbackup.

> 2. A programmer.

Er. Yes. :)

Thx,
   Bastian

=2D-=20
 Bastian Friedrich                  ba...@ba...
 Adress & Fon available on my HP   http://www.bastian-friedrich.de/
\~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\
\ FATAL ERROR; SYSTEM HALTED; Press any key to do nothing.