On Mon, Oct 27, 2014 at 7:25 AM, Alan Brown <a.br...@ucl.ac.uk> wrote:
> On 24/10/14 23:27, Ana Emília M. Arruda wrote: > >> Maybe this could be usefull. But I'm still trying to understand why are >> you using disk drives directly in archive device configuration. >> > > We don't. We use tape drives. 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. > > I also think that backup software cannot be aware of hardware faliures. >> > > I _strongly_ disagree, especially in an enterprise-scale setup. > Sorry Alan, in an enterprise-scale setup, you need, as I mentioned before, other fault tolerance levels (disk-to-disk backups in storage arrays before disse-to-tape backup, raids, multipaths, etc.). Best regards, Ana
------------------------------------------------------------------------------
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
