Крон в данном случае не вариант, но сделали через запуск процесса, отсоединенного от родителя.
Да, я как раз собираюсь арендовать сервер, который будет стоить после повышения цен примерно столько же, сколько был в Оверсане.
Я уже арендовал там один сервер и один привез на колокейшен, все нравится, поддержка быстрая и квалифицированная.---------- Добавлено 03.02.2016 в 13:07 ----------
Дороговато у них, и не нашел конфигураций с SSD.
Предложили перенести арендованный сервер в SMARTAPE.RU со сменой IP.
Подумываю все же насчет Селектела.
Нам нужен не скрипт, а API. Оно уже готовое в панели. А свое еще делать, добавлять сайты в конфиги nginx и апача, создавать базы данных, перезапускать nginx и апач...
Сделать, конечно, все это можно, но исторически пользуемся уже готовым из панели.
Может со временем дойдут руки и до этого, да...
Во всяком случае, на новых серверах уже не пользуемся бекапом панели, а только своими скриптами. Но тут выбора не было - в ISPmanager постоянно меняется формат бекапных файлов, перекачивать неудобно.
Вариант FreeBSD без панели тоже применяем, но только для размещения отдельных магазинов. Для системы клонирования магазинов панель удобна, кроме того, с ней легче работать программистам.
А так, конечно, если не нужно API панели или если все можно сделать из командной строки, то лучше так и поступить.
Озадачился подобным вопросом, когда перестал поддерживаться ISPmanager для FreeBSD. В итоге перешел на Debian и ISPmanager версии 5 (бесплатная VestaCP не устроила меня по возможностям и, в частности, по легкости миграции на нее).
Миграция на Debian прошла относительно спокойно, проблема лишь в том, что мигрировать нужно сотни сайтов магазинов на многих серверах, и эта затея может растянуться надолго. Фактически пришлось немного поднастроить панель ISPmanager, чтобы домашний каталог у сайтов был как на FreeBSD, и добавить пару симлинков.
Поэтому мы сразу и не удаляем. Дело даже не в кривости бекапа, а в том, что можно быстро переключиться обратно на старый сервер, если что-то пошло не так, или "добыть" из него старые данные и программы, если их забыли перенести или перенесли с ошибками.
Мы на нашем сервисе переносим подобным образом интернет-магазины. Особенность в том, что нужно обеспечить минимальное время простоя и исключить дублирование заказов.
Последовательность действий такая:
1. Переносим средствами панели или вручную сайт магазина на новый сервер и проверяем его работу, прописывая локальный DNS.
2. Подготавливаем редирект для сайта на новый сервер, редактируя на старом сервере конфигурацию nginx.
3. Блокируем на старом сервере оформление заказов, и размещаем сообщение что оформление заказов временно приостановлено (на несколько минут).
4. Копируем базу данных со старого сервера на новый.
5. Перезапускаем nginx с новой конфигурацией, после чего все пользователи перенаправляются на новый сервер, оформление заказов начинает работать.
6. Проверяем, что на новом сервере все работает нормально.
7. Вносим изменения в DNS.
8. Через пару недель удаляем сайт со старого сервера.
Конечно, этот метод не очень годится для массовых переносов сайтов, однако при переносе одиночных и довольно крупных магазинов обеспечивает очень малое время простоя.
А ведь точно, на сервере полно файлов, которые принадлежат уже удаленным пользователям. Это файлы в /tmp, а также в инкрементных бекапах rdiff-backup. И еще почему-то в каталогах существующих пользователей, из которых устанавливались вручную модули Perl.
Сейчас я почистил эти файлы на одном из серверов, теперь подожду, когда они уйдут из инкрементных бекапов и снова проверю скорость работы repquota.
Посмотрел /etc/passwd, никаких особых аномалий нет.
На сервере с FreeBSD 7.4 id обычных пользователей в диапазоне до 1070, но есть пользователи nobody, tty и kmem с id порядка 655хх.
При этом на другом сервере с FreeBSD 9.2 аналогичный расклад с id пользователей, но утилита repquota работает во много раз быстрее.
