Re: Recovering from as identical as faulty backup disk..

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 <my25mb@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
>