​IMHO.

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

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), 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. I mean, if the first drive designated for the job or the pool falis (director could check if no response is received, like it already does) and then director instructs the use of the second drive, present in job or pools definition of storage (Storage = Drive-1, Drive-2). This way it is not necesary to reastart the failed job (once it could not run because of the drive failure) and you can have enough time to change the crashed drive and no changes in bacula-sd.conf would be necesary since you will have symlinks for the archive device configuration.