Help, my disk array has one dead member

[Bruce Ferrell]

On 03/22/2017 07:41 PM, Kevin O'Gorman wrote:
> On Wed, Mar 22, 2017 at 7:17 PM, Xen <list at xenhideout.nl <mailto: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 <tel:22-03-2017%2022>: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 <mailto:ubuntu-users at lists.ubuntu.com>
>     Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users <https://lists.ubuntu.com/mailman/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.
>
>
>
>
I've done the dd thing on simple disks; the wisdom is it's ok between same type disks (make/model/etc).  The wisdom of raid is NO, full stop.  Not without serious lab facilities 
(recovery houses).  your description doesn't seem to warrant that last and you stated as much.

If mdadm mounts it, the md daemon is talking to it...  The filesystems are inactive because it's read only, but the physical device is active and capable of change in the midst of 
a possible dd.  tar, rsync etc are safe on the filesystem because it's ro but the physical volume is rw.

I've had to deal with exactly your situation Kevin.  I pulled off the stuff I needed in chunks in tar files to hop over the bad stuff.  No matter what you choose to do, it's not 
painless or fast.

I was just trying to save you some time down a rat hole that I've been down.

I'm out