А Вы перенесите на 3ware или LSI контроллер. То не диво, что можно менять контроллер на другую аналогичную модель или даже близкую модель того же производителя.
Ключевое слово может. А может и нет. На одном недорейд promise (SAS) - диски у были в JBOD (по одному логическому тому на диск). Т.е. отдельные диски по-идее. С удивлением увидел, что вынутый диск не читается как отдельный.
Задачка на здравый смысл. Кому надо писать софт для переноса данных, лежащих на недорейдконтроллерах от совершенно разных производителей. Весьма вероятно, что на дисках они метаданные хранят совершенно различным образом. Кроме того неизвестным никому помимо создателей...
Отучаемся говорить за других. На самые тяжелые случаи - есть пакеты с отладочными символами. Ставим и цепляем отладчик в нужный момент.
Но 99.999% проблем решается чтением логов и анализом скрипта на предмет данных с которыми он работает (вспоминаем задачу - работало все нормально, ничего не трогал и вдруг поломалось).
В процентах 20% (а может и больше) это наоборот приведет к проблемам - сид он для других вещей. Не нужно ставить оттуда пакеты, если не знаете точно зачем Вам они.
В общем, не советуйте ерунды.
Да кто-ж его знае - может лимиты какие выставлены. Посмотрите /etc/security/limits.conf - может раскомментировано что.
Может что-то в системных логах есть еще любопытное при отработке скрипта? Посмотрите /var/log/syslog и т.п.
Или баг какой при работе скрипта - нужно идти и смотреть что он делает.
PS: В общем, вы разве не слыхали что телапатия не работает?
Да кто-ж Вам тулзы будет сочинять для переноса данных с одного говенного софт-рейда на другой :) Где Вы здесь вообще нашли "рейд железный"?
Т.е. единственный вариант миграции: raid1 старый -> бекап на отдельном диске -> raid1 новый (в котором недорейд лучше не использовать). Как вариант - можно использовать один из дисков для бекапа, вытащив его предварительно из массива.
А чем куча виртуалхостов не нравится? Вы же не пишете их руками - есть какой-то интерфейс, скрипт и т.п. Можно что-то вроде mod_macro для апача использовать - чтобы "шаблонизировать" конфиг.
Тем более, у Вас nginx - access.log'и логично вообще на нем собирать. Тем более, что со всякими map на нем шаблонные конфигурации достаточно легко делаются:
http://catap.ru/blog/2009/07/20/nginx-config-samples-typical-hosting/
Да никак особо. Раньше апачу могло быть плохо, если делали кучу лог-файлов (т.е. для каждого виртуалхоста - свой). Сейчас вроде бы лучше (не используется select, а что-то вроде poll для работы с логами). Но делать так нет особой необходимости и общий лог-файл, мне кажется, предпочтительнее.
Очевидно, сперва проснуться надоть.
А коли регулярно невысыпаетесь - что-то явно не так. Может сервера клиентов доставляют много хлопот (переоценили свои силы). Или там со здоровьем проблемы...
Раз в месяц проснуться от смс-ки мониторинга проблема?
Это с потолка числа? Потому что реальность им не соответствует - 5-7 человек это системный отдел достаточно крупного хостинга (несколько сотен серверов). И с "бесперебойной организацией мониторинга" все достаточно неплохо, уверяю. Зачем нужно по админу на сервер, думаю, непонятно и ТС :D
Да.
Варианты:
1) обучение (что будет когда действительно реальная проблема возникнет?)
2) взять виртуальный хостинг, не пожадничав
3) брать vps/сервер, доверив его профессиональному администратору
