Linux — Восстановление поврежденных блоков на массиве RAID1 с помощью GPT

Question 1

Все эти ответы "poke the sector" откровенно говоря, безумны. Они рискуют (возможно, скрытым) повреждением файловой системы. Если бы данные уже исчезли, потому что на этом диске хранилась единственная копия, это было бы разумно. Но на зеркале есть совершенно хорошая копия.

Вам просто нужно, чтобы mdraid очистил зеркало. Он заметит плохой сектор и автоматически перезапишет его.

# echo 'check' > /sys/block/mdX/md/sync_action    # use 'repair' instead for older kernels

Вам нужно поместить туда правильное устройство (например, md0 вместо mdX). Это займет некоторое время, так как по умолчанию это касается всего массива. На достаточно новом ядре вы можете сначала записать номера секторов в sync_min/sync_max, чтобы ограничить его только частью массива.

Это безопасная операция. Вы можете сделать это на всех ваших mdraid устройствах. Фактически, выдолженделайте это на всех ваших устройствах mdraid, регулярно. Ваш дистрибутив, вероятно, поставляется с cronjob для обработки этого, может быть, вам нужно что-то сделать, чтобы включить его?

Скрипт для всех RAID-устройств в системе

Некоторое время назад я написал этот скрипт для «ремонта» всех RAID-устройств в системе. Он был написан для старых версий ядра, где только «ремонт» мог исправить плохой сектор; теперь достаточно просто выполнить проверку (ремонт по-прежнему отлично работает на новых ядрах, но он также перекопирует/перестроит четность, что не всегда то, что вам нужно, особенно на флэш-накопителях)

#!/bin/bash

save="$(tput sc)";
clear="$(tput rc)$(tput el)";
for sync in /sys/block/md*/md/sync_action; do
    md="$(echo "$sync" | cut -d/ -f4)"
    cmpl="/sys/block/$md/md/sync_completed"

    # check current state and get it repairing.
    read current < "$sync"
    case "$current" in
        idle)
            echo 'repair' > "$sync"
            true
            ;;
        repair)
            echo "WARNING: $md already repairing"
            ;;
        check)
            echo "WARNING: $md checking, aborting check and starting repair"
            echo 'idle' > "$sync"
            echo 'repair' > "$sync"
            ;;
        *)
            echo "ERROR: $md in unknown state $current. ABORT."
            exit 1
            ;;
    esac

    echo -n "Repair $md...$save" >&2
    read current < "$sync"
    while [ "$current" != "idle" ]; do
        read stat < "$cmpl"
        echo -n "$clear $stat" >&2
        sleep 1
        read current < "$sync"
    done
    echo "$clear done." >&2;
done

for dev in /dev/sd?; do
    echo "Starting offline data collection for $dev."
    smartctl -t offline "$dev"
done

Если вы хотите сделать checkвместо repair, то этот (непроверенный) первый блок должен работать:

    case "$current" in
        idle)
            echo 'check' > "$sync"
            true
            ;;
        repair|check)
            echo "NOTE: $md $current already in progress."
            ;;
        *)
            echo "ERROR: $md in unknown state $current. ABORT."
            exit 1
            ;;
    esac

Answer

Все эти ответы "poke the sector" откровенно говоря, безумны. Они рискуют (возможно, скрытым) повреждением файловой системы. Если бы данные уже исчезли, потому что на этом диске хранилась единственная копия, это было бы разумно. Но на зеркале есть совершенно хорошая копия.

Вам просто нужно, чтобы mdraid очистил зеркало. Он заметит плохой сектор и автоматически перезапишет его.

# echo 'check' > /sys/block/mdX/md/sync_action    # use 'repair' instead for older kernels

Вам нужно поместить туда правильное устройство (например, md0 вместо mdX). Это займет некоторое время, так как по умолчанию это касается всего массива. На достаточно новом ядре вы можете сначала записать номера секторов в sync_min/sync_max, чтобы ограничить его только частью массива.

Это безопасная операция. Вы можете сделать это на всех ваших mdraid устройствах. Фактически, выдолженделайте это на всех ваших устройствах mdraid, регулярно. Ваш дистрибутив, вероятно, поставляется с cronjob для обработки этого, может быть, вам нужно что-то сделать, чтобы включить его?

Скрипт для всех RAID-устройств в системе

Некоторое время назад я написал этот скрипт для «ремонта» всех RAID-устройств в системе. Он был написан для старых версий ядра, где только «ремонт» мог исправить плохой сектор; теперь достаточно просто выполнить проверку (ремонт по-прежнему отлично работает на новых ядрах, но он также перекопирует/перестроит четность, что не всегда то, что вам нужно, особенно на флэш-накопителях)

#!/bin/bash

save="$(tput sc)";
clear="$(tput rc)$(tput el)";
for sync in /sys/block/md*/md/sync_action; do
    md="$(echo "$sync" | cut -d/ -f4)"
    cmpl="/sys/block/$md/md/sync_completed"

    # check current state and get it repairing.
    read current < "$sync"
    case "$current" in
        idle)
            echo 'repair' > "$sync"
            true
            ;;
        repair)
            echo "WARNING: $md already repairing"
            ;;
        check)
            echo "WARNING: $md checking, aborting check and starting repair"
            echo 'idle' > "$sync"
            echo 'repair' > "$sync"
            ;;
        *)
            echo "ERROR: $md in unknown state $current. ABORT."
            exit 1
            ;;
    esac

    echo -n "Repair $md...$save" >&2
    read current < "$sync"
    while [ "$current" != "idle" ]; do
        read stat < "$cmpl"
        echo -n "$clear $stat" >&2
        sleep 1
        read current < "$sync"
    done
    echo "$clear done." >&2;
done

for dev in /dev/sd?; do
    echo "Starting offline data collection for $dev."
    smartctl -t offline "$dev"
done

Если вы хотите сделать checkвместо repair, то этот (непроверенный) первый блок должен работать:

    case "$current" in
        idle)
            echo 'check' > "$sync"
            true
            ;;
        repair|check)
            echo "NOTE: $md $current already in progress."
            ;;
        *)
            echo "ERROR: $md in unknown state $current. ABORT."
            exit 1
            ;;
    esac

Question 2

У меня только что была почти такая же проблема с массивом RAID1. Плохой сектор находился в самом начале одного из разделов — секторе 16 /dev/sdb2. Я следовал инструкциям выше: убедившись, что логический блок 2 не используется файловой системой, и внимательно выполняя dd seek и skip в правильном направлении, обнулил 1 блок файловой системы:

# dd if=/dev/zero of=/dev/md0 bs=4096 count=1 seek=2

Что это сделало? Это не исправило плохой сектор. Теперь я знаю, что это потому, что /dev/md0 не отображается напрямую на /dev/sdb2, вам нужно учитывать RAID DATA OFFSET! Подробнее об этом ниже. То, что это сделало, было небольшим, но потенциально разрушительным дерьмом в моей файловой системе. Оказывается, логический блок 2 /dev/md0 содержал полезные метаданные файловой системы и был в порядке на обоих дисках, пока я не нагадил наобакопирует, записывая в /dev/md0. К счастью, e2fsck -y /dev/md0 исправил проблему (после выдачи тревожного количества вывода) без видимой потери данных. Урок: если debugfs icheck говорит «блок не найден», это не обязательно означает, что соответствующие сектора не используются.

Вернемся к смещению данных: используйте mdadm, чтобы найти смещение следующим образом:

# mdadm --examine /dev/sdb2
/dev/sdb2:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : ef7934b9:24696df9:b89ff03e:b4e5a05b
           Name : XXXXXXXX
  Creation Time : Sat Sep  1 01:20:22 2012
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 1953241856 (931.38 GiB 1000.06 GB)
     Array Size : 976620736 (931.38 GiB 1000.06 GB)
  Used Dev Size : 1953241472 (931.38 GiB 1000.06 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : f3b5d515:446d4225:c2191fa0:9a9847b8

    Update Time : Thu Sep  6 12:11:24 2012
       Checksum : abb47d8b - correct
         Events : 54


    Device Role : Active device 0
    Array State : AA ('A' == active, '.' == missing)

В этом случае смещение данных составляет 262144 сектора по 512 байт. Если вы выполните dd из /dev/md0 и сравните его с данными из необработанного раздела со смещением 131072K, вы обнаружите, что они совпадают. Так что в моем случае логический блок 2 (сектора 16--23) /dev/sdb2 даже не находится в файловой системе; они находятся в суперблоке RAID, о котором вы можете прочитать здесь: https://raid.wiki.kernel.org/index.php/RAID_superblock_formats- для версии 1.2 он состоит из 256 байт + 2 байта на устройство в массиве, все начинается с 4096 байт, поэтому в моем случае плохой сектор не использовался. Соответствующие сектора /dev/sdc2 (другая половина массива RAID1) равны нулю, поэтому я решил, что будет безопасно сделать так:

# dd if=/dev/zero of=/dev/sdb2 bs=4096 count=1 seek=2

Это сработало!

Answer

У меня только что была почти такая же проблема с массивом RAID1. Плохой сектор находился в самом начале одного из разделов — секторе 16 /dev/sdb2. Я следовал инструкциям выше: убедившись, что логический блок 2 не используется файловой системой, и внимательно выполняя dd seek и skip в правильном направлении, обнулил 1 блок файловой системы:

# dd if=/dev/zero of=/dev/md0 bs=4096 count=1 seek=2

Что это сделало? Это не исправило плохой сектор. Теперь я знаю, что это потому, что /dev/md0 не отображается напрямую на /dev/sdb2, вам нужно учитывать RAID DATA OFFSET! Подробнее об этом ниже. То, что это сделало, было небольшим, но потенциально разрушительным дерьмом в моей файловой системе. Оказывается, логический блок 2 /dev/md0 содержал полезные метаданные файловой системы и был в порядке на обоих дисках, пока я не нагадил наобакопирует, записывая в /dev/md0. К счастью, e2fsck -y /dev/md0 исправил проблему (после выдачи тревожного количества вывода) без видимой потери данных. Урок: если debugfs icheck говорит «блок не найден», это не обязательно означает, что соответствующие сектора не используются.

Вернемся к смещению данных: используйте mdadm, чтобы найти смещение следующим образом:

# mdadm --examine /dev/sdb2
/dev/sdb2:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : ef7934b9:24696df9:b89ff03e:b4e5a05b
           Name : XXXXXXXX
  Creation Time : Sat Sep  1 01:20:22 2012
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 1953241856 (931.38 GiB 1000.06 GB)
     Array Size : 976620736 (931.38 GiB 1000.06 GB)
  Used Dev Size : 1953241472 (931.38 GiB 1000.06 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : f3b5d515:446d4225:c2191fa0:9a9847b8

    Update Time : Thu Sep  6 12:11:24 2012
       Checksum : abb47d8b - correct
         Events : 54


    Device Role : Active device 0
    Array State : AA ('A' == active, '.' == missing)

В этом случае смещение данных составляет 262144 сектора по 512 байт. Если вы выполните dd из /dev/md0 и сравните его с данными из необработанного раздела со смещением 131072K, вы обнаружите, что они совпадают. Так что в моем случае логический блок 2 (сектора 16--23) /dev/sdb2 даже не находится в файловой системе; они находятся в суперблоке RAID, о котором вы можете прочитать здесь: https://raid.wiki.kernel.org/index.php/RAID_superblock_formats- для версии 1.2 он состоит из 256 байт + 2 байта на устройство в массиве, все начинается с 4096 байт, поэтому в моем случае плохой сектор не использовался. Соответствующие сектора /dev/sdc2 (другая половина массива RAID1) равны нулю, поэтому я решил, что будет безопасно сделать так:

# dd if=/dev/zero of=/dev/sdb2 bs=4096 count=1 seek=2

Это сработало!

Question 3

Если вы используете Debian, у вас, скорее всего, есть задание в /etc/cron.d/mdadm . Оно будет запускаться /usr/share/mdadm/checkarray --cron --all --idle --quiet в первое воскресенье каждого месяца. Запускайте его вручную, когда у вас возникают неисправимые аппаратные ошибки, чтобы ускорить переписывание.

Answer

Если вы используете Debian, у вас, скорее всего, есть задание в /etc/cron.d/mdadm . Оно будет запускаться /usr/share/mdadm/checkarray --cron --all --idle --quiet в первое воскресенье каждого месяца. Запускайте его вручную, когда у вас возникают неисправимые аппаратные ошибки, чтобы ускорить переписывание.

Question 4

Если у вас есть sw-raid1 и вы пишете данные на один из участников напрямую, вы немедленно получите поврежденный raid. НЕ записывайте данные на sdaX или sdbX, если они являются частью mdX. Если вы пишете на mdX, вы скопируете данные на оба диска, если вы читаете с mdX, вы будете читать данные с одного из дисков.

Answer

Если у вас есть sw-raid1 и вы пишете данные на один из участников напрямую, вы немедленно получите поврежденный raid. НЕ записывайте данные на sdaX или sdbX, если они являются частью mdX. Если вы пишете на mdX, вы скопируете данные на оба диска, если вы читаете с mdX, вы будете читать данные с одного из дисков.

Linux — Восстановление поврежденных блоков на массиве RAID1 с помощью GPT

ПРАВКА 1:

ПРАВКА 2

ПРАВКА 3

решение1

Скрипт для всех RAID-устройств в системе

решение2

решение3

решение4

Связанный контент