Hello bacula-users :-) Are any tools available to mend Bacula after almost certainly spurious errors reported by a tape autoloader? Within a few minutes of Bacula starting to use an autoloader which
Are you sure it was the loader which had the critical error? Most "critical errors" of this kind are bacula attempting to unload a locked drive (Lesson: issue explicit unlocking commands in your star
Hello Charles, If you do not know who Alan Brown is, I can say that he is at least 10 times more knowledgeable about the use of tape drives with Bacula than I am, so I defer to his analysis. The one
No Confirmed in bacula.log Have modified /etc/init.d/bacula-sd (Debian Jessie), adding mt rewoffl and mtx unload commands immediately before bacula-sd is started. Done Many thanks for sharing your in
Thanks for being thorough, Kern. Our bacula-sd.conf's Device stanza for the autoloader did not have an Alert Command directive. Now fixed. -- Developer Access Program for Intel Xeon Phi Processors Ac
That should do the trick, although I'd add mt unlock to make absolutely sure. No problem Bacula takes no notice of autoloader status and mtx won't show loader status anyway (other than full/empty). W
According to both the man pages and experimentation, Debian Jessie's mt and mtx do not support an unlock command. HP StoreEver 18G2 LTO-6 Ultrium 6250 Tape Autoloader tapeinfo reports: HP Ultrium 6-S
Whilst other debian versions do mt-st v. 1.3 default tape device: '/dev/tape' lock (SCSI tapes) Lock the tape drive door. unlock (SCSI tapes) Unlock the tape drive door. You might want to check the v