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.