Восстановление почтового сервера после fsck.ext4 на монтированном разделе

за ночь файловая система опять задумалась о вечном и ушла в readonly

Надо понять, почему. Возможно, надо таки разворачивать заново, если hdd помирает.

Кстати вопрос, а в чём проблема тормознуть всякие syslog и прочие сервисы, и отмонтировать /var для проверки ? Надо только ssh-у сказать, чтобы он не писал в /var/run и /var/lock.

HDD здоров по всем параметрам смарта, а вот файловая похоже основательно покрошилась проверкой самой себя. На сервере один раздел, var в корне болтается.

На сервере один раздел

Это плохо. Я бы только из-за этого всё переставил. Надо разделять каталоги, которые имеют разный поток обращений. Например, для почтового сервера с Cyrus-IMAP и Sendmail у меня побито так:

/
/boot
/home
/usr
/var
/var/log/mail
/var/spool/mqueue
/var/lib/imap
/var/lib/mysql/db
/var/spool/imap

/boot и /usr - старая привычка, а остальное надо однозначно делить. У тебя набор софта другой, но принцип должен быть какой-то такой же. Логи отдельно, спул постфикса - отдельно, маилбоксы - отдельно и т.д. Вероятнее всего, что беда случилась из-за спула Постфикса или логов (как наиболее часто изменяемых данных), а навернулось всё...

А, да. /tmp на tmpfs. Кстати, /var/lock и /var/run сейчас тоже многие переносят на tmpfs, но тут надо осторожно, так как некоторые приложения хотят там подкаталоги.

По идее надо было изначально, но я задался вопросом, что же делать если я забиваю на этот сервер? Логи переполнятся и демоны встанут. Поэтому решил не делить. Теперь мне понятна моя ошибка.

Контора располагается вроде в центре города, а энергоснабжение хуже динамомашины, обрубается каждую неделю, часто в выходные. Упс не вытягивает долго. Есть ли смысл отойти от ext4 в пользу ext3 или ext2 что бы обезопасить себя от критических последствий hard halt?

Хотя я бы хотел реанимировать то, что сейчас работает, т.к. там на firebird крутится БД-шка написанная для компании, саппорта нет уже в помине. Когда на этом же сервере накрыло lvm, да еще под зеркалом контроллера, я неделю потерял все восстанавливая.

Логи переполнятся и демоны встанут.

Логи (или спул почтовый), в теории, могут переполниться и тут. Только последствия будут более печальные, так как могут возникнуть неожиданные проблемы с обновлением служебных файлов, тех же баз.

Упс не вытягивает долго.

Так гасить плавно, и всё. Только бесперебойник нужен умный, который понимает, что если сказали гасить, то уже гасить, а не тормозить процесс, если питание вернётся в этот момент. В BIOS сервера выставить «всегда включаться». Бесперебойник APC Smart UPS это умеет точно.

Есть ли смысл отойти от ext4 в пользу ext3 или ext2

Точно сказать не могу, но вряд ли это сыграет существенную роль. Предложения по ручному запуску fsck я видел со всеми extfs. ext4 использовать начал года два как, это не статистика ещё. Многое остаётся на ext3.

т.к. там на firebird крутится БД-шка

Не знаю, как у firebird (но могу спросить наверное), а у его прородителя interbase, вся БД - это просто один файл, который лежит где угодно и где может читать/писать демон. Путь к файлу определяет клиент при подключении.

Сложно спрогнозировать сколько места в итоге потребуется для каждого раздела. Вдруг надо делать апдейт ядра, и 10gb в /usr уже не хватит.

Как бы то ни было, я восстановил работу всех служб через перестановку пакетов + выслеживание логов. Много ошибок вылезало ссылаясь на перл-модули. Когда удалял perl, он потянул за собой почти всю систему, так что пришлось провозиться, избавляясь от битых пакетов в апт-кэше и подгружая апачу модули. Рухнули веб-панели, скачивал по-новой. Пока только раундкуб не пускает почему то, но им никто не пользуется.

БД живая, и да, вылитый interbase, я кстати через interbase и выполнял тестирование резервных копий бд в тот роковой час.

Если фс будет уходить в ro, придётся готовить резерв. А пока ставлю в fstab remount,rw. Терять нечего, только своё время.

Вдруг надо делать апдейт ядра, и 10gb в /usr уже не хватит.

Не смеши тапочки. :-)

/dev/sda5       4,0G  903M  2,9G  24% /
shmfs           250M     0  250M   0% /dev/shm
tmpfs           5,0G   76K  5,0G   1% /tmp
/dev/sda1       289M   51M  224M  19% /boot
/dev/sda9       102G   91G  5,4G  95% /home
/dev/sda6        30G  7,8G   21G  28% /usr
/dev/sda7       6,0G  3,6G  2,1G  65% /var

HDD здоров по всем параметрам смарта

И long тест в SMART'е прошёл успешно?

badblocks застрял на одном блоке

Что значит застрял? Сообщил об ошибке или вобще завис и было ли что-то при этом в dmesg. Кроме винта может дохнуть шлейф или контроллер, поведение схожее.

Есть ли смысл отойти от ext4 в пользу ext3 или ext2

Ну уж точно не ext2. И лучше купить нормальный UPS, который всегда выключается по команде и не включается, пока не будет нужный уровень заряда батареи. И настроить завершение работы по сигналу от UPS. Потому что файловая система это одно, но уровнем выше может быть софт, который тоже не особо любит hard halt.

И long тест в SMART'е прошёл успешно?

Да, хотя помимо сплошь положительных месседжей у диска наработка 1500 дней.

Что значит застрял? Сообщил об ошибке или вобще завис и было ли что-то при этом в dmesg. Кроме винта может дохнуть шлейф или контроллер, поведение схожее.

Он задумался на несколько минут, потом выдал один блок. В dmesg при этом ничего не падало, т.к. к тому моменту я уже проверил ФС. Когда его проверяли с монтированной файловой системой он сыпал эрроры как раз о ata.0x DRDY READ ERROR. Я вначале полагал что контроллеру на диске пришла старушка с косой, т.к. замена шлейфов не помогала. Но у меня на руках был другой диск, с ним никаких проблем не возникло, поэтому можно говорить о том что материнский контроллер жив и шлейфы ни при чем. А когда я нормально проверил основной HDD, то и на нем больше таких сообщений не вылезало.

Надо бы конечно smart ups им закупить, я такие с linux-системой еще не сливал в дуэт, будет интересно.

Кстати о бесперебойниках, любые с USB-интерфейсом подходят для сабжа? Хочу сузить поиск до моделей по приемлимой цене, а затем уже ходить по сайтам произодителя и смотреть на наличие софтинок под Debian