[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] Pre-alpha version of Bacula plugins working


Thanks for your comments and the encouragement :-)

see below for more:

On Friday 22 February 2008 09.05:35 Bastian Friedrich wrote:
> Kern,
> On Thursday 14 February 2008, Kern Sibbald wrote:
> > Mark today in your calendar.  Bacula just did its first backup and
> > restore of a MySQL database using a plugin. I did it with using a
> > simplistic "pipe" plugin.
> despite some other comments: What you have designed and implemented is of
> immense value value for me. Thank you very much! It is straight forward,
> easy to use, and it seems to work quite well. Wow. Great. Astonishing.
> Fantastic. :)

Yes, I am also pretty surprised how effective it is.  This is just a simple 
bpipe program that knows nothing about what it is doing other than 
interfacing to another program.  You can imagine the possibilities when one 
writes a *real* mysql plugin that really understands mysql and databases.

> The encapsulation provided by the plugin interface seems to be quite
> hands-on and provides (almost) everything that is required while giving
> users exactly the power they require. The bpipe plugin, on the other hand,
> is exactly what will be usable for most users out there - out of the box.

Yes, bpipe will probably be the most popular general purpose plugin, and will 
allow users to simply do quite a lot of things.  Given that it is not too 
hard to write plugins, though, I think we will see a number of specialized 
plugins -- I might even write one for PostgreSQL (or perhaps MS Exchange) 
just to server as an example.

> I'm sure you already have that on your radar; nonetheless, I'd like to
> mention that (if I understood things right...) currently plugins -- and the
> reader/writer executables in the bpipe plugin -- do not have access to the
> target directory specification during restore ("where"; the same holds true
> for the "replace" setting).

Well, the plugin has access to the full plugin stream so it could if it wishes 
put anything on the command line.  In fact the plugin could actually do all 
the work without calling another program.  

Currently the plugin doesn't have access to the where or replace strings, but 
that is simply because this is a pre-alpha version -- that is planned.  The 
plugins do have access to a list of Bacula "variables", and all that is 
necessary is adding the 3 or 4 lines of code necessary to expose each of the 
necessary variables.  These are just the details that are planned but I 
haven't gotten to yet.

> In the case of the mysql sample you provided, 
> it might be good to be able to restore to a different database, or rename
> the tables in a way that resembles the target directory (e.g. restoring
> table foo, "where"=/tmp/restore, could result in the generation of table
> foo.tmp.restore or sth. like that. Of course, that is up to the author of
> the respective reader/writer scripts/programs).

What you mention above will certainly be possible.  There *are* several 
aspects that I have not yet worked out.  For example, I think we need a way 
to be able to feed arbitrary restore command info to the plugin (much like 
the arbitrary plugin command invocation line).  That way, during the restore, 
the user could specify some plugin specific command that says restore only 
table X or restore to a different database, or whatever, and the plugin could 
adapt accordingly.  I'll work this out so that it is possible.  As with the 
plugin command string, it will probably just be a user definable plugin 
restore string.  

Even better would be to allow the plugin to directly interact with the user, 
but this is probably going to have to wait until much later, because it would 
require a good number of new mechanisms in Bacula (currently even the FD has 
no way to interact with the user, much less a plugin).

> While I suspect that you already have a solution for that in mind: if there
> is anything I can do to help you - feel free to ask :)

I have solutions in mind for a lot of things, but surely not for everything. 
In a couple of weeks, I should have more features implemented, and it should 
be a bit more tested with some preliminary documentation. At that point, it 
would be *really* helpful for users to start testing it and to point out any 
deficiencies or problem areas, and also try to force it into as many error 
conditions as possible ...

> Oh, for that matter: Once the bpipe plugin knows about these data, it might
> pass them to the readers/writers via the environment, or via some "%w"
> and "%r" flags?

I think that could be a good solution.  My part will be to make sure that the 
plugin has at it's disposal all the information, then it can either use it 
directly or pass it to any other programs it might use in the most 
appropriate way.

Best regards,


> Thx again for your efforts!
>    Bastian
> PS: Beauty is in the eye of the beer holder ;) While the syntax you created
> may or may not be "beautiful", it works. This is what matters.

Thanks.  It was inspired from the URI standards, which are 
equally "nonbeautiful", but in very wide use for many things.

   The URI syntax is essentially a URI scheme name 
    like "HTTP", "FTP", "mailto", "URN", "tel", "rtsp", "file", etc., followed
    by a colon character, and then a scheme-specific part. The syntax and
    semantics of the scheme-specific part are determined by the specifications
    that govern the schemes, although the URI syntax does force all schemes to
    adhere to a certain generic syntax that, among other things, reserves
    certain characters for special purposes, without always saying what those
    purposes are. The URI syntax also enforces restrictions on the
    scheme-specific part, in order to, for example, provide for a degree of
    consistency when the part has a hierarchical structure. Percent-encoding
    is an often-misunderstood aspect of URI syntax.

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Bacula-devel mailing list

This mailing list archive is a service of Copilotco.