The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Восстановление массива RAID5 после сбоя двух дисков. (raid recover sync crash disk mdadm)


<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>
Ключевые слова: raid, recover, sync, crash, disk, mdadm,  (найти похожие документы)
From: Алексей Цыбань <leshats@a3d.od.ua.> Newsgroups: email Date: Mon, 08 Apr 2009 14:31:37 +0000 (UTC) Subject: Восстановление массива RAID5 после сбоя двух дисков. Слабое место RAID5 - процесс синхронизации с новым диском после сбоя. Следующее хранилище важных данных я буду делать на RAID6. Эта статья - попытка описать последовательность действий после краха массива. Я постараюсь привести все команды, которыми пользовался, но не буду объяснять их подробно. Очень рекомендую почитать документацию перед тем, как применять их самому. Начиналось все обыкновенно. Из RAID5 массива на шести дисках вывалился раздел sdc1. Пара бэд-блоков - не такой уж редкий случай. Вывожу диск из массива: mdadm /dev/md0 --remove /dev/sdc1 И хочу понять, что с ним не так: badblocks -vsw /dev/sdc Утилита badblocks в таких случаях проблем не находит, так как поврежденные блоки подменяются резервными прямо в процессе проверки. После проверки диск можно включать обратно в RAID, но тут начинается самое интересное. sfdisk -d /dev/sda | sdfisk /dev/sdc mdadm /dev/md0 --add /dev/sdc1 В самом начале синхронизации из массива вываливается раздел sdd1. Теперь массиву не хватает двух дисков и он радостно разваливается на части. В моем случае система находится на другом разделе, поэтому компьютер продолжает работать. Если так обвалится системный раздел, придется грузиться с внешнего загрузочного диска. Мне больше нравится systemrescuecd. Сначала подозрения пали на SATA контроллер, поэтому, заменив контроллер, пытаюсь собрать массив обратно. Собираю на пяти дисках из шести возможных, sdc1 полезных данных не содержит, его в команду включать НЕ НАДО! mdadm --assemble --force /dev/md0 /dev/sd[abdef]1 Команда позволяет собрать разрушенный массив. Такой опыт у меня уже был. Однако, сегодня явно не мой день и это почему-то не срабатывает: mdadm: failed to RUN_ARRAY /dev/md0: Input/output error Поиск в интернете дал такое решение: # cat /sys/block/md0/md/array_state inactive # echo "clean" > /sys/block/md0/md/array_state # cat /sys/block/md0/md/array_state clean Помогло, массив собрался (на пяти дисках из шести, sdc1 пропущен), хотя я и не понял, почему. Но день еще не кончился. Попытка запустить на разделе xfs_repair -n /dev/md0 приводит к краху массива из-за все того же sdd1. Контроллер был в порядке, а sdd - нет. Если вы пока еще не паниковали, на этом месте можете начинать. Покупаю новый винчестер, подключаю к системе. Это будет диск sdg. Разбиваю его на разделы: sfdisk -d /dev/sda | sdfisk /dev/sdg При помощи утилиты ddrescue копирую все, что осталось c sdd1 на sdg1 ddrescue -n /dev/sdd1 /dev/sdg1 /root/ddrescue_sdd1.log ddrescue -d -r3 /dev/sdd1 /dev/sdg1 /root/ddrescue_sdd1.log Лог этой утилиты должен быть на любом другом рабочем разделе. Можно запускать и без лога, но с ним гораздо лучше. Пока шло копирование, я успел подумать, что есть еще два варианта действий. Первый - копировать можно было не на новый диск, а на sdc. Он ведь проходит проверку. Второй - пройти по разделу sdd1 утилитой badblocks в неразрушающем режиме. badblocks -vsn Если дело в нескольких бэдах, как это было в моем случае, то винчестер их подменит на резервные (remap) и собрать с ним массив. Но эти варианты я не опробовал. Итак, после окончания копирования собираю массив. Пять из шести с новым диском sdg вместо sdd. Но сначала проверю: mdadm --examine /dev/sdg1 Суперблок должен быть. Дальше: mdadm --assemble --force /dev/md0 /dev/sd[abefg]1 Собрался, хотя это ничего не значит. Контрольного диска нет, сравнивать не с чем, он бы с любым диском, содержащим суперблок, собрался. Можно собрать и без суперблока. У меня на этом разделе XFS, поэтому сначала монтирую, потом сразу размонтирую, потом xfs_repair -n /dev/md0 И вот тут можно вздохнуть. Кому с облегчением, а кому как. Мне, похоже повезло. Дальше, по необходимости xfs_repair /dev/md0 И теперь возвращаюсь к началу: mdadm /dev/md0 --add /dev/sdc1 Затаить дыхание на все время синхронизации не получится, просто скрестите пальцы. Полезные ссылки Linux RAID wiki: http://linux-raid.osdl.org/index.php/Linux_Raid SystemRescueCd: http://www.sysresccd.org/ Google: http://www.google.com

<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, Elenium (ok), 21:23, 08/04/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У меня такая же история была, мне тоже повезло (постучал по голове) :)) А вообще после таких вот танцев с бубнами я рад что собирал изначально массивы бюджетные именно на linux-raid(mdadm) а не на fake-raid (дешевые контроллеры).
    От себя посоветую очень внимательно отнеситесь к sata шнурочкам, в идеале есть шнурки с защелкой, тк бывает заденешь рукой и голову потом ломай почему у тебя райд развалился. :))
     
  • 1.2, Аноним (-), 22:33, 08/04/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    О ужас.. В какое состояние могли придти данные после этого лучше и не думать (кто сказал, что на втором вылетевшем диске данные более адекватные?). Только zfs, однозначно.
     
     
  • 2.3, Static (?), 22:47, 08/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >О ужас.. В какое состояние могли придти данные после этого лучше и
    >не думать (кто сказал, что на втором вылетевшем диске данные более
    >адекватные?). Только zfs, однозначно.

    +1024, аналогично, только ZFS.

     
  • 2.4, Автор (?), 23:03, 08/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >О ужас.. В какое состояние могли придти данные после этого лучше и
    >не думать (кто сказал, что на втором вылетевшем диске данные более
    >адекватные?).

    Более адекватные чем что? Первый вылетевший уже отформатирован. Без второго массив не работал, то есть рассинхронизации данных на дисках нет.
    Основная опасность для данных в этом случае - выдергивание из-под XFS раздела на лету. Плюс потери в тех блоках, которые прочитать не удалось.
    В данном конкретном случае повредилась БД, в которую постоянно данные помногу пишутся. Восстановили из дампа отдельно. Больше потерь не замечено.

    Ужас, но не "Ужас! Ужас!"


     

  • 1.5, dammer (?), 00:01, 09/04/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А что за винчестеры использовались?
     
     
  • 2.6, Автор (?), 00:42, 09/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    WDC WD5000AAKS-00YGA0

    А зачем это Вам?

     
     
  • 3.8, Planner (?), 16:33, 09/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    годами использую WDC.

    Работает пол сотни SATA'шных WDxxxxABYS (AYYS, теперь и FBYS -- RAID Edition).
    С прошлых лет осталось пару десятков IDE'шных WDxxxxAAJB (остальные проданы).

    С 2001-го года был один раз заводской брак на WВ4001ABYS (винт приехал нерабочий) и один раз после двух месяцев експлуатации сдох акселерометр на таком же накопителе - выражалось характерным свистом головок над внешними дорожками и необходимостью перепозиционирования их на начало диска и обратно для считывания данных (TLER и ZFS помогли).

    То есть, за неполные восемь лет пользования топовыми сериями (a.k.a Enterprise-class) накопителей WDC на нескольких десятках серверов данные не терял ни разу.

    В то же время Seagate, IBM, Fujitsu - дохли десятками.
    На Samsung'и трёх-четырехлетней давности жалоб нет, но их у меня гораздо меньше (WD'шек же добрая сотня).

     

  • 1.7, i (??), 14:10, 09/04/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а в чем смысл использовать разделы?
    почему не делать рейд сразу из девайсов ?
    типо:
    md0 : active raid5 sdc[0] sdb[4] sdd[3] sdf[2] sde[1]
          1953545728 blocks level 5, 128k chunk, algorithm 2 [5/5] [UUUUU]
     
     
  • 2.9, Автор (?), 23:22, 09/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Можно и так.
    А если хочется несколько разделов на RAID массиве, то можно собрать несколько RAID из разделов или один RAID из целых дисков разбить на разделы.
    Кому что больше нравится.
    В описаном случае, благодаря тому, что разделов было несколько, не пришлось грузиться с внешних носителей. И даже почтовый сервер работал все то немалое время, пока восстанавливался битый массив.
     

  • 1.10, cvsup (ok), 07:44, 10/04/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Повторю вечную истину:
    "Обжегшись на молоке, на воду не дуют".
    Статью следовало озаглавить "бекап/рестор" и переписать. Мои ИМХО.
    P.S. боюсь думать, сколько протянет этот RAID после таких измывательств =-O
    Ничего, после второго крупного попадалова на $ иногда люди учатся, но есть исключения.
     
  • 1.12, Serg (??), 18:21, 13/04/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    НИКОГДА не делайте так, как описано.
    Можно было избежать выделения значительной части адреналина, если бы автор следовал простому правилу - всегда перед реконфигурацией массива делать полный дамп данных, даже если массив находится в "degraded" режиме. Без одного винта данные бы прочитались, хотя и медленнее. А вот потом уже удалять/добавлять диски, проверять их и т.д. Ситуация с вылетом второго диска в массиве при попытке что-либо с ним сделать настолько стандартная, что ее даже к Мэрфи не отнесешь...
     

    игнорирование участников | лог модерирования

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру