Набег 1 не может синхронизировать с новым Диском. его остановка в 30%

у меня была попытка добавить новый жесткий диск вместо жесткого диска Falty. но новый жесткий диск не может синхронизировать со старым, один .sync обрабатывает показанных до 30% после этого его остановленный.

cat /proc/mdstat
Personalities : [raid1] 

md2 : active raid1 sda3[0] sdb3[2](S)
      1458319504 blocks super 1.0 [2/1] [U_]

md1 : active raid1 sda2[3] sdb2[2]
      524276 blocks super 1.0 [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[2]
      6291444 blocks super 1.0 [2/2] [UU]

md0 и синхронизация md1 успешно, но md2 не могут

это - деталь

mdadm --detail /dev/md2
/dev/md2:
        Version : 1.0
  Creation Time : Fri May 24 11:22:21 2013
     Raid Level : raid1
     Array Size : 1458319504 (1390.76 GiB 1493.32 GB)
  Used Dev Size : 1458319504 (1390.76 GiB 1493.32 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Mon Aug  4 22:08:23 2014
          State : clean, degraded 
 Active Devices : 1
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 1

           Name : rescue:2  (local to host rescue)
           UUID : 96b46a6c:f520938c:f94879df:27851e8a
         Events : 616

    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync   /dev/sda3
       1       0        0        1      removed

       2       8       19        -      spare   /dev/sdb3

то любое решение. я хочу скопировать свои данные

0
задан 5 August 2014 в 05:09
3 ответа

Переключатель mdadm "grow" должен втягивать запасной элемент в массив. Что-то вроде "#mdadm --grow / dev / sdb3 --raid-devices = 3" Если это не поможет, я бы просмотрел системный журнал, чтобы выяснить, почему.

0
ответ дан 5 December 2019 в 13:36
mdadm --manage /dev/md2 --add /dev/sdb3

Это должно сработать,

/ dev / sdb3 все еще помечен как Запасной, поэтому ( S).

Если этого недостаточно, вы также можете: удалить его и попробовать снова добавить:

mdadm --manage /dev/md2 --remove /dev/sdb3

Вы можете остановить и перезапустить массив:

   mdadm --stop /dev/md2 ; mdadm --start /dev/md2

И ваш последний вариант - принудительная повторная синхронизация (не волнуйтесь, это не деструктивно):

mdadm --assemble --run --force --update=resync /dev/md2 /dev/sda3 /dev/sdb3

Кроме того, просто перезапуска массива в большинстве случаев достаточно, чтобы выполнить работу без лишних хлопот. И более того: вы даже можете воссоздать все это с помощью mdadm --create. ;)

0
ответ дан 5 December 2019 в 13:36

Извините за опоздание. Итак, я удивлен, что никто не ответил на это. Есть даже ссылка на аналогичную проблему, но я сомневаюсь, что в данном случае дело в кабелях.

Вы запустили синхронизацию с новым диском, но когда синхронизация достигла 30 %, источник (последний оставшийся диск со всеми данными) обнаружил ошибку чтения. В случае ошибок чтения драйвер Linux MD RAID запрашивает чтение с других компонентных устройств, но в этом случае нет синхронизированного компонентного устройства для чтения, поэтому он отказывается. Он остановит синхронизацию при первой такой неисправимой ошибке, а затем перезапустит синхронизацию с самого начала. Конечно, удаление запасного и повторное его добавление не поможет. В таком случае вы должны использовать другие способы для завершения синхронизации или иным образом получить (слегка поврежденные) данные.

Система может работать идеально, потому что этот сектор может не содержать никаких данных, поэтому он никогда не пытался читать из во время нормальной работы, но синхронизация RAID — это особый случай, когда он читает все. Такие случаи мы называем тихими плохими блоками.

Первая идея состоит в том, чтобы заставить диск переназначить сбойный блок внутри. К сожалению, это невозможно сделать с гарантией, но есть большая вероятность, что если вы запишете этот конкретный сектор, он будет переназначен, а затем успешно прочитан. Для этого можно использовать утилиту hdparm (уведомление --repair-sector является псевдонимом для --write-sector):

hdparm --write-sector 448271680

I намеренно поставил здесь почти случайное число. Это 896543360/2, где большое число было взято из сообщения об ошибке dmesg.Вы должны сами рассчитать для своего случая. Будьте предельно осторожны. Я предлагаю выполнить проверку чтения ( --read-sector) с тем же номером, чтобы вызвать то же сообщение об ошибке и, следовательно, доказать, что это действительно правильный сектор. Заметьте, вы ничего потеряете в этом секторе, но он все равно нечитаем, так что он уже по сути потерян, а если он молчит, то никакой полезной информации не было.

Повторите это для всех нечитаемых блоков. Вам также нужно будет заменить этот диск, когда синхронизация будет завершена.

Другим способом исправить ситуацию является остановка службы на длительный период времени. Вам нужно остановить неисправный RAID и запустить ddrescue с неисправного диска на новый диск. После этого нужно сначала полностью удалить старое устройство и запустить систему с нового диска (знаю, с деградировавшими массивами). Затем, если это работает, добавьте еще один новый диск и завершите синхронизацию.

В случае, если вам интересно, я успешно ремонтировал обе стороны.

Урок здесь таков: просто наличия RAID недостаточно; чтобы данные были в безопасности, вам нужно мониторить состояние вашего массива, очищать его периодически (т.е. выполнять проверку чтения для всех устройств и сравнивать — чтобы убедиться, что каждый блок читается) и, конечно, принять необходимые меры своевременно. Аппаратные RAID-массивы также имеют возможность настроить автоматическую периодическую очистку. Для каждого MD RAID вы должны делать один раз в месяц:

echo check >> /sys/block/md0/md/sync_action

(в Debian это по умолчанию, насколько я знаю). Так что когда на каком-то диске появляется нечитаемый сектор, через месяц вы это обнаружите.Тогда не забудьте заменить умирающий диск как можно скорее!

0
ответ дан 26 June 2021 в 05:55

Теги

Похожие вопросы