Help, my disk array has one dead member

[Kevin O'Gorman]

On Wed, Mar 22, 2017 at 7:17 PM, Xen <list at xenhideout.nl> wrote:

> Bruce Ferrell schreef op 23-03-2017 0:12:
>
>> On 3/22/17 3:37 PM, Xen wrote:
>>
>>> Bruce Ferrell schreef op 22-03-2017 22:36:
>>>
>>> Simple raid0 is destroyed with a member drive or partition out so no
>>>> copy is needed/possible.
>>>>
>>>
>>> He said that one of the drives was damaged, but still readable. The
>>> other was fine.
>>>
>>> Yes and he also said it's an md raid.  As I said, the devil is in the
>> details;  If it's raid1 (or higher) and one of the elements is
>> damaged, the others cover for that with speed degradation.
>>
>
> He said it was raid0.
>
> raid0, do NOT use any dd variant on the physical disk.  md has
>> internal data structures on the physical disks and doesn't transplant
>> well to new drives.
>>
>
> He didn't try to do that because there's no point in that if it has a
> stripe, right.
>
> You *might* be able to get away with dd on the md device, but that is
>> active and managed by the md subsystem.  I was taught NEVER use dd on
>> active devices... Unless you want trash data.
>>
>
> I don't see a reason against it. The block volume is managed from the
> outside by the filesystem. The filesystem manages the logical block space.
> It has no interference with the md subsystem.
>
> In place of the filesystem, you can also use dd on the block device. It
> makes no difference.
>
> You also can't trash data on any device just by reading, usually.
>
> Use tar and you may have to be selective about what you copy but then
>> again maybe sector relocation can help you get past the damage for
>> tar.
>>
>
> Maybe, but filesystem recovery is a step after you secure the data, I
> think.
>
> Where this get's REALLY dicey; damaged data may have been mirrored
>> back to the good drive from the bad one.  NASTY!
>>
>
> It was a raid0. He said it was a stripe.
>
> Bottom line, one size never fits all...  poke, prod (gently) and use
>> trouble shooting steps to make a determination of what's needed to
>> recover and NEVER blindly follow "just do this..." instructions
>>
>
> It wasn't a blanket just do it instruction. It was geared to his
> particular use case.
>
> Anyway, sorry for responding again still.
>
>
> --
> ubuntu-users mailing list
> ubuntu-users at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/ubuntu-users
>


I pretty much agree with Xen.  It's just that because the root directory on
the raid, and some of the subdirectories as well are still there, and many
of the files in them are so small, it happens that  a lot of these small
files are still readable, because they don't happen to occupy the broken
part at all.  (BTW: I don't know if the whole drive is gone, and I kind of
doubt it because blkid reports all three.  Also BTW, mdadm on seeing the
damage remounts the filesystem read-only, so no there is no activity on it.)

Unfortunately, I have no place to direct a copy of the entire RAID, so
ddrescue is not an option.  I did get the three drives that I'm going to
put in the other system, but my machine cannot support all 6 and a boot
drive at the same time.  All drive bays are full; all SATA ports are in use.

-- 
Kevin O'Gorman
#define QUESTION ((bb) || (!bb))   /* Shakespeare */

Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20170322/fa5934fb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 441 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20170322/fa5934fb/attachment.gif>