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!

Realistically it's 3 minutes.

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 difference is that you typically have lots of more tapes than readers.

Gmail had an event with data loss in their early days and restoring from tapes took (from memory) many weeks, if not months.

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.

All fine and dandy if you have more drives than concurrent retrieve jobs or requests...

Hours comes into play when you have a queue of retrievals and many tapes....