После проверки целостности диска (Scan Disk) получил:
«Warning : The device with Raid 1 is degraded now. Please remember to rebuild the Raid 1 for data integrity.
Auto-Rebuild Configuration allows you to enable or disable the Auto-Rebuild feature. You can also manually rebuild by clicking the Manually Rebuild Now button. Please note that rebuilding will erase all data on the newly inserted drive.»
Все диски пустые, я в шоке, все за больше чем 1 год пропало. Как, как такое может быть? Зачем тогда рейд 1? Ребята из DLink, что вы выпускаете?
Начал разбираться. Купил адаптер USB-SATA. Установил R-Linux, вытащил диски из NAS, начал последовательно подключать через адаптер.
Решил сделать побитовую копию правого диска на другом диске (пришлось еще купить диск на 2 Тб), чтобы не проводить эксперименты на оригинальном диске из NAS, провел клонирование диска с помощью Acronics True Image через загрузочный образ, которое завершилось не успешно после 18 часов работы.
Решил повторить попытку уже из-под Windows, процесс начался заметно быстрее, вечером возможно буду изучать результаты.
Доброе время суток! Да, NAS мне предлагал восстановить диски, но Вы думаете я доверюсь системе, которая при «безопасной» операции проверки дисков на ошибки разрушила зеркало?
И таки да, при игнорировании операции восстановления, данных на зеркале не было и можно было создать директорию через встроенный файловый менеджер веб-интерфейса, что конечно я не сделал.
После попытки сделать клон диска из-под Windows, через Acronis True Image 2014, после 18 часов работы, попытка не увенчалась успехом. Через некоторое время поисков в Интернет, я нашел драйвер ext4 для Windows Ext2Fsd и решился его использовать на свой страх и риск. Установил, подключил правый диск разрушенного зеркала и. я увидел нужную мне структуру директорий, получил доступ к файлам, которые я уже думал потерял навсегда.
В настоящий день уже больше 12 часов идет копирование файлов и архивов и проверка их целостности. Пока боюсь загадывать, но приблизительно 98-99% информации думаю получится восстановить. Но часть файлов около 1-2% все равно стали недоступными, хотя они присутствуют в каталоге, думаю вернуться к ним после завершения восстановления основных файлов.
Интересные выводы. Диски, работающие в зеркале в NAS-325 (SMART обоих дисков показывает отличное их здоровье), благодаря безобидной операции логически разрушились, на одном диске информация потерялась полностью, на другом на 1-2%, мне повезло. могло бы быть гораздо хуже. Доверие к программным рейдам в лице NAS-325 и к компании DLINK подорвано навсегда.
Восстановить всю возможную информацию через ext2fsd, не получилось, порядка 8-9% информации не удалось извлечь. Ряд файлов присутствуют в каталогах, но скопировать их не получилось, возникает ошибка копирования. Наличие их в каталоге подвигло меня дальше искать варианты их восстановления. С помощью утилиты WinMerge я составил для себя список файлов, которые не получилось скопировать. Потом я вернулся опять к утилите R-Linux, предварительно удалив драйвер ext2fsd из системы.
После сканирования диска в течении 4-5 часов, я увидел ту же иерархию каталогов, что и через ext2fsd, руководствуясь списком не скопированных файлов, я попытался восстановить их и. у меня получилось! Файлы скопировались и похоже, что удастся существенно снизить процент потерь информации. продолжение следует.
Вот и закончилась эпопея с восстановлением казалось бы потерянной информации. длинною в 1 неделю. Компьютер копировал, восстанавливал и гонял терабайты информации между дисками круглосуточно. Удалось восстановить всю важную информацию и частично менее важную. Потери составили порядка 1% от объема исходной информации.
Не понятно вообще никому. «корневой» папкой я в данном случае назвал одну из папок в расшаренной Volume_1.
А как понять «открыть доступ» и «посмотреть, что внутри»? И есть ли смысл в это фразе, если объём занимаемой информации уменьшился на порядка 600 Гб? И если оба диска при монтировании видятся с ext4 одинаковыми? и если testdisk видит удалённые папки и файлы? только пишет что они «damaget»?
В голове до сих пор один вопрос: КАК, Б**ДЬ. Как удалилась полностью одна папка из Volume_1 и как из другой папки удалились половина подпапок и половина файлов.
В современном мире все уже давно поняли какой ценностью обладает информация и какой огромный потенциал заложен в развитии IT технологий. Поскольку сервера и компьютеры могут выходить из строя – автоматически возник вопрос как обеспечить безопасность данных, так как их потеря важной информации может обанкротить целые компании, а убытки могут достигать многих миллионов. В свою очередь это привело в появлению RAID массивов – технологии, которая призвана предотвратить потерю информации путем объединения нескольких накопителей в один массив. Однако, как показала практика – RAID массивы также могут ломаться.
В этой статье мы рассмотрим главные причины выхода из строя RAID массивов.
Содержание:
История развития RAID
В самом начале развития компьютерных технологий все внимание было направлено на том, как сделать компьютеры максимально удобными для пользователя. В те времена не существовало понятия «персональный компьютер», так как наиболее часто компьютеры использовались в военной промышленности (но там совсем другая история, так как военная индустрия обладает своими наработками по безопасности информации и т.д.) и в больших корпорациях. Но в те времена функционал компьютеров был очень небольшим и с ними по большей части работали программисты.
Даже в 1970х годах, когда Apple и Microsoft начали свою деятельность – вопрос о безопасности данных не был на первом месте. Все изменилось с появлением и развитием интернета, который начал охватывать все больше и больше стран и позволял пользователям обмениваться информацией. Стоит также отметить, что к тому времени все уже привыкли к персональным компьютерам и поняли, что они способны сильно облегчить жизнь обрабатывая огромные массивы информации. С появлением цифровых фотоаппаратов и видеокамер для личного использования всем стало ясно, что персональные компьютеры так или иначе будут практически в каждом доме. После этого начался бум цифровой индустрии, который автоматически поднял вопрос о безопасности данных. Немало этому посодействовали большие компании, которые уже в те времена обладали большими серверами для хранения данных, от которых сильно зависел уровень их эффективности. Поэтому, в 1987 году были придуманы RAID массивы. Их главным заданием было избежание потерь важной информации и поскольку технология была эффективной и предлагала на выбор несколько вариантов защиты данных, в зависимости от потребностей пользователя – она быстро приобрела распространение. Примерно так выглядит блок дисков, объединенных в RAID:
Несмотря на то, что никакой стандартизации не проводилось – следующие уровни массива RAID были приняты как стандарт:
Все остальные типы RAID массивов (такие как RAID 10, RAID 50 и т.д.) построены на вышеперечисленных типах RAID и так или иначе используют их концепцию.
Использование массивов RAID оказалось настолько эффективным, что на сегодняшний день практически все современные хранилища данных (сервера, NAS и т.д.) используют RAID массивы в том или ином виде.
Однако, несмотря всю надёжность такого решения стоит отметить, что вероятность потери данных все же осталась (хоть и сильно снизилась) так как даже RAID массивы иногда выходят из строя. Это может происходить по многим причинам и для того, чтобы узнать больше информации на эту тему читайте следующий пункт этой статьи.
Что такое деградированный режим RAID?
RAID массив как и обычные диски может подвергаться сбоям рода и в случае, если один из дисков выйдет из строя – весь массив перейдет в так называемый «Деградированный режим» В этом режиме данные остаются доступными и массив продолжает свою работу но с сильным снижением производительности. За переход массива в «деградированный режим» отвечает контроллер, который переводит массив в этот режим в случае обнаружение сбоев в работе любого из дисков массива или полного отсутствия одного из дисков. В случае перехода массива в деградированный режим пользователь увидит сообщение «DegradedArray event was detected on device md dev/md/1» либо «ARRAY IS DEGRADED – 1 disk is missing»
Также о переходе массива в деградированный режим может свидетельствовать символ «[U_]» при проверке состояния RAID массива в терминале. Обычно он находится возле поврежденного диска и означает, что он рассинхронизирован.
В этом случае следует немедленно заменить поврежденный диск так как в случае выхода из строя еще одного диска все данные массива будут потеряны.
Причины потери данных на RAID массивах
При использовании RAID массивов данные хранятся на таких же накопителях, что и в обычных компьютерах, которые могут ломаться и т.д. Технология RAID позволяет предотвратить потерю данных, но процесс восстановления информации может сильно затянуться, так как нередко при выходе из строя одного накопителя скорость работы всего RAID массива сильно снижается, особенно это актуально, когда речь заходит о терабайтах информации, как например на сервере. Кроме того, в некоторых случаях, чтобы заменить поврежденный носитель на новый – требуется отключение питания, что тоже не очень подходит для серверов. Поэтому лучше всего знать главные причины выхода из строя RAID массивов, чтобы иметь возможность предотвратить неприятности.
Итак, среди основных причин можно выделить следующие:
Выход из строя RAID контроллера
Контроллер RAID массива является одним из наиболее важных элементов, так как именно он отвечает за распределение данных между накопителями и позволяет работать с массивом как с единым накопителем. Если массив прекращает свою работу – наиболее часто это вызвано именно поломкой контроллера. Стоит отметить, что аппаратные контроллеры ломаются немного реже чем программные, но и стоят они на порядок дороже. Кроме того, между аппаратными контроллерами разных производителей нет совместимости. То есть, если вы приобрели контроллер от фирмы Supermicro то для восстановления работоспособности массива вам придется купить такую же модель. В противном случае вам придется создавать массив заново, что приведет к потере данных. Среди причин, из-за которых контроллер выходит и строя можно выделить такие как перепад напряжения или резкое отключение энергии. Это актуально как для аппаратных RAID контроллеров, так и для программных. Поэтому, обязательно позаботьтесь о бесперебойном источнике питания, чтобы обеспечить ваш RAID массив от возможных проблем.
Ошибка пересборки/сборки RAID массива
Во время каждой перезагрузки компьютера RAID массив пересобирается заново и от того, пройдет ли сборка нормально зависит дальнейшая работа массива. Если во время перестройки массива произойдёт перепад напряжения или другое форс-мажорное событие – массив не будет пересобран, и пользователь моет потерять данные.
Выход накопителя из строя
Все мы знаем, что главным предназначением RAID массивов является защита данных на случай выхода из строя одного или двух дисков. Обычно RAID массив без проблем справляется с этой задачей. Но иногда случаются ситуации, когда при выходе одного или нескольких дисков повреждаются данные на соседнем носителе и в такой ситуации RAID массив может оказаться полностью неработоспособным, что в свою очередь приведет к потере информации. Поэтому настоятельно рекомендуется периодически проверять состояние накопителей, из которых построен RAID массив.
Отсутствие разделов массива
Для обеспечения нормальной работы RAID массивов применяется технология чередования, главной задачей которой является распределение информации меду дисками в рамках одного логического тома. Это позволяет обеспечить высокий уровень производительности и защиты данных, однако, если механизм чередования будет повреждён – данные окажутся недоступными, даже если физически они в полной сохранности. Все дело в том, что RAID массив просто не смоет определить диски с данными и соответственно не сможет собрать массив для дальнейшей работы.
Поломка сервера
Хост компьютер, как и любой другой может поломаться или дать сбой. Это в свою очередь отобразится на RAID массиве. В 70% таких случаев данные оказываются недоступными.
Все вышеперечисленные поломки являются наиболее часто встречающимися причинами выхода из строя RAID массивов. Обычно, после таких поломок приходится использовать стороннее ПО для восстановления данных. О том, как восстановить данные на RAID массиве читайте в следующем пункте этой статьи.
Что делать при сбое RAID массива или если RAID массив не собирается после перезагрузки?
Если ваш RAID массив перестал работать после сбоя, либо не собирается после перезагрузки то для восстановления рабочего состояния без потери данных вам следует сначала извлечь данные массива, чтобы не повредить их во время восстановления работоспособности RAID. Для этого следует:
Шаг 1: Выключите питание вашего компьютера/сервера или NAS устройства и отсоедините накопители, из которых состоял RAID массив.
Шаг 2: Подсоедините эти диски в рабочему компьютеру (предварительно отключив его питание).
Шаг 3: Включите рабочий компьютер. Затем скачайте и установите програму RS RAID Retrieve следуя подсказкам мастера установки Windows.
Мы специально выбрали эту программу, так как она обладает широкими возможностями восстановления данных и интуитивно-понятным интерфейсом одновременно, а значит она отлично подходит как для неопытных пользователей, так и для профессионалов.
Шаг 4: Запустите программу RS RAID Retrieve дважды кликнув по иконке на рабочем столе. Перед вами откроется встроенный RAID конструктор.
Шаг 5: Выберите тип добавления RAID массива для сканирования. RS RAID Retrieve предлагает на выбор три варианта:
После того, как выберите подходящий вариант – нажмите «Далее»
Шаг 6: Выберите диски, из которых состоял RAID массив и нажмите «Далее». После этого начнется процесс обнаружения конфигураций массива. После его завершения нажмите «Готово»
Шаг 7: В окне программы выберите ваш массив, щелкните по нему правой кнопкой мыши и выберите «Сохранить диск», а затем укажите место для сохранения копии диска и снова нажмите «Сохранить»
После этого начнется копирование файлов в указанное место. Вы также можете сохранить отдельные файлы или восстановить потерянные данные, если нужно. Для этого дважды щелкните на массиве и выберите тип сканирования. RS RAID Retrieve предлагает на выбор два типа сканирования: быстрое сканирование и полное сканирование. Первый вариант стоит выбрать если вы просто хотите скопировать файлы на другой носитель, а второй вариант выберите если хотите восстановить утерянные данные.
Также на этом этапе выберите тип файловой системы вашего массива. RS RAID Retrieve поддерживает ВСЕ современные файловые системы. Теперь, когда все настроено, нажмите «Далее».
Начнётся процесс сканирования массива, по завершении которого вы увидите прежнюю структуру файлов и папок.
Шаг 8: Выберите файл, который хотите восстановить и жажды на нем щелкните. Затем выберите место, куда хотите восстановить утерянный файл. Это может быть жесткий диск, ZIP-архив, или FTP-сервер. Главное, чтобы место записи нового файлов отличалось от дисков массива. Затем нажмите «Восстановить»
Теперь, когда данные находятся в безопасности – можно приступать к восстановлению работоспособности самого массива. В первую очередь нужно найти причину проблемы и устранить ее.
RAID массив мажет не пересобираться после перезагрузки по следующим причинам:
Первые две причины являются достаточно распространенными, поэтому на них стоит обратить особое внимание.
Если же причина или сбой были на физическом уровне – замените вышедшие из строя нужные элементы.
Если вы не хотите тратить время на исправление программных ошибок – вы можете просто создать RAID массив заново, а затем скопировать данные обратно из сохраненной копии.
Как неоднократно говорилось всеми умными людьми — «Пока гром не грянет. «, ну а дальше и так всем уже понятно.
На работе есть сервер на Windows Server 2008 R2 являющийся одновременно главным контроллером домена и файловым сервером. Собран на базе контроллера LSI Megaraid 9260-16i и восьми 2Тб жестких дисков Seagate ST2000DM001.
Диски объединены в массив RAID6.
Некоторое время назад практически одновременно два диска вылетели из массива — в логах были сообщения вида Uncorrectable Media Errors со ссылками на эти два диска, затем были сообщения об их отключении и включении по питанию, а затем оба диска перешли в состояние Failed, а состояние массива стало Degraded. Данные с массива при этом были доступны, система нормально работала, при перезапуске сервера — он без проблем стартовал.
Были заказаны да аналогичных жестких диска. Немногим больше одной недели их закупали, потом еще примерно неделю я выжидал подходящего момента для замены. В праздники приступил к замене. Сменил статус двух «больных» дисков на — «подготовка к замене». По данным установленной в ОС программы MegaRaid Storage Manager эти диски в вышли из Virtual Drive, спустились ниже и стали Unconfigured Bad. Я извлек их из машины. Через некоторое время последовательно установил два диска им на замену.
При этом контроллер самостоятельно не начинал процедуру «ребилда», и по этому я, перевел оба новых диска в состояние Global Hot Spare, затем обновил программу управления контроллером (в смысле refresh) — и увидел, что оба диска «подтянулись» в Virtual Drive и на них начался процесс Rebuild’а. Шел он последовательно, сперва прогресс-бар заполнился на одном винте, затем начался на другом. Я не стал дожидаться окончания процедуры. По журналу контроллера примерно через 6 часов оба диска уже были «в строю».
И все пришло в норму.
То есть, «задурил» еще один жесткий диск. При этом, он очень быстро пришел в «негодность» — проскочило сообщения о том, что он перешел в состояние Unconfired Bad и он окрасился рыже-красным значком.
То есть, когда я утром запустил MSM и увидел все эти события в логе, состояние массива было Partially degraded. Так как я не достаточно знаком с терминологией и особенностями работы raid-массивов, в частности, очень редко посещал этот форум и не читал обязательной и рекомендованной тут литературы, первым делом принялся искать на просторах всемирной сети информацию о том, что собственно произошло, и чем это все может грозить.
Но было уже поздно. Сотрудники фирмы сообщили о проблемах с доступам к некоторым расположенным на этом сервере сетевым папкам и файлам. Я проверил права доступа — там все было в норме, но и с самого сервера (локально) я не мог открыть эти директории. Затем почти сразу отовсюду посыпались ошибки системы, ошибки с адресами в ОЗУ и ошибки доступа к системным файлам Windows.
Буквально через пару минут моя терминальная сессия повисла, а затем закрылась. Сервер ушел на перезагрузку, и ОС с него уже не загружалась. И вот тут, я запаниковал, и сделал единственное что пришло в голову после поверхностного прочтения информации об ошибках их журнала с контроллера — нужно сделать Consistency Check. Я запустил эту процедуру из БИОСа контроллера.
Спустя сутки она была завершена, но не принесла положительного результата — ОС так и не загружалась.
Через некоторое время, после подбора загрузочного диска с дистрибутивом Windows 2008 Server R2, и его записи на флешку с поддержкой UEFI (в противном случае другие дистрибутивы и загрузочные носители ругались на то, что Восстановление системы с этого диска невозможно, видимо, не определяя GPT структуру разделов в массиве), удалось с нее загрузиться и запустить Восстановление системы.
Там было всего три пункта для выбора, и верхний из них предлагал восстановление системы из резервной копии образа. Так как регулярные бэкапы на сетевое хранилище выполнялись только для файлового хранилища, судя по всему, не неся в себе System State и другую информацию для восстановления ОС, я попробовал посмотреть резервную копию на локальном диске С.
Но, открывшейся проводник не смог получить доступ в разделы C и D (раздел под установленную ОС и раздел с файловым архивом), и выставив Вид в проводнике в Таблицу — я увидел, что файловая система этих разделов с массива — RAW.
Собственно, в этот момент я понял, что могу дальше необдуманными действиями совсем все поломать или сделать еще хуже. Подскажите, пожалуйста, как мне быть? Как вы считаете, что можно в сложившейся ситуации предпринять? Какими должны быть мои действия для восстановления данных и работоспособности сервера?
P.S. Мысли и вопросы на данную тему..
а) так как массив Partially degraded — будет ли ему (и данным на нем) лучше или хуже, если я доставлю еще один такой же диск на 2Тб и запущу процесс пересборки массива? Как это может сказаться на нем?
б) может, мне с установочного дистрибутива ОС запустить CHKDSK /F для системного раздела и файловая система и структура будут восстановлены? Читал, что есть мнения, о том, что для проблемных RAID5 этого лучше не делать, так как это может совсем испортить данные на диске. Но у меня проблемный массив RAID6 ([хотя, в текущем состоянии, он, наверное, ближе к проблемного RAID5), да и верно ли это утверждение о вреде CHKDSK для RAID массивов созданных на аппаратном контроллере с кэшем, памятью, батареей и тп?
г) я так понимаю, что в любом случае, раз уж массив поврежден, сыпал указанными выше ошибками, то вне зависимости от того, получится с него данные восстановить и перенести в другое место, или не получится, я могу смело на этом же контроллере к оставшимся незадействованными портам подключать новые диски и создавать новый дисковый массив, что бы в дальнейшем его использовать, а поврежденный массив вывести из эксплуатации и забрать диски?
Re: How to rebuild degraded RAID1 array
Post by Toxic17 » Tue Sep 26, 2017 5:34 am
ssh into your NAS with PuTTy, type in the following:
you should see something :
please post YOUR output.
Объединение 2-х дисков в 1: настройка RAID-массива на домашнем компьютере (просто о сложном)
При подключении нескольких дисков к компьютеру (ноутбуку) — каждый из них появляется под своей буквой (C, D, E и др.) и представляет из себя отдельный независимый накопитель. Но объединив эти диски в RAID-массив — можно из двух дисков по 1 ТБ (например) получить единый накопитель на 2 ТБ (причем, с удвоенной* скоростью работы!).
Согласитесь, звучит заманчиво?! Однако, многим пользователям слово «RAID» — либо вообще ничего не говорит, либо напоминает что-то такое отдаленное и сложное (явно-недоступное для повседневных нужд на домашнем ПК/ноутбуке). На самом же деле, все проще, чем есть…
Программный RAID в Linux с помощью mdadm
mdadm – утилита для работы с программными RAID-массивами в Linux. В статье мы рассмотрим, как работать с утилитой mdadm (multiple disks admin) для создания массива, добавления дисков, управления дисками, добавление hot-spare и много другой полезной информации.
Установка утилиты управления программным RAID — mdadm
Чтобы установить утилиту mdadm, запустите команду установки:
В резульатте в системе будет установлена сама утилита mdadm и необходимые библиотеки:
У меня на сервере установлены два дополнительных диска и я хочу содать на низ програмное зеркало (RAID1). Диски пустые, данные на них не писались. Для начала, нужно занулить все суперблоки на дисках, которые мы будем добавлять в RAID-массив:
Массив смонтировался без ошибок. Чтобы не монтировать устройство каждый раз вручную, внесем изменения в fstab:
/dev/md0 /backup ext4 defaults 1 2
Просмотр состояния, проверка целостности RAID массива
Чтобы проверить целостность данных в массиве, используйте команду:
#echo ‘check’ > /sys/block/md0/md/sync_action
После чего, нужно посмотреть вывод файла:
Если в результате вы получаете 0, то с вашим массивом все в порядке:
Чтобы остановить проверку, используйте команду:
#echo ‘idle’ > /sys/block/md0/md/sync_action
Восстановление RAID при сбое, замена диска
Если у вас вышел из строя или повредился один из дисков в RAID-массиве, его можно заменить другим. Для начала определим, поврежден ли диск и какой диск нам следует менять.
Personalities : [raid1]md0 : active raid1 vdb[0]20954112 blocks super 1.2 [2/1] [U_]
Из листинга команды, вы видим, что только один диск активен. Так же о проблеме говорит [U_]. Когда оба диска рабочие, вывод будет [UU].
Подробная информация о RAID-массиве также показывает, что естт проблемы:
/dev/md0:Version : 1.2Creation Time : Tue Oct 29 12:39:22 2019Raid Level : raid1Array Size : 20954112 (19.98 GiB 21.46 GB)Used Dev Size : 20954112 (19.98 GiB 21.46 GB)Raid Devices : 2Total Devices : 2Persistence : Superblock is persistentUpdate Time : Tue Oct 29 14:41:13 2019State : clean, degradedActive Devices : 1Working Devices : 1
State : clean, degraded – данная строка указывает на то, что диск в raid-массиве поврежден.
В нашем случае нужно заменить неисправный диск /dev/vdc. Для восстановления массива, нужно удалить нерабочий диск и добавить новый.
Удаляем неиспраный диск:
# mdadm /dev/md0 —remove /dev/vdc
Добавляем в массив новый диск :
# mdadm /dev/md0 —add /dev/vdd
Восстановление диска запустится автоматически после добавления нового диска:
/dev/md0:Version : 1.2Creation Time : Tue Oct 29 12:39:22 2019Raid Level : raid1Array Size : 20954112 (19.98 GiB 21.46 GB)Used Dev Size : 20954112 (19.98 GiB 21.46 GB)Raid Devices : 2Total Devices : 2Persistence : Superblock is persistentUpdate Time : Tue Oct 29 14:50:20 2019State : clean, degraded, recoveringActive Devices : 1Working Devices : 2Failed Devices : 0Spare Devices : 1Consistency Policy : resyncRebuild Status : 69% completeName : server.vpn.ru:0 (local to host server.vpn.ru)UUID : 9d59b1:7b0a7b6d:15a75459:8b1637a2Events : 42Number Major Minor RaidDevice State0 253 16 0 active sync /dev/vdb
2 253 48 1 spare rebuilding /dev/vdd
rebuild Status : 69% complete — показывает текущее состояние восстановления массива.
spare rebuilding /dev/vdd — показывает какой диск добавляется к массиву.
После восстановления массива, листинг по дискам выглядит так:
Mdmonitor: Мониторинг состояния RAID и email оповещения
Для мониторинга состояния RAID массива можно использовать службу mdmonitor. Сначала нужно создать файл /etc/mdadm.conf с конфигурацией текущего массива:
# mdadm –detail –scan > /etc/mdadm.conf
В конце файла /etc/mdadm.conf добавьте email адрес администратора, на который нужно слать оповещения о проблемах с RAID:
Останолось перезапустить службу mdmonitor через systemctl:
# systemctl restart mdmonitor
После этого система будет оповещать вас по email об ошибках в mdadm и неисправных дисках.
RAID массив в состоянии inactive
При сбоях оборудования или аварийного выключения по питанию, массив может перейти в состояние inactive. Все диски помечаются как неактивные, но ошибок на дисках нет.
Восстановление RAID 1 или как мне поменяли не тот диск
Хочу рассказать поучительную историю, которая случилась со мной на днях. На одном из серверов в ЦОД вышел из строя диск в составе рейда mdadm. Ситуация типовая, с которой регулярно сталкиваюсь. Оставил заявку в техподдержку на замену диска с указанием диска, который надо поменять. В цоде заменили рабочий диск и оставили сбойный. Дальше история, как я решал возникшую проблему.
Цели статьи
Введение
Когда первый раз сталкиваешься с рукожопством сотрудников техподдержки дата центра, впадаешь в ступор и думаешь, ну как так то? Сейчас я спокойно отношусь к таким ситуациям и действую исходя из самых худших ожиданий. На днях я столкнулся с ситуацией, когда мне заменили не тот диск в сервере с RAID1. Вместо сбойного диска вынули рабочий и заменили чистым. К счастью все закончилось хорошо, но обо всем по порядку.
Не скажу, что у меня прям большой опыт аренды серверов, но он есть. Я регулярно обслуживаю 10-15 серверов, расположенных в разных дата центрах, как российских, так и европейских. Первый негативный опыт я получил именно в Европе и был очень сильно удивлен и озадачен.
Я, как и многие, был под влиянием либеральной пропаганды на тему того, что у нас все плохо, а вот Европа образец надежности, стабильности и сервиса. Как же я ошибался. Сейчас отдам предпочтение нашим дата центрам. По моему мнению и опыту, у нас тех поддержка и сервис в целом лучше, чем там, без привязки к стоимости.
В Европе дешевле схожие услуги, так как там масштабы сервисов в разы больше.
Приведу несколько примеров косяков саппорта, с которыми сталкивался.
Было много всяких инцидентов помельче, нет смысла описывать. Хотя нет, один все же опишу. Устанавливал свой сервер в ЦОД. Решил пойти в маш зал и проконтролировать монтаж. Если есть такая возможность, крайне рекомендую ей воспользоваться. Местный рукожоп неправильно прикрепил салазки и сервер во время монтажа стал падать. Я его поймал, тем спас его и сервера других клиентов.
В итоге помог с монтажом. Сам бы он просто не справился. Я не представляю, что было, если бы я не пошел в машзал. К чести руководства, я написал претензию, где подробно описал данный случай и попросил бесплатно месячную аренду. Мне ее предоставили. Советую всем так поступать. Зачастую, руководство может быть не в курсе того, что происходит в реальности. Надо давать обратную связь.
Уровень моего доверия к тех поддержке дата центров и хостингов вы примерно представляете 🙂 Ну и вот случилось очередное ЧП. Подробнее остановлюсь на этой ситуации, так как она случилась вчера, свежи воспоминания.
Замена диска в рейде mdadm
Речь пойдет о дешевых дедиках от selectel. Я их много где использую и в целом готов рекомендовать. Это обычные десктопные системники за скромные деньги. Свое мнение об этих серверах, а так же сравнение с полноценными серверами сделаю в конце, в отдельном разделе.
На сервере была установлена система Debian из стандартного шаблона Selectel. Вот особенности дисковой подсистемы этих серверов и шаблона.
В целом, хорошая и надежная разбивка, чему будет подтверждение дальше. На сервере был установлен proxmox, настроен мониторинг mdadm. Мониторинг дисков не сделал. В какой-то момент получил уведомление в zabbix, что mdadm развалился. Сервер при этом продолжал работать. Ситуация штатная. Пошел в консоль сервера, чтобы все проверить. Посмотрел состояние рейда.
Убедился, что один диск выпал из массива. В системном логе увидел следующее.
Попробовал посмотреть информацию о выпавшем диске.
Информации не было, утилита показывала ошибку обращения к диску. Получилось посмотреть модель и серийный номер только работающего диска.
Я не стал разбираться, что там к чему с диском. Если вижу проблемы, сразу меняю. Предупредил заказчика, что с диском проблемы, нужно планировать замену. Так как железо десктопное, «сервер» надо выключать. Согласовали время после 22 часов. Я в это время уже сплю, поэтому написал тикет в тех поддержку, где указал время и серийный номер диска, который нужно было оставить. Я сделал на этом акцент, объяснил, что сбойный диск не отвечает, поэтому его серийник посмотреть не могу. Расписал все очень подробно, чтобы не оставить почвы для недопонимания или двойного толкования. Я в этом уже спец, но все равно не помогло.
Я спокойно согласился на эту операцию, потому что часто делаются бэкапы и они гарантированно рабочие. Настроен мониторинг бэкапов и делается регулярное полуручное восстановление из них. Договоренность была такая, что хостер после замены дожидается появления окна логина, а заказчик проверяет, что сайт работает. Все так и получилось — сервер загрузился, виртуалки поднялись, сайт заработал. На том завершили работы.
Утром я встал и увидел, что весь системный лог в ошибках диска, рабочего диска в системе нет, а есть один глючный и один новый. Сразу же запустил на всякий случай ребилд массива и он вроде как даже прошел без ошибок. Перезагрузка временно оживила сбойный диск.
В принципе, на этом можно было бы остановиться, заменить таки сбойный диск и успокоиться. Но смысл в том, что этот сбойный диск почти сутки не был в работе и данные на нем старые. Это не устраивало. Потом пришлось бы как-то склеивать эти данные с данными из бэкапов. В случае с базой данных это не тривиальная процедура.
Созвонился с заказчиком и решили откатываться на рабочий диск, который вытащили накануне ночью.
Я создал тикет и попросил вернуть рабочий диск на место. К счастью, он сохранился. К нему добавить еще один полностью чистый. Хостер оперативно все сделал и извинился. В завершении прислал скриншот экрана сервера.
И самоустранился. Дальше решать проблему загрузки он предложил загрузившись в режиме rescue. Этот режим доступен через панель управления сервером в админке, даже если сервер не имеет ipmi консоли. Как я понял, по сети загружается какой-то live cd для восстановления. Я в нем загрузился, убедился, что данные на месте, но понять причину ошибки не смог. Может быть и смог бы, если бы дольше покопался, но это очень неудобно делать, не видя реальной консоли сервера. Я попросил подключить к серверу kvm over ip, чтобы я мог подключиться к консоли. Тех поддержка без лишних вопросов оперативно это сделала.
К слову, мне известны случаи, когда техподдержка selectel потом сама чинила загрузку и возвращала mdadm в рабочее состояние. Видел такие переписки в тикетах у своих клиентов до того, как они обращались ко мне. Но я не стал настаивать на таком решении проблемы, так как боялся, что будет хуже. К тому же это было утро воскресенья и специалистов, способных это сделать, могло просто не быть. Плюс, я не думаю, что они обладали бы большими компетенциями, чем я. Я бы за их зарплату не пошел работать в ЦОД.
После того, как я подключился к консоли сервера, восстановление загрузки было делом техники.
You are in emergency mode
У меня много примеров того, как я восстанавливал загрузку сломавшихся linux дистрибутивов.
В данной ситуации с mdadm я был уверен, что все получится, так как сам массив с системой жив, данные доступны. Надо только разобраться, почему система не загружается. Напомню, что ошибка загрузки была следующая.
Дальше нужно ввести пароль root и вы окажетесь в системной консоли. Первым делом я проверил состояние массива mdadm.
Состояние массива md0, на котором располагается раздел /boot — inactive. Вот, собственно, и причина того, почему сервер не загружается. Судя по всему, когда был подключен сбойный диск, mdadm отключил массив, чтобы предотвратить повреждение данных. Не понятно, почему именно на разделе /boot, но по факту было именно это. Из-за того, что массив остановлен, загрузиться с него не получалось. Я остановил массив и запустил снова.
После этого массив вышел из режима inactive и стал доступен для дальнейшей работы с ним. Я перезагрузил сервер и убедился, что он нормально загружается. Сервер фактически был в рабочем состоянии, просто с развалившимся массивом mdadm, без одного диска.
Если вам это не поможет, предлагаю еще несколько советов, что можно предпринять, чтобы починить загрузку. Первым делом проверьте файл /etc/fstab и посмотрите, какие разделы и как там монтируются. Вот мой пример этого файла.
Вам нужно убедиться, что указанные lvm разделы /dev/mapper/vg0-root и /dev/mapper/vg0-swap_1 действительно существуют. Для этого используйте команду:
Восстановление RAID 1 массива
Массив RAID 1 является одним из самых популярный в мире и наделен достаточно неплохой степенью отказоустойчивости. Но, даже имея 100% избыточность дублирования данных, он все равно не дает гарантию абсолютной защиты информации, и восстановление RAID 1 массива нашим инженерам приходится осуществлять очень часто.
Человеческий фактор часто выступает основной причиной потери файлов на RAID, ответственные за компьютеры и серверы частенько перестают делать резервирование данных или создают копии прям на этот же массив. Частенько RAID распадается из-за не правильного завершения работы или иных недопустимых манипуляций.
Если после разрушения массива RAID1 не делать самостоятельно никаких нелепых манипуляций по восстановлению его в рабочее состояние, а незамедлительно обратиться к настоящим специалистам, то спасти файлы можно почти в 100% случаев.
Мы имеем собственные разработки и успешно оказываем услуги по восстановлению данных с RAID массивов любого уровня и при любых неисправностях. Возможно экстренное выполнение работы в любое время суток, а также присутствие заказчика при исполнении абсолютно всех услуг для обеспечения беспрецедентной конфиденциальности.
Внутреннее устройство RAID 1 массива
RAID 1 (mirroring — «зеркалирование») состоит всего лишь из 2-х дисков, которые являются идентичными копиями друг друга. Данный массив очень прост в реализации, поддерживается почти всеми RAID контроллерами, внешними NAS хранилищами и даже программно во многих операционных системах.
Его целесообразно применять, если ценность и безопасность информации намного важнее стоимости дискового пространства. Естественно, как и любой другой массив, RAID1 не имеет никакой защиты от логических сбоев любого вида. При возникновении логической проблемы она будет на двух копиях одновременно.
Поэтому использование даже такого, казалось бы, надежного и отказоустойчивого хранилища никак не отменяет создание резервных копий важных данных на других накопителях.
Достоинства массива RAID 1
Недостатки массива RAID 1
При переходе массива RAID 1 в нерабочее состояние мы крайне не советуем делать любые манипуляции для восстановления его в рабочий вид, если у Вас нет копии всей ценный информации, находящейся на нем.
Ведь наш многолетний опыт по восстановлению данных с RAID 1 позволяет уверенно утверждать, что при выполнении таких операций велика вероятность возникновения ошибок, в результате которых присутствует риск полной потери всей информации, записанной на массиве.
Этапы восстановления информации с RAID1
Это этапы работ в общем виде, на самом деле отдельные этапы могут состоять из дополнительных видов работ.
К примеру, частенько в первом пункте для создания клона какого-то из дисков, возможно, потребуется заменить сломанный блок головок HDD массива RAID 1 восстановление данных и при таких проблемах реально сделать фактически всегда. А если есть серьёзные повреждения магнитной поверхности одного или более дисков, то выгрузку информации подчас разумное время реализуемо исключительно методом одновременного создания клона минуя первый этап.
Естественно все это обязательно согласовывается с заказчиком во время детального изучения мастерами состояния определенного массива RAID.
Восстановление данных RAID 1 самостоятельно
Во-первых, мы крайне не рекомендуем что-либо делать самостоятельно, когда хотя бы 1 участник массива содержит механические проблемы. Во-вторых, для начала работы все диски должны быть подключены к обыкновенному контроллеру (не RAID), в противном случае контроллер должен обладать функцией подключения дисков в режиме Host. Так как массив не содержит ни контрольных сумм, ни чередования блоков, то виртуальная сборка RAID 1 не требуется. В некоторых случаях данные полностью сохраняются в исходном виде на одном из дисков.
Еще в ряде ситуаций для восстановления пользовательских данных будет достаточно любой программы позволяющей делать логическое восстановление с дисков, к примеру: Recuva, Easy Recovery, R-Studio, UFS Explorer. При более сложных проблемах, безусловно, будут необходимы серьезные исследования, знания внутреннего строения файловых систем и структур, чего совершенно невозможно объяснить в формате этой статьи. Конечно же, ни в коем случае на оригинальные диски ничего записывать нельзя, а также модифицировать их текущее содержимое.
Воспрещено форматировать, запускать проверку с помощью CheckDisk, ScanDisk и fsck, инициализировать, создавать или удалять разделы.
Мы можем восстановить RAID массив любого типа
Наши специалисты прекрасно представляют, как восстановить RAID 1 при любых проблемах: после пересборки или инициализации, исчезли разделы или тома, сгорел или сломался RAID контроллер, RAID перешел в Falled или Degraded или развалился, сделан неудачный Rebuild.
Мы восстанавливаем данные после ошибки контроллера RAID, когда он подвисает, пищит, выдает Kernel Panic или Error и даже синий экран смерти.
Объединение 2-х дисков в 1: настройка RAID-массива на домашнем компьютере (просто о сложном)
При подключении нескольких дисков к компьютеру (ноутбуку) — каждый из них появляется под своей буквой (C, D, E и др.) и представляет из себя отдельный независимый накопитель. Но объединив эти диски в RAID-массив — можно из двух дисков по 1 ТБ (например) получить единый накопитель на 2 ТБ (причем, с удвоенной* скоростью работы!).
Согласитесь, звучит заманчиво?! Однако, многим пользователям слово «RAID» — либо вообще ничего не говорит, либо напоминает что-то такое отдаленное и сложное (явно-недоступное для повседневных нужд на домашнем ПК/ноутбуке). На самом же деле, все проще, чем есть…
Raid 1 degraded что делать
mdadm — утилита для работы с программными RAID-массивами различных уровней. В данной инструкции рассмотрим примеры ее использования.
Установка mdadm
Утилита mdadm может быть установлена одной командой.
Если используем CentOS / Red Hat:
Если используем Ubuntu / Debian:
apt-get install mdadm
Сборка RAID
Перед сборкой, стоит занулить суперблоки на дисках, которые мы будем использовать для построения RAID (если диски ранее использовались, их суперблоки могут содержать служебную информацию о других RAID):
mdadm —zero-superblock —force /dev/sd
* в данном примере мы зануляем суперблоки для дисков sdb и sdc.
. то значит, что диски не использовались ранее для RAID. Просто продолжаем настройку.
Для сборки избыточного массива применяем следующую команду:
* где /dev/md0 — устройство RAID, которое появится после сборки; -l 1 — уровень RAID; -n 2 — количество дисков, из которых собирается массив; /dev/sd — сборка выполняется из дисков sdb и sdc.
Мы должны увидеть что-то на подобие:
mdadm: Note: this array has metadata at the start and may not be suitable as a boot device. If you plan to store ‘/boot’ on this device please ensure that your boot-loader understands md/v1.x metadata, or use —metadata=0.90
mdadm: size set to 1046528K
Также система задаст контрольный вопрос, хотим ли мы продолжить и создать RAID — нужно ответить y:
Continue creating array? y
Создание файла mdadm.conf
В файле mdadm.conf находится информация о RAID-массивах и компонентах, которые в них входят. Для его создания выполняем следующие команды:
* в данном примере хранится информация о массиве /dev/md0 — его уровень 1, он собирается из 2-х дисков.
Создание файловой системы и монтирование массива
Создание файловой системы для массива выполняется также, как для раздела:
* данной командой мы создаем на md0 файловую систему ext4.
Примонтировать раздел можно командой:
* в данном случае мы примонтировали наш массив в каталог /mnt.
Чтобы данный раздел также монтировался при загрузке системы, добавляем в fstab следующее:
/dev/md0 /mnt ext4 defaults 1 2
Для проверки правильности fstab, вводим:
Мы должны увидеть примонтированный раздел md, например:
/dev/md0 990M 2,6M 921M 1% /mnt
Информация о RAID
Посмотреть состояние всех RAID можно командой:
В ответ мы получим что-то на подобие:
md0 : active raid1 sdc[1] sdb[0] 1046528 blocks super 1.2 [2/2] [UU]
* где md0 — имя RAID устройства; raid1 sdc[1] sdb[0] — уровень избыточности и из каких дисков собран; 1046528 blocks — размер массива; [2/2] [UU] — количество юнитов, которые на данный момент используются. ** мы можем увидеть строку md0 : active(auto-read-only) — это означает, что после монтирования массива, он не использовался для записи.
Подробную информацию о конкретном массиве можно посмотреть командой:
* где /dev/md0 — имя RAID устройства.
Version : 1.2 Creation Time : Wed Mar 6 09:41:06 2019 Raid Level : raid1 Array Size : 1046528 (1022.00 MiB 1071.64 MB) Used Dev Size : 1046528 (1022.00 MiB 1071.64 MB) Raid Devices : 2 Total Devices : 2
Persistence : Superblock is persistent
Update Time : Wed Mar 6 09:41:26 2019 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0
Consistency Policy : resync
Name : proxy.dmosk.local:0 (local to host proxy.dmosk.local) UUID : 304ad447:a04cda4a:90457d04:d9a4e884
Number Major Minor RaidDevice State 0 8 16 0 active sync /dev/sdb
1 8 32 1 active sync /dev/sdc
Подробнее про каждый параметр можно прочитать в мануале для mdadm:
Также, информацию о разделах и дисковом пространстве массива можно посмотреть командой fdisk:
