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.
Thanks,
John
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel
