Arno Lehmann wrote: > Hi, > > 30.10.2009 11:56, James Harper wrote: > >>> -----Original Message----- >>> From: Ralf Gross [mailto:r...@stz-softwaretechnik.de] On Behalf Of Ralf >>> >> Gross >> >>> Sent: Friday, 30 October 2009 21:47 >>> To: James Harper >>> Cc: bacula-users@lists.sourceforge.net >>> Subject: Re: [Bacula-users] Bacula features >>> >>> James Harper schrieb: >>> >>>>> Arno Lehmann schrieb: >>>>> >>>>>> 30.10.2009 07:24, Leslie Rhorer wrote: >>>>>> >>>>>> >>>>>>> 2. Span multiple target drives >>>>>>> >>>>>> Sure. >>>>>> >>>>> I'm not sure if he might has thought of a single backup job >>>>> >> spanning >> >>>>> multiple drives. >>>>> >>>>> This wouldn't be possible AFAIK. >>>>> >>>>> >>>> It should work afaict. It certainly works with multiple tapes. >>>> >>> Multile tapes is no problem, but I don't think bacula can switch >>> drives during a backup job or write to multiple drives in parallel. I >>> haven't seen an option for that. >>> >>> >> Hmmm... to be honest I have never had cause to find out, but I have seen >> bacula fill up a disk and ask for another volume. The autochanger script >> should just take care of the rest. >> > > I agree with James... from Baculas point of view, the volume files > don't matter, just the place where it finds them is important. And > that doesn't change. At least that's how I understand vchanger works. > >
Well, that's how Bacula itself works. In bacula-sd.conf you set the ArchiveDevice to a particular device node for a real tape drive, or a particular directory path for File type storage, or to a particular device node for a Device resource that is part of an Autochanger resource. Once a Device resource is assigned to a job, the job will use only that Device resource, and therefore whatever device node or path that is given by the ArchiveDevice directive. When the volume in that Device becomes full, Bacula will ask the operator to insert a new volume. Or, if the Device is part of an Autochanger, then it will invoke the autochanger script (or program) to ask the robot to insert a new volume. So Bacula will ask for new volumes to be inserted into the particular Device assigned to the job, but it will never ask for a volume on another Device resource. This is by design, I think to prevent deadlock situations when concurrent jobs are running. A disk autochanger differs from a tape autochanger in two major ways. The first is that the ArchiveDevice for the associated Device resource(s) is set to the path to a symlink, as opposed to a device node. The second is that the DeviceType is set to File rather than to Tape. The second difference is only so the Storage Daemon knows to open the ArchiveDevice as a regular file, rather than as a tape drive, since they of course use different device drivers for i/o. The actual reading/writing of data to the volume is the same as far as Bacula is concerned. It is only the selection of the device driver during the open() that is different. This is the beauty of Unix. Everything is a file. It is the device driver's problem to get the bytes to/from the physical media. Since the ArchiveDevice for a disk autochanger is a symlink, the autochanger script can "load" a volume into the Device by setting the symlink to point to the requested volume, which is just a regular file. The regular file can be located anywhere. Bacula only needs to know where the symlink is. > Quite similar to tapes - you access the tape with a constant name, but > which tape is in the tape drive is independent from the tape drive's name. > > I guess I'll have to try vchanger some day :-) > It performs the same function as the disk-changer shell script that ships with Bacula, but with some enhancements. Removable drives are treated as magazines containing some number of volume files. An autochanger has some number of magazine bays into which magazine drives can be "inserted". Each magazine has the same number of slots. The total number of autochanger slots is the number of bays times the number of slots per magazine. There can be any number of virtual drives (<= the number of virtual slots). The virtual drive (ie. ArchiveDevice) can be loaded from any of the magazines currently inserted into one of the bays. Removable drives acting as magazines can be assigned to the autochanger by filesystem UUID. This allows for a simple autofs map that makes swapping drives pretty much plug-n-play, at least on systems with udev (or Windows). You still have to issue an update slots in bconsole to tell Bacula which volumes are in which slots, but it makes the operation at least as simple as changing a tape magazine. Currently, it works with Linux, and works on Windows invoking it manually, though I've never tried it with a Windows version of Bacula SD. As is, it doesn't yet compile cleanly on FreeBSD, though one user has gotten it to work with some tweaks. I don't have a FreeBSD development environment, nor much knowledge of FreeBSD for that matter. > Arno > > >> James >> > > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
