Debian восстановление raid 10
Обновлено: 08.07.2024
Отказоустойчивость и сохранность данных является краеугольным камнем любой IT инфраструктуры. Помимо резервных копий, немаловажным моментом является использование RAID массивов, что позволяет поддерживать сервер в рабочем состоянии, даже если один из дисков вышел из строя. Согласитесь, если у Вас выйдет из строя единственный жесткий диск, на котором храниться жизненно важная информация для функционирования предприятия, последствия могут быть крайне неприятны. Использование RAID массивов позволяет продолжать работу сервера в штатном режиме, пока выполняется замена сбойного жесткого диска, при условии, если Вы используете RAID1 и выше. Существуют как аппаратные, так и программные RAID массивы. В данной статье мы рассмотрим утилиту mdadm, разработанную для управления программными RAID-массивами в Linux.
В Linux можно использовать следующие разновидности RAID:
RAID0 (striping) - распределение блоков на нескольких физических дисках для повышения скоростей записи и чтения, но без обеспечения отказоустойчивости. В случае отказа одного из дисков вся информация будет уничтожена;
RAID1 (mirroring) - зеркалирование, то есть запись одних и тех же данных одновременно на несколько дисков, что обеспечивает отказоустойчивость при выходе из строя любого количества дисков, пока остаётся хотя бы один работоспособный;
RAID4 - похож на RAID 3, но отличается от него тем, что данные разбиваются на блоки, а не на байты;
RAID5 - массив с обеспечением отказоустойчивости за счет минимальной избыточности (требуется минимум три диска, для отказоустойчивости — четыре диска);
RAID6 - похож на RAID 5, но имеет более высокую степень надежности - под контрольные суммы выделяется ёмкость 2-х дисков, рассчитываются 2 суммы по разным алгоритмам;
В этом примере мы добавим программный массив RAID1 на тестовый сервер Debian с двумя дополнительными дисками для хранения данных.
Утилита присутствует в официальном репозитории и установить её можно просто командой:
Примечание: Для удобства, в этом примере используется VPS. Один виртуальный диск размером 10Gb зарезервирован под операционную систему Debian 10, два диска, по 120Gb каждый - под RAID массив. Порядок действий ничем не отличается от работы на физическом сервере, с той разницей, что диски будут иметь названия /dev/sda, а не /dev/vda.
Создание разделов
Утилитой fdisk проверим названия разделов. Важно быть внимательным и выполнять операции с нужными дисками, иначе Вы рискуете удалить информацию без возможности восстановления
Если данные диски уже где-то использовались, первым делом нам нужно их полностью очистить и удалить старую «память о рейде», если на них уже был создан массив ранее:
После этого удаляем ссылки на разобранный RAID-массив в /etc/mdadm/mdadm.conf (в Debian) или в /etc/mdadm.conf (в CentOS), если они делались там ранее.
Создание RAID-массива
Массив RAID1 мы будем собирать из следующих дисков:
Для начала, уже известной нам командой fdisk создадим партиции на разделах. Данную операцию необходимо выполнить два двух дисков: /dev/vdb и /dev/vdc
Создав партиции, приступим к созданию непосредственно RAID:
Операция займет некоторое время, в зависимости от типа дисков, которые вы используете и их объема. Проверить процесс создания в реальном времени Вы можете командой: cat /proc/mdstat. После успешного создания массива мы увидим следующий результат:
Снова проверяем результат:
Затем в файле /etc/mdadm/mdadm.conf добавляем следующие строки и сохраняем файл:
DEVICE /dev/vdb1 /dev/vdc1
CREATE owner=root group=disk mode=0660 auto=yes
ARRAY /dev/md0 UUID=24ef0763:12d8c289:4f5e4658:14648eab
В консоли, от суперпользователя root перезапустим массив, обновим ядро и выполним перезагрузку операционной системы, после чего raid станет требуемым md0
Создание файловой системы на RAID-массиве
Отлично, массив RAID1 создан, приступим к созданию файловой системы ext4 поверх него. В массиве RAID1 понятие chunk size отсутствует, т.к. это размер блока, который по очереди пишется на разные диски, потому создать FS можно простой командой:
В реальном времени наблюдаем процесс создания файловой системы, пока не увидим done:
Создадим точку монтирования для RAID-массива и примонтируем массив:
узнать UUID нашего массива можно с помощью команды blkid
Мониторинг состояния RAID-массива
Первым делом установим утилиту smartmontools и настроим оповещения на email:
Затем в файле /etc/default/smartmontools раскоментируем строку: start_smartd=yes
А в файле /etc/smartd.conf добавим следующее:
и перезагрузим службу:
Замена сбойного диска в RAID-массиве
Информация о целостности RAID-массива находится в файле /proc/mdstat
В случае выхода диска из строя, при условии что Вы настроили мониторинг, картина будет следующая:
Наш массив состоит из двух дисков. [2/1] [U_] означает, что один из дисков вышел из строя и raid в режиме inactive. При рабочем raid-массиве это значение будет иметь вид: [2/2] [UU]
Допустим, наш диск /dev/vdc вышел из стоя. Нам необходимо пометить его как «сбойный» и удалить его с массива:
Вынимаем старый диск с сервера. Если ваши диски установлены в корзины и материнская плата поддерживает hotswap, это можно выполнить без остановки сервера, «на горячую». После того, как новый диск будет в сервере, копируем разметку следующей командой (с «живого» диска на новый):
И добавляем его в наш массив md0:
Процесс синхронизации массива проверяем уже знакомой нам командой, пока не увидим следующий результат:
Получить более развернутую информацию о raid массиве вы можете выполним следующую команду:
Заключение
Для настройки программного RAID массива не требуется покупать дополнительное оборудование в виде дорогостоящих raid контроллеров. Утилита mdadm является отличным бесплатным инструментом для построения отказоустойчивой инфраструктуры и риск потери данных сводится к минимуму. Наш дата-центр предлагает полный спектр услуг хостинга. У нас Вы можете арендовать выделенный сервер и наша круглосуточная служба технической поддержки поможет с его настройкой.
Всегда легко говорить о восстановление RAID массива, если все вы делали сами и с нуля. Тут вам и карта в руки. И количество разделов, и структура все вам знакома. Сложнее когда сервер чужой и уже рабочий, соответственно придется разбираться. Если же учесть что вы в первый раз восстанавливаете RAID задача усложняется, поскольку любая ошибка может привести к сбою сервера.
Да и помочь вам мало кто сможет, службы поддержки от потенциально опасных задач пытаются откреститься.
Понятно что для квалифицированного сотрудника это мало вероятно, но зачем рисковать. Так что в бой пойдем одни с книжкой в руках.
Для начала нам нужно определиться, что у нас RAID массивом. Проверяем его состояние:
Так выглядит классический, RAID1 в рабочем состояние при двух винтах.
При ошибке [UU] будет иметь вид [U_] [_U] в зависимости от диска, вышедшего из строя.
К сожалению, в момент написания статьи у меня RAID массив уже восстанавливался, а сделать скрин, я попросту забыл, так что довольствуемся текстом и картинками в перемешку.
Как мы видим, диск sda вышел из строя, соответственно разделы sda1 и sda3 вылетели из массивов, соответственно я предполагаю, что sda2 вышел из строя тоже, но не задействован в рейд.
Проверяем какие диски у нас на данный момент есть в системе.
Его я приводить не буду, но думаю вам почитать лучше там.
Для простоты я использую
Как видим, диск вообще из системы пропал, и мы не сможем пометить разделы как «ошибочные» Но зато мы видим четко 3 раздела на sdb это:
- sdb1 отданный под md0 очевидно это /boot
- sdb2 явно swap соответственно
- sda3 наши данные
Ну и основной диск sdb3 его копия sda3 ныне почившая, остальные соответственно.
Все верно, в системе было два диска побитых по 3 раздела + 1 ssd накопитель
Помечаем раздел как сбойный раздел
mdadm: cannot find /dev/sda1: No such file or directory
Пробуем удалить раздел:
mdadm: cannot find /dev/sda1: No such file or directory
Что же происходит, мы сделали все по правилам, пометили как сбойный и попробовали удалить, однако ни один из вариантов не сработал вообще. Дело тут в том что диск вообще из системы пропал, и следовательно система честно отвечает что удалить его не может поскольку диска попросту нет. Тут я в свое время впал в небольшой ступор, поскольку вариантов удалить не так уж и много. Но нашелся вариант удаления и отсутствующих дисков
В таком случае мы их сможем удалить, поскольку массивов два соответственно чистим каждый из них.
Далее все просто. Просим службу поддержки поменять диски, или делаем это самостоятельно. Единственное на что пришлось обратить внимание так на то что smart отказался давать серийник дисков отсутствующих в системе.
smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Так что в службу поддержки пришлось писать о замене диска sda, но в связи с отсутствием возможности посмотреть серийник, были перечислены диски НЕ требующие замены. В привычку у меня вошел и еще один момент, я всегда указываю какой именно диск менять и другие диску категорически прошу не менять. Даже при нахождение на них сбоев, поскольку я попросту мог их не забэкапить (было дело выкинули не реплицируемый SSD накопитель, на котором болтались базы данных 300 сайтов.
Пришлось бегать как пострадавший и в экстренном порядке восстанавливать все БД из бэкапов, а поскольку БД самой админки почила там же, пришлось хорошо побегать.
После замены диска (уж не знаю зачем германцы тормозят сервера для замены диска это остается для меня тайной).
Смотим на систему, видим появился чистенький диск /dev/sdd и он не размечен.
Нам осталось разбить его на разделы нужного нам размера и добавить нужный раздел в нужный массив.
На самом деле все куда проще, поскольку RIAD1 и разделы у нас должны быть идентичны мы их попросту скопируем с рабочего диска.
Внимательно делайте это действие. Копируем с sdb на sdd
Однако, я в начале сделаю backup.
Восстановим с backup на другой диск, поскольку диск реципелент совершенно чистый, добавим -force
Как видим разметка в наличие.
Остается добавить их в соответствующие массивы.
Процесс восстановления запущен, а md0 очень маленький уже восстановил свою работоспособность.
Осталось нам заменить sda2 на sdd2 в /etc/fstab
И ждем восстановление основного массива.
Если процесс восстановления идет слишком медленно или слишком сильно ест ресурсы системы, можно искусственно понизить скорость восстановлениия или увеличить ее.
Выставляем нужные нам пределы
Для вступления изменений в силу.
Дополнительно: sfdisk не работает!
WARNING: GPT (GUID Partition Table) detected on ’/dev/sda’! The util sfdisk doesn’t support GPT. Use GNU Parted.
В данном случае утилита sysctl не сможет работать с дисками с GPT, для переноса разделов нам понадобится другая утилита.
Устанавливаем пакет gdisk
Копируем таблицу разделов с рабочего диска на замененный:
ВНИМАТЕЛЬНО СИНТАКСИС! sgdisk -R <Новый_диск> <Рабочий_диск>
Для Debian 8.6 данная статья уже не очень актуальна, т.к. там всё уже грузится "из коробки", даже при деградированном массиве с загрузочным разделом, однако я оставлю нижеследующий текст в исторических целях, да и мало ли где ещё такая проблема всплывёт, плюс часть о собственно восстановлении массивов по-прежнему актуальна, хотя это в общем-то элементарная вещь, легко находимая гуглом.
В последней (восьмой на момент написания статьи) версии Debian восстановление развалившегося загрузочного software-raid-массива, как оказалось - дело не совсем тривиальное. Когда-то давно, во времена первого GRUB-а - компьютер спокойно загружался при отсутствии части дисков в массиве, однако в 7 и 8 версиях Debian - что-то сломали. Система выдаёт примерно такое:
ALERT /dev/disks/by-uuid/куча-разных-кракозябликов does not exist.Dropping to a shell!
Поэтому распишу вкратце, во-первых, о том, что стоит сразу же подшаманить в установленном на программный raid Debian-е, во-вторых - как это дело быстро восстановить. Здесь не будет ничего о том, как устанавливать систему на raid или как перевести существующую. Кроме того, крайне рекомендуется помнить о том, что манипуляции с raid и дисками могут привести к необратимой потере данных, поэтому убедитесь, что для всего важного есть бекап.
Первым делом - подшаманим загрузочный скрипт. Это позволит системе загружаться даже с деградировавшего массива.
Открываем файл /usr/share/initramfs-tools/scripts/local-top/mdadm , находим там все вхождения --assemble и заменяем их на --incremental - скорее всего, это нужно будет сделать в двух строчках.
Обновляем образ initramfs.
Опции означают, что обновляются образы для всех имеющихся версий ядра (-kall), в том числе те, которые уже существуют (-u).
Дальше - важно, чтобы загрузчик (по умолчанию в Debian используется GRUB) был установлен на все загрузочные жёсткие диски. Предположим, у вас два жёстких диска, на которых расположена корневая файловая система вместе с /boot и лежит это всё в виде зеркалки - raid1. По-умолчанию, если в таком виде всё изначально устанавливалось - инсталлятор debian установит GRUB только на один жёсткий диск. Поэтому имеет смысл повторить установку для обоих жёстких дисков - выполнить от root-а примерно такие команды:
Здесь /dev/sda и /dev/sdb - ваши два диска. В результате система будет загружаться с любого из имеющихся дисков. Если система даже после этих мер не грузится - проверьте настройки BIOS, не пытается ли он грузиться с какого-нибудь флоппика? Подобное тоже бывает в некоторых материнках после удаления одного из дисков (приоритет в загрузке для оставшегося диска оказывается ниже, чем DVD-привода, например).
Теперь перейдём к восстановлению. Допустим, у нас два одинаковых по объёму жёстких диска, на которых в raid1 работают два массива - md0 и md1. На md1 у нас лежит swap (оно нужно на случай умирания диска в процессе работы, чтобы запущенным процессам не стало плохо при обращении к сбойной странице памяти). На md0 - корневая файловая система с /boot и всеми остальными файлами. Т.е. предельно упрощённый вариант, без всяческих выделений под /boot или /home отдельных разделов. Допустим, диски у нас обозначаются /dev/sda и /dev/sdb.
И вот, работал себе /dev/sdb, работал. и внезапно умер. Печальный итог его жизни. В случае если вы не подшаманили скрипт загрузки - теперь при попытке стартовать система будет выдавать вышеприведённый ALERT и выкидываться в busybox. С подшаманенным же скриптом - система, скорее всего, загрузится. Если вы не настроили никаких действий и уведомлений на сбой raid - вы о проблеме с диском можете даже не узнать, но настройка уведомлений - выходит за рамки этой статьи. Чтобы проверить состояние raid-а вручную - достаточно выполнить вот такую команду:
Или посмотреть содержимое файлика любым другим способом. В файле будет что-то примерно такое:
md0 : active raid1 sda1[1]
2926528 blocks super 1.2 [2/2] [_U]
md1 : active raid1 sda2[1]
5855168 blocks super 1.2 [2/2] [_U]
Здесь для каждого массива перечислены оставшиеся в массиве разделы (как видно, расположенные на sda) + видно, что из двух разделов в массиве работает только один - в норме в квадратных скобках было бы написано [UU] .
Итак, диск умер, но raid жив. Отключаем компьютер. Достаём где-нибудь новый (или выдранный из потрохов другого компа) винчестер такого-же или бОльшего размера. Подключаем его на место умершего. Включаем комп и тут же лезем в BIOS - нужно убедиться, что загрузка пойдёт с выжившего старого винта, а не с только что добавленного. Загружаем операцинку.
Теперь нужно удалить разделы на новом жёстком диске (если имеются) и заново разбить его - так, чтобы /dev/sdb1 и /dev/sdb2 совпадали по размерам с /dev/sda1 и /dev/sda2 соответственно. Можно сделать это с помощью fdisk. Можно воспользоваться графическим gparted. Кто-то сделает это webmin-ом. Выбор за вами. Меня больше всего устраивает parted. Вызываем его и смотрим, что есть на дисках.
Number Start End Size Type File system Flags
1 2048s 5859327s 5857280s primary boot, raid
2 5859328s 17577983s 11718656s primary raid
(parted) print /dev/sdb
Model: ATA ST3802110AS (scsi)
Disk /dev/sda: 156299375s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Красным цветом - обозначены команды, введённые пользователем. Итак, у нас два диска по 80 гиг, на /dev/sda - разделы raid-а, на /dev/sdb - пусто.
Команда unit s заставляет parted показывать размеры и смещения в секторах, в противном случае - parted показывает эти цифры в человеко-читаемой и усреднённой форме (типа 7,45GB), установить по которым точное количество байт не представляется возможным. Значения в секторах удобнее тем, что один сектор по умолчанию равен 512 байтам (см. строку Sector size в выводе parted).
Строчка " Using /dev/sda " означает, что отданные пользователем команды по умолчанию будут применяться к диску /dev/sda. Нас это не устраивает. Поступаем следующим образом:
Теперь команды будут применяться ко второму диску. На оном, как видно - уже есть таблица разделов типа msdos. Если бы её не было - пришлось бы создавать командой mklabel . Этим же способом можно быстро удалить старую таблицу разделов, если там сейчас что-то старое и не нужное.
Теперь, когда диск пуст и таблица разделов создана - создаём два новых раздела с теми же размерами, какие видно на первом диске.
(parted) mkpart primary 2048s 5859327s
(parted) set 1 lba off
(parted) set 1 raid on
(parted) set 1 boot on
(parted) mkpart primary 5859328s 17577983s
(parted) set 2 lba off
(parted) set 2 raid on
(parted) print /dev/sdb
Model: ATA MAXTOR STM380215 (scsi)
Disk /dev/sdb: 156299375s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 2048s 5859327s 5857280s primary boot, raid
2 5859328s 17577983s 11718656s primary raid
Как видно, размеры указываются в секторах - такие же, какие видны на /dev/sda. Команды set на разделы - включают и отключают нужные и ненужные флаги - например, флаг lba ставится по-умолчанию, но он нам особо не нужен, в то же время нужен флаг raid и флаг boot для загрузочного раздела.
Теперь можно восстановить деградировавшие массивы. Это весьма просто:
mdadm /dev/md1 -a /dev/sdb2
cat /proc/mdstat
Последняя команда должна вывести информацию по массивам, в которых будет что-то вроде прогрессбара (полоски с процентами) для процесса восстановления. Эпизодически посматривая содержимое /proc/mdstat можно отслеживать этот процесс. Либо можно делать это в реальном времени примерно такой командой:
Команда будет выводить содержимое файла на экран раз в секунду.
Спасибо за внимание, и ещё раз напоминаю, что никакой raid не заменит резервное копирование, выполнять которое желательно на подключаемое лишь в момент создания копии устройство, а хранить - где-то подальше географически :).
RAID 10
В нем начались какието сбои, после чего перестал работать. Проблема в том, что несколько человек уже его смотрели и каждый делал чтото свое.
Точно, они поменяли Sata шлейфы местами. Насчет работоспособности жестких дисков, все в биосе детектятся. Задача- восстановить инфу, которая была на
рейде, потом все снести. На скринах:
1. Внутренности компа
2. Загрузчик
3. Пауза во время загрузки
4. На этом все
Загружался с загрузочного линукса, видит файловую систему, но при попытке открыть рейд выдает ошибку.
Там были фотки, видео, как их поднять?
Заранее огромный сенкс!
Disk /dev/sda: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x0001f2d0
Device Boot Start End Blocks Id System
/dev/sda1 * 1 29164 234259798+ 83 Linux
/dev/sda2 29165 30401 9936202+ 5 Extended
/dev/sda5 29165 30401 9936171 82 Linux swap / Solaris
Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000e56bb
Device Boot Start End Blocks Id System
/dev/sdb1 1 60801 488384001 fd Linux raid autodetect
Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xf7caf7ca
Device Boot Start End Blocks Id System
/dev/sdc1 1 121601 976760001 fd Linux raid autodetect
Disk /dev/sdd: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00040658
Device Boot Start End Blocks Id System
/dev/sdd1 * 1 6 48163+ 83 Linux
/dev/sdd2 7 1714 13719510 5 Extended
/dev/sdd3 1715 1750 289170 83 Linux
/dev/sdd4 1751 60801 474327157+ fd Linux raid autodetect
/dev/sdd5 7 255 2000061 82 Linux swap / Solaris
/dev/sdd6 256 863 4883728+ 83 Linux
/dev/sdd7 864 1471 4883728+ 83 Linux
/dev/sdd8 1472 1714 1951866 83 Linux
Disk /dev/md3: 1986.0 GB, 1986018213888 bytes
2 heads, 4 sectors/track, 484867728 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Disk identifier: 0x00000000
Оказалось, что это RAID 01 (то есть объеденены 3 в raid 0, 3других тоже и вся эта куча в raid 1)
Полетел массив потому, что по видимому скакало напряжение и в диске 1 (там где стоял линукс и был первый раздел рейда) случились бока с ФС.
В зеркале есть другие траблы, второй диск к сожалению, имее бэды (неясно, софт или апаратные)
Оказывается mdadm не ипет размер дисков, поэтому был такой рейд-0: 466гб+500гб+1Тб (примерно так)
На зеркалах была чистая копия самого рейда (без файловой системы). Удивительно, что на терабайте какогото х. был загрузочный сектор.
Размер страйпа не известен, но, возможно, он был 64 кб (так как едет повторение, по моим наблюдениям в вингекс)
Update Time : Sat Feb 26 02:21:04 2011
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Chunk Size : 64K
UUID : d1387d16:c57016ed:9cddb6ff:8008d1a4
Events : 0.7
Number Major Minor RaidDevice State
0 8 20 0 active sync /dev/sdb4
1 8 33 1 active sync /dev/sdc1
2 8 49 2 active sync /dev/sdd1
Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00040658
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 6 48163+ 83 Linux
/dev/sdb2 7 1714 13719510 5 Extended
/dev/sdb3 1715 1750 289170 83 Linux
/dev/sdb4 1751 60801 474327157+ fd Linux raid autodetect
/dev/sdb5 7 255 2000061 82 Linux swap / Solaris
/dev/sdb6 256 863 4883728+ 83 Linux
/dev/sdb7 864 1471 4883728+ 83 Linux
/dev/sdb8 1472 1714 1951866 83 Linux
Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000e56bb
Device Boot Start End Blocks Id System
/dev/sdc1 1 60801 488384001 fd Linux raid autodetect
Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xf7caf7ca
Device Boot Start End Blocks Id System
/dev/sdd1 1 121601 976760001 fd Linux raid autodetect
Disk /dev/md0: 1986.0 GB, 1986018213888 bytes
2 heads, 4 sectors/track, 484867728 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Disk identifier: 0x00000000
Читайте также: