Re: [Bacula-users] Autochanger not changing
Am 08.04.2018 um 21:08 schrieb Sebastian Suchanek: > [...] > This makes me wonder if the problem is maybe caused by the LTO4 drive > itself. But what I didn't mention so far: during my various trial runs > around this problem, I also replaced the LTO4 drive with another one. > (AFAIR both of them were the same Seagate model, though...) JFTR: Finally, also the LTO4 drive works as expected. (Tested in the meantime by two "live" backup jobs with ~2TB each.) The realy funny/strange thing is: I only changed the Maximum block size from "1MB" to "1048576" and reduced the Maximum file size from "40GB" to "10737418240". Anyway - as long as it works, I don't care too much about the details. ;-) Regards, Sebastian -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Autochanger not changing
Am 09.04.2018 um 17:46 schrieb Kern Sibbald: Hi Kern! > The output from lsscsi looks odd. From what I see, I am not reassured > that both the tape drives are actually part one at a time and see if > physically the right tapes are mounted. I'm afraid, I didn't fully understand what you meant to say here. But I assume, you are wondering why the devices of the library are so "distributed". That I can explain at least partially: The reason is, that the way the library is connected to the server is somewhat "unique". The library is an Overland NEO2000 which, unlike most other libraries, has a dedicated controller card with its own parallel SCSI connectors. The LTO1 drive also has its own parallel SCSI connectors. The LTO4 drive, on the other hand, has a Fibre Channel connection. In order not having to use two different host adapters (SCSI & FC), I installed a FC-to-SCSI bridge in library. (An ATTO FibrBridge 2390C, relabled by Overland.) On the server side, I'm using a dual channel FC controller Emulex LPe 11002. The LTO4 drive and the FibreBridge are connected directly to one of the FC controller ports respectively. Or, as a sketch: -. .- Server | | Library | +-. .---+ Fibre Channel | | | |=| LTO4 drive | | FC HA | | | | |==## +-' '---+ || | | || +-. -' || | | || ,---+ LTO1 drive | || | | | ||SCSI | +-' || | | || | +-. || '---+ | || | Controller | || .---+ | || | +-' ||SCSI | | || | +-. || '---+ | || | FibreBridge | ##=| | Fibre Channel+-' | '- But I don't have the slightest clue why the kernel splits up the two channels of the single FC controller into two non-consecutive controller numbers (0 and 7). But this number asignment is persitent through system reboots, though... > [...] > My experience on LTO-1 and LTO-4 drives is that 512K buffer sizes get > quite adequate performance so I am a bit skeptical about your need for > 1MB buffers, but that said, they should be OK. Well, that's what I found out with some btape "speed" test runs: https://hirnfasching.de/2018/02/19/geschwindigkeitsmessung-lto-4-laufwerk/ The blog post itself is in German - sorry for that - but the figures should be understandable anyway. OK, I have to admit "significantly" is a bit of an exaggeration when comparing the 1MB values with the 512kB block size values, but 1MB does result in a larger throughput after all. Best regards Sebastian -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Autochanger not changing
Hello, The output from lsscsi looks odd. From what I see, I am not reassured that both the tape drives are actually part one at a time and see if physically the right tapes are mounted. I also am a bit skeptical about using a 40GB maximum file size on your LTO-4 -- that seems *much* larger than what we recommend to be an optimal compromise between restore speed and write speed. My experience on LTO-1 and LTO-4 drives is that 512K buffer sizes get quite adequate performance so I am a bit skeptical about your need for 1MB buffers, but that said, they should be OK. Also you should probably be using device independent device names rather than /dev/nst0 and /dev/nst1 as depending on the boot, the devices could get swapped -- the same goes for the /dev/sg4 name. Others on this list should be able to help you with the details of my suggestions ... Best regards, Kern On 04/02/2018 01:53 PM, Sebastian Suchanek wrote: Am 02.04.2018 um 09:54 schrieb Kern Sibbald: Hello Kern, thank you for your reply. First, I would recommend that you use at *most* 1MB block sizes for LT0-1 and LTO-4 tapes. OK, I changed that for the LTO-4 drive. (I don't want go below 1MB though, because it significantly reduces write rates.) [...] You haven't shown your full autochanger device configuration so it will be hard/impossible to diagnose your problem. No problem, here's my full bacula-sd.conf, only comments and passwords are removed: | Storage { | Name = tigersclaw-sd | SDPort = 9103 | WorkingDirectory = "/var/lib/bacula" | Pid Directory = "/var/run/bacula" | Maximum Concurrent Jobs = 20 | SDAddress = 10.1.0.1 | } | | Director { | Name = tigersclaw-dir | Password = | } | | Director { | Name = tigersclaw-mon | Password = | Monitor = yes | } | | Device { | Name = FileStorage | Media Type = File | Archive Device = /srv/bacula/file | LabelMedia = yes | Random Access = yes | AutomaticMount = yes | RemovableMedia = no | AlwaysOpen = no | } | | Autochanger { | Name = Overland-NEO2000 | Device = LTO1-Drive-1 | Device = LTO4-Drive-1 | Changer Command = "/etc/bacula/scripts/mtx-changer %c %o %S %a %d" | Changer Device = /dev/sg4 | } | | Device { | Name = LTO1-Drive-1 | Drive Index = 0 | Media Type = LTO-1 | Archive Device = /dev/nst1 | AutomaticMount = yes | AlwaysOpen = yes | RemovableMedia = yes | RandomAccess = no | AutoChanger = yes | Maximum File Size = 2GB | Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'" | Spool Directory = "/srv/bacula/spool" | } | | Device { | Name = LTO4-Drive-1 | Drive Index = 1 | Media Type = LTO-4 | Archive Device = /dev/nst0 | AutomaticMount = yes | AlwaysOpen = yes | RemovableMedia = yes | RandomAccess = no | Maximum block size = 1MB | Maximum File Size = 40GB | AutoChanger = yes | Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'" | Spool Directory = "/srv/bacula/spool" | } | | Messages { | Name = Standard | director = tigersclaw-dir = all | } JFTR: "tigersclaw" is the name of my server which runs (among other things) the Bacula director, storage daemon und also the client where the backup job in question comes from. (I have more jobs configured, also from other clients, but they are way to small to even fill a LTO-1 tape.) Also the output from a: lsscsi -g would be necessary. No problem either: | # lsscsi -g | [0:0:1:0]tapeHP Ultrium 4-SCSI H63H /dev/st0 /dev/sg3 | [1:0:0:0]diskATA Samsung SSD 850 2B6Q /dev/sda /dev/sg0 | [2:0:0:0]diskATA WDC WD40EFRX-68W 0A82 /dev/sdb /dev/sg1 | [3:0:0:0]diskATA WDC WD40EFRX-68W 0A82 /dev/sdc /dev/sg2 | [7:0:0:0]mediumx OVERLAND NEO Series 0616 /dev/sch0 /dev/sg4 | [7:0:0:1]tapeSEAGATE ULTRIUM06242-XXX 1603 /dev/st1 /dev/sg5 | # Note in general, if btape works then Bacula will work because the SD uses the same subroutines that btape uses for reading/writing tapes. Well, that's what I expected and that's why I'm so puzzled about this error... Consequently there may be some other problem. When the SD seems to be stuck, you can probably get more information by doing: bconsole set debuglevel=200 storage= trace=1 mount set debuglevel=0 storage= trace=0 then look at the trace file in your working directory to see what it going on. Here's the trace file from the beginning of the job until the point where the first tape was full and Bacula got stuck: https://suchanek.de/temp/tigersclaw-sd.trace (47kB) And here ist what happend when I manually cancelled the stuck job (which worked) and try to do a "release LTO4-Drive" command in bconsole. (Which didn't work, i.e. Bacula got stuck here too.) https://suchanek.de/temp/tigersclaw-sd.trace.2 (3kB) I hope you can find anything usefull in these debug files, because I'm totally lost here... Best regards Sebastian
Re: [Bacula-users] Autochanger not changing
Am 07.04.2018 um 22:11 schrieb Dan Langille: >> On Apr 1, 2018, at 11:12 AM, Sebastian Suchanek wrote: >> >> [...] >> Any idea what exactly is going wrong here? What can I do to track down >> the reason for this error? What can I do to fix it? > > It is usually permissions. It it nearly always permission. I agree - during my years of dealing with Linux, I've come across many problems that were caused by permission issues of some sort. > This might be your best bet: > https://dan.langille.org/2016/02/04/dell-tl4000-tape-library-running-btape-and-configuring-baculas-mtx-changer/ > [...] I repeated almost all tests you described in your blog post (of course adapted to my system): - 8< - bacula@tigersclaw:~$ lsscsi -g [0:0:1:0]tapeHP Ultrium 4-SCSI H63H /dev/st0 /dev/sg3 [1:0:0:0]diskATA Samsung SSD 850 2B6Q /dev/sda /dev/sg0 [2:0:0:0]diskATA WDC WD40EFRX-68W 0A82 /dev/sdb /dev/sg1 [3:0:0:0]diskATA WDC WD40EFRX-68W 0A82 /dev/sdc /dev/sg2 [7:0:0:0]mediumx OVERLAND NEO Series 0616 /dev/sch0 /dev/sg4 [7:0:0:1]tapeSEAGATE ULTRIUM06242-XXX 1603 /dev/st1 /dev/sg5 bacula@tigersclaw:~$ /usr/sbin/mtx -f /dev/sg4 inquiry Product Type: Medium Changer Vendor ID: 'OVERLAND' Product ID: 'NEO Series ' Revision: '0616' Attached Changer API: No bacula@tigersclaw:~$ /usr/sbin/tapeinfo -f /dev/nst0 mtx: Request Sense: Long Report=yes mtx: Request Sense: Valid Residual=no mtx: Request Sense: Error Code=0 (Unknown?!) mtx: Request Sense: Sense Key=No Sense mtx: Request Sense: FileMark=no mtx: Request Sense: EOM=no mtx: Request Sense: ILI=no mtx: Request Sense: Additional Sense Code = 00 mtx: Request Sense: Additional Sense Qualifier = 00 mtx: Request Sense: BPV=no mtx: Request Sense: Error in CDB=no mtx: Request Sense: SKSV=no INQUIRY Command Failed bacula@tigersclaw:~$ /usr/sbin/tapeinfo -f /dev/sg3 Product Type: Tape Drive Vendor ID: 'HP ' Product ID: 'Ultrium 4-SCSI ' Revision: 'H63H' Attached Changer API: No SerialNumber: 'HUE4020D8F' MinBlock: 1 MaxBlock: 16777215 SCSI ID: 1 SCSI LUN: 0 Ready: yes BufferedMode: yes Medium Type: Not Loaded Density Code: 0x46 BlockSize: 0 DataCompEnabled: yes DataCompCapable: yes DataDeCompEnabled: yes CompType: 0x1 DeCompType: 0x1 BOP: yes Block Position: 0 Partition 0 Remaining Kbytes: 799204 Partition 0 Size in Kbytes: 799204 ActivePartition: 0 EarlyWarningSize: 0 NumPartitions: 0 MaxPartitions: 0 bacula@tigersclaw:~$ /usr/sbin/tapeinfo -f /dev/sg4 Product Type: Medium Changer Vendor ID: 'OVERLAND' Product ID: 'NEO Series ' Revision: '0616' Attached Changer API: No SerialNumber: '2B44300035' SCSI ID: 0 SCSI LUN: 0 Ready: yes bacula@tigersclaw:~$ /usr/sbin/mtx -f /dev/sg4 status Storage Changer /dev/sg4:2 Drives, 30 Slots ( 1 Import/Export ) Data Transfer Element 0:Full (Storage Element 1 Loaded):VolumeTag = SU1001L1 Data Transfer Element 1:Full (Storage Element 20 Loaded):VolumeTag = SU4101L4 Storage Element 1:Empty Storage Element 2:Full :VolumeTag=SU1002L1 Storage Element 3:Full :VolumeTag=SU1003L1 Storage Element 4:Full :VolumeTag=SU1004L1 Storage Element 5:Full :VolumeTag=SU1005L1 Storage Element 6:Full :VolumeTag=SU1006L1 Storage Element 7:Full :VolumeTag=SU1007L1 Storage Element 8:Full :VolumeTag=SU1008L1 Storage Element 9:Full :VolumeTag=SU1009L1 Storage Element 10:Full :VolumeTag=SU1010L1 Storage Element 11:Full :VolumeTag=SU1101L1 Storage Element 12:Full :VolumeTag=SU1102L1 Storage Element 13:Full :VolumeTag=SU1103L1 Storage Element 14:Full :VolumeTag=SU1104L1 Storage Element 15:Full :VolumeTag=SU4001L4 Storage Element 16:Full :VolumeTag=SU4002L4 Storage Element 17:Full :VolumeTag=SU4003L4 Storage Element 18:Full :VolumeTag=SU4004L4 Storage Element 19:Full :VolumeTag=SU4005L4 Storage Element 20:Empty Storage Element 21:Full :VolumeTag=SU4102L4 Storage Element 22:Full :VolumeTag=SU4103L4 Storage Element 23:Full :VolumeTag=SU4104L4 Storage Element 24:Full :VolumeTag=SU4105L4 Storage Element 25:Full :VolumeTag=SU4106L4 Storage Element 26:Full :VolumeTag=SU4107L4 Storage Element 27:Full :VolumeTag=SU4108L4 Storage Element 28:Full :VolumeTag=SU4109L4 Storage Element 29:Full :VolumeTag=SU4110L4 Storage Element 30 IMPORT/EXPORT:Empty bacula@tigersclaw:~$ /usr/sbin/mtx -f /dev/sg4 load 1 0 Loading media from Storage Element 1 into drive 0...done bacula@tigersclaw:~$ mt -f /dev/nst1 status SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 512 bytes. Density code 0x0 (default). Soft error count since last status=0 General status bits on (4101): BOT ONLINE IM_REP_EN bacula@tigersclaw:~$ /etc/bacula/scripts/mtx-changer /dev/sg4 loaded x x 0 1 bacula@tigersclaw:~$ /etc/bacula/scripts/mtx-changer /dev/sg4 l
Re: [Bacula-users] Autochanger not changing
Am 01.04.2018 um 17:12 schrieb Sebastian Suchanek: > while still setting up Bacula (v5.2.6), I've come accross a rather > strange issue with my tape library (an Overland NEO2000) with a > LTO4-FC-Drive. When I do "fill" test with btape over multiple tapes, > everything works fine. Also, for example, when I do a "label barcodes" > command in btape over multiple slots, the individual tapes are moved > into the drive, get written and are put back into their original slot. > > But when I run a "real" backup job which spans more than one tape, the > job gets stuck as soon as the end of the first tape is reached. The last > messages from the job are: > > | [...] > | 2018-04-01 14:16:42 tigersclaw-sd JobId 111: Volume "SU4103L4" > previously written, moving to end of data. > | 2018-04-01 15:55:32 tigersclaw-sd JobId 111: End of Volume > "SU4103L4" > at 21:2548 on device "LTO4-Drive-1" (/dev/nst0). Write of 200 bytes > got -1. > > And after that, nothing happens anymore. Not even if I wait for half an > hour. > [...] In the meantime, one of my LTO1 tapes (which of course is written in the LTO1 drive of my library) managed to fill up during a backup job. And now it get's really weird: this time, the tape was exchanged without any noticable problems. This makes me wonder if the problem is maybe caused by the LTO4 drive itself. But what I didn't mention so far: during my various trial runs around this problem, I also replaced the LTO4 drive with another one. (AFAIR both of them were the same Seagate model, though...) Best regards Sebastian -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Autochanger not changing
> On Apr 1, 2018, at 11:12 AM, Sebastian Suchanek wrote: > > Hi everyone, > > while still setting up Bacula (v5.2.6), I've come accross a rather > strange issue with my tape library (an Overland NEO2000) with a > LTO4-FC-Drive. When I do "fill" test with btape over multiple tapes, > everything works fine. Also, for example, when I do a "label barcodes" > command in btape over multiple slots, the individual tapes are moved > into the drive, get written and are put back into their original slot. > > But when I run a "real" backup job which spans more than one tape, the > job gets stuck as soon as the end of the first tape is reached. The last > messages from the job are: > > | [...] > | 2018-04-01 14:16:42 tigersclaw-sd JobId 111: Volume "SU4103L4" > previously written, moving to end of data. > | 2018-04-01 15:55:32 tigersclaw-sd JobId 111: End of Volume > "SU4103L4" > at 21:2548 on device "LTO4-Drive-1" (/dev/nst0). Write of 200 bytes > got -1. > > And after that, nothing happens anymore. Not even if I wait for half an > hour. > > Here's the (hopefully) relevant part of my bacula-sd.conf: > [snip] > > Any idea what exactly is going wrong here? What can I do to track down > the reason for this error? What can I do to fix it? It is usually permissions. It it nearly always permission. I have documented my experiences here: https://dan.langille.org/ Search for mtx and mtx-loader. There are several configuration step and low level testing at the command line. This might be your best bet: https://dan.langille.org/2016/02/04/dell-tl4000-tape-library-running-btape-and-configuring-baculas-mtx-changer/ start slow. Make sure mtx-changer works. If you need to customize it, move it away from /etc/bacula/scripts/mtx-changer ... I put mine at /usr/local/sbin well away from the installed one. Make sure all the steps with mtx-changer work: load, unload, loaded, list Then make sure they work as the bacula user (your SD should be running as bacula, not root; there is no need for bacula-sd to run as root). To get mtx-changer working, first make sure mtx works. Try what I tried and make sure it all works. HTH -- Dan Langille - BSDCan / PGCon d...@langille.org -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Autochanger not changing
Am 02.04.2018 um 09:54 schrieb Kern Sibbald: Hello Kern, thank you for your reply. > First, I would recommend that you use at *most* 1MB block sizes for > LT0-1 and LTO-4 tapes. OK, I changed that for the LTO-4 drive. (I don't want go below 1MB though, because it significantly reduces write rates.) > [...] > You haven't shown your full autochanger device configuration so it will > be hard/impossible to diagnose your problem. No problem, here's my full bacula-sd.conf, only comments and passwords are removed: | Storage { | Name = tigersclaw-sd | SDPort = 9103 | WorkingDirectory = "/var/lib/bacula" | Pid Directory = "/var/run/bacula" | Maximum Concurrent Jobs = 20 | SDAddress = 10.1.0.1 | } | | Director { | Name = tigersclaw-dir | Password = | } | | Director { | Name = tigersclaw-mon | Password = | Monitor = yes | } | | Device { | Name = FileStorage | Media Type = File | Archive Device = /srv/bacula/file | LabelMedia = yes | Random Access = yes | AutomaticMount = yes | RemovableMedia = no | AlwaysOpen = no | } | | Autochanger { | Name = Overland-NEO2000 | Device = LTO1-Drive-1 | Device = LTO4-Drive-1 | Changer Command = "/etc/bacula/scripts/mtx-changer %c %o %S %a %d" | Changer Device = /dev/sg4 | } | | Device { | Name = LTO1-Drive-1 | Drive Index = 0 | Media Type = LTO-1 | Archive Device = /dev/nst1 | AutomaticMount = yes | AlwaysOpen = yes | RemovableMedia = yes | RandomAccess = no | AutoChanger = yes | Maximum File Size = 2GB | Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'" | Spool Directory = "/srv/bacula/spool" | } | | Device { | Name = LTO4-Drive-1 | Drive Index = 1 | Media Type = LTO-4 | Archive Device = /dev/nst0 | AutomaticMount = yes | AlwaysOpen = yes | RemovableMedia = yes | RandomAccess = no | Maximum block size = 1MB | Maximum File Size = 40GB | AutoChanger = yes | Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'" | Spool Directory = "/srv/bacula/spool" | } | | Messages { | Name = Standard | director = tigersclaw-dir = all | } JFTR: "tigersclaw" is the name of my server which runs (among other things) the Bacula director, storage daemon und also the client where the backup job in question comes from. (I have more jobs configured, also from other clients, but they are way to small to even fill a LTO-1 tape.) > Also the output from a: > > lsscsi -g > > would be necessary. No problem either: | # lsscsi -g | [0:0:1:0]tapeHP Ultrium 4-SCSI H63H /dev/st0 /dev/sg3 | [1:0:0:0]diskATA Samsung SSD 850 2B6Q /dev/sda /dev/sg0 | [2:0:0:0]diskATA WDC WD40EFRX-68W 0A82 /dev/sdb /dev/sg1 | [3:0:0:0]diskATA WDC WD40EFRX-68W 0A82 /dev/sdc /dev/sg2 | [7:0:0:0]mediumx OVERLAND NEO Series 0616 /dev/sch0 /dev/sg4 | [7:0:0:1]tapeSEAGATE ULTRIUM06242-XXX 1603 /dev/st1 /dev/sg5 | # > Note in general, if btape works then Bacula will work because the SD > uses the same subroutines that btape uses for reading/writing tapes. Well, that's what I expected and that's why I'm so puzzled about this error... > Consequently there may be some other problem. When the SD seems to be > stuck, you can probably get more information by doing: > > bconsole > set debuglevel=200 storage= trace=1 > mount > set debuglevel=0 storage= trace=0 > > then look at the trace file in your working directory to see what it > going on. Here's the trace file from the beginning of the job until the point where the first tape was full and Bacula got stuck: https://suchanek.de/temp/tigersclaw-sd.trace (47kB) And here ist what happend when I manually cancelled the stuck job (which worked) and try to do a "release LTO4-Drive" command in bconsole. (Which didn't work, i.e. Bacula got stuck here too.) https://suchanek.de/temp/tigersclaw-sd.trace.2 (3kB) I hope you can find anything usefull in these debug files, because I'm totally lost here... Best regards Sebastian -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Autochanger not changing
Hello Sebastian, First, I would recommend that you use at *most* 1MB block sizes for LT0-1 and LTO-4 tapes. Note, once a tape is written with a given block size in Bacula you must re-initialize that volume (write two EOF marks at the beginning) before changing the block size. You haven't shown your full autochanger device configuration so it will be hard/impossible to diagnose your problem. Also the output from a: lsscsi -g would be necessary. Note in general, if btape works then Bacula will work because the SD uses the same subroutines that btape uses for reading/writing tapes. Consequently there may be some other problem. When the SD seems to be stuck, you can probably get more information by doing: bconsole set debuglevel=200 storage= trace=1 mount set debuglevel=0 storage= trace=0 then look at the trace file in your working directory to see what it going on. Best regards, Kern On 04/01/2018 05:12 PM, Sebastian Suchanek wrote: Hi everyone, while still setting up Bacula (v5.2.6), I've come accross a rather strange issue with my tape library (an Overland NEO2000) with a LTO4-FC-Drive. When I do "fill" test with btape over multiple tapes, everything works fine. Also, for example, when I do a "label barcodes" command in btape over multiple slots, the individual tapes are moved into the drive, get written and are put back into their original slot. But when I run a "real" backup job which spans more than one tape, the job gets stuck as soon as the end of the first tape is reached. The last messages from the job are: | [...] | 2018-04-01 14:16:42 tigersclaw-sd JobId 111: Volume "SU4103L4" previously written, moving to end of data. | 2018-04-01 15:55:32 tigersclaw-sd JobId 111: End of Volume "SU4103L4" at 21:2548 on device "LTO4-Drive-1" (/dev/nst0). Write of 200 bytes got -1. And after that, nothing happens anymore. Not even if I wait for half an hour. Here's the (hopefully) relevant part of my bacula-sd.conf: | [...] | Autochanger { | Name = Overland-NEO2000 | Device = LTO1-Drive-1 | Device = LTO4-Drive-1 | Changer Command = "/etc/bacula/scripts/mtx-changer %c %o %S %a %d" | Changer Device = /dev/sg4 | } | | Device { | Name = LTO4-Drive-1 | Drive Index = 1 | Media Type = LTO-4 | Archive Device = /dev/nst0 | AutomaticMount = yes | AlwaysOpen = yes | RemovableMedia = yes | RandomAccess = no | Maximum block size = 2MB | Maximum File Size = 40GB | AutoChanger = yes | Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'" | Spool Directory = "/srv/bacula/spool" | } | [...] Any idea what exactly is going wrong here? What can I do to track down the reason for this error? What can I do to fix it? Best regards Sebastian -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] Autochanger not changing
Hi everyone, while still setting up Bacula (v5.2.6), I've come accross a rather strange issue with my tape library (an Overland NEO2000) with a LTO4-FC-Drive. When I do "fill" test with btape over multiple tapes, everything works fine. Also, for example, when I do a "label barcodes" command in btape over multiple slots, the individual tapes are moved into the drive, get written and are put back into their original slot. But when I run a "real" backup job which spans more than one tape, the job gets stuck as soon as the end of the first tape is reached. The last messages from the job are: | [...] | 2018-04-01 14:16:42 tigersclaw-sd JobId 111: Volume "SU4103L4" previously written, moving to end of data. | 2018-04-01 15:55:32 tigersclaw-sd JobId 111: End of Volume "SU4103L4" at 21:2548 on device "LTO4-Drive-1" (/dev/nst0). Write of 200 bytes got -1. And after that, nothing happens anymore. Not even if I wait for half an hour. Here's the (hopefully) relevant part of my bacula-sd.conf: | [...] | Autochanger { | Name = Overland-NEO2000 | Device = LTO1-Drive-1 | Device = LTO4-Drive-1 | Changer Command = "/etc/bacula/scripts/mtx-changer %c %o %S %a %d" | Changer Device = /dev/sg4 | } | | Device { | Name = LTO4-Drive-1 | Drive Index = 1 | Media Type = LTO-4 | Archive Device = /dev/nst0 | AutomaticMount = yes | AlwaysOpen = yes | RemovableMedia = yes | RandomAccess = no | Maximum block size = 2MB | Maximum File Size = 40GB | AutoChanger = yes | Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'" | Spool Directory = "/srv/bacula/spool" | } | [...] Any idea what exactly is going wrong here? What can I do to track down the reason for this error? What can I do to fix it? Best regards Sebastian -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users