Linux Software Raid запускает чек-массив в первое воскресенье месяца? Зачем?

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

Это кажется нелогичным, пока вы не углубитесь в то, как диски имеют тенденцию выходить из строя. Я согласен с тем, что если два диска не синхронизированы, проверка не принесет никакой пользы. Но что, если на одном из дисков есть сектор, который недавно вышел из строя? Что ж, чтение с этого диска во время проверки приведет к ошибке чтения для этого диска, верно? Это ценная информация для драйвера RAID, поскольку он знает из информации зеркала, хранящейся на втором диске, что следует хранить в отказавшем секторе. Таким образом, драйвер RAID теперь попытается перезаписать сбойный сектор (даже в режиме проверки, который, по мнению неопытных пользователей, доступен только для чтения). Эта перезапись может работать или нет, но на всех современных дисках есть запасные сектора, которые заменят неисправный сектор при записи (а не при чтении - при чтении он сообщит только об ошибке чтения). Таким образом, за счет комбинации драйвера RAID, перезаписывающего сектор, и жесткого диска, перераспределяющего резервный сектор для отказавшего, массив RAID фиксируется на лету. Драйвер RAID фактически не знает (и не должен знать), что произошло перераспределение. Это делается внутри самого диска, и при правильной настройке (см. Smartctl) операционная система может отправить электронное письмо администратору, чтобы сообщить ему, что сектор был перераспределен, а это означает, что пришло время заменить медленно выходящий из строя диск. Современные большие диски имеют тенденцию создавать ошибки чтения «ожидающих секторов», например, из-за колебаний температуры. Использование их в массиве RAID значительно повысит надежность, а регулярные проверки обеспечат автоматическое обновление сомнительных секторов при возникновении проблем с чтением. Эти обновления записи могут фактически привести к успешной операции записи в секторе, и в этом случае «ожидающий сектор» не становится «перераспределенным сектором», или, другими словами, диск совсем не плох, потому что он может напишите сектор сейчас.

В любом случае, используя smartctl и выполняя регулярные проверки, вы сделаете свой RAID-массив намного более надежным. Комментарии о zfs (например, zfs3 или z3) также важны. По мере увеличения размеров дисков и по мере того, как информация записывается более плотно, а разработка дисков больше определяется потребительскими рынками, а не рынками серверов, общий риск потери данных на единицу хранения резко возрастает. Запуск RAID5 на дисках размером несколько ТБ сопряжен с риском из-за длительного времени восстановления и необходимости интенсивного чтения со всех других дисков во время восстановления. Рассмотрим RAID6 с двумя запасными частями, если вы хотите защитить себя от частоты катастрофических сбоев потери данных (да, это всего лишь вероятность, и вам необходимо учитывать и другие факторы, такие как сбои контроллера, перебои в подаче электроэнергии ... вам нужно сделать много, чтобы сбалансировать надежность множества различных компонентов). И даже RAID6 может быть в сотни раз менее надежным, чем наличие трех дисков с четностью, как в RAIDZ и / или Z3.

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

1) RAID - это решение UPTIME / ACCESS SPEED, а не решение для резервного копирования. Сбой RAID не должен означать потерю данных, так как вы не должны использовать его для этого.

2) Мне любопытно, почему вы думаете, что зеркалирование всего диска «неэффективно». Зачем увеличивать сложность и полагаться на компьютер, который ничего не упускает, если можно просто отразить все?

3) «Рискованно, потому что в случае сбоя диска восстановление зеркального или четного диска для больших и активных массивов может занять несколько дней - в этом интервале, если другой диск из деградированного массива выйдет из строя, это означает потерю данных». В отличие от чего, хранить все на одном диске? RAID не идеален, но это означает, что вы можете пережить выход из строя всего диска, не теряя доступа к вашим данным, и можете ВОССТАНОВИТЬ, не теряя доступа к вашим данным. Кроме того, для чего-либо, кроме RAID1, периодическое тестирование может обнаружить диск, который становится неисправным (он отслеживает сбои отдельных блоков для определенного диска, а также использует данные SMART) и может пометить его как сбойный ДО того, как вы потеряете доступ к данные. Немедленный катастрофический отказ диска - не единственный сценарий потери данных.

Я согласен, что zfs и btrfs выглядят интересным решением по сравнению с обычным mdadm RAID5 (в некоторых ситуациях).

Но...

• btrfs не имеет стабильной версии. ты действительно хочешь рискнуть этим?
• zfs кажется зрелым, но решение для Linux-систем ... немного неоднородное. ПРЕДОХРАНИТЕЛЬ? Сторонние собственные модули ядра?

Я говорю, придерживайтесь встроенной поддержки - на LVM2 на mdadm RAID1 / 5/6 ...

мои два цента.

Тот факт, что пакет Debian mdadm упрощает отключение ежемесячного контрольного массива, подсказывает мне, что это не очень важно. Вот соответствующее сообщение, которое вы получите от dpkg-reconfigure mdadm:

Если ядро ​​поддерживает это (версии выше 2.6.14), mdadm может периодически проверять избыточность MD-массивов (RAID). Это может быть ресурсоемкий процесс, в зависимости от локальной настройки, но он может помочь предотвратить редкие случаи потери данных. Обратите внимание, что это проверка только для чтения, если не обнаружены ошибки; если будут обнаружены ошибки, mdadm попытается исправить их, что может привести к доступу для записи на носитель.

Лично у меня нет проблем с запуском скрипта checkarray один раз в месяц на моем зеркале емкостью 1 ТБ (простой файловый сервер), поскольку он занимает менее 3,5 часов в воскресенье утром, и в любом случае ничего другого не происходит. В случаях, когда контрольный массив вызывает заметные проблемы с производительностью, я бы без колебаний отключил его или, возможно, запланировал его запускать реже (например, каждые 6 месяцев, в определенные праздники и т. Д.).