Re: raid5 (/dev/md0) w. luks broken - can't decrypt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 21 Jan 2011 at 13:46, Arno Wagner wrote:
>
> The keyslots themselves do not fit. In principle,
> if there are no bad sectors in the keyslot-0 area, the
> keyslot should still be intact, but there is some reason
> the RAID manager kicked two disks and it seems your
> keyslot now _is_ corrupt.
>
> In fact I am a bit surprised. A failed RAID array should
> not come up again by itself without manual intervention,
> even if the disks work fine again.
>
> Ok, first an emergency backup to not make things worse:
> Do a LUKS header backup as described in the FAQ
> (http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions)

Great minds etc-  - already did that :-)

>
> Then check the RAID status (cat /proc/mdstat).

# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sda1[0] sdd1[3] sdc1[2] sdb1[1]
      2930279808 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

unused devices: <none>


>
> Can you post the RAID info (or send it directly to me?
> Command is mdadm -D /dev/md<nr>

# mdadm -D /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Wed Jan 19 22:16:47 2011
     Raid Level : raid5
     Array Size : 2930279808 (2794.53 GiB 3000.61 GB)
  Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Wed Jan 19 23:13:50 2011
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : c4adbb76:fa093a35:2246d218:877ebf8a
         Events : 0.2

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1
       2       8       33        2      active sync   /dev/sdc1
       3       8       49        3      active sync   /dev/sdd1

>
> You can also run a RAID consistency check, which is
> a bit tricky. The procedure is to read
> /sys/block/md<nr>/md/mismatch_cnt to make sure it
> is zero, then echo 'check' into
> /sys/block/md<nr>/md/mismatch_cnt, wait until
> the ckeck is finished (as visible in /proc/mdstat)
> and check the mismatch_cnt again. If it is >0,
> then your RAID is in an inconsistent state.
> This test should not make changes to the disks.

# cat /sys/block/md0/md/mismatch_cnt
0
# echo check >/sys/block/md0/md/sync_action
# cat /sys/block/md0/md/mismatch_cnt
72

>
> If the RAID did not assemble again properly,
> manual intervention and assembly may be necessary
> in order to unlock and safe the data.

mdadm --assemble --scan works fine and sets up the raid just fine.

I *really* hope that I'm not completely scr*w*d :-(

/S
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux