On 09/01/17 23:01, Dimitri Maziuk wrote:
>
> What are you trying to achieve? I agree that "virtual autochanger" is a
> mind boggle with no obvious practical use, but why are you looking at it
> in the first place?
The primary advantage of the virtual autochanger is you can more easily
use removab
On 1/10/2017 4:49 AM, Timo Neuvonen wrote:
>
> I'm not trying to achieve anything special, I'm rather trying to avoid doing
> anything unnecessarily complicated.
> I just want to set up (and to fully understand my set-up) a simple but
> working file storage device for a small business / home offi
On 2017-01-10 03:49, Timo Neuvonen wrote:
> What confused me is that the example conf files supplied with current Bacula
> releases don't give an example of the very basic disk-based setup, but just
> show how to setup a virtual disk autochanger.
> The whitepapers that Kern referred gave me an imp
> > I'm still wondering if this really is the
> > simplest way of implementing the file storage?
> >
> > What would I lose if I simply had only one of the two device resources,
> > no autochanger resource at all, and the jobs would refer directly to the
> > device resource? I think it should work t
On 01/09/2017 01:55 PM, Timo Neuvonen wrote:
> I'm still wondering if this really is the
> simplest way of implementing the file storage?
>
> What would I lose if I simply had only one of the two device resources, no
> autochanger resource at all, and the jobs would refer directly to the device
>
Hello,
The Autochanger definition for the SD you show below is a Virtual
Autochanger. It is anything but a dummy, though that is arguable.
If you want more information about it, there are two whitepapers
on the bacula.org web site that talk about th
Pasted below is a piece of the default bacula-sd.conf
My installation is from epel-bacula repo for CentOS 7, but exactly the same
conf example can be found from the latest Bacula source tarball.
Could someone explain why a file storage device is definend as an "dummy"
autochanger, and the two fil
