Чтобы выбрать верную стратегию миграции сайта на другой сервер, прежде всего нужно определиться - допускается ли отлючение операций записи/обновления в БД на время переноса ресурса, т.е. фактический простой? Предположим что мы начали перенос нагруженного интернет-магазина, где каждые три минуты происходит заказ. Если тупо снять дамп БД, сделать архив файлов, перегнать на другой сервак, развернуть всё это дело, то лаг по времени будет минимум минут 30, даже при условии что новая железка будет находиться в той же стойке. Пока будет происходить перенос, в старую базу уже буду записаны новый заказы. Как вариант можно на время миграции запретить создание заказов и пользователей, но простой в 30 минут (а реально 2 часа) бизнес не устраивает, поэтому на крупных проектах практикуется бесшовный переезд - сначала устанавливается балансировщик, на него переписывается DNS, а он в свою очередь проксирует трафик на старый сервер, далее поднимается второй сервак, на нём разворачивается БД, которая подлючается к БД на старом сервере как slave, скрипты синхронизируются rsync/csync, файлы выносятся в
облако. В итоге получаем классическую master-slave модель. В завершении меняем роли в БД, новую делаем мастером, а старую слейвом. Тушим старый сервер.
