Wanted: LTO-5 tapes (used?)

Grant Taylor cctalk at gtaylor.tnetconsulting.net
Fri Sep 28 18:11:26 CDT 2018


On 09/28/2018 04:14 PM, Andrew Luke Nesbit via cctalk wrote:
> I'm designing and implementing a backup regime according to a 3-2-1 
> strategy.  I've never used tape before but LTO-5 was recommended to me as 
> being hands-down the best option for long-term backup or archival storage.

I know a number of people that use LTO, some of whom use LTO-5.

> LTO-5 has been recommended to me a few times, I didn't ask too many 
> questions.  I thought it would be better to learn more about what it 
> is, and about tape backup and archiving in general so that I could 
> contextualize my questions and understanding better.

Fair enough.

> As it happens, I'm now seriously looking into tape.  Off the top of 
> my head I imagine the following things to be the potential attractions 
> of LTO-5:
> 
> -   Is LTO-5 somewhat of the standard by which other LTO tape systems 
> are judged?

LTO is a type of tape.  The 5 vs 4 vs 3, is the generation.  So LTO-5 is 
the fifth generation of LTO tape.  Newer generations typically hold more 
data and / or are faster to access.  Benefits of the evolution of the 
technology.

> -   Is bang for the buck the primary attraction of LTO-5?

"bang for the buck" is subjective.  Are you talking raw capacity?  Raw 
Read / Write speed?  Seek time?  What?

I'm guessing that it's better $ per byte.

> -   Is LTO-5 the best option when a priority is to use open hardware 
> and open source drivers to interface the tape drive to the host?

I'm probably not qualified to answer that.

It's my understanding that many manufacturers make LTO drives (of 
varying generations) with varying types of interfaces.  I'm guessing 
that (some version of) SCSI and / or Fibre Channel are the most common 
interfaces.  With the former being directly attached to a host and the 
latter being attacked to a SAN that can be accessed by multiple hosts.

> I did some research and got the impression that HP LTO-5 Ultrium RW 
> 3 TB cartridges are more-or-less the standard when it comes to the 
> actual tapes.

It's important to know if you're looking at uncompressed / native / raw 
capacity.  Many drives and / or backup applications will (try to) 
compress data before it's written to tape.  It's not uncommon to see 
some claims of up to 2:1 compression ratios.  You might get this with 
text.  I doubt binary data will get it.  Your mileage may vary.

> From my perspective, 3 TB doesn't seem like a huge amount of storage. 
> Especially when, for example, a 12-disk array of 8-10 GB HDD's is 
> hardly uncommon.  Am I completely misinterpreting the way that tapes 
> are supposed to be used when making backups or archiving such an array? 
> Obviously I'm not going implement an intricate differential or incremental 
> backup or archiving solution until I've got full backups working properly.

My experience has been to use some sort of incremental backup strategy. 
Full backups of the entire data set usually take prohibitively long and 
can't be done in normal backup windows.  (There is an entire 
sub-industry for optimizations here.)

I would recommend you at least learn about the traditional grandfather, 
father, son backup methodology.  An alternate is incremental forever, 
which does one really big incremental (from zero) and then deltas 
between each backup run.

You probably want to do some reading about how tapes actually store 
sessions.  Specifically, can you continue writing to the tape after you 
finish a backup?  Can the next backup start writing to the same tape 
after the point that the first backup stopped at?  Or do you end up 
wasting tape.

> Comments and opinions are well appreciated.

I'd suggest you look into something that can manage backups for you.  It 
is possible to do it yourself, with something like tar, but you will be 
doing a lot of manual effort.

That being said, I have rolled my own backups using tar and the raw SCSI 
tape device.  But I've been told I'm a masochist.  ¯\_(ツ)_/¯



-- 
Grant. . . .
unix || die


More information about the cctalk mailing list