Sorry, ‘check’ does indeed write back to the array when it encounters an error – see https://www.apt-browse.org/browse/ubuntu/trusty/main/amd64/mdadm/3.2.5-5ubuntu4/file/usr/share/doc/mdadm/README.checkarray
‘check’ is a read-only operation, even though the kernel logs may suggest
otherwise (e.g. /proc/mdstat and several kernel messages will mention
“resync”). Please also see question 21 of the FAQ.If, however, while reading, a read error occurs, the check will trigger the
normal response to read errors which is to generate the ‘correct’ data and try
to write that out – so it is possible that a ‘check’ will trigger a write.
However in the absence of read errors it is read-only.
… so it may already be too late to collect the data you’re looking for, sorry.
For the longer term, it’s worth noting that RAID5 (and 6, and 1) have no protection against bit-rot which is likely the situation you have encountered.
When data in one disc goes bad, they have no way of determining which of the data is good vs bad. I’d suggest planning to migrate to a filesystem that checksums each disc such as btrfs or zfs.
(RAID-5 really shouldn’t be used in new deployments – and really really shouldn’t where the capacity of raw discs is over 2TB each – see http://www.zdnet.com/article/why-raid-5-stops-working-in-2009/)