Anyone that's never had the (dis)pleasure of working with tapes, there's some gotchas to know about before archiving and forgetting about it.

When you create an archive, do not skip the step of reading it back. I'm not talking about just having the system confirm it is readable. I mean actually restoring the data from the tape. I've had tapes fail to retrieve data off of the tape even though the writing app confirmed it was readable.

Drives can have issues reading data written by another drive. Drives can have issues reading a tape it wrote itself.

Why write one when you can write two at twice the time/cost? In all of my experience with tape, I've never written just one tape. In the early days of DVDs, the images were written to LTO to send to have the discs pressed. Two were always sent on the chance one wasn't readable and schedules were so tight that the loss of a couple of days to send a new tape would wreck delivery dates. Another facility wrote three tapes: one kept on site, one sent to IronMountain, one sent to the client directly. Plenty of occasions saw the local copy unreadable and the IronMountain copy was retrieved. These were managed by large robotic tape libraries so each tape was written in a different drive at the same time so it was 3x cost while only 1x time.

Use the drive cleaning cassette as recommended. Your dirty heads can cause the data to not be written/read correctly depending on which head is dirty. If you're having issues reading, clean the heads before giving up on the tape. If you're having issues reading a tape just written, do not think someone else will be able to read it.

Ensure whoever might be using a tape you've written understands what was used to write the tape. Not all archivers are compatible. If you use the tar command to write to tape, people using a GUI app won't be able to read it.

▲

f1shy 41 minutes ago | parent | next [-]

I have worked with 5 different LTO tapes versions, 5 different other cassette formats (DAT, DDS, etc), and open spools… never, ever, ever in the 15 years had ANY problem (I’ve probably used 1000 of them). We did cycle them very often, we did have proper maintenance of the drives, through. Now that, compared with RAID Disk arrays, where we had monthly failures, was much better. Also I would not trust the „semi-permanent“ NVMEs, where after 1 year without power they get basically reset

	▲	Teever 2 minutes ago \| parent [-]
		When I hear wildly differing stories like this I often wonder how much environmental conditions play a factor in the different experiences that people have. Perhaps one of you is living in a much more humid and/or hot environment that causes issues with the writing process.

▲

mapt an hour ago | parent | prev | next [-]

Is there some reason that the data is not written to a section of tape using one head, and then read off of that same tape 1 inch (hundreds of milliseconds? tens?) later using a separate head for verification, before it's tucked back into the spool?

	▲	throw0101d 13 minutes ago \| parent \| next [-]
		> The read-write head has 32 read-write elements. Each element contains a write component sandwiched between two read components – one for reading, the other for read-after-write checking. The overall read-write head reads or writes 32 adjacent tracks at once. This group of 32 adjacent tracks running the length of the tape is called a wrap. The write tracks are partially overlapped, leaving a clearly readable read track, narrower and in the middle of its write track. This track overlapping is called shingling after shingled roof tiles, and is a way of cramming more write tracks into a data band to increase the tape’s capacity. * https://www.blocksandfiles.com/tape/2025/07/29/why-lto-10-fe... > The tape drives use a strong error correction algorithm that makes data recovery possible when lost data is within one track. Also, the head assembly includes separate read heads positioned just "behind" each write head, to verify the data just written without making a separate verification pass. This allows the drive to write a second copy of any data that fails the verify without the help of the host system. * https://en.wikipedia.org/wiki/Linear_Tape-Open#Logical_struc...
	▲	londons_explore an hour ago \| parent \| prev [-]
		I think the issue arises if the tape is out of alignment - ie. too high or too low. Then it writes in the wrong spot, reads in the wrong spot, so you think all is good... But when you try to read it back with a different, correctly aligned machine, it is unreadable.

▲

btown 2 hours ago | parent | prev | next [-]

From your experience are any of the big cloud providers more effective/careful at this than others?

▲

bob1029 an hour ago | parent | next [-]

The big cloud providers use something like erasure coding across a collection of tapes (or hard drives) to preserve information. If you've ever downloaded something from usenet and restored it with quickpar, this is basically the same idea. Every physical cartridge gets a chunk of the file. Depending on parity settings you would have to lose many tapes distributed across an arbitrary # of locations to actually lose any data.

▲

jfindley 2 hours ago | parent | prev | next [-]

Note that the hardware the big cloud providers use for tape archives is very different from the devices the GP poster appears to have used, and usually have robust verification systems.

In addition the need for cloud providers to comply with userdata erasure means they have to frequently test their ability to read and write their backups - which should increase your confidence in their correctness. Yes problems can and do still happen, but IME far less often than the more traditional tape setups GP describes.

	▲	marklar423 an hour ago \| parent [-]
		Erasure can be done much more efficiently with crypto erasure, where you encrypt the user data and just delete the key when users request deletion. This way you don't need to spend expensive tape vault / library time rewriting a tape.

▲

shiftpgdn 2 hours ago | parent | prev [-]

[flagged]

▲

dang 2 hours ago | parent [-]

Can you please stop posting unsubstantive comments and flamebait? Your account has been doing a lot of this and we've asked you this before.

https://news.ycombinator.com/newsguidelines.html

	▲	shiftpgdn 2 hours ago \| parent [-]
		Sorry.

▲

DetroitThrow an hour ago | parent | prev | next [-]

Are there any recommended alternatives to IronMountain nowadays?

▲

shiftpgdn 2 hours ago | parent | prev [-]

Symantec Backup Exec was genuinely one of the worst pieces of software I have ever had to use. Later in life I got to use the IBM Storage Archive setup with much larger tape libraries which still sucked but my god the level of competency difference between the two applications was insane.