In the message dated: Thu, 28 Feb 2008 11:21:31 EST,
The pithy ruminations from Bob Hetzel on
<Re: [Bacula-users] Volumes marked with Error> were:
=>
=> First a quick note... drives LTO 2nd generation and newer should not
=> shoeshine unless you're really running way to slow a cpu for what else
=> is going on with the computer.
Huh? That's exactly the opposite of everything I've heard from drive
manufacturers, from Curtis Preston, etc.
The faster the drive, the more difficult it is to supply it with enough data to
prevent shoe-shining. In general, the limiting factor isn't the CPU of the
backup server, but the disk drives that are supplying data and the network
connection[s] end-to-end between the data source and the tape drive.
For example, an LTO-3 drive supports a native (uncompressed) throughput of 80MB/
sec. This means that, for "average" data that the drive will be compressing, the
server must supply data at the rate of 120~160MB/sec to keep the drive running
at full speed. This is not trivial. Many tape drives are capable of variable
write speeds, deliberately slowing down when the incoming data rate is
insufficient, in an attempt to avoid shoe-shining. AFAIK, the minimum data rate
that LTO3 drives must receive in order to avoid shoe-shining is ~35MB/s. This
can be difficult to achieve in a real-world environment, such as reading data
from a server in active use, sending that data over a network (even GigE) that's
used for other tasks, and competing with other streams of client data being sent
the same backup media server (ie., storage director).
My simple rule of thumb:
If the data source is a single spindle (ie. not a RAID device), then
you will not be able to feed an LTO3 drive fast enough to prevent
shoe-shining. With a single disk, even an LTO2 drive may shoe shine,
depending on the overall system and the compressibility of the data.
http://www.open-mag.com/features/Vol_117/LTO3/LTO3.htm
http://www.datastor.co.nz/Datastor/Promotions.nsf/4a91ca5e06d20e15cc256ebe0002290e/d954d1c5e5e6df09cc25723b00740956/$FILE/When%20to%20Choose%20LTO3%20Tape%20Drives.pdf
=>
=> If the room air temp is less than 85 degrees or so it's unlikely in a
=> tape autoloader cabinet (i.e. good airflow by design) that you've got a
Yep.
[SNIP!]
=>
=> Also, have you considered spooling everything? I know this may slow
=> down your backups on fast servers but the increase gained in doing more
=> than one thing at a time may balance this, especially on incrementals.
Absolutely. You may be able to avoid shoe-shining by spooling data from
individual servers onto a fast RAID device on the storage director. This will
probably produce a small decrease in the backup time for individual servers,
and a significant decrease in the aggregate backup duration for multiple
concurrent clients.
=>
=> > Date: Wed, 27 Feb 2008 09:31:40 +0000
=> > From: Bob Cregan <[EMAIL PROTECTED]>
=> > Subject: Re: [Bacula-users] Volumes marked with Error
=> > To: bacula-users@lists.sourceforge.net
=> > Message-ID: <[EMAIL PROTECTED]>
=> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
=> >
=> > Hi,
=> > I am running the following
=> >
=> > Director, Storage deamon 2.2.6. The library is an Overland Arcvault 24
=> > (LTO3)
=> > Most clients (about 30 ~ 8TB in total) are 2.2.4
=> >
[SNIP!]
=> >
=> > There is one thing that I thought may have a bearing. I am using a
=> > mixture of spooled and non spooled backups. Some of the backups are on
=> > old hardware, consist of lots of very small files (several million ~1Kb
=> > html files ) and the resulting very poor throughput can result in a big
=> > shoeshining problem - I generally spool these. Other ones are large
=> > database files with good throughput so I run these direct to tape. The
=> > spool files can be as big as 80Gb.
=> >
I have a very similar arrangement. I spool data from ~25 clients (some on GigE
and some on 100Mb) to 3 spool files on my storage director. The spool files are
located on separate LUNs on a fast RAID array. Each spool file is limited to
60~90GB.
In my case, the only client which writes to tape directly (without spooling) is
the storage director (which is also a file server with about 3TB). I haven't
checked backup performance for "collisions" between unspooling data and a
direct backup of the sd.
=> > The director allows four concurrent jobs, I have two tape drives one of
=> > which is generally Incrementals only the other Full backups only.
=> >
=> > Can there be a problem if a spool file is despooling and a "direct to
=> > tape" job also need to write to the tape? Should I spool all my jobs?
=> >
Hmmm.... I'm not ready to suggest that, but I am very interested in hearing
about your findings if you do try it.
=> > Any advice would be very welcome.
=> >
=> > Thanks
=> >
=> > Bob
=> >
=>
----
Mark Bergman [EMAIL PROTECTED] 215-662-7310
System Administrator Section of Biomedical Image Analysis
Department of Radiology University of Pennsylvania
PGP Key at: https://www.rad.upenn.edu/sbia/bergman
The information contained in this e-mail message is intended only for the
personal and confidential use of the recipient(s) named above. If the reader of
this message is not the intended recipient or an agent responsible for
delivering it to the intended recipient, you are hereby notified that you have
received this document in error and that any review, dissemination,
distribution, or copying of this message is strictly prohibited. If you have
received this communication in error, please notify us immediately by e-mail,
and delete the original message.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
