Вот потому, что она "не админ" - вполне может включить ротацию раз в сутки. А логи клиентов за это время - засрут все. Никогда не видели error.log для сайта за сутки на 5Gb? При _нормальной_ работе, с точки зрения пользователя. Еще примеры Вам alw привел.
Никакая программа не может такое спрогнозировать. Самая супер-дупер, чего уж там говорить про ispmanager.
Нет. Только в том, что кто-то своевременно не изменил размеры разделов. Системный администратор не компетентен / вовсе отсутствовал.
Кстати, если "полно места было на других разделах" - что-то таки должно было еще работать. Вместо того, чтобы из-за проблемы в /var/log/ - не работать _всему_. Интересно, подобный сценарий будет "понятен" клиенту? Что сайты у него не работают только потому, что логи некуда писать?
Прогнозировать можно и нужно. Ошибетесь в прогнозе - перепланируете разбивку, добавив места именно туда, где оно заканчивается.
И чтобы сделать бекап баз данных - Вы для всего тома LVM с _одним_ разделом будете снапшот делать?
Но лучше не все сразу, верно? Пусть засранные логи не убъют клиентам возможности работать с базой данных и файлами сайтов. Не?
Вы и nosuid не захотите включить? А то еще флажки есть иногда полезные, могу напомнить...
Но и noexec полезен, зря Вы так; хоть ради скрипт-киддисов - и то дело.
Разные файловые системы. LVM + возможность динамически изменять размер разделов + куча операций, проводимых online (вместо тупого rsync, к примеру, при переносе данных на новый диск) + снапшоты.
Хватит уже юродствовать, netwind, Вы не андрейка ;)
fsbackup - тоже "скрипт для простого народа" (ну, разве на почту не отсылается). Там нет подобной тупости, насколько я помню.
Разработчикам моча ударила в голову, что они для бекапа на почту используют те же методы, что и при создании гигабайтовых бекапов?
Вы начисто проигнорировали контекст. Если бекап-процесс собирается где-то сохранять огромадные временные данные - логично это сделать там, куда он потом сохраняет файлы. Там _должно быть_ много места. Только потому - это более разумное умолчание.
Мда. Оказывается, маразма тут можно не только от андрейки наслушаться. netwind тоже порой "отжигает" ;)
О, они еще и не такие вещи делают... Видимо, в расчете на большинство хомячков, у которых один раздел / на весь сервер.
Правильное решение - _не использовать_ ISP бекап.
1) Существуют вполне нормальные системы бекапа, которые _не используют_ временные файлы.
2) Чем Вам не угодил для этого раздел, на который делается бекап?
Тогда все приемущества двухуровневой схемы потеряются.
Чтобы "все в одном", вплоть до сервера приложений (не написаных специально под задачу) - такого пока никто не придумал. Почитайте apache-httpd-dev на досуге - там была пара интересных обсуждений (заголовки типа httpd 3.0) вокруг этой темы.
netwind, я не пытался "оспаривать" кому что и зачем нужно. Просто выссказал свое мнение.
Ко мне постоянно приходят люди, читающие этот форум, в т.ч. этот раздел - вовсе не из указанной Вами категории (в финансовом плане малоинтересной ;)). Обобщайте сколько угодно - просто эти обобщения без статистики ценны лишь для Вас.
С "обобщением 2" - я вполне согласен. Просто тогда нету речи о сравнении "что лучше" или вопросе "что на что имеет смысл заменить". Лучше - то, для чего полно хавту на говноблогах или есть кнопка в панели ISP. Ваш ответ, утрированно.
PS:
Более содержательной частью моего предыдущего поста - было выяснение того, чем Вам mod_php помешал. Эту часть Вы предпочли "не заметить".
Ну и каким образом mod_php на бакенде мешает у Вас mpm_event на фронтенде? Это _два разных_ веб-сервера. Модули, установленные у одного - совершенно "параллельны" другому...
Почему вдруг "не нужны", да еще причем здесь "хостеры"? Кроме массового виртуального хостинга - других проектов не признаем?
До появления первых проблем. В частности, связанных и с деталями конфигурации связки с nginx, о которых я упомянул. Тем только в данном форуме об этом - более чем предостаточно.
Незачем. Тем, кто ставить ispmanager на VPS - советы уже не нужны by design. И разве этот раздел форума только для счастливых обладателей ispmanager?
Для кого добрые дяди уже все решили - что толку советы раздавать?
А зачем Вам на прокси mod_php? 😮 А на бакенде - держите себе спокойно prefork (как и в случае nginx).
Если Вы обнаружили подобную "проблему" - я начинаю подозревать, что Вы так и не поняли _что_ именно вообще предлагали сделать. Наверно, стоило переспросить - вместо того, чтобы лезть в обсуждение?
И у nginx - линейная (лучше быть просто _не может_, даже теоретически). Просто кто-то минул этап обучения и не сумел это на графике показать. Но коэффициентик относительно мал, с этим не спорю.
Эта "разница" масштабируется по числу клиентов так же, как и у апача. Коэффициент другой, да. Но с учетом задач nginx в его типичной роли - не он будет основным пожирателем памяти, а бакенд. Точно также, если nginx в этой роли заменить на любой другой современный сервер (тот же апач).
Раздача статики - относительно простая задача во всех смыслах. Апач в самой традиционной архитектуре prefork - с этим справляется на ура. worker/event - еще лучше.
А вот "такая архитектура" становится _выгодной_ - при раздаче _много_ статики. Я не уверен, что ТС с такой задачей на практике столкнулся. Более того, не уверен - что _Вы_ сталкивались.
Преждевременная оптимизация? Прям как "творцы" из ISP - сделали раздачу статики nginx умолчанием при его установке. Проблем - огребли по самые уши (километровые конфиги nginx, логи, в которые пишут и nginx, и апач, и список можно продолжать). Приемуществ для типового сайта - нуль.
Может и хорошо, если апач будет терять _таких_ пользователей? Кому нужны подобные придурки-"одминистраторы", не умеющие посмотреть на багзиллу вебсервера или пошерстить мейл-лист на тему "а что Вы ребята с этой уязвимостью делаете/сделали"?
Все остальные в курсе методов защиты от этой атаки, "изобретенной" "RSnake". Они давно уже есть в нормальных дистрибутивах, в т.ч. и mod_reqtimeout - сейчас это стандартный модуль апача.
Смотрите когда в дебиане был закрыт баг:
http://bugs.debian.org/533661
Март 2010!
Оно _включится_. Просто работать не будет.
Но ТС вполне ясно описал проблему (xcache *вообще не работает*) - и она явно не в конфигурации xcache.
