This is really, really, dangerous advice unless you're following proper archival practice and have made multiple copies which are regularly checked for bit errors. For all media, but particularly for CD-Rs, you have to be very careful about environmental conditions – a few degrees temperature difference makes a difference for how fast the dye degrades and unless you actually monitor this, it's easy to have that problem without noticing it until things start failing.

For a small user, you have the extra concern of betting large on a single production run from a single vendor. If you care about archival, you'd really want to burn multiple copies using discs from different production runs and, preferably, different manufacturers.

(This is, of course, why I'd really recommend using CD-Rs only in conjunction with a different technology such as AWS Glacier which has a completely different set of failure modes)

There's actually a lot less commonality in a single production run than you'd think, or so I believe having analyzed Taiyo Yuden disc hub numbers. Different physical machines, I suspect. But of course the "chemistry" will be roughly the same, and thus a whole batch or more could go bad early. Although one might hope they do accelerated aging tests on their production.

You are of course correct about the precautions that have to be used, but there's screw cases for everything you can use to back up your data. I was merely responding to the assertion that CD-Rs are entirely unsuited for archival purposes, and backed it up with my own experiences over a decade and a half.

Me, I live a hair's breath from Tornado Alley, and use multiple means to backup my data, local discs, disks in another room (which got trashed enough to be unreliable in a tornado http://www.ancell-ent.com/1715_Rex_Ave_127B_Joplin/images/) which I've switched to LTO-4 tape, some of which live in a safe deposit box, and the really important stuff offsite to rsync.net (which saved the only important data totally lost locally from the tornado, or at least without $$$ to a data recovery firm). And of course the CD-Rs, which at some point I'll start putting into the disk and LTO bases system.

> Although one might hope they do accelerated aging tests on their production

The experienced storage admins I know share that hope but don't trust vendors not to get it wrong. It's just too easy to miss a factor which turns out to matter.

> I was merely responding to the assertion that CD-Rs are entirely unsuited for archival purposes, and backed it up with my own experiences over a decade and a half.

Question: have you done bit-level checksum validation on that old media or is that just the ability to read without errors? There's a little bit of error correction built into the format but I wouldn't trust it for anything important.

Bit level CRC-32 checksum validation, absolutely. (Which is actually probably marginal for the file sizes concerned, but that's the standard everyone uses.)

However my words are coming across in this discussion, I'm really not a very trusting guy! Many of my early computer experiences were in the early '80s with surplus hardware from the '70s, including a PDP-11/45 that was a bit beyond the 300th DEC manufactured. Of course everyone used magtape back then for backups, and those were quite reliable (originally intended to be reliable off-line storage).

ADDED: and there are other precautions to take. E.g. I only bought my optical media in April and October, to minimize the environmental stress during shipping.

> Bit level CRC-32 checksum validation, absolutely. (Which is actually probably marginal for the file sizes concerned, but that's the standard everyone uses.)

In the digital preservation community, the standard is at least MD-5 / SHA-1 and most people are moving to SHA-256/512. With a CRC-32 check you're likely to get false-negatives for modern data volumes and there are disturbing reports of CRC failures at higher than expected rates[1] which suggest that the best answer is using multiple, cryptographic hashes particularly since the computation has effectively been free for a least a decade except on unusually CPU-starved storage hosts.

1. I don't recall the paper but I believe it was a followup to http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigco...