Re: How to use dmsetuup?
On 11/5/23 01:04, Thomas Schmitt wrote:
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.
Okay.
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.
Adding checksum file(s) to the contents burned to disc is an important
step that should not be omitted -- checksum files are a simple and
direct way to validate the integrity of disc contents. Without checksum
files, a computer with working applications is required to read and
validate the specific file format(s). I suspect tar(1), gzip(1) and
ccrypt(1) do this (?), but you are lost with plain text files.
Lesson learnt: Never overwrite the two youngest backups.
I try to use the term "backup" to mean a data copying process whereby
older data is overwritten by newer data.
I try to use the term "archive' to mean a data copying process whereby
the copy is never modified or erased.
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 expect CD disc rot occurs when discs are accidentally scratched or
when discs are treated badly (e.g. stored loose; not in a case).
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.
Okay.
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.
The DVD+-RW in my primary workstation started producing intermittent
write failures a few months ago. This quickly progressed to consistent
write failures and consistent read failures. I cleaned the lens today,
and now it reads okay. I will find out if it writes okay the next time
I burn a disc.
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.
Okay.
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,
The optical media could be a single point of failure. If I remove two
DVD-R discs from the same case this month, burn them with identical
contents, verify the checksums, store one disc locally, store the other
disc off-site, and verify checksums once per year in the future, I could
find that both discs fail in the same year.
So, I both burn my monthly archive encrypted tarballs to DVD-R and I
keep the original on RAID, which is included in my backup process.
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.
Interesting. My WAG is that there was a marginal/ ambiguous dot on disc
(?).
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.
xorriso(1) is a killer app. :-)
I seem to recall a post by you that indicated *BSD lacked the features
needed for good optical drive/ media/ format support. Has this
improved? Can I get xorriso(1) on FreeBSD?
David
Reply to: