Basically, tape has a very very high latency (on the order of minutes to hours) for random access and it has a very low number of writes (usually a few dozen) before you need to copy it to a new medium.
The drives are also quite expensive and if you use them for backups, you need to keep one ready in case the other borks it but you need the tape's data.
Lastly you need specialized tools for access since most average tools will mishandle the tape.
Not sure where you've got the 'few dozen' number from - that's not to my experience. Tandberg quote "1,000,000 passes on any area of tape, equates to over 20,000 end to end passes/260 full tape backup" http://www.tandbergdata.com/default/assets/File/Data_Sheets/...
Atleast from what I've been told and from experience, if you rotate over master backup tapes every few months, the tape will be almost 6 years old by the time it reaches the first two dozen end to end writes, that usually means newer LTO standards, newer drives and newer tapes on the market to replace them with.
> 1,000,000 passes on any area of tape, equates to over 20,000 end to end passes
What in the world does that first number mean?
My best guess is that it's some nonsense math based on the fact that the tape head contacts 32 tracks at once. So writing a full tape is 1 "full pass", which equals 208 "end to end passes" as the tape feeds back and forth, which equals 6656 """passes on any area""".
My LTO-7 drive needs about 2 minutes from one end of the tape to the other, so that is the maximum latency when the tape is already loaded. Adding another minute to manually find and load a tape, would reach a 3 minute latency.
So a few minutes of latency in the worst case, yes, but certainly not hours of latency, unless you must drive a car to an off-site location, but that would be the same for a HDD or optical disc stored in another place.
Few hours of latency are expected when backups stretch across multiple tapes and recatalog of the tapes is required (the original backup server is dead). Having to do it manually with a single reader because your tape library is dead will slow the operation even more.
That is a problem of the backup software, not of the tapes. I have a custom program that generates an index with all the files on all my tapes and which updates the index after any tape write. I can determine in a second the location of any file, so I know immediately which tape cartridge must be loaded to retrieve anything.
The file index is actually a relational database table with a lot of metadata about the files, including: position in the tape collection as tape number + file number, name, path name, modification time, length, content hash (to identify duplicates) and a set of keywords and tags, to be able to search for a file even when the name is not known, or to be able to retrieve sets of files.
The files written on the tape are grouped in compressed archive files, but the database with metadata is about the files inside of those archive files.
Obviously, the file index itself is also backed up regularly.
That's essentially what most backup software is doing. Restoring the index database from the tape and matching the physical tapes in the set to their logical names in the index gets complex and time consuming when you have many tapes in a set.
It gets worse when you have to use more than one set because there is too much data to have full backup daily and you also need to index few incremental sets.
Restoring the index database from a tape would be needed only if the SSD where my database is normally located would become defective, which should be a very seldom event, especially if it is replicated on a few SSDs.
In my custom program & file database, I only use physical tape names, i.e. the names that I write on the labels of the cartridges. Either the program tells me what cartridge to load in the drive, or I inform it what cartridge I have loaded (e.g. for a new cartridge). I see no reason for a logical name. If I would ever copy a tape on another and I would discard the original tape, it would be trivial to substitute the name in the database.
Maybe for a large enterprise maintaining a comprehensive file database could be time consuming even in the best implementation, but I doubt it.
In my experience, keeping an up-to-date file database for about 120 TB of content that increases by about 10 to 20 GB per day still takes a negligible time.
While I have worked in a few large companies where a lot of data existed, in all small- and medium-sized companies (less than 100 computers) that I have seen there was less backup data than that (not counting things like standard disk images with the OS and with SW, which do not belong in periodic backups and which where shared, being identical for various classes of employees).
Usually when someone gives latency numbers, they're not including the "server died and everything has to be rebuilt" case. Even SSDs might take days to return data in that case!
Plugging a SSD to a new server and restoring a file should take few minutes, since the filesystem table is accessible instantly. With tapes you either have the catalog saved outside the media or you need to read it from the media. Depends on the type of the backups taken and the amount of data, this process can take much longer than expected naively.
The post above was about the latency of random access to a file, not about the duration of a restoring operation.
The tapes have the fastest sequential transfer speed of any alternative, so the restoring duration should be better than from anything else, if the restoring software plans correctly the sequence of retrievals.
It is true that if the backup software is not clever, you could waste a lot of time to determine what you must restore and where is it. However, this has nothing to do with the tapes, the same can happen with backup on HDDs if the backup software is equally bad.
I am not sure what you mean by having lots of more tapes than reader, as that is the point of tape storage and the cause of it low cost per terabyte.
The only way that I could understand that phrase as a disadvantage for tapes is that when you would need to read as fast as possible e.g. 300 TB with one reader, that would need 10 days, but if the 300 TB were stored on 25 HDDs and you would also have 25 spare computers and some technicians that could open the computers and connect the HDDs inside them and you would also have an 100 Gb/s Ethernet network from those computers to the destination of those 300 TB, then yes, you could read the 300 TB 12 times faster that with a single tape reader.
However, such circumstances seem too unbelievable. For such a huge organization it would be more realistic to buy immediately e.g. 3 more readers to reduce the reading time from 10 days to 2.5 days.
On the other hand, if the 25 HDDs would have been located from the beginning inside a backup system, then that system would have had a price with at least 5 digits, far higher than the cost of a tape backup system, and unless it would have been connected by 100 Gb/s or at least 25 Gb/s Ethernet, its speed could not have been much higher than that of a single tape drive.
Well, they are tightly coupled. If you only have one tape to consider then fine - whatever works and the discussion would be pointless.
Also, why on earth would you need 25 spare computers for 25 drives??? 25 drives fit into a single 4U chassi. A single operation and everything is done.
Seeking a file on a harddrive is about 7ms. Seeking 25 drives is also about 7ms. But will be quite the operation for a tape system.
You don't just "buy three more readers", you are likely making use of tape robots and fitting them into your infrastructure probably isn't an afternoon of work. And the whole cost benefit of tapes greatly rely on the fact that you don't have to. Which is also why the latency skyrocket. You still want to perform your backups of course, maybe doubly so because of any unforeseen secondary effects that whatever caused the restore process might lead to - which will compete with precious time.
I'd love to use tape, but the cost is prohibitive and you really want to verify your backups so for home use it is quite the hassle. In my opinion. But if I stumble on a great deal, sure! It'll be fun.
> why on earth would you need 25 spare computers for 25 drives??? 25 drives fit into a single 4U chass
I have already mentioned that with other words at the end of my reply and in that case you will not have a speed 25 times higher, but maybe at most 4 times higher than a single HDD, i.e. twice higher than a single tape drive.
Maybe I misunderstood, but the initial posting mentioned a restoring operation from tapes that was slow and my point was that using HDDs is unlikely to make it faster. For a restoring operation the duration will be dominated by sequential transfers, not by seeking, so tape drives would be faster than HDDs, unless you use ridiculous resources, like in my example with a computer per HDD and with a network fast enough to aggregate the data from all computers.
If we are talking about general-purpose data storage on tapes, then obviously, what is frequently accessed should be on SSDs, because the average seek time for a file stored on tape will be between 1 minute and 2 minutes.
I suppose that there might exist applications where there exists a quantity of data so large that it would be too expensive to be stored on SSDs and with worst case latency requirements so severe that it cannot be stored on tapes, so you have to use HDDs. However, in some 40 years of using all kinds of computer systems in many companies, I have never encountered such an application. Everything I have seen could be better handled by a combination of SSDs and tapes, without any HDDs. The only problem with tapes is the prohibitive cost of drives, which limits their use to data sizes of at least 50 to 100 TB, unless long term storage reliability is more important than the cost.
