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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
