У меня есть сервер на Linux (ядро 5.15.82) с bare-metal установкой на Supermicro X9DRD-iF, имеющим 48 ГБ оперативной памяти и два процессора Xeon 2620. На нем установлен контроллер Adaptec 5805 с шестью дисками в RAID 6, общей емкостью 18 ТБ. Сервер успешно выполнял свои задачи в течение более года, но затем один из жестких дисков вышел из строя. Хоть диск и полетел, RAID автоматически активировал горячий резерв, и начался процесс ребилда, пока я был в отпуске. Инженер заменил неисправный диск на новый без моего ведома. Вернувшись вечером, я обнаружил сбой на разделе с данными, который был защищен RAID, - обнаружилось множество ошибок файловой системы. Например: <pre><code>Oct 15 20:00:23 nakivo kernel: EXT4-fs error (device sdb1): ext4_find_extent:929: inode #3736241: comm bh: pblk 3435773917 bad header/extent: invalid magic - magic b074, entries 31441, max 60113(0), depth 39622(0) Oct 15 20:00:23 nakivo kernel: EXT4-fs error (device sdb1): ext4_find_extent:929: inode #3736241: comm bh: pblk 3435773917 bad header/extent: invalid magic - magic b074, entries 31441, max 60113(0), depth 39622(0) Oct 15 20:00:30 nakivo kernel: EXT4-fs error (device sdb1): ext4_ext_remove_space:2993: inode #3738362: comm bh: pblk 3281567223 bad header/extent: invalid magic - magic a25e, entries 52767, max 15585(0), depth 38526(0) Oct 15 20:00:30 nakivo kernel: EXT4-fs error (device sdb1) in ext4_setattr:5523: Corrupt filesystem</code></pre> И подобных ошибок накопилось довольно много. В процессе ребилда массива я начал паниковать, так как на нем хранятся ценнейшие данные. Я перезагрузил сервер, зашел в однопользовательский режим и запустил fsck. Процесс проверки занял несколько часов, и он обнаружил массу ошибок во время ребилда массива. После завершения fsck я смог смонтировать файловую систему, но состояние данных осталось неясным — они могли быть повреждены или нет. Далее я запустил программу для работы с...
Ситуация, которую вы описали, вызывает серьезные опасения по поводу целостности данных и потенциальных проблем с оборудованием. Рассмотрим несколько ключевых аспектов, которые могут помочь вам понять причины возникновения ошибок: 1. **Ошибки файловой системы**: Учитывая сообщения из журналов, файловая система EXT4 указывает на серьезные проблемы с данными. Ошибки, связанные с "bad header/extent: invalid magic", могут свидетельствовать о повреждении структуры метаданных или данных. Это может произойти по ряду причин: аппаратные сбои, некорректное завершение работы системы, проблемы с электропитанием, сбои на уровне контроллера RAID и т. д. 2. **Ребилд RAID**: Процесс ребилда RAID 6 может создать дополнительную нагрузку на дисковую подсистему. Если система работает со сбоями, что может происходить, если старый диск (который был заменен) имел проблемы, возможны ошибки, которые, в свою очередь, могут усугубить повреждение файловой системы. 3. **Проблемы с оборудованием**: - **Жесткие диски**: Т.к. у вас возникли проблемы с одним диском, это может быть признаком того, что другие диски также могут быть близки к выходу из строя. Проверьте состояние всех дисков с помощью утилит SMART. - **Контроллер RAID**: Контроллер Adaptec 5805 также может быть источником проблем. Убедитесь, что он имеет актуальную прошивку и любой журнальный файл не содержит предупреждений или ошибок. - **Проблемы с памятью**: Ошибки в оперативной памяти также могут вызвать проблемы с целостностью данных. Рекомендуется провести тестирование памяти с помощью утилит, таких как Memtest86+. 4. **Избыточность и резервное копирование**: Если вы не делали резервные копии данных, это может представлять собой серьезную опасность. Убедитесь, что у вас есть система резервного копирования и восстановление данных. 5. **Проверка состояния после fsck**: После того как вы запустили `fsck`, важно проверить состояние данных. Если данные были повреждены во время ребилда, есть возможность, что некоторые файлы могут быть утеряны или повреждены. Использование инструмента для восстановления данных, такого как TestDisk или PhotoRec, может помочь в восстановлении некоторых из них. 6. **Будущие действия**: В зависимости от состояния данных, вы можете: - Оценить степень повреждения файлов и решить, что можно восстановить. - Заменить либо контроллер, либо диски, если они все еще вызывают сомнения. - Рассмотреть возможность создания нового RAID массива с использованием новых, проверенных дисков и восстановления данных из резервной копии. Таким образом, несмотря на то, что проблемы с оборудованием являются наиболее вероятной причиной ошибок, они также могут быть связаны с неправильным поведением системы во время нагрузки на дисковую подсистему. Провести комплексную диагностику оборудования и состояния данных необходимо для установления точной причины и минимизации риска в будущем.
(В это время идет ребилд массива). Я тихо паникую - на массиве ценные данные - сервак перегружаю, ухожу в single, стартую fsck. fsck идет несколько часов, валит туеву хучу ошибок (а ребилд все идет).
На первый взгляд спросонья, дело не в железе и не в радиусе изгиба рук.
Мне думается, что решение запустить fsck во время ребилда , принятое в состоянии аффекта, с определённой вероятностью было неразумным.
У меня сравнительно небольшой опыт эксплуатации серверного железа под линуксом, но в целом я склоняюсь к точке зрения, что если нужно что-то восстановить, сохранить, сберечь, fsck не сильно лучше его виндового собрата (checkdisk), который обращается с данными, аки годзилла.
У нас были заказы на восстановление RAID, по которым в т.ч. прошлись fsck.
Исправление же файловой системы (т.е. её изменение) во время rebuild вообще отдаёт мистикой.
Насколько чётко контроллер сумеет такое отработать? Не начнёт ли фсчк "исправлять" живые данные на основе нулей или чего-то ещё, появившегося в процессе? Не возникнет ли при этом циклов "перестроение-исправление"? И так далее.
можно ли что-то сделать, чтобы так не было?
Думаю, что в идеале было бы дать рейду перестроиться с минимумом дополнительной нагрузки, или вообще без неё, раз вы подключались вечером.
При этом понятно, что нерабочего времени на full rebuild может быть недостаточно, либо система боевая и даунтайма не терпит.
P.S.
Нет худа без добра: посмотрели что реально происходит в околокритической ситуации, лишний раз подчеркнули для всех важность резервного копирования, цвет волос, надеюсь, тоже сохранили :)