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 it. > 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 > or > 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 query directly? > 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 > API. 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. j -- Joshua Kugler Part-Time System Admin/Programmer http://www.eeinternet.com 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 http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
