Ааа :) Капец, ну как же без изречений Укропа о том что телепаты в отпуске :)
Скажу так - работа осуществляется со счетами пользователей, т.е. по сути с деньгами. Пропущенныей запрос - потеря денег, жалоба, потеря репутации. Соответсвенно, раз на кону деньги, критичность высокая. ОС сейчас - Сentos 5 x86_64 только не совсем понимаю какое это имеет значение. Объем. Объем чего? Базы, файлов? Если да, то и у одного и у второго маленький. Тип сервера. Что имеется ввиду? Я не понял вопрос. Интернет сервер. VDS.

По сути, при надобности, пользователям можно показать заглушку типа "Работы на сайте", но главное чтобы все внутренние процессы проходили без сбоев.

Укроп написал(а):

что твой сервер делает

Основное - работа с БД. Второстепенное - работа с файлами (мало).

Укроп написал(а):

что значит непрерывность

В моем понимании, в данной ситуации - это процесс по "переезду" с одного сервера на другой без остановки внутренних процессов, без потерь информации и в идеале не заметный для пользователя.

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

Сделай объявление заранее, дескать сайт будет в дауне N часов в связи с переездом на более мощный (даже если это и не правда :) ) сервер.
Посетители что не люди? не поймут? Даже такие монстры как вебмани иногда лажают, и трансферы через их систему подтупливают... и ничего - репутация не потеряна :)

JONIK написал(а):

по быстрому поднимаешь nginx на первом серваке в самой простой конфигурации с proxy на новый сервак

лучше настроить редирект в файерволе... те, кто будет попадать по старому ИПу, будут переброшены на новый... и тогда все будет логироваться в одной системе...

Кощей, Для более быстрого переключения днс надо заранее изменить TTL зоны на поменьше, например в полчаса... потом вернешь назад... синхронизацию базы настроить средствами базы... mysql это позволяет легко реализовать... если необходимо синхронизовать файло, то тут очень хорошо подойдет rsync... сначала делаешь полную копию, потом будут пересылаться только изменения... настроить синхронизацию раз в час, к примеру... вот и все... все переключение займет секунды...
вообще, рекомендую написать план миграции и четко ему следовать... в план же внести примерное время простоя, если таковой имеется...

:) просто уже не один раз наши клиенты делали подобные переезды... вот и имеются некоторые знания про особенности данного процесса...