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 - 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.

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.





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