Bacula-users

Re: [Bacula-users] Who is right about the tape size: Bacula or the tapeloader??

2011-09-01 12:19:53
Subject: Re: [Bacula-users] Who is right about the tape size: Bacula or the tapeloader??
From: Stefan Michael Guenther <s.guenther AT in-put DOT de>
To: Alan Brown <ajb2 AT mssl.ucl.ac DOT uk>
Date: Thu, 1 Sep 2011 18:17:06 +0200
Hi Alan,

THANKS for the long list of suggestions! It will check this during the next 
days and hopefully send positive results to the list.

Stefan

-----Ursprüngliche Nachricht-----
An:     Stefan Michael Guenther <s.guenther AT in-put DOT de>; 
CC:     John Drescher <drescherjm AT gmail DOT com>; bacula-users AT 
lists.sourceforge DOT net; 
Von:    Alan Brown <ajb2 AT mssl.ucl.ac DOT uk>
Gesendet:       Do 01.09.2011 18:10
Betreff:        Re: [Bacula-users] Who is right about the tape size: Bacula or 
the tapeloader??
> 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