Accessing Tape Drive on another linux system

[Joel Jaeggli]

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 at darkwing.uoregon.edu
GPG Key Fingerprint:     5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2