On Fri, 23 Dec 2005, Mike McCarty wrote:
You have to benchmark whether udp or tcp nfs performance is better than
stuffing a bit-stream through a tcp pipe. I generally find that If I can
use really large block sizes (say 2MB) that the pipe is faster, of course
I'm also backing up tens of terabytes...
Read what I wrote about streaming tapes. To make sure that everything
got onto tape, I'd do a two-stage process. Eats a lot of disc, but
how much is your backup worth to you?
The situation isn't quite as dire as it used to be, back when 1/2" trape
transports were for big dec or ibm servers and pc's pretty much had
nothing but 1/4" (I was storing things on tk50s in those days).
To look at the particular hardware that I use currently. the higher-end
lto2 drives have a native speed of 32MB/s (which is actually about 3.4
meters per second of tape) but the drive is also capable of stepping down
through 13 additional linear speeds in order to continue to stream without
repositioning, depending on the particular drive it may have a 32 or 64MB
of buffer to allow time for transition without having to stop.
Obviouslly in terms of a given backup operation you want it go as fast as
possible so that you can free up the drive for something else sooner, but
also so that the servers are actually doing their real jobs as opposed to
constantly supporting this backup process. notwidthstanding that however
not having to worry about actual throughput on a momentary basis reduces
some of the engineerinng challenges quite a bit.
I will also agree with you that a two stage process is a good way to work
it. data-recovery from a near-line disk farm is a heck of a lot faster
than from tape, prinicipally we use tape principally as a disaster
recovery method.
Tens of TB? Man!
Mike
--
--------------------------------------------------------------------------
Joel Jaeggli Unix Consulting joelja@xxxxxxxxxxxxxxxxxxxx
GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
