subject:"\[Bacula\-users\] Autochanger not changing"

Re: [Bacula-users] Autochanger not changing

2018-05-08 Thread Sebastian Suchanek

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

2018-04-13 Thread Sebastian Suchanek

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

2018-04-09 Thread Kern Sibbald


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

Re: [Bacula-users] Autochanger not changing

2018-04-08 Thread Sebastian Suchanek

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:~$

Re: [Bacula-users] Autochanger not changing

2018-04-08 Thread Sebastian Suchanek

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

2018-04-07 Thread Dan Langille

> 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

2018-04-02 Thread Sebastian Suchanek

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

2018-04-02 Thread Kern Sibbald


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

2018-04-01 Thread Sebastian Suchanek

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

Re: [Bacula-users] Autochanger not changing

Re: [Bacula-users] Autochanger not changing

Re: [Bacula-users] Autochanger not changing

Re: [Bacula-users] Autochanger not changing

Re: [Bacula-users] Autochanger not changing

Re: [Bacula-users] Autochanger not changing

Re: [Bacula-users] Autochanger not changing

Re: [Bacula-users] Autochanger not changing

[Bacula-users] Autochanger not changing

9 matches

Site Navigation

Mail list logo

Footer information