undefined

points

[-]

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

by Teever52 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.

by f1shy20 minutes ago|

parent|

[-]

Tapes were constantly kept in the data center, so constant temperature and humidity 25C/50%. As I said, Tapes were changed after N uses, drives properly serviced. So if you leave them at home, in the sun in summer and in winter expose them to 10C with humidity from 10% to 90%, old drives, never clean heads… IdK That all being said, when I started working there, in my ignorance, I said “TAPES?!?! They are not reliable” due to my experience with audio tapes. But I was laughed at, and they told me about people putting 10 9 track spools in a car [0] (by the way, the same we used for billing backups!) and they went literally thousands of miles driving on partially dirt roads, in summer w/o AC, doing updates to systems, and also never ever had an issue. They were so sure they would work, that they did not take a second set, even when driving 1000 miles, and a read error would mean going back!!!

[0] https://en.wikipedia.org/wiki/9-track_tape

by bartread26 minutes ago|

parent|

prev|

[-]

I suppose there could potentially be magnetic factors at play as well.

by ghshephard4 minutes ago|

prev|

[-]

I used to do a ton of data-retrievals during litigation - pulling Iron Mountain LTO tapes back by the container (24 per container) - and restoring email and other data for the lawyers to comb through. We had a smallish 48-tape library, and this would have been 2003 - so old school LTO-1 I'm guessing (?).

Data was only 3-4 years old at most, but there was never a recovery failure - at least one that was visible during the restore process.

Oh - important data-point - we never re-used tapes. It was one-and-done-and-off-to-iron-mountain. (That eventually would have changed - but we were only 4 years into our tape-rotation when I left)

Anecdote of 1, but it was over probably 10+ restores of data. Not certain how many tapes were actually read - we would just jam them in 24 at a time and let the index figure out which ones to restore from.

The caution to validate backups by doing constant restore + validation is a good one though. Nobody cares about backups, it's the restores they want.

by mapt1 hours ago|

prev|

[-]

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?

by throw0101d1 hours ago|

parent|

[-]

> 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...

by londons_explore1 hours 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.

by btown2 hours ago|

prev|

[-]

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

by bob10292 hours ago|

parent|

[-]

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.

by jfindley2 hours ago|

parent|

prev|

[-]

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.

by marklar4232 hours 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.

by shiftpgdn2 hours ago|

parent|

prev|

[-]

[flagged]

by dang2 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

by shiftpgdn2 hours ago|

parent|

[-]

Sorry.

by DetroitThrow1 hours ago|

prev|

[-]

Are there any recommended alternatives to IronMountain nowadays?

by shiftpgdn2 hours ago|

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.