[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] Couple questions about using a "disk-changer"
On Sunday 17 August 2008, Kern Sibbald said something like:
> There is very little documentation for the disk_changer script,
> because it was originally intended for testing, and is extensively
> used in the Bacula regression scripts. There is at least one very
> large user that is using disk_changer in production ...
> The main place for "user" documentation on using the script is at the
> top of the file.
Yup, have read that. Will read it again to try to internalize more of
> Before using disk_changer to access a slot, you must create the slot
> (sort of like inserting a blank tape). Typically I do it by:
> touch <disk-changer-directory>/slot<n>
> where <n> is the slot number you want to use.
OK, thanks. That's what I assumed. So basically, an empty file. Cool.
> By default, disk_changer allows a maximum of 10 slots, and two
> drives. The doc (at the top of the file) tells you how to modify it.
Right. If using S3, then basically you'd set your max to as many
volumes that fill up the amount of space you want to pay for. :)
> > 2. Is there a database independent way of getting information about
> > volumes?
> list volume=xxx
> llist volume=xxx
OK, that requires piping to bconsole, which shouldn't be too bad. Just
wanted to avoid that if possible.
> or the equivalent SQL commands.
Right, but that would require find the type of database, getting the
passwords (which requires parsing the bacula config file if not
SQLite), and then issuing a query once connected. Bconsole might be my
best route. :)
> There is a C interface to the databases that is mostly SQL database
> independent, but it is written only for Bacula so would not be easy
> to use in an external program.
Where might I find code (docs?) for that? But that would still require
parsing, say, bconsole (for the director password) or the larger conf
file for database passwords. Is there any documentation on basically
creating one's own bconsole, such that you connect to the director and
> You can always use a DBI interface -- e.g. perl, or libdbi ...
True. And I guess for just getting info about the databases, the
queries will be the same, no SQL differences needed.
> I am a bit skeptical about the practical use of S3, but it is clearly
> something we need.
It would be cool, yup.
> I believe the best way (maybe not the easiest) is to implement it as
> a Bacula device driver in the trunk svn. The trunk has a fairly well
> defined interface to device drivers that make adding new ones more or
> less trivial. For the moment it requires compiling it into Bacula,
> but at some point we will have a plugin interface. For the moment,
> this interface is only documented by the code.
> Doing it via the disk_changer probably will not be possible since
> accessing S3 with any degree of security and control requires
> programming at the open, read, write, lseek, close levels via their
For the moment, I'm going to see what I can come up with via disk
changer, since the systems I'll be using it on are only used for
backup, with no other user logins, so there is no chance of the volumes
being tampered with. Doing direct opens/reads/writes would make the
backup very slow. My idea with disk changer is to have another process
that handles uploading so the backup can proceded at full speed. Like
I said, it's in the idea stage...we'll see how far I get.
Part-Time System Admin/Programmer
PGP Key: http://pgp.mit.edu/ ID 0xDB26D7CE
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Bacula-devel mailing list
This mailing list archive is a service of Copilotco.