Выбор RAID 6 и 10 для базы данных определяет окно риска

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

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

Время перестроения задает окно риска, а не победителя

Перестроение важно потому, что все это время массив работает с уменьшенным запасом отказоустойчивости и делит диски с пользовательским вводом-выводом. Но короткий rebuild не делает RAID 10 автоматически безопаснее RAID 6, а двойная четность не делает долгий rebuild приемлемым. Надо отдельно спросить, какой отказ разрушит массив в этом окне и какую задержку увидит база.

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

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

IBM в описании RAID 6 прямо указывает: после первого отказа массив по уровню защиты похож на исправный RAID 5, а третий отказ делает его недоступным. Это полезнее рекламной фразы «выдерживает два диска», потому что показывает смену состояния. Для RAID 10 документация IBM формулирует условие иначе: доступ сохраняется, пока в каждой зеркальной паре жив один диск; потеря обоих участников одной пары останавливает массив.

Время восстановления сервиса и время перестроения массива тоже нельзя смешивать. База может продолжать обслуживать запросы во время rebuild, но выйти за допустимую задержку. И наоборот, массив может быстро стать исправным, а база после аварийного отключения еще долго воспроизводить журнал транзакций. Для решения нужны RTO сервиса, допустимый p95 или p99 задержки и собственно длительность rebuild.

Малые случайные записи оставляют RAID 6 в долгу

Для базы с частыми синхронными записями RAID 10 обычно дает более предсказуемую задержку. Каждый измененный блок записывается в обе копии зеркала. RAID 6 для неполной полосы должен сохранить согласованность данных и двух блоков четности, а это требует чтения старых данных и четности либо эквивалентной работы в кэше контроллера.

Учебное правило называет для маленькой записи штраф RAID 10 в две физические записи, а для RAID 6 классический цикл read-modify-write включает шесть операций: чтение старых данных и двух значений четности, затем запись новых данных и двух новых значений четности. Не следует превращать эти числа в обещание производительности. Контроллер с защищенным write-back кэшем объединяет запросы в полные полосы, SSD обслуживают операции параллельно, а база сама группирует фиксации транзакций.

Разница проявляется там, где кэш перестает скрывать физику: устойчивый поток WAL или redo, checkpoint, массовое обновление индекса, заполненный кэш контроллера, отключенный write-back из-за неисправной батареи или конденсатора. Средняя пропускная способность может выглядеть прилично, пока хвост задержки уже нарушает SLA. Поэтому сравнивать надо не только transactions per second, но и задержку подтверждения транзакции на p95 и p99, глубину очереди и состояние кэша.

Полная полоса уменьшает штраф четности. Если система собирает все блоки данных одной полосы, старые данные читать не нужно: контроллер вычисляет P и Q из нового содержимого. Это помогает крупной последовательной загрузке, резервному копированию и некоторым checkpoint-нагрузкам. Типичный OLTP поток состоит из небольших обращений к разным страницам и редко добровольно складывается в идеальные полосы.

Большой кэш не отменяет требование надежного подтверждения записи. Если контроллер сообщает базе об успешном fsync до устойчивого сохранения данных, без батареи, конденсатора или другой подтвержденной защиты питания, быстрый тест измеряет риск потери транзакций. Проверять надо весь путь: настройки базы, файловой системы, драйвера, контроллера и самого накопителя. Один компонент, который игнорирует flush или force unit access, ломает гарантию остальных.

Чтение выглядит ровнее. Оба уровня распределяют последовательные и случайные чтения по нескольким дискам, а RAID 10 может выбирать менее занятое зеркало. RAID 6 читает исправные данные без вычисления четности, пока все участники на месте. Поэтому преимущество RAID 10 для базы обычно сильнее на записи и смешанном OLTP, чем на чистом чтении.

Деградированный режим надо считать отдельным профилем нагрузки

После отказа диска база получает другую систему хранения, хотя имя тома не меняется. В RAID 10 чтение данных потерянного участника идет с его зеркала, которое одновременно обслуживает обычные запросы и поток rebuild. В RAID 6 чтение отсутствующего блока требует реконструкции из данных и четности на оставшихся участниках. Это увеличивает число внутренних операций и растягивает очереди.

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

IBM публиковала испытания distributed RAID, где начало rebuild повышало задержку чтения, а ускорение восстановления после дополнительных отказов резко поднимало задержку записи. Эти конкретные графики нельзя переносить на другой контроллер как прогноз. Они подтверждают принцип, который нужно проверить на своей системе: алгоритм управления rebuild меняет поведение нагрузки, и средняя скорость диска не описывает результат.

Для базы полезен отдельный аварийный бюджет. Например, штатный p99 фиксации транзакции может быть 20 мс, а в течение обслуживания после отказа бизнес допускает 60 мс. Тогда тест должен ответить, способен ли массив восстанавливаться с такой скоростью, чтобы уложиться и в 60 мс, и в установленное окно ремонта. Если таких чисел нет, спор RAID 6 против RAID 10 остается спором вкусов.

Нагрузочный профиль во время отказа тоже меняется. Реплика может начать догонять журнал, резервное копирование продолжит последовательное чтение, мониторинг запустит расширенную проверку, а оператор решит проверить контрольные суммы. Эти разумные по отдельности действия вместе отнимают ресурс у rebuild. В регламенте нужно заранее указать, какие фоновые задачи приостанавливаются и кто имеет право менять приоритет восстановления.

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

Второй отказ у RAID 10 зависит от адреса

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

У RAID 6 адрес второго отказа не важен: любая пара отказавших участников допустима. После двух отказов запаса уже нет, и следующая ошибка чтения или третий отказ может сделать данные недоступными. Такая определенность особенно полезна, когда диски разделяют общие корзины, кабели или партии и независимость отказов вызывает сомнения.

Вероятность нельзя честно получить из одной цифры AFR в паспорте. Отказы коррелируют из-за одинакового возраста, температуры, вибрации, версии прошивки, общей полки, кабеля, экспандера и действий оператора. Замена одного диска иногда нагружает его ровесников самым интенсивным чтением за месяцы. Модель с независимыми одинаковыми дисками удобна для сравнения, но она недооценивает общие причины.

Размещение зеркальных пар меняет результат RAID 10. Если оба участника пары находятся за одним кабелем, портом или в одной полке, отказ этого элемента убирает сразу обе копии. Документация IBM для RAID 10 описывает попытку контроллера разнести участников пары по разным соединениям именно по этой причине. При проектировании надо зафиксировать фактическое отображение слотов в пары, а не полагаться на порядок наклеек на лицевой панели.

Hot spare сокращает паузу до начала rebuild, но не добавляет самостоятельную копию данных до завершения восстановления. Глобальный резерв может оказаться занят другим массивом, не подойти по размеру или типу, либо ждать ручного подтверждения из-за политики контроллера. Проверка автоматического старта rebuild должна входить в приемочные испытания.

Неисправимый сектор при чтении, URE, не равен полному отказу диска. RAID 6 после одного отказа еще имеет вторую четность и может восстановить один плохой блок на другом участнике. RAID 10 сможет исправить плохой блок, если здоровая копия находится на зеркале; проблема на единственной оставшейся копии нужного блока опасна. Но простая формула из паспортного URE не учитывает фоновые проверки, исправление секторов контроллером и реальные прочитанные объемы, поэтому использовать ее как единственный аргумент нельзя.

Свое окно восстановления измеряют, а не угадывают

Нижняя оценка проста: объем, который надо записать на замену, делят на устойчивую скорость rebuild. Для диска 12 ТБ и реальной скорости 120 МБ/с идеальная нижняя граница близка к 27,8 часа при десятичных единицах. Если под нагрузкой контроллер дает 45 МБ/с, граница вырастает примерно до 74 часов. Это арифметика, а не прогноз: паузы, ошибки чтения, внутреннее копирование и изменение приоритета увеличат срок.

На Linux MD текущее состояние и фактическую скорость можно получить без предположений:

cat /sys/block/md0/md/sync_action
cat /sys/block/md0/md/sync_completed
cat /sys/block/md0/md/sync_speed
cat /proc/mdstat

Документация ядра Linux определяет sync_completed как долю завершенных секторов, а sync_speed как среднюю скорость за последние 30 секунд в КБ/с. Значения sync_speed_min и sync_speed_max задают пределы для конкретного массива. Это полезный интерфейс измерения, но не универсальная ручка: аппаратный RAID имеет собственные команды и свою политику планирования.

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

Расчет можно оформить без сложной модели. Пусть C означает число байтов для восстановления, Rbusy означает десятый процентиль скорости rebuild под рабочей нагрузкой, а Tdetect включает обнаружение и физическую замену, если hot spare не стартует автоматически. Тогда плановое окно равно Tdetect + C / Rbusy, после чего добавляют время проверки массива. Десятый процентиль здесь полезнее среднего, потому что учитывает медленные периоды.

Проверять надо два режима. Первый сохраняет аварийный SLA базы и показывает максимально возможную длительность rebuild. Второй завершает rebuild в заданное окно и показывает худшую задержку базы. Если ни один режим не проходит оба ограничения, смена уровня RAID может помочь, но иногда правильнее добавить диски, разделить широкую группу, вынести журнал на отдельный защищенный том или перейти к распределенному spare space.

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

Большой диск увеличивает объем чтения, SSD не отменяет риск

Емкость одного участника влияет на rebuild сильнее, чем его пиковая скорость из паспорта. Большой HDD может последовательно читать быстро по внешним дорожкам, но база добавляет случайные перемещения головок, а скорость падает по мере продвижения по поверхности. Массив на 18 или 22 ТБ способен оставаться деградированным дольше рабочего дня даже при исправном железе.

Ширина RAID 6 дает полезную емкость, но расширяет область отказа и число участников, занятых реконструкцией. В группе из восьми дисков по 12 ТБ RAID 6 дает 72 ТБ сырой полезной емкости до накладных расходов формата, а RAID 10 дает 48 ТБ. Это не честная пара для теста производительности базы: первый вариант имеет шесть дисков данных и двойную четность, второй имеет четыре зеркальные пары и другую емкость.

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

SSD сокращают механические задержки и часто ускоряют rebuild, но большие QLC или TLC накопители могут упереться в устойчивую скорость записи после исчерпания внутреннего кэша. На восстановление влияет сборка мусора, thermal throttling, запас резервных блоков и оставшийся ресурс записи. Паспортная скорость короткого теста мало говорит о многотерабайтном непрерывном rebuild.

У SSD есть общие причины отказов: одинаковая прошивка, одинаковая партия, одинаковое число записанных данных и общий сбой питания. Поэтому фраза «у SSD нет механики» не оправдывает широкую группу без проверки. Обновление прошивки и замена партии тоже могут потребовать последовательного вывода дисков, что превращает скорость rebuild в операционное ограничение.

Паспортный показатель невосстановимых ошибок чтения надо читать буквально и вместе с документацией накопителя. Он описывает верхнюю заявленную частоту события на прочитанное число бит, а не вероятность гибели конкретного массива. Seagate, например, указывает разные пределы для разных классов дисков; подставлять показатель потребительской модели в расчет корпоративного SAS нельзя. Еще хуже считать, что одна URE непременно уничтожит весь RAID 6: после первого отказа вторая четность как раз может восстановить такой блок. Используйте паспорт для выбора совместимого класса, а фактические media errors, patrol read и успешные scrub для эксплуатации.

Фоновые patrol read, consistency check или scrub уменьшают шанс встретить старую ошибку только при аварии. Они сами читают весь массив и конкурируют с базой, поэтому им нужен график и лимит. Я предпочитаю законченный ежемесячный scrub с наблюдаемым результатом бесконечно отложенной проверке, но период выбирают по документации контроллера, объему и допустимой нагрузке.

База данных требует доказанного fsync и контролируемого хвоста

Уровень RAID не исправит неверную схему надежности базы. Журнал транзакций, страницы данных, временные файлы, архив журнала и резервные копии имеют разные шаблоны ввода-вывода и разные последствия отказа. Складывать их на один логический том удобно, но тогда checkpoint, backup и rebuild дерутся за одну очередь.

Для OLTP решение часто склоняется к RAID 10 из-за синхронной записи журнала и случайного обновления страниц. Для аналитической базы с крупным последовательным чтением, редкими пакетными загрузками и жестким бюджетом емкости RAID 6 может оказаться разумнее. Название СУБД само по себе ничего не решает: PostgreSQL, Microsoft SQL Server и Oracle можно настроить под очень разные нагрузки.

Сначала фиксируют RPO и RTO. RAID защищает доступность при отказе накопителя, но не возвращает удаленную таблицу, не отменяет ошибочный DROP, не лечит логическую порчу и не заменяет автономную резервную копию. Реплика тоже может быстро повторить ошибку пользователя. Нужны проверенные backup и restore, а для малого RPO еще архивирование журнала или другая технология непрерывного восстановления.

Затем проверяют семантику записи. Тест, который отключает fsync, synchronous_commit или эквивалент, измеряет режим, где база согласилась потерять подтвержденные транзакции. Он годится только тогда, когда это и есть производственная политика. Для обычной критичной базы нужно оставить гарантии включенными и убедиться, что контроллер не маскирует нестабильный кэш накопителей.

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

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

Контроллер и схема размещения меняют смысл названия RAID

Два массива с надписью RAID 6 могут вести себя по-разному из-за ширины полосы, размера chunk, защищенного кэша, алгоритма full-stripe write, приоритета rebuild и распределенного spare space. Название уровня сообщает принцип избыточности, но не гарантирует задержку или длительность восстановления.

Документация ядра Linux предупреждает о dirty degraded RAID 5 или RAID 6: после незавершенной записи четности нельзя доверять, а отсутствующие блоки нельзя надежно восстановить. Поэтому MD обычно отказывается автоматически запускать такой массив без явного принуждения. Это не повод отказаться от программного RAID. Это напоминание, что write hole, журнал четности, write-intent bitmap и порядок сброса кэша относятся к целостности, а не к тюнингу.

Для Linux MD журнал RAID 4/5/6 может закрывать write hole, а write-back режим также объединяет запись. Аппаратный контроллер решает похожую задачу собственным защищенным кэшем и метаданными. Нельзя включить write-back ради теста и забыть проверить состояние батареи или CacheVault: многие контроллеры при проблеме переходят в write-through, после чего задержка RAID 6 резко меняется.

Сбой питания проверяют отдельно от отказа диска. На стенде запускают запись, снимают питание способом, предусмотренным производителем, затем проверяют сборку массива, журнал базы и подтвержденные перед отключением транзакции. Такой опыт нельзя проводить на рабочей системе и нельзя заменять обычным перезапуском ОС: корректное завершение успевает сбросить кэш и скрывает ошибку. Если контроллер меняет write-back на write-through после деградации защиты кэша, мониторинг должен сообщить об этом до того, как пользователи заметят рост задержки.

Контрольные суммы базы и файловой системы дополняют RAID, потому что контроллер не знает, какой вариант блока логически верен. Зеркало без end-to-end checksum может иметь две разные копии и не иметь основания выбрать хорошую. Двойная четность тоже восстанавливает математически согласованный блок, но не понимает структуру страницы СУБД. Включайте поддерживаемые page checksums, проверяйте отчеты scrub и храните результат последней успешной проверки. Ошибка контрольной суммы требует поиска источника, а не автоматического объявления диска виновным: проблема может находиться в памяти, кабеле, прошивке или пути DMA.

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

Очередность дисков и домены отказа надо вынести в схему. Для RAID 10 укажите пары, для обоих уровней укажите полку, expander, порт HBA, кабель и источник питания. Массив, переживающий два независимых отказа дисков, может не пережить отказ общей полки. Двойной контроллер тоже не помогает, если оба пути ведут к одному ошибочно настроенному кэшу.

GSE проектирует и интегрирует инфраструктуру центров обработки данных на базе серверов S200 с vendor-neutral подходом, поэтому уровень RAID можно выбирать вместе с контроллером, накопителями и требованиями конкретной базы. Для эксплуатации важнее зафиксировать проверенную конфигурацию и процедуру замены, чем покупать сервер по одной строке «поддерживает RAID 6».

Выбор начинается с ограничения, которое нельзя нарушить

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

Если емкость и стоимость слотов ограничены, преобладают чтение и пакетная запись, а любой второй отказ должен переживаться независимо от его адреса, RAID 6 дает сильный аргумент. Он особенно уместен для больших наборов данных, где половинная полезная емкость зеркал делает проект невозможным. Цена решения состоит в четности, более тяжелом деградированном чтении и необходимости доказать приемлемый хвост задержки во время rebuild.

Сводить выбор удобно к проверяемым ограничениям. Низкий p99 синхронной записи обычно указывает на RAID 10, но испытание должно охватывать заполненный кэш и активный rebuild. Требование пережить любую пару отказавших дисков указывает на RAID 6, причем проверяют поведение после каждого отказа. Ограничение полезной емкости на слот тоже поддерживает RAID 6, если устойчивая запись и реконструкция проходят заданные пределы. Короткое окно копирования, простая раскладка и предсказуемая запись поддерживают RAID 10, но только после проверки пар и автоматического spare. Большой последовательный read-mostly набор часто подходит RAID 6, если деградированное чтение не ломает запросы.

Таблица не заменяет измерение. Например, восемь HDD в RAID 10 могут уступить более дорогому массиву RAID 6 с мощным защищенным кэшем на пакетной записи. А дешевый контроллер может сделать красивую емкость RAID 6 непригодной для WAL. Сравнивайте полностью заданные конфигурации, а не абстрактные уровни.

Есть и третий вариант: изменить архитектуру. Локальные зеркала на каждом узле плюс синхронная репликация между узлами дают другой профиль отказа, чем один большой RAID 6. Распределенное хранилище, erasure coding и облачные диски тоже переносят rebuild в другой слой, но не устраняют его. Тогда надо измерять восстановление реплики, сетевой предел и поведение кворума.

Я не выбираю RAID по времени rebuild в одной строке спецификации. Я сначала исключаю вариант, который нарушает задержку или емкость, затем проверяю оставшийся вариант при реальном отказе. Если оба проходят, детерминированная защита RAID 6 от любой пары отказов часто важнее нескольких часов; если RAID 6 ломает SLA записи, эта защита не спасает работающий сервис от постоянных тайм-аутов.

Решение считается готовым после учебного отказа

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

Перед вводом в эксплуатацию выполните один контролируемый цикл:

1. Зафиксируйте пары или ширину RAID 6, версии прошивок, политику кэша, spare и домены отказа.
2. Запустите копию производственной нагрузки с включенными гарантиями fsync и сохраните базовую задержку.
3. Штатно выведите выбранный диск, подтвердите оповещение и автоматическое начало rebuild.
4. Измерьте скорость, p95 и p99 базы, очереди и температуру до полного восстановления.
5. Проверьте целостность массива и восстановите тестовую базу из независимой резервной копии.

Для RAID 10 полезно повторить стендовый опыт с отказом диска из другой пары, а затем отдельно доказать, что система блокирует опасную операцию со вторым участником поврежденной пары. Для RAID 6 проверка второго отказа требует полностью изолированного стенда и актуального backup: цель состоит в наблюдении деградированного режима, а не в демонстрации смелости на производстве.

Оповещение должно содержать физический слот, серийный номер, логический массив, состояние spare и прогноз завершения. Сообщение «virtual drive degraded» без привязки к корпусу заставляет техника угадывать, а ошибка при замене способна превратить переносимый отказ в потерю массива. Процедура обязана включать двойную проверку слота другим человеком или средствами контроллера.

Запасной диск хранят там, откуда его действительно можно установить в пределах Tdetect. Для удаленной площадки обещание 24 часов доставки может добавить сутки к rebuild, даже если само копирование занимает восемь часов. Автоматический hot spare сокращает это время, но после его использования складской остаток надо восстановить.

Регламент должен различать rebuild, consistency check и восстановление базы. Rebuild возвращает избыточность после замены диска. Consistency check сравнивает зеркала или четность и ищет расхождения. Restore создает рабочую базу из backup и журнала. Один успешно завершенный процесс ничего не доказывает о двух остальных, поэтому у каждого должны быть свой владелец, частота испытания и критерий завершения.

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

Результат испытания действует только для проверенной конфигурации. Замена HDD на более емкий, обновление прошивки, изменение размера полосы, расширение группы или новый профиль базы требуют хотя бы сокращенного повторного теста. Время восстановления решает не выбор между двумя аббревиатурами, а то, сколько проверенного запаса остается у сервиса после реального отказа.