В жизни каждого пользователя (и тем более администратора) однажды случается ОНО - разваливается RAID и "перетрахивается" (с) файловая система. Не миновала сия чаша и меня.

Собственно, суть. Из-за старательной поддержки жары в серверной и нестабильной работы одного из пары дисков в сервере развалилось зеркало. Rebuild интегрированными средствами не помог, а только усугубил ситуацию - все файлы, которые были открыты, которые открывались, с которыми велась работа, повредились: что-то превратилось из файла в каталог, что-то наоборот, где-то посеклись или превратились в кашу данные, что-то ВНЕЗАПНО стало симлинком, ну и так далее. В общем, праздник в сумасшедшем доме. Во итоге имеем:

Больной скорее мёртв, чем жив. Но нас таким не напугаешь :)

Было решено восстанавливать работоспособность, так как погибший сервер - один из пары, на которых крутятся виртуалки. Всеми силами стараюсь поддерживать идентичность этих серверов, поэтому переустановка всего с нуля очень печалила (хотя попытка и была предпринята, но где-то забуксовала, и я забил). Итак, как я восстанавливал утопленникаперегренца.

Первым делом, была предпринята попытка восстановить работоспособность yum, дабы путём yum reinstall повосстанавливать бинарники. Загружаемся с компашки (ни одно из имевшихся на узле ядер не грузится), чрутимся, вооружаемся wget'ом (благо, сеть поднималась) и вперёд, качаем python, python-libs и yum. И тут ждала первая засада - rpm не возжелал ставить пакеты. Ничего, rpm --rebuilddb спас. Устанавливаем пакеты и... видим фигу, потому как покорёжился glibc. Ладно, начнём с glibc. Обновление glibc привело к глобальной неработоспособности всего, что завязано на библиотеки из пакета glibc и зависимые от него. Почесал репу, так как по идее версия glibc при стабильном API влиять ни на что не должна. Отмонтировал файловые системы, на всякий случай запустил fsck... мама, роди меня обратно. Стало только хуже.

Я совсем забыл про то, что вместе с данными покорёжились и структуры ext4. Ну что ж, будет уроком. Восстанавливаем файловую систему путём удержания кнопки y на клавиатуре, попутно офигеваем с количества побитого. И это только корень! В /boot та же фигня, в /var тоже, в /tmp тоже, но его-то как раз не жалко. Своп не проверял :) После восстановления ФС пакеты наконец-то начали устанавливаться. Но только после rpm --rebuilddb, так как при любой ошибке при установке некорректно закрывалась база rpm. А ошибок было предостаточно: пакет, пытаясь установиться поверх уже имеющихся "файлов", яростно матерился. Приходилось удалять объект (как вам превратившаяся в каталог библиотека? :) ), ребилдить базу rpm, устанавливать пакет.

На 10 пакете я откровенно задолбался и вспомнил про то, что у меня есть второй идентичный сервер и scp. Решил скопировать /bin, /sbin, /usr, /boot, /lib, /lib64 с копии и даже начал это делать, но вовремя вспомнил, что scp не сохраняет права и метки SELinux. tar со всеми опциями --preserve спас отца русской демократии. Даже заработал yum :) Последовала переустановка ядра, но тут отмер grub. Сервер перестал загружаться сам по себе даже хотя бы до kernel panic. Пришлось переустанавливать и grub, а на fakeraid-зеркало он ставится не вполне тривиально. Побороли, запустились, но grub не перечитывал автоматически свой конфиг. Ладно, не великое зло, хотя бы загрузка работает.

Ещё через несколько итераций переустановки пакетов и выявления померших конфигов и rc-скриптов (половина из которых оказались заполненными ошмётками политики SELinux) удалось загрузиться до незапускающегося dbus. Ещё одна перезагрузка - и dbus выкинут из автозапуска. Ииииии... мы загрузились до работоспособного ssh! Урра! Теперь можно сидеть в удобном кресле и, попивая кофе с молоком, любоваться на гору Фудзи в цветках сакуры... На самом деле, я не люблю ни кофе, ни молоко, да и японская культура мне тоже не близка, ну да ладно :) Хотя бы мониторинг успокоится - агент запустился, пинг есть, ssh пускает. Половина сервисов не работает и vt не запускается, но это же мелочи, у нас есть ssh :)

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

На данный момент сервер не проявляет никаких признаков сбоя или нарушений в работе. Будем надеяться, что восстановлено действительно всё. Время восстановления - 4 вечера и суммарно часа 4 через ssh.

Выводы: