Elie Azar wrote: > Hi Josh, > > Thanks for the reply... > > > Josh Fisher wrote: >> There is a script called disk-changer that is packaged with Bacula >> that does much the same thing and is what vchanger was based on. The >> disk-changer script uses a file in the base directory of each >> autochanger to simulate barcodes for its volumes. So it is designed >> to use a single disk for each configured autochanger. Another way to >> view it would be that it emulates a tape autoloader that will only >> ever use a single magazine. So disk-changer fits well with fixed drives. >> >> The vchanger script modifies that approach to generate the barcode >> labels on the fly based on the number of slots defined and the >> "magazine label". The magazine label is a number stored in a file in >> the root directory of the USB drive. So each USB drive belonging to a >> particular autochanger has the same filesystem label, but a different >> magazine label. It emulates a tape autoloader that will be used with >> multiple magazines. So vchanger fits well with removable drives. >> >> Why use either one of these scripts? Basically, because the storage >> device must be specified in either the Pool or the Job. That leaves >> two possible solutions; use a virtual autochanger or use LVM. LVM >> would take care of the space problem, but it would be impossible to >> remove a drive with intact backups on it. > > As was pointed out, these approaches work well with a single drive per > changer. I've been looking at vchanger, and I was hoping to be able to > use it, but it supports one drive per changer; no simultaneous drives > present. The mountpoint directive in the vchanger conf file restricts > it to a single drive.
Right. It simplifies the script quite a bit. :) > In my case, I would like to implement bacula so that it backs up on > any of a set of hard drives, all present in the system, either all > mounted or using autofs to mount. In my case, I would like to define > four changers, based on retention values and other criteria, each with > a number of hard drives. Then, I want to define my jobs to go to one > of these changers. At that point, the backup will happen on any of the > drives within that changer, without worrying about whether there is > enough space on a specific drive. And if a drive is full, it is > replaced with a new one. Here, I'm not sure about spanning a single > job across more than one drive; i.e. if bacula picks up a volume and > starts backing up and it runs out of room on the disk, would it span > across to another disk to finish the job; I'm not sure about these issues. The bacula autochanger interface is pretty straight forward and is documented at http://www.bacula.org/dev-manual/Autochanger_Resource1.html#SECTION0032120000000000000000. There are only 5 commands issued by bacula to the autochanger script. Bacula uses the 'list' command to determine what volumes are in the autochanger and in which slots. It issues a 'loaded' command for each of the autochanger's drives to determine which slots (if any) are already loaded and ready to use. Based on this info, bacula selects a volume to use for the job and, if needed, issues 'unload' and 'load' commands to load the volume it needs from the selected slot. Once the volume is loaded, bacula begins using it. Spanning to another drive is not a Bacula issue, per se. If a write error occurs due to the disk being full, then bacula will mark the volume full and begin looking for another available volume to continue to write the job to. This means it would again query the autochanger script for available volumes and attempt to load one. So the script would have to deal with maintaining "slots" on multiple physical drives. Then it should work out automatically. Bacula will only know it is spanning the job across volumes....it doesn't care which drive those volumes are on. However, there is a problem. Let's say we have 5 slots on each of 2 physical drives. Drive-0 has slots 1 through 5 with slot-1 being a large volume with status=Used and slot-2 through slot-5 being unused with status=append. Drive-1 has slots 6 through 10, all unused with status=Append. We start a big job and Bacula selects slot-2 on drive-0. Bacula writes to that volume until drive-0 becomes full, so it marks the slot-2 volume status=Used. Now drive-0 has no remaining free space and has slot-1 with status=Used, slot-2 with status=Full, and slot-3 through slot-5 with status=Append. Bacula thinks there are 3 more appendable volumes on drive-0. It might still work, though, because if Bacula loads one of the appendable volumes on drive-0, it will immediately get a write error when it attempts to write to it and again (I think) mark the volume status=Full and look for another appendable one. I have no idea how many times Bacula will repeat that process before giving up and failing the job. But if it doesn't give up, then it will eventually get all of the volumes in slots 1 through 5 marked status=Full and then finally choose slot-6, which is of course on drive-1 with plenty of free space. > So basically, the mountpoint needs to somehow be dynamically bound to > a certain hard drives belonging to that autochanger; bacula can then > use any of the volumes from that drive. No, the /var/lib/bacula/some-autochanger-name/drive0 symlink needs to point to the correct file (ie. slot) regardless on where the drive is mounted. The drives need to be mounted (or in the case of autofs, mountable) at different (but known) mountpoints Bacula can then use any of the volumes from ANY of the drives. > I have introduced a couple of directives in the vchanger conf file for > testing purposes; one is "basedir" which defines the base directory > where all drives eventually will mount, and the second is "disklabels" > defining all the hard drives (their labels) belonging to this > autochanger. > > Then in the vchanger script itself, I made some changes, with a for > loop around the case statement, to take a single drive label from > "disklabels", and use it to build the actual mountpoint needed for > this instance. I tested it with the list command in vchanger and it > worked. > The 'basedir' and 'disklabels' should work. However, maybe I misunderstood, but if you are saying that the list command only lists the volumes on one drive at a time, then that is defeating the purpose. The 'list' command must advertise to Bacula ALL of the slots on ALL drives. Same for the 'slots' command. Vchanger currently sees one disk as one magazine. The idea, here, is for it to see multiple disks as one magazine. So all slots in the "magazine" must be listed by the 'list' command. > The problem is, I don't know enough about bacula to figure out how it > interfaces with vchanger, and what the rest of the code changes may be. Hope this helps. > > > Thanks again for all your help, > Elie ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
