[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:
> 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
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
> Thx again for your efforts!
> 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.