Bacula-users

Re: [Bacula-users] Configuration reload for bacula-sd

2014-11-06 12:50:51
Subject: Re: [Bacula-users] Configuration reload for bacula-sd
From: Kern Sibbald <kern AT sibbald DOT com>
To: Alan Brown <ajb2 AT mssl.ucl.ac DOT uk>, "Ana Emília M. Arruda" <emiliaarruda AT gmail DOT com>
Date: Thu, 06 Nov 2014 18:48:29 +0100
On 10/28/2014 02:24 PM, Alan Brown wrote:
> On 28/10/14 12:46, Ana Emília M. Arruda wrote:
>
>> ​You have autochangers resources (fisical for tape librareis and virtual
>> for disks) in Bacula. They are a "pool of drives" to be used by your
>> jobs. I still think about having jobs and pools associated with clients
>> instead of devices associated with clients are the better choice.
> Devices are not associated with any clients. They're used as-available. 
> Tying devices to clients is an unnecessary restriction on resources and 
> generally indicates accountants gone mad or lack of thought about what 
> you are trying to achieve.
>
>> In spite of this, If you have to work with tape drives (stand alone or
>> tape library ones connected directly - not in a fabric topology)
> They are fabric connected.
>
>> , maybe
>> a second device definition for a job or pool could be more helpful than
>> a bacula-sd.conf reload on-the-fly or the enable/disable commands.
> This does not work. I've tried it.
>
> If an autochanger tape drive fails, jobs pile up behind it.
>
> What's far worse than a drive failing is one getting dirty - they spend 
> forever doing rewrites and througput drops from hundreds of Mb per 
> second to 10-20, WITHOUT raising errors in the backup system - and 
> running a cleaning tape doesn't work in a lot of cases (LTO drives are 
> self cleaning, If you need a tape then you're already in trouble)
>
> This is far from ideal behaviour, especially when there are petabytes of 
> science data involved.
>
>
> The only way out of either situation at the moment involves restarting 
> the storage daemon, which kills ALL jobs running on ALL drives.
>
>
>
> Comment: Please don't presume to lecture me about what I should or 
> should not be doing in my enterprise environment, or indeed about the 
> way systems are setup (it's all fabric path for starters and bacula does 
> not do d2d unless you count disk spooling 

I am surprised that you say that Bacula does not do d2d.  With Copy and
Migration jobs that is exactly what it does.

What it does not do is Hierarchical backups as well as it should since
it does not have the concept of cost or speed.


> - which we use intensively), 
> you have no idea of the operational constraints on my site and you're 
> making a bunch of fairly arrogant assumptions about the way things are 
> run which impinge on the way you think Bacula should operate.
>
> It's this kind of attitude which results in inflexible software that 
> gets sworn at, rather than sworn by.
>
>
> Thankfully Kern and his team are well aware that needs vary depending on 
> setups and that multiple-tape drive setups need improvement.

Yes.

>
> Tape and disk are different animals and need to be approached differently.
>
> Virtual autochangers are a kludge to allow for removable disks but in 
> most configured installations they do _not_ treat those disks in the 
> same way as real tape drives.

Virtual autochangers were not written for removable disks.  Prior to
virtual autochangers, I wrote code that allows (at least for me) Bacula
to deal with removable disks such as USB sticks.   Virtual autochangers
were written to allow much more flexibility with disks -- i.e. multiple
drives on one Storage, multiple directories, ... For the most part
virtual autochangers with fixed disks functions virtually identically to
tape drives similarly configured.

I am not sure why you consider virtual autochangers a kludge, since it
does *exactly* what I intended it to do for fixed disks.  I have never
tried using *removable* disks with virtual autochangers, nor even
thought about it, so perhaps you are trying to make it do something it
was not designed for.   In fact, there is a chance that removable disks
will work well with virtual autochangers, *provided* you tell Bacula it
is working with a removable device so it can use the removable disk code.

Best regards,
Kern

>
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bacula-users mailing list
> Bacula-users AT lists.sourceforge DOT net
> https://lists.sourceforge.net/lists/listinfo/bacula-users


------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users