Re: [Bacula-users] Bacula features

Arno Lehmann wrote:
> Hi,
>
> 30.10.2009 11:56, James Harper wrote:
>   
>>> -----Original Message-----
>>> From: Ralf Gross [mailto:rg AT stz-softwaretechnik DOT de] On Behalf Of Ralf
>>>       
>> Gross
>>     
>>> Sent: Friday, 30 October 2009 21:47
>>> To: James Harper
>>> Cc: bacula-users AT lists.sourceforge DOT 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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users