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

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

On Tuesday 19 February 2008 23.13:04 John Stoffel wrote:
> Kern> Mark today in your calendar.  Bacula just did its first backup
> Kern> and restore of a MySQL database using a plugin.  I did it with
> Kern> using a simplistic "pipe" plugin.
> Congrats!
> Kern> The operation consisted of adding the following line to the
> Kern> Include section of the FileSet:
> Kern>                   1                    2                             
>     3                                               4 Kern> Plugin =
> "bpipe:/@MYSQL/regress.sql:mysqldump -f --opt --databases regress:mysql"
> Kern> This plugin line goes in the FileSet section where you have your
> Kern> File = xxx lines, and for this plugin is composed of 4 fields
> Kern> separated by colons (I've indicated the field numbers above the
> Kern> Plugin line for reference only.
> Ugh... sorry to be negative, but could we spend some time coming up
> with a nicer syntax please?
> Kern> Field 1 specifies a specific plugin name (in this case bpipe).
> Ok.  But would it make more sense to have a plugin { ... } resource block
> instead in the FileSet?
> Kern> Field 2 specifies the namespace (in this case the pseudo
> Kern>    path/filename under which the backup will be saved -- this
> Kern>    will show up in the restore tree selection).
> Hmm... what are the limits in Bacula's design in terms of namespace
> support?  Does it strictly follow the unix rooted tree, or does it
> also support the notion of drive letters as in PCs?  If so, why not
> just extend the drive letter to be:
>      DB:/MYSQL[345N]/<database>/<table>
> instead?  Maybe the version of mysql doesn't matter, but might be
> useful if you try to restore a version 5 mysql dump onto a version 3
> server to get a warning.
> Kern> Field 3 is the "reader" shell command used for doing a backup.
> Kern>    Since this is a pipe plugin (Linux shared object), it does a
> Kern>    popen() on that command.
> It would be nice to just abstract this out even more, so that the
> command is specified elsewhere, and we just feed in the standard
> connection arguements.  Sorta like the Perl::DBI modules abstract out
> DB connection stuff.
> Kern> Field 4 is the "writer" shell command used for doing the restore.
> Does this need to be different, or handle remote DBs, etc?
> Kern> I created a MySQL database named regress, populated it, backed
> Kern> it up, dropped the database, then I restored the "file"
> Kern> /@MYSQL/regress.sql, and the database was restored.  There is
> Kern> nothing magical about /@MYSQL/...  It is just something unique
> Kern> and distinctive enough that it will not be confused with another
> Kern> file on the system.
> Not sure I like this, esp since /@MYSQL/ is perfectly legal on Unix
> systems as a filename.
> Kern> As I mentioned, this is a rather trivial example of what can be
> Kern> done with a simple pipe plugin.  As it stands, bpipe knows
> Kern> nothing about MySQL (it is 365 lines of C code), but it could be
> Kern> any shared object that can implement a C interface, and I could
> Kern> imagine for example a MySQL specific plugin which could all
> Kern> databases or a list of databases.  Also, Bacula was running with
> Kern> an SQLite database -- it certainly would not work very well if
> Kern> Bacula were using the MySQL database in question during the
> Kern> restore ...
> Kern> Obviously, this is a first cut and there remains a lot to be
> Kern> done (much clean up, a lot of additional implementation, error
> Kern> message implementation, and documentation), but at least it is
> Kern> now a full proof of concept.
> Kern> By the way, this is an example of what I call a "plugin
> Kern> command", where a specific plugin is referenced, and it backs up
> Kern> a specific file (or set of files).  I have also planned plugins
> Kern> that will be called when particular Options are met (i.e. to
> Kern> backup all .gz files, ...).  However, I am putting off
> Kern> implementation of those plugins until later.
> Can we nail down how the plugin interface is used first?  And maybe we
> need to put all the plugins under their own 'plugin:/...' namespace as
> well, so that it doesn't get mixed up with regular files and such when
> browsing.

Aside from specifying the name of the plugin followed by a colon, everything 
else on the line is up to the plugin designer.  In this particular case, 
fields 2, 3, and 4 have defined meanings but the user can put anything he/she 
wants into them.

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 Copilot Consulting.