Как перенести сайт или приложение на новый облачный сервер
Чтобы безопасно перенести проект на облачный сервер, не трогайте старый сервер, пока новый не обслужит реальный трафик. Это план для сайта, магазина или приложения: три чеклиста (до, переключение, откат), команды, которые можно адаптировать, и честные границы по простою. Сначала подберите ресурсы по руководству по выбору облачного сервера, а регион выберите по руководству по локациям в Европе.
Выберите способ миграции
Почти любой перенос укладывается в четыре способа. Часто их сочетают.
| Способ | Подходит для | Главный риск |
|---|---|---|
| rsync файлов | Статические сайты, загрузки, код приложения | Данные меняются во время копирования, нужна финальная синхронизация |
| Образ или восстановление из бэкапа | Та же ОС и структура, проверенное восстановление | Старые драйверы и имена интерфейсов, больший объем |
| Повторное развертывание приложения | Контейнеры и код в git | Забытое скрытое состояние на старом диске |
| Репликация базы данных | Большие или нагруженные базы | Сложность настройки и ограничения версий |
Начните с облачного сервера от EUR 15.00/мес, проверено 2026-10 и отрепетируйте там весь план.
Чеклист перед миграцией
- Инвентаризация - выпишите сервисы, порты, cron-задачи, настройки почты, сертификаты, правила файрвола и все имена, которые указывают на старый IP.
- Скрытое состояние - найдите файлы вне веб-каталога: загрузки, очереди, сессии, лицензии, секреты в переменных окружения.
- Бэкапы - сделайте полную копию старого сервера и один раз восстановите ее в другом месте: непроверенный бэкап - лишь надежда.
- Доступ - только SSH-ключи, файрвол и пользователь без прав root на новом сервере.
- Снапшот - сделайте снапшот нового сервера перед первой настоящей синхронизацией, чтобы ошибка стоила минуты.
Копирование файлов и данных
В примерах новый сервер имеет адрес из документации 203.0.113.10. Подставьте свои имена и пути. Шаги 1 и 2 можно безопасно повторять, шаг 5 выполняется, только когда старый сайт переведен в режим чтения.
# 1. Bulk copy while the old server keeps serving (repeat any time)
rsync -aHAX --numeric-ids --info=progress2 \
-e ssh /var/www/ deploy@203.0.113.10:/var/www/
# 2. Database dump and restore (MySQL / MariaDB shown)
mysqldump --single-transaction --routines --triggers appdb \
| gzip | ssh deploy@203.0.113.10 'gunzip | mysql appdb'
# 3. Test the new server under the real hostname, DNS untouched
curl -sS --resolve example.com:443:203.0.113.10 \
https://example.com/ -o /dev/null -w '%{http_code}\n'
# 4. Check the TTL resolvers will honour
dig +noall +answer example.com A
# 5. Final sync after the old site is read-only
rsync -aHAX --numeric-ids --delete \
-e ssh /var/www/ deploy@203.0.113.10:/var/www/
Флаг --delete удаляет на цели файлы, которых уже нет на источнике. Используйте его только в последнем запуске и только когда точно знаете, какая сторона главная.
Сначала проверьте через файл hosts
До смены DNS заставьте свой компьютер открывать сайт с нового сервера. Добавьте строку в файл hosts (/etc/hosts или C:\Windows\System32\drivers\etc\hosts в Windows): 203.0.113.10 example.com www.example.com. Параметр --resolve у curl (шаг 3) делает то же для одного запроса. Потом уберите строку, иначе будете неделями тестировать новый сервер, не замечая этого.
Снизьте TTL в DNS и переключитесь
Уменьшите TTL записей A и AAAA примерно до 300 секунд минимум за один полный период старого TTL до переезда. Иначе резолверы держат старый адрес столько, сколько разрешает старый TTL. Часть резолверов игнорирует короткий TTL, поэтому ожидайте хвост посетителей на старом IP в течение часов (это оценка, а не измерение).
Чеклист переключения:
- TTL - сниженное значение действует, старое уже истекло.
- Только чтение - старый сайт в режиме обслуживания или чтения.
- Финальная синхронизация - сделан последний дамп базы и шаг 5 из кода выше.
- DNS - записи A и AAAA указывают на новый IP; почтовые записи не меняйте, если почта не переезжает.
- Дымовой тест - вход, заказ, загрузка, почта, cron и сертификат проверены на публичном имени.
- Старый сервер - оставьте его работающим, доступным и нетронутым.
Чеклист отката
- Порог - заранее определите, что считать сбоем (например, неудачные платежи или доля 5xx), и кто принимает решение.
- DNS обратно - верните записи на старый IP; при низком TTL большинство посетителей возвращается за минуты или часы.
- Запись данных - снова откройте старый сайт. Если новый после переключения принял заказы или файлы, сначала выгрузите их и воспроизведите на старом.
Что на самом деле нужно для нулевого простоя
Нулевой простой зависит от архитектуры вашего приложения, и мы не обещаем его ни для какого проекта. Нужны приложение без состояния, база, которая реплицируется или принимает запись с обеих сторон, общее или реплицируемое хранилище и проверенное переключение. Классический сайт с одной базой обычно имеет короткое окно чтения на несколько минут.
После переезда
Минимум неделю следите за журналами ошибок, диском, памятью, временем ответа и доставкой почты. Когда все стабильно, верните TTL к большему значению. Выводите старый сервер только после полного цикла бэкапов на новом; еженедельный бэкап входит в каждый пресет. Проверьте все по чеклисту пробного периода до заказа; короткий тест можно обсудить, написав на sales@dcxv.com, на усмотрение DCXV и без гарантий.
Настройте облачный сервер для переезда или спросите инженера о миграции.
