Stefan Michael Guenther wrote:
> Hi,
> 
>> you do not impose a limit on how many bytes that bacula can write to a
>> tape bacula will write as many bytes as it can up until it hits the
>> first tape write error. At this point bacula assumes the tape is full.
>> Check your dmesg to see if there are any problems. Also try a brand
>> new LTO3 tape.
>>
> here is the corresponding output of dmesg:
> 
> [    7.806343] st 3:0:1:0: Attached scsi tape st0
> [    7.806345] st 3:0:1:0: st0: try direct i/o: yes (alignment 512 B)
> [ 3295.705344] st0: Block limits 1 - 16777215 bytes.
> [ 3299.906724] st0: Failed to read 65536 byte block with 64512 byte transfer.
> [ 3856.794626] st0: Failed to read 65536 byte block with 64512 byte transfer.
> [ 4027.852762] st0: Failed to read 65536 byte block with 64512 byte transfer.
> [ 4173.406028] st0: Failed to read 65536 byte block with 64512 byte transfer.
> 
> And, yes, we already tried it with a brand new tape - same result.


1: As others have stated, "Maximum Volume Bytes" should not be used on 
tape volumes.

2: Nor should "Maximum Block Size" - this is imposing significant 
overheads all by itself and is intended for old-school tape drives using 
fixed block sizes. Avoid using unless you really have to. (You may find 
tapes written using this parameter are not readable once it is removed. 
It is best to run full backups on everything if you remove this setting)

3: In addition I would not use "Maximum Volumes" or "Maximum Volume 
Jobs" unless you have specific reasons for them.

4: I would add "Maximum File Size = 10GB" (This is the size of each file 
block on the tape. The default is 1Gb, which is a bit small for LTO3 and 
  newer.

5: Make sure the max network buffer size is the same everywhere and 
don't exceed 65536. (If this is changed older tapes written with 
different values will not be readable)

6: find the matching /dev/sg for your tape drive and Use "smartctl  -H 
-d scsi -l error /dev/sg{X}" to see if any errors are being reported 
after tape write

7: Run a cleaning tape through the drive.

8: Make sure your spooling is working ok (best method is to use 
dedicated spool drive(s) - ssds are better for keeping up with LTO demands.

9: What size files are you backing up? Smaller files will result in less 
data being reported due to fixed per-file overheads which bacula doesn't 
report as part of the save set.

Notes:

The GB sizes quoted on LTOs are decimal based, so the maximum 
uncompressable data you'll fit on a LTO3 is about 380GiB.

If you are backing up a lot of small files it's not uncommmon to lose 
another 20-25%.

Using fixed block sizes will eat a lot of tape in blocking overheads

LTO uses a serpentine layout, so getting 250Gb means that your drive has 
spooled to the end of the tape and back at least 4-5 times. That in turn 
means that not reaching the uncompressed maximum is down to losing tape 
into overheads (see below) or error rewrites due to vibration or 
dirty/misaligned heads - LTO drives have separate read/write heads and 
read data as soon as it's written in order to detect errors/rewrite the 
data - if this is occuring then you'll see it using smartctl.





------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users