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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users