Beyond the reporting problem of the disk in OpenBSD I'm going ahead with my analysis.
I'm performing an H3 test and H5 test on the CRC disk (backup #2) by a copy machine. H3 test result is successful. I'm waiting for H5 test result and I am enough curious. It shouldnt be a problem of disk capacity as attaching the same disk around three weeks ago I didnt get the CRC advise.. further than not receiving any destination error by the copy machine. A CRC error caused by a bit-to-bit copy problem is strange enough.. and the source should be fine as the 3rd backup is intact too. For honesty I need to say that I hear clearly my first disk time-to-time having a mechanical glitch that reoccurs from an age, like a typo of the typical regenerated drives... I don't want that this *typo* manifested itself during the last second backup causing the CRC.. Let's see what are the H5 results.. -- Daniele Bonini Mar 24, 2023 17:47:36 Daniele Bonini <my2...@aol.com>: > > I checked backup #3 disk and faulty partition is perfectly intact. > > So I came back to the faulty backup #2 disk and reattached it obtaining > a slight different console output: > > https://5md.at/l/obcons1 > > in this sense: I dont only receive the CRC error (on sd1, that it has > same UID) but this time (after the fss_chk) I see the sd3 device just > attached correctly too. > > As said above, as the console CRC problem popup just after I inserted > backup #2 disk I expect there is problem on that disk and there is a > problem in OpenBSD caused by the same UID of the two disks. This > statement comes confirmed from the fact that when I inserted backup #3 > disk all apparently was fine. > > > -- Daniele Bonini >