Замена нерабочего жесткого диска на raid 1

Введение

Когда первый раз сталкиваешься с рукожопством сотрудников техподдержки дата центра, впадаешь в ступор и думаешь, ну как так то? Сейчас я спокойно отношусь к таким ситуациям и действую исходя из самых худших ожиданий. На днях я столкнулся с ситуацией, когда мне заменили не тот диск в сервере с RAID1. Вместо сбойного диска вынули рабочий и заменили чистым. К счастью все закончилось хорошо, но обо всем по порядку.

Не скажу, что у меня прям большой опыт аренды серверов, но он есть. Я регулярно обслуживаю 10-15 серверов, расположенных в разных дата центрах, как российских, так и европейских. Первый негативный опыт я получил именно в Европе и был очень сильно удивлен и озадачен. Я, как и многие, был под влиянием либеральной пропаганды на тему того, что у нас все плохо, а вот Европа образец надежности, стабильности и сервиса. Как же я ошибался. Сейчас отдам предпочтение нашим дата центрам. По моему мнению и опыту, у нас тех поддержка и сервис в целом лучше, чем там, без привязки к стоимости. В Европе дешевле схожие услуги, так как там масштабы сервисов в разы больше.

Приведу несколько примеров косяков саппорта, с которыми сталкивался.

1. При заказе приватной сети у хостера leaseweb.com развалили весь сервис на несколько часов. Был крупный проект у хостера. Рос постепенно, с нуля. Покупался сервер за сервером. Когда серверов стало много, решили, что надо объединяться в единую локалку. У хостера есть такая услуга и называется приватная сеть. Так как сервера сильно разнесены по стойкам, хостер сказал, что надо переносить все поближе друг к другу. Согласовали время для переноса серверов и все остальное. Хостер заранее выдал все сетевые настройки. После того, как хостер все сервера перенес и отчитался в тикете об успешном окончании, началась свистопляска. На части серверов указанные сетевые настройки не приводили к доступности. Часть серверов не видели друг друга. Началась длительная переписка с техподдержкой, где предлагали то включить dhcp, то отключить, и кучу всяких других бесполезных действий. В итоге оказалось, что просто напутали и с сетевыми настройками, и сервера не туда перенесли. Это была жесть. Плюс все общение на английском. С тех пор я больше никогда не заказываю подобных услуг на работающем сервисе. Если надо объединяться, то настраиваю vpn на текущих сетевых подключениях. И вообще обращаюсь к тех поддержке по минимуму. Если нужны глобальные изменения — плавных переход на дублирующую систему.
2. Как-то раз перед новым годом, 31-го декабря в 16 часов отрубился полностью крупный проект. Как оказалось, хостер выполнял какие-то работы в стойке и по ошибке вырубил питание на нашем сервере, который был балансером и точкой входа для всех запросов. В итоге весь сайт и сервис лег для посетителей. Повезло, что где-то часа за 2 они это обнаружили и отписались в тикете, что все ОК. А при первоначальном запросе сказали, что сейчас будем разбираться, но все инженеры уже празднуют, так что ничего не обещаем.
3. Ну и под конец классика. Заменили не тот диск в рейде. Вместо сбойного вынули рабочий. Каким-то чудом рейд не развалился. Все зависло, вернули обратно рабочий диск и перегрузили сервер.

Было много всяких инцидентов помельче, нет смысла описывать. Хотя нет, один все же опишу. Устанавливал свой сервер в ЦОД. Решил пойти в маш зал и проконтролировать монтаж. Если есть такая возможность, крайне рекомендую ей воспользоваться. Местный рукожоп неправильно прикрепил салазки и сервер во время монтажа стал падать. Я его поймал, тем спас его и сервера других клиентов. В итоге помог с монтажом. Сам бы он просто не справился. Я не представляю, что было, если бы я не пошел в машзал. К чести руководства, я написал претензию, где подробно описал данный случай и попросил бесплатно месячную аренду. Мне ее предоставили. Советую всем так поступать. Зачастую, руководство может быть не в курсе того, что происходит в реальности. Надо давать обратную связь.

Уровень моего доверия к тех поддержке дата центров и хостингов вы примерно представляете Ну и вот случилось очередное ЧП. Подробнее остановлюсь на этой ситуации, так как она случилась вчера, свежи воспоминания.

Введение

В этой статье мы рассмотрим принципы восстановление данных с RAID массивов в так называемых «простых» случаях, используя методы, которые доступны практически всем и не требуют глубоких знаний в области компьютерного «железа» и программного обеспечения. Случаи, которые можно отнести к «сложным», слишком отличаются друг от друга, и требуют индивидуального подхода, поэтому нет смысла описывать их в рамках одной статьи. Однако, можно обсудить конкретную ситуацию в предназначенном для этой цели разделе форума.

Внимание!!! Если потерянная информация критически важна, а Вы не являетесь специалистом в области восстановления данных, то настоятельно рекомендуем сразу обратиться в компанию, чьей основной областью деятельности является решение такого рода проблем. Но если судьба данных волнует Вас меньше чем желание попробовать самостоятельно их восстановить, то эта статья для Вас

Но если судьба данных волнует Вас меньше чем желание попробовать самостоятельно их восстановить, то эта статья для Вас.

Замена диска в рейде mdadm

Речь пойдет о дешевых дедиках от selectel. Я их много где использую и в целом готов рекомендовать. Это обычные десктопные системники за скромные деньги. Свое мнение об этих серверах, а так же сравнение с полноценными серверами сделаю в конце, в отдельном разделе.

На сервере была установлена система Debian из стандартного шаблона Selectel. Вот особенности дисковой подсистемы этих серверов и шаблона.

• 2 ssd диска, объединенные в mdadm
• /boot раздел на /dev/md0 размером 1G
• корень / на /dev/md1 и поверх lvm на весь массив

В целом, хорошая и надежная разбивка, чему будет подтверждение дальше. На сервере был установлен proxmox, настроен мониторинг mdadm. Мониторинг дисков не сделал. В какой-то момент получил уведомление в zabbix, что mdadm развалился. Сервер при этом продолжал работать. Ситуация штатная. Пошел в консоль сервера, чтобы все проверить. Посмотрел состояние рейда.

# cat /proc/mdstat

Убедился, что один диск выпал из массива. В системном логе увидел следующее.

Попробовал посмотреть информацию о выпавшем диске.

# smartctl -i /dev/sda

Информации не было, утилита показывала ошибку обращения к диску. Получилось посмотреть модель и серийный номер только работающего диска.

Я не стал разбираться, что там к чему с диском. Если вижу проблемы, сразу меняю. Предупредил заказчика, что с диском проблемы, нужно планировать замену. Так как железо десктопное, «сервер» надо выключать. Согласовали время после 22 часов. Я в это время уже сплю, поэтому написал тикет в тех поддержку, где указал время и серийный номер диска, который нужно было оставить. Я сделал на этом акцент, объяснил, что сбойный диск не отвечает, поэтому его серийник посмотреть не могу. Расписал все очень подробно, чтобы не оставить почвы для недопонимания или двойного толкования. Я в этом уже спец, но все равно не помогло.

Я спокойно согласился на эту операцию, потому что часто делаются бэкапы и они гарантированно рабочие. Настроен мониторинг бэкапов и делается регулярное полуручное восстановление из них. Договоренность была такая, что хостер после замены дожидается появления окна логина, а заказчик проверяет, что сайт работает. Все так и получилось — сервер загрузился, виртуалки поднялись, сайт заработал. На том завершили работы.

Утром я встал и увидел, что весь системный лог в ошибках диска, рабочего диска в системе нет, а есть один глючный и один новый. Сразу же запустил на всякий случай ребилд массива и он вроде как даже прошел без ошибок. Перезагрузка временно оживила сбойный диск. В принципе, на этом можно было бы остановиться, заменить таки сбойный диск и успокоиться. Но смысл в том, что этот сбойный диск почти сутки не был в работе и данные на нем старые. Это не устраивало. Потом пришлось бы как-то склеивать эти данные с данными из бэкапов. В случае с базой данных это не тривиальная процедура. Созвонился с заказчиком и решили откатываться на рабочий диск, который вытащили накануне ночью.

Я создал тикет и попросил вернуть рабочий диск на место. К счастью, он сохранился. К нему добавить еще один полностью чистый. Хостер оперативно все сделал и извинился. В завершении прислал скриншот экрана сервера.

И самоустранился. Дальше решать проблему загрузки он предложил загрузившись в режиме rescue. Этот режим доступен через панель управления сервером в админке, даже если сервер не имеет ipmi консоли. Как я понял, по сети загружается какой-то live cd для восстановления. Я в нем загрузился, убедился, что данные на месте, но понять причину ошибки не смог. Может быть и смог бы, если бы дольше покопался, но это очень неудобно делать, не видя реальной консоли сервера. Я попросил подключить к серверу kvm over ip, чтобы я мог подключиться к консоли. Тех поддержка без лишних вопросов оперативно это сделала.

К слову, мне известны случаи, когда техподдержка selectel потом сама чинила загрузку и возвращала mdadm в рабочее состояние. Видел такие переписки в тикетах у своих клиентов до того, как они обращались ко мне. Но я не стал настаивать на таком решении проблемы, так как боялся, что будет хуже. К тому же это было утро воскресенья и специалистов, способных это сделать, могло просто не быть. Плюс, я не думаю, что они обладали бы большими компетенциями, чем я. Я бы за их зарплату не пошел работать в ЦОД.

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

Небольшое отступление

Рассматривая массивы, мы не можем не упомянуть о RAID контроллерах, которых сегодня великое множество, с разбросом цен от двадцати до нескольких тысяч долларов. Сравнение надёжности – вопрос сложный, но догадаться, что разница в цене «не из пальца высосана», думаю, может каждый.

Контроллеры бюджетного уровня, имеют упрощенный алгоритм работы и восстановления после сбоев, что выражается в большей вероятности потери информации. Дорогие модели заметно надёжнее, алгоритмы обработки ошибок более совершенны, но и они не безупречны.

Вопросы, касающиеся особенностей работы определённых моделей RAID контроллеров, Вы можете задать здесь.

RAID массив не является панацеей от потери информации. Практика показывает, что случаются как сбои в работе контроллера, так и сбои в работе жестких дисков, или же происходит одно вытекающее из другого. В любом случае, полностью полагаясь на надёжность массивов и не позаботившись о своевременном создании резервных копий, Вы рискуете однажды остаться без «надежно хранимой» информации.

Вероятность потери данных можно заметно уменьшить, регулярно отслеживая состояние массива и выполняя профилактические работы, но полностью свести к нулю таким образом её нельзя.

Практика: Чего не стоит делать

Упомянем о том, чего не стоит делать, для того, чтобы окончательно не потерять данные.

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

Запуск инициализации тоже ни к чему хорошему не приведёт, так что рекомендуется от неё отказаться, а если это не возможно, то использовать только quick init.

Чем еще можно навредить массиву? Запуском чекдиска или чего-то подобного. А вообще лучше всего помнить, что при потере информации на RAID следует отказаться от любой записи на диски. Если Вы точно не знаете, приведут ли определенные действия к утрате информации или нет, то лучше либо проконсультироваться с тем, кто это знает, либо отказаться от их выполнения.

Установка загрузчика

Если вы производите починку в загруженной системе, то будет достаточно, в случае GRUB2, выполнить grub-install на новый жёсткий диск, например, так:

grub-install /dev/sdb

В случае Grub1 (устаревшая версия grub) то, в зависимости от того какой диск выпал, потребуется больше шагов
Запустить консоль grub: grub
Указать раздел, на котором лежит /boot: root (hd0,1) (/dev/sda2 = (hd0,1))
Записать загрузчик в MBR: setup (hd0)
Для того чтобы записать загрузчик на второй жёсткий диск:
Укажите grub переключиться на sdb: device (hd0) /dev/sdb
В точности повторить шаги 2 и 3
Завершить консоль grub: quit

Probing devices to guess BIOS drives. This may take a long time.


   GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

 [ Minimal BASH-like line editing is supported.  For the first word, TAB
  lists possible command completions.  Anywhere else TAB lists the possible
  completions of a device/filename.]
grub> device (hd0) /dev/sdb
device (hd0) /dev/sdb
grub> root (hd0,1)
root (hd0,1)
 Filesystem type is ext2fs, partition type 0xfd
grub> setup (hd0)
setup (hd0)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  26 sectors are embedded.
succeeded
 Running "install /boot/grub/stage1 (hd0) (hd0)1+26 p (hd0,1)/boot/grub/stage2 /boot/grub/grub.conf"... succeeded
Done.
grub> quit
#

Замена нерабочего жесткого диска на RAID 1

В данной теме «Замена нерабочего жесткого диска на RAID 1» поговорим как легко можно заменить полетевший жесткий диск на вашем raid1 массиве (зеркало).

Чтобы посмотреть какой у вас установлен raid  и работает ли он вообще, используйте:

У вас должно появится картинка, примерного содержания, я ее приведу ниже.

Рабочий raid1 который мы проверили с помощью mdstat

На рисунке видно что рейд состоит из 4-х разделов ( sdb1,sdb2,sdb3,sdb4) и он полностью рабочий ( работают оба диска- это видно по опции ). У меня всего 4 объединенных массива на которых: md0,md1,md2,md3.

Предположим что у нас вышел из строя диск с меткой /dev/sdb, определить можно это когда мы видим  или — это собственно означает что наш массив не синхронизирован. Покажу как выглядит нерабочий массив, на наглядном скриншоте у низу  все хорошо видно.

Нерабочий raid1

Все изменения мы будем вносить в программный raid1 с нашей рабочей ОС ( на живую так сказать). Если вы увидели у себя нечто подобное как на рисунке выше, то пришло время заменять диск.

Убираем нерабочий ХДД из системы, а можно это сделать выполнив команды для каждого раздела по отдельности:

Не всегда может выполнить эти команды ( бывают разные случаи), если появились ошибки не расстраивайтесь, выполняйте все как написано!

Чтобы показать все диски у вашем входящем массиве (допустим в md0):

Есть случаи что жёсткий диск бывает повреждённый частично, например,  у него показывается статус и это только у массива /dev/md0, а все остальные массивы имеют статус — то есть они работают, то выполните команду для этого случая:

Нечего не выйдет, т.к устройство /dev/md1 в норме. Исправить можно командой:

Это даст возможность поменять статус RAID-а на . Сейчас мы подготовим новый жёсткий диск для нашего рейда1 — это нужно сделать для того что 2 HDD в массиве должны содержать одинаковые разбиения, т.к существует 2 основных типа таблиц  для раздела(ов) (GPT и MBR), то нужно использовать нужные программы для копирования этих таблиц разделов между собой.

GPT используют для дисков у которых более 2ТБ (для примера, EX4 и EX6).

Если Вы используете HDD с GPT

На HDD хранится пару копий таблиц разделов GUID (GPT), по этому для того чтобы можно отредактировать их есть программы, которые поддерживают GPT, например такие как parted или такие как GPT fdisk. Программа sgdisk из GPT fdisk (она имеется в Rescue-системе и готова к использованию) которая позволяет простым и удобным способом скопировать вашу таблицу разделов на новый подключенный жёсткий диск. Для примера нам нужно скопировать все таблицы разделов с диска sda на диск sdb, то нужно выполнить:

Далее, ХДД нужно присвоить новый и случайный UUID следующей командой:

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

Если Вы используете жёсткий ХДД с MBR

Любую таблицу разделов можно просто скопировать на новый диск с помощью утилиты sfdisk:

собственно  /dev/sda — это источник, а /dev/sdb — ХДД (новый) назначения.(Опционально): если разделы не видны в системе, то таблица разделов должна быть перечитана ядром:

Конечно же, разделы можно создать вручную с помощью fdisk, cfdisk или других инструментов. Разделы должны иметь тип Linux raid autodetect (ID fd). Сейчас уже можно добавить новый жесткий диск, как только вы удалили повреждённый диск, можно добавлять новый. Проделать это нужно для каждого раздела:

Только созданный новый HDD уже часть массива, и теперь массив будет выполнять синхронизацию.Данная процедура займет определенное время ( все зависит от объема ваших дисков). Наблюдать за происходящим можно выполнив команду:

синхронизация нового raid1 масива

Собственно последним этапом будет установка загрузчика, если вы производите починку на живую ( с под загруженной ОС), то достаточно запустить grub-install на новом жёстком диске, например можно это сделать следующим образом (если юзаете GRUB2,):

Если используете Grub1 ( это старая версия grub) то нужно выполнить немного больше шагов.

установка grub1 на новый ХДД

Замена нерабочего жесткого диска на RAID 1 завершена! Спасибо что читаете https:/

Теория: Уровни RAID и принципы восстановления данных

Чаще всего сейчас используются массивы уровней 0, 1, 10, 5, 50. В последнее время наблюдается возрастающий интерес к шестому уровню.

Ниже приведена краткая информация о принципах работы массивов. Более подробно, об этом можно прочитать в соответствующей статье.

RAID 0 – использование чередующейся записи (страйп). Строится из двух и более накопителей. Информация записывается на все диски массива блоками определенного (8кб,16кб,32кб,64 кб, 128кб…) размера. Файлы, размер которых один блок, равномерно распределяются по двум или более дискам.

Из-за отсутствия избыточности или дублирования данных, при выходе из строя одного из дисков, восстановить информацию в полном объеме невозможно без использования данных с неисправного накопителя. Исключением будут лишь файлы, размер которых меньше размера блока. Для полноценного восстановления информации в таких случаях необходимо сначала снять данные с неисправного диска, после чего восстанавливать RAID.

В случаях, когда все диски исправны, а массив отказывается корректно работать, восстановление производится программными методами, которые описаны

RAID 1 – использование технологии зеркалирования (зеркало). Строится из двух дисков. Информация одновременно пишется на оба накопителя, каждый диск является полной копией своего собрата. В случае выхода из строя одного из дисков массив остается работоспособным.

Если происходит сбой в работе контроллера и массив перестает определяться, то восстановление данных можно выполнить, воспользовавшись советами из статьи «Простое восстановление данных». Для этого один из дисков следует подключить к компьютеру на прямую, минуя RAID контроллер. Если повезёт, после подключения Ваши данные могут оказаться доступными и без использования программ, описанных в вышеуказанной статье.

RAID 10 – это объединение уровня 0 с уровнем 1, т.е. два страйпа объединяются в зеркало. В массиве используются минимум 4 диска. Он может остаться работоспособным при выходе из строя одного из составляющих его RAID 0.

При возникновении проблемы, в первую очередь необходимо определить, с чем именно возникли неполадки – с контроллером или с дисками

Когда проблема на уровне контроллера, Вам следует определить, какие винчестеры являются парами, составляющими страйпы

Здесь важно не перепутать диски, т.к. это приведет к потерянному времени и отсутствию результата

После того, как это станет известно, берётся одна такая пара, и с неё снимается информация таким же образом, как и с самостоятельного RAID 0.

Во время эксплуатации RAID 10, случается и такое, что выходят из строя два диска. Здесь возможны следующие варианты:

1) Оба диска принадлежат к одному страйпу, контроллер корректно обрабатывает исключительную ситуацию, и массив продолжает функционировать нормально.

2) Оба диска принадлежат к одному страйпу, но массив разваливается. В этом случае просто берём исправный страйп, и программно собираем его (об этом ниже).

3) Диски принадлежат к разным страйпам, но в одном из них уцелел первый, а в другом второй накопитель. Попробуйте программно собрать из них RAID 0.

4) Вышли из строя одноимённые диски разных страйпов. Увы  Один из сломанных дисков придётся отремонтировать, или каким-либо ещё образом снять с него данные. Затем программная сборка.

RAID 5 – массивы с контролем четности. Основным его достоинством является распределение блоков информации и контрольных блоков четности по всем дискам массива. Для создания такого массива требуется минимум три диска. Объём массива равен сумме объёмов составляющих его накопителей, минус один диск. Блоки контроля чётности используются для вычисления недостающей информации при выходе из строя одного из накопителей, составляющих массив. Таким образом, при утрате одного из дисков данные не теряются, и массив может продолжать работу.

Но, случается и такое, что после выхода из строя одного накопителя, контроллер неверно обрабатывает исключительную ситуацию и массив перестает корректно работать, либо полностью «падает». Подобный сбой может возникнуть также во время выполняемого после замены диска перестроения массива. Иногда в течение короткого времени после смерти первого диска, выходит из строя ещё один.

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

Замена дисков в RAID массиве и восстановление информации

Нередко бывают случаи, когда один из жестких дисков выходит из строя. Собственно, для предотвращения потери информации и создается массив RAID 1. Как же в таком случае заменить сломавшийся винчестер?

Достаточно просто:

1. Убираем из компьютера «полетевший» жесткий диск и вставляем на его место новый, идентичный по объему
2. Заходим в панель управления RAID массивом
3. Добавляем новый диск и запускаем функцию восстановления «Rebuild Array»

После этого все данные будут повторно продублированы с первого жесткого диска на второй, и массив RAID 1 заработает, как прежде.

В RAID 5 все немного сложнее. При выходе из строя жесткого диска не нужно ничего трогать. Необходимо вставить в компьютер новый изайти в утилиту конфигурации RAID. Определить его и подключить к существующему массиву в качестве «горячий резерв», после чего контроллер массива создаст его заново.

Вот собственно и все — RAID настроен и теперь компьютер будет воспринимать ваши диски как один. Вот так, например, будет виден Raid при установке Windows.

Думаю, что вы уже поняли преимущества использования Raid. Напоследок приведу сравнительную таблицу замеров скорости записи и чтения диска отдельно или в составе режимов Raid — результат, как говорится, на лицо.

Как создать массив из жестких дисков на компьютере через RAID контроллер?

Прежде, чем мы сможем создать эту систему, нужно узнать, поддерживает ли материнская плата работу с дисковыми массивами Raid. Во многих современных системных платах уже имеется встроенный Raid-контроллер, который-то и позволяет объединить жесткие диски. Поддерживаемые схемы массивов имеются в описаниях к материнской плате. Например, возьмем первую попавшуюся мне на глаза в Яндекс Маркете плату ASRock P45R2000-WiFi.

Здесь описание поддерживаемых Raid массивов отображается в разделе «Дисковые контроллеры Sata».

В данном примере мы видим, что Sata контроллер поддерживает создание массивов Raid: 0, 1, 5, 10. Что означают эти цифры? Это обозначение различных типов массивов, в которых диски взаимодействуют между собой по разным схемам, которые призваны, как я уже говорил, либо ускорять их работу, либо увеличивают надежность от потери данных.

Если же системная плата компьютера не поддерживает Raid, то можно приобрести отдельный Raid-контроллер в виде PCI платы, которая вставляется в PCI слот на материнке и дает ей возможность создавать массивы из дисков. Для работы контроллера после его установки нужно будет также установить raid драйвер, который либо идет на диске с данной моделью, либо можно просто скачать из интернета. Лучше всего на данном устройстве не экономить и купить от какого-то известного производителя, например Asus, и с чипсетами Intel.

Я подозреваю, что пока что вы еще не очень имеете представление, о чем все же идет речь, поэтому давайте внимательно разберем каждый из самых популярных типов Raid массивов, чтобы все стало более понятно.

Исходная ситуация

Исходные настройки:

# cat /proc/mdstat
Personalities :  
md3 : active raid1 sda4 sdb4
     1822442815 blocks super 1.2 [2/2] 

md2 : active raid1 sda3 sdb3
     1073740664 blocks super 1.2 [2/2] 

md1 : active raid1 sda2 sdb2
     524276 blocks super 1.2 [2/2] 

md0 : active raid1 sda1 sdb1
      33553336 blocks super 1.2 [2/2] 

unused devices: <none>

Всего четыре массива:
/dev/md0 — swap
/dev/md1 — /boot
/dev/md2 — /
/dev/md3 — /home

Например, /dev/sdb — это сбойный диск. или показывает, что массив не синхронизирован. Когда массив в порядке, он отображается как .

# cat /proc/mdstat
Personalities : 
md3 : active raid1 sda4 sdb4(F)
     1822442815 blocks super 1.2 [2/1] 

md2 : active raid1 sda3 sdb3(F)
     1073740664 blocks super 1.2 [2/1] 

md1 : active raid1 sda2 sdb2(F)
      524276 blocks super 1.2 [2/1] 

md0 : active raid1 sda1 sdb1(F)
     33553336 blocks super 1.2 [2/1] 

unused devices: <none>

Вносить изменения в программном RAID можно из работающей системы. Если один из дисков не отображается в массиве как показано ниже, то можете сразу согласовать время замены диска.

# cat /proc/mdstat
Personalities : 
md3 : active raid1 sda4
     1822442815 blocks super 1.2 [2/1] 

md2 : active raid1 sda3
     1073740664 blocks super 1.2 [2/1] 

md1 : active raid1 sda2
     524276 blocks super 1.2 [2/1] 

md0 : active raid1 sda1
     33553336 blocks super 1.2 [2/1] 

unused devices: <none>

Изъятие повреждённого жёсткого диска
Перед установкой нового диска необходимо удалить сбойный диск из RAID-массива. Это необходимо сделать для каждого раздела.

# mdadm /dev/md0 -r /dev/sdb1
# mdadm /dev/md1 -r /dev/sdb2
# mdadm /dev/md2 -r /dev/sdb3
# mdadm /dev/md3 -r /dev/sdb4

Следующая команда показывает диски, входящие в массив:

# mdadm --detail /dev/md0

В некоторых случаях, жёсткий диск может быть повреждён частично, например, статус только у массива /dev/md0, а все другие массивы имеют статус . В таком случае команда

# mdadm /dev/md1 -r /dev/sdb2

не пройдёт, так как устройство /dev/md1 в порядке.

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

# mdadm --manage /dev/md1 --fail /dev/sdb2

чтобы изменить статус RAID-массива на .

Заключение

Надеюсь, моя статья была интересной. Для тех, кто никогда не работал с ЦОДами будет полезно узнать, чего можно от них ожидать. Я скучаю по временам, когда все сервера, которые я администрировал, были в серверной, куда никому не было доступа и куда я мог в любой момент попасть и проверить их. Сейчас все стало не так. И твои сервера уже не твои. Их может сломать, уронить, что-то перепутать сотрудник тех поддержки дата центра.

Сейчас большой тренд на переход в облака. Я смотрю на эти облака и не понимаю, как с ними можно нормально взаимодействовать. Заявленная производительность не гарантированная, нагрузка плавает в течении суток. Упасть может в любой момент и ты не будешь понимать вообще в чем проблема. Твои виртуалки могут быть по ошибке удалены и кроме извинений и компенсации в 3 копейки ты ничего не получить. Каждое обращение в ТП как лотерея. Думаешь, что сломают в этот раз. Если сервера железные, то когда пишу тикет на доступ к железу, я морально и технически всегда готов к тому, что этот сервер сейчас отключится и я больше не смогу к нему подключиться.

В целом, опыт работы с облаками у меня негативный. Несколько раз пробовал для сайтов и все время съезжал. Нет гарантированного времени отклика. А это сейчас фактор ранжирования. Для очень быстрого сайта остается только один вариант — свое железо, а дальше уже кому какое по карману. Зависит от надежности и допустимого времени простоя.

Я про облака заговорил, потому что тенденции к тому, что от железных серверов надо отказываться и все переносить в облака. С одной стороны удобно должно быть. Как минимум, не будет указанных выше в статье проблем. А с другой стороны добавляется куча других проблем. Я пока сижу на железяках разного качества и стоимости. А у вас как?

Онлайн курс «SRE практики и инструменты»

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «SRE практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и Linux. Обучение длится 3 месяц, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

На курсе вы узнаете как:

• Внедрить SRE практики в своей организации
• Управлять надежностью, доступностью и эффективностью сервисов
• Управлять изменениями
• Осуществлять мониторинг
• Реагировать на инциденты и производительность
• Работать со следующим технологическим стеком: Linux, AWS, GCP, Kubernetes, Ansible, Terraform, Prometheus, Go, Python.

Проверьте себя на вступительном тесте и смотрите подробнее программу по .

Заключение

В заключении ещё раз отметим – если данные очень важны, отложите эксперименты на другое время, и обратитесь к специалистам. Советуем это, зная печальный опыт многих людей.

Версия от 27.03.2009.Валерий Пьянков, R.LAВ, восстановление RAID массивов.

Основное условие распространения – сохранение ссылок, содержащихся в тексте данной статьи и подписи.

Отзывы о статье Восстановление RAID массивов простыми методами 10.09.2008

Толковая статья. Хорошо бы еще рассказать о массивах уровней 1Е, 5Е, 6 -они теперь часто встречаются 11.09.2008

Да, я сейчас планирую заняться написанием статьи о массивах. В этой статье не упоминали их т.к.  доступного софта для сборки массивов  уровней 1Е, 5Е пока еще нет, а статья сама именно о их восстановлении. 11.09.2008

Очень хорошая статья!!! Интересная и понеятная! З.Ы. Вы случайно не педогог….? 27.09.2008

Наверное не педогог…А получился бы отличный… 27.09.2008

Нет, не педагог 29.09.2008

написано грамотно и доступно! Побольше таких лекций! 06.11.2008

Большое спасибо за статью. Даный материал помог мне написать реферат на тему : «Обслуживание RAID — масивов ПК» с дисциплины «Диагностика КС» (возможно отзыв позволить быстрее нагуглить эту статью нуждающимся в ней). 05.02.2010

Спасибо Старался 05.02.2010

спасибо за статью, сейчас как раз пробую востановить RAID 5, 4HDDx 320Gbкак что отпишу, действительно это очень долго, но я так понимаю просто не хватает ресурсов (жадные директора)Валерию спасибо за консультации по телефону 10.10.2010

|