Hi, Gene Heskett wrote: > > I have 3 100 disk spindles of dvd's bought years ago, that are > > no longer recognized in any of the 4 or 5 dvd writers I have, but one box > > of rewritables about the same age, stored n a light tight cardboard box, > > will likely outlast me.
Unwritten write-once media can indeed get unusable when exposed to light over a long time. But i have not heard of written DVD getting bad from indirect light. (Direct sun light is deadly for many things.) > > Lesson learnt, do not use optical media for long term storage unless > > stored in tin boxes like AOL gave away billions of 20 years or more ago. I have a little locker for my media stock. But a substantial number of my written media are not completely protected from stray light. David Christensen wrote: > I have been burning archive DVD-R discs for ~14 years and storing them in a > drawer (e.g. darkness). I checked the oldest just now and it reads okay. That's my experience too. I check by MD5 which are stored on the medium together with the data. If a medium turns out unreadable then in nearly all cases directly after burning. Lesson learnt: Never overwrite the two youngest backups. > I have heard of CD discs disintegrating if the lacquer is scratched: > https://en.wikipedia.org/wiki/Disc_rot This never hit me. But i keep my media away from high moisture, corroding chemicals, and abrasive substances. > I have heard that RW media has a shorter lifespan than R media. Not to my experience. I have 4x CD-RW from 2002 (*), DVD+RW from 2004, and BD-RE from 2008 which still work for backups. From time to time a medium dies during writing. This seems not to be closely related to age, though. (*) I have older 2x CD-RW, but no burner any more which would accept them. They can be still read. > Does anyone have experience with M-Disc media? Only by reports of libburn users which say that M-Disc works like the other media. Their durability can hardly be evaluated, given that normal media seem to last for more than 2 decades without much problem. I think the better alternative for archived data would be to make several identical copies and to checkread them in intervals of a few years. As soon as one of the copies shows problems, make new copies of the healthy ones. Payload checksums on the medium give extra trust, although i only once in my life watched a DVD giving bad data without an SCSI error. That was reproducible with only a single drive. All others either read the affected 32 KiB chunk correctly or threw error. Having more than one drive helps a lot when the read quality is on the edge. A sincere rescue effort would look like: xorriso -outdev /dev/sr0 \ -check_media use=outdev \ what=disc \ time_limit=7200 \ data_to="$HOME"/sr0.image \ sector_map="$HOME"/sr0.sector_map \ -- After 7200 seconds the attempt will end even if not finished. If you want to abort earlier, do not press Ctrl+C but rather do touch /var/opt/xorriso/do_abort_check_media The disc image will emerge as file "$HOME"/sr0.image . The file "$HOME"/sr0.sector_map will record which blocks could be read without SCSI error. If the run is repeated, then only the missing blocks will be attempted to be read. One may repeat with the same drive or better with different ones. The file "$HOME"/sr0.image and "$HOME"/sr0.sector_map may be carried to other computers to continue the rescue attempt with their drives. If there are other partly damaged identical copies of the archive medium, then one may use them too with the same sr0.image and sr0.sector_map files. If the image is an ISO 9660 filesystem made by xorriso with option -for_backup and thus contains MD5s, then one may check the resulting image by: xorriso -for_backup -indev "$HOME"/sr0.image -check_media -- Any protest would indicate that the rescue attempt was not successful. If the direcory tree is undamaged, one may check the data files by xorriso -for_backup -indev "$HOME"/sr0.image -check_md5_r sorry / -- to get the paths of files with damaged content. Other than with most rescue tools, the read operations of xorriso on an optical drive will be done by direct SCSI commands, not by the Linux block layer. This has the advantage that error messages are more specific than just "i/o error" and that no inappropriate reading ahead will happen. Such reading ahead causes the old TAO CD bug of Linux which gave birth to interesting urban legends about a "fuzzy end" of data CDs. Have a nice day :) Thomas
