Добрый день! Вышел из строя диск в рейде 5. Можно ли заменив диск на исправный восстановить работу, не потеряются ли данные? И вообще корректно ли восстанвливается работа рейда 5 после замены диска?

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

(0) Да именно для этого RAID и существует. RAID5 выдерживает отказ одного диска. RAID6 выдерживает одновременный отказ до двух дисков.

(1) Во время восстановления RAID-массива вероятность выхода из строя резко повышается. Поэтому сначала надо сделать бэкап того, что считывается.

(3) Так при бэкапе вероятность точно так же повышается. Когда в массив будет добавлен новый диск - контроллер просто считает данные с оставшихся дисков и запишет необходимую информацию на новый диск (тут главное чтобы этот диск не оказался SMR). Чтение дисков для создания бэкапа даст такую же нагрузку. И даже сильнее, ведь ребилд идет последовательно, а при копировании если файл фрагментирован - будет больше операций поиска. Поэтому в нормальных массивах есть 1-2 spare диска, чтобы начать ребилд как только диск откажет.

(4) При бэкапе вероятность повышается, но не так сильно, как при ребилде массива.

Бэкап - обязательно.

Не понял, какая вероятность повышается при бэкапе?

(7) Я так понимаю вероятность выхода из строя других дисков

(7) это он хочет смонтировать диски перед бэкапом почему то)

(8) С чего это?

(10) На них повышается нагрузка. Начинают считываться сектора, которые стали нестабильными. Раньше они лежали себе в сторонке и никто их не трогал, а теперь к ним будет обращение.

Позвольте, я процитирую:

>>
Когда происходит выход из строя (полный или частичный) одного из дисков группы типа RAID-5, то RAID-группа переходит в состояние degraded, но наши данные остаются доступными, так как недостающая часть их может быть восстановлена за счет избыточной информации того самого «дополнительного объема, размером в один диск». Правда обычно быстродействие дисковой группы резко падает, так как при чтении и записи выполняются дополнительные операции вычислений избыточности и восстановления целостности данных. Если мы вставим вместо вышедшего из строя новый диск, то умный RAID-контроллер начнет процедуру rebuild, «перестроения», для чего начнет считывать со всех дисков оставшиеся данные, и, на основании избыточной информации, заполнит новый, ранее пустой диск недостающей, пропавшей вместе со сдохшим диском частью.

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

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

Так, в интернете легко можно найти истории, когда сравнительно небольшой 4-6 дисковый RAID-5 из 500GB дисков восстанавливал данные на новый диск в течении суток, и более.

С использованием же терабайтных и двухтерабайтных дисков приведенные цифры можно смело умножать в 2-4 раза!

И вот тут начинаются страсти.
Дело в том, и это надо себе трезво уяснить, что на время ребилда RAID-5 вы остаетесь не просто с RAID лишенным отказоустойчивости. Вы получаете на все время ребилда RAID-0

https://habr.com/ru/post/78311/

RAID-5 в состоянии "degraded" эквивалентна отсутствию RAID вообще.
Поэтому лучшей стратегий будет забрать оттуда остатки информации, т.е. сделать бэкап.
Это будет медленно, но это ещё возможно.

Ребилд массива повысит вероятность выхода из строя оставшихся дисков и тогда вы не сможете сделать бэкап даже медленно.

Продолжим цитирование
>>
Так, например, для 6-дискового RAID-5 с дисками 1TB величина отказа по причине BER оценивается в 4-5%, а для 4TB дисков она же будет достигать уже 16-20%.

Эта холодная цифра означает, что с 16-20-процентной вероятностью вы получите отказ диска во время ребилда (и, следовательно, потеряете все данные на RAID). Ведь для ребилда, как правило, RAID-контроллеру придется прочитать все диски, входящие в RAID-группу, для 6 дисков по 1TB объем прочитанного RAID-контроллером потока данных с дисков достигает 6TB, для 4TB он уже станет равным 24TB.
24TB это, при BER 10^15, четверть от 110TB.

Но даже и это еще не все.
Как показывает практика, примерно 70-80% данных, хранимых на дисках, это так называемые cold data. Это файлы, доступ к которым сравнительно редок. С увеличением емкости дисков их объем в абсолютном исчислении также растет. Огромный объем данных лежит, зачастую, нетронутый никем, даже антивирусом (зачем ему проверять гигабайтные рипы и mp3?), месяцами, а возможно и годами.
Ошибка данных, пришедшаяся на массив cold data обнаружится только лишь в процессе полного чтения содержимого диска, на процесс ребилда.
>>

Итак, ребилд массива с вероятностью 20% приведёт к ошибке и развалу всего RAID.
Из-за чтения дурацких "cold data" вы с вероятностью 20% потеряете ценнейшие "hot data".

Выводы (для тех, кто ниасилил):
3. Повышенная нагрузка на диски в период восстановления потенциально еще повышает вероятность сбоя.

(11) Ну это из серии "жить вредно, это приводит к смерти".

(14) При попытке сделать бэкап произойдет ровно то же самое.

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

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

А вообще, BER - это чисто маркетологический параметр. Делают одинаковые диски, в них заливают немного разные прошивки - и вуаля: у одного диска BER 10e14, а у другого - 10e16. В реальности вероятность ошибки гораздо ниже, при этом совсем не факт что она вообще будет обнаружена. НЯП, изначально эта цифра рассчитывалась как вероятность ошибке при "безошибочном" чтении. Т.е. вероятность того, что ошибка будет пропущена, и считанные данные будут неверными. Т.е. это вероятность искажения данных, а не read error.

Вероятность отказа дисков при ребилде вычисляется исходя из MTBF. Т.е., например, если 6-дисковый массив ребилдится сутки - наработка составит 6*24 часа, что, например, при 1,2 млн. часов MTBF дает вероятность 0,012%. Если бы это было не так - в датацентрах требовалась бы куча админов для жонглирования дисками.

+(19) Да, дискам должно быть не более 5-7 лет (или сколько там производитель установил срок службы), т.к. после этого срока MTBF уже не работает.

(17) Нет-нет. Во время бэкапа будут считываться только ценные "hot data"

(18) Точно. Только изменившаяся часть "hot data". Бэкап может занять несколько минут, но его надо сделать именно сейчас, ещё до ребилда.

(21) Это если процесс резервного копирования настроен правильно. Но тогда бэкап уже есть, и автоматически выполняется постоянно, а потому его не надо запускать отдельно. А если бэкап настроен неправильно - то придется вычитывать всё. Особенно если это база данных.

(21) Ну вот лежит БД на диске. Где там hot, а где cold?

(24) Последние изменённые данные в БД — это hot data

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

(25) Ну и где они лежат? В каком файле?

(26) Зачем тогда вообще RAID? Задача RAID - обеспечение непрерывности работы. Сохранение данных должен обеспечивать правильно настроенный бэкап.

(27) Это зависит от типа базы. Если там один файл на всю базу, то надо смотреть потаблично. Если настроено обмен или зеркалирование на уровне 1С или СУБД, то его надо выполнить.

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

(28) Задача RAID - имитация мощного отказоустойчивого кластера из дешёвых ненадёжных дисков. Если случился отказ, то RAID уже не RAID, а тупой диск и вести с ним себя надо соответствующим образом, делать 2-3 копии.

(29) Ну а поскольку бэкап не был правильно настроен - копировать придется всё. Более того, потеря части hot data (которые, как правило, вполне восстановимые) может оказаться меньше убытков от простоя, вызванного "подумать", когда все пользователи курят бамбук.

(30) Нафига тогда было выбирать RAID 5? Можно было выбрать RAID 6, тогда отказ 1 диска все еще оставляет избыточность.

(31) RAID-5 выбирают жмоты, у которых нет денег на RAID-10.

(32) RAID-10 точно так же допускает потерю только 1 диска. В degraded состоянии начинается русская рулетка - какой из дисков откажет раньше - тот, для которого уже нет зеркала, или же тот, для которого еще есть зеркало. Поэтому в случае RAID-10 при отказе 1 диска при нормальном контроллере тут же начинается ребилд в RAID-5, если все spare диски закончились.

https://ru.wikipedia.org/wiki/RAID#RAID_5

Недостатки:
>>
В ходе восстановления (rebuild или reconstruction) контроллер осуществляет длительное интенсивное чтение, которое может спровоцировать выход из строя ещё одного или нескольких дисков массива. Кроме того, в ходе чтения могут выявляться ранее не обнаруженные сбои чтения в массивах cold data (данных, к которым не обращаются при обычной работе массива, архивные и малоактивные данные), препятствующие восстановлению. Если до полного восстановления массива произойдет выход из строя, или возникнет невосстановимая ошибка чтения хотя бы на ещё одном диске, то массив разрушается и данные на нём восстановлению обычными методами не подлежат.
>>

(34) Вот поэтому в датацентрах диски не старше 3-5 лет и жесткие требования к вибрациям стоек. В этом случае вероятность развала массива при ребилде сильно меньше 1% + нормальное резервное копирование.

(33) У RAID-1 надёжность "очень высокая", а точнее "максимально возможная надёжность"

Скорость чтения: высокая
Скорость записи: высокая

Из недостатков можно отметить только "двойная стоимость дискового пространства",
но при современной ёмкости дисков это копейки фигня.
Зарплата админов и обустройство/аренда серверной будет гораздо дороже.

Таким образом, "RAID-5 must die, а RAID-1 наше фсё!"

Если развалится массив RAID-1, то вы берёте один диск и работаете с ним персонально. Можно достать данные.
Если развалится массив RAID-5, то вы ничего с ним не сделаете.

Почувствуйте разницу.

(35) По закону Мёрфи, вероятность развала массива при ребилде примерно 100%.

(38) Вообще-то, 50%...

(39) Если рассчитывать на 50%, то будет 100%, а если рассчитывать на 100%, то отказа может и не случиться. Закон Мёрфи он сука такой...

(36)
RAID-1:
Коэффициент емкости 1
Коэффициент отказов 2
Вероятность потери данных при отказе 1 диска - 0%
Вероятность потери данных при отказе 2 дисков - 100%

RAID-10:
Коэффициент емкости 2
Коэффициент отказов 4
Вероятность потери данных при отказе 1 диска - 0%
Вероятность потери данных при отказе 2 дисков - 50%

RAID-5 (из 4 дисков):
Коэффициент емкости 3
Коэффициент отказов 4
Вероятность потери данных при отказе 1 диска - 0%
Вероятность потери данных при отказе 2 дисков - 100%

RAID-6 (из 5 дисков):
Коэффициент емкости 3
Коэффициент отказов 5
Вероятность потери данных при отказе 1 диска - 0%
Вероятность потери данных при отказе 2 дисков - 0%

Как можно видеть, по последствиям отказов RAID-1 и RAID-5 идентичны. Однако, в случае RAID-1 частота отказов будет в 1,5 раза выше (т.к. вместо 4 дисков массива RAID-5 потребуется 6 дисков массива RAID-1).

В случае RAID-10 вместо 4 дисков для RAID-5 потребуется 6 дисков для RAID-10. Так что частота отказов RAID-10 также будет в 1,5 раза выше, чем в RAID-5. Правда, при определенных условиях этот массив может пережить потерю 2 дисков.

В случае RAID-6 вместо 4 дисков для RAID-5 потребуется 5 дисков для RAID-6. Частота отказов возрастает в 1,25 раза, но массив гарантированно переживает отказ 2 дисков. Т.е. RAID-6 самый надежный: он испытывает меньшую частоту отказов по сравнению с массивами RAID-1/RAID-10, при этом гарантированно переживает отказ 2 дисков.

(37) Нет разницы. При отказе как 1, так и 2 дисков поведение обоих массивов идентично.

(38) Как и при резервном копировании с деградировавшего массива ;)

Кстати, на нормальных контроллерах одиночные read error даже при ребилде не приводят к развалу массива: контроллер просто помечает эти сектора как сбойные, и при попытке прочитать вернет ошибку. Все остальное нормально будет читаться.

(41) Если развалился массив RAID-1, то есть все шансы восстановить данные с одиночного диска без всякого RAID-контроллера.

При определенных условиях массив RAID-10 может пережить потерю 2 дисков, если они они из разных RAID-1, входящих в него.

Так что надо забить на RAID 5/6 и работать исключительно с RAID-1 (или RAID 10, если нужно максимально ускорить запись/чтение).
Если есть лишние диски, то лучше их выделить под бэкапы, так как RAID не заменяет бэкап.

(44) В таком случае лучше сразу работать без RAID, а освободившиеся диски пустить под бэкапы. Частота отказов в 2 раза ниже будет.

(45) Но тогда теряются последние изменения в "hot data"

(46) Можно просто чаще делать разностные бэкапы ;)

(47) Потеря даже 15 последних минут может быть критична, а куда уж чаще?
Нет, RAID хорош, но не панацея.
Отказ одного диска в составе RAID 1 позволяет штатно завершить работу пользователей, сделать бэкап и попытаться сделать ребилд (без актуальной работы пользователей). Это всё, на что способен RAID.

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

(48) Первичка же есть, восстановят все за час максимум. А вот сутки простоя - это реальная потеря денег.

(48)+ Чтобы пользователи могли работать, нужно 2 системы, между которыми сделана синхронизация. Это уже отказоустойчивый кластер на разных машинах, на каждой из которых RAID 1 или выше. Если на одной машинке RAID деградировал, то надо делать sync между машинами и снимать нагрузку с раненого бойца.

+(49) Ну и можно же настроить зеркальную БД, куда в режиме реального времени будут идти данные, и на которую пользователи переключатся при сбое.

(48) Хорошо, когда ты можешь себе позволить "штатно завершить работу пользователей".

Плохо, когда не можешь.

(50) А раз это не было сделано - значит оно не нужно, и потеря части данных не критична.

(51) Мы понимаем друг друга.
(52) Согласен

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

(55) Есть же встроенные средства MS SQL Server
https://winitpro.ru/index.php/2020/01/28/vysokaya-dostupnost-dannih-mssql-server/

(52) Выбор между "штатно завершить" и "скоро навернется с концами" - очевиден.

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

(57) Да вот не факт. Выбор между "штатно завершить и курить бамбук до завтра, теряя 100000$" и "продолжить работать, зная что возможно скоро все навернется и будут потеряны операции за последний час (или как часто там копирование идет), но шансы сбоя - менее 1%" далеко не очевиден.