Очевидно, что сбой вызывал процесс бэкапа, ведь нагрузка на дисковую подсистему создается много большая, чем при штатной работе сервера днём. В пользу сбоев дисковой системы говорил и тот факт, что не было сообщения об ошибке в системных журналах. Т.е. вероятнее всего имею дело с kernel panic. На сервере стоит опция panic=30 - при панике ядра через 30 секунд произойдет автоматическая перезагрузка сервера.
После некоторых раздумий выработал несколько решений:
- Отключить опцию panic=30 и утром посмотреть что за сообщение будет на экране. У этого подхода есть минус, если сообщение окажется больше одного экрана, то не получится его посмотреть целиком.
- Собрать null-модемный кабель и загрузить систему с перенаправлением системной консоли в последовательный порт, а для отлова сообщения об ошибке использовать отдельную машину, подключенную к null-модемному кабелю.
- Случайно нагуглил еще один подход. Он состоит в загрузке дополнительного модуля netconsole, который выполняет роль null-модемного кабеля через IP сеть. Сообщение передается в UDP пакетах и чтобы его смотреть достаточно использовать netcat.
Выбрал последний подход. Загрузил модуль с параметрами:
modprobe netconsole netconsole="src-port@src-ip/src-iface,dst-port@dst-ip/dst-mac"
У себя на компьютере запустил netcat
nc -l -u -p dst-port, где заменил src-/dst- константы на соответствующие параметры. Утром меня ждало сообщение о сбое в модуле reiserfs. Проверка радздела на 70GB заняла более полутора часов, причем мое терпение лопнуло, после начала проверки семантики FS, после проверки BTREE структуры. Впереди еще предстоит починка FS и спасение данных, но мое отношение к reiserfs здорово переменилось, теперь подумываю о миграции на XFS/JFS.Для себя сделал вывод, что иметь нуль-модемный кабель + свободный COM-порт на соседней машинке - это must-have для любого сисадмина.
Комментариев нет:
Отправить комментарий