Elie Azar wrote: > Hi Josh, > > Thank you very much for your kind reply... > > So, what is the point of using vchanger then; we can get the same > result using pools, I think.
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. > I was going to define a couple of pools, with different retention > values, and put a number of drives in each pool. Then, I figured if I > don't have a Storage directive in the job definitions, the jobs will > get directed to the pool corresponding to the retention value defined > in that job. Then, the job will use a volume from the corresponding > pool, regardless of which physical drive that volume resides on. Am I > off base here (I'm always worried since I still don't know much about > Bacula) The storage device has to be specified somewhere. If not in the Job, then in the Pool. > > Basically what I want is to backup jobs to a couple of servers, each > with an array of twenty 500GB drives, without having to specify, for > each job, which drive to backup to; which is what we currently have. I > want Bacula to do a backup without having to worry about available > disk space on an individual hard drive. Currently, I go in and change > a job's storage directive from the filled hard drive to one that has > enough space... > > And eventually, I'd like to be able to replace full hard drives > without having to change the whole configuration. > > Thanks again for your help, > Elie > > > Josh Fisher wrote: >> >> Elie Azar wrote: >>> Hi, >>> >>> I'm kind of new to Bacula, and definitely to Vchanger, so please >>> bear with me. >>> >>> I want to implement vchanger on a set of hard drives, with the idea >>> that I will have a pool of, let's say, 10 drives available for >>> backup, and where I do not have to specify a storage device for >>> every job I define. >>> >>> One of the issue that come up right off the bat is the drive >>> labeling. In the "Removable Disk HowTo" document, they talk about >>> labeling the drives with the same label corresponding to the >>> vchanger that these drives are going to be attached to. Now, I am >>> not using USB drives, but rather fixed drives in a HD enclosure; so >>> they will all be installed in the system (Linux Gentoo). So, how >>> will the system mount these drives, all with the same label, and >>> differentiate between them. Unless the intention of the HowTo >>> document was not to have the USB drives installed at the same time. >>> >> >> That is correct. Vchanger is designed for removable >> USB/Firewire/e-SATA etc. drives and treats the drive as a magazine of >> Bacula volumes. There can be multiple vchanger autochangers, where >> each autochanger would have its own config file. Each of these >> vchanger "instances" would have their own unique filesystem volume >> label (as opposed to Bacula label). Every drive belonging to a >> particular autochanger would have a filesystem labeled with that >> autochanger's label. The label is needed so that autofs can mount the >> filesystem at a predetermined mountpoint. Each autochanger may have >> only one of its drives (ie. "magazines") inserted at a time, just as >> a tape autoloader (of which vchanger is emulating) may have only one >> magazine loaded at a time. >> >> It is entirely possible, however, to configure 10 vchangers, one for >> each physical drive. Since vchanger initially places all volumes in >> the Scratch pool, if a drive fills up then Bacula will move a volume >> from the Scratch pool into the needed pool and use it. So that may do >> what you want. >> >> One problem is that there is no good way to reclaim the disk space >> after a volume is purged. Bacula does not delete the physical media, >> but only removes the catalog entries. That is probably the way it >> should be, and I'm not sure I've figured out a good way to handle >> that case. The best way is to carefully assign retention times such >> that enough volumes get recycled before they are needed. >> >>> The other issue is that, if that would work as is, and I have >>> multiple drives attached to the vchanger, these drives will be >>> pooled, and thus Bacula will backup on some volume form this pool, >>> regardless of which drive it belongs to. The question then arises as >>> to what happens if the backup job is larger that the balance of disk >>> space on the chosen drive; will the job span across multiple drives; >>> i.e. it will start on a certain drive, then the "Volume" will "grow" >>> on another drive? I thought that's how it worked with tape backups; >>> bacula just went to the changer and got a new magazine tape and >>> continued the job. >>> >> >> If a vchanger's drive becomes full, then Bacula will look for another >> volume from the specified pool. In the case of a single vchanger, >> there is only one drive mounted at a time, so Bacula will issue an >> operator intervention needed message. >> >>> I may have this whole thing completely misunderstood, but I thought >>> that that was the intention. Pool together several drives, and tell >>> Bacula to backup to them, without having to specify a drive, and >>> without having to worry if there was room on a specific device, etc. >>> >> >> Not exactly. The primary reason was to be able to use removable USB >> drives in a plug and play fashion. >> >>> Any help would be greatly appreciated. >>> >>> Thanks, >>> Elie Azar >>> >>> ------------------------------------------------------------------------- >>> >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2005. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> Bacula-users mailing list >>> Bacula-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bacula-users >>> > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
