Как перенести сайт или приложение на Linux VPS без длительного простоя: файлы, база, DNS, SSL и откат

Перенос работающего сайта или веб-приложения на новый Linux VPS — это не просто копирование файлов с одного сервера на другой. Пока идет переезд, пользователи продолжают оформлять заказы, отправлять формы, загружать документы и менять данные в базе. Если перенести проект вечером, а DNS переключить только через несколько часов, старая и новая копии уже могут различаться.

Еще одна частая ошибка — слишком рано выключить старый сервер. На компьютере администратора домен уже открывается с нового IP, поэтому кажется, что переезд закончен. Но часть пользователей еще некоторое время может попадать на старый адрес из DNS-кэша.

Отдельно нужно проверить HTTPS, фоновые задачи, почту, webhook и другие интеграции. Сайт может нормально открыть главную страницу на новом VPS, но при этом не отправлять письма, дважды запускать cron или сохранять данные не туда.

Поэтому безопасный перенос лучше строить поэтапно: сначала подготовить новый VPS и скопировать основную часть данных, затем проверить проект без смены DNS, синхронизировать последние изменения и только после этого переключать пользователей. Старый сервер при этом еще некоторое время остается точкой возврата.

Ниже разберем такой сценарий для типичного сайта или веб-приложения на Linux. Цель здесь не в обещании «нулевого простоя» для любой системы, а в том, чтобы свести техническое окно к минимуму и заранее понимать порядок отката.

Как выглядит безопасный перенос сайта или приложения на новый VPS

Из каких этапов состоит миграция

Для большинства проектов порядок работ выглядит примерно так:

1. Проверить, из каких компонентов состоит текущий сайт или приложение.
2. Подготовить новый Linux VPS.
3. Заранее уменьшить TTL нужных DNS-записей.
4. Сделать резервную копию исходной системы.
5. Перенести основной объем файлов.
6. Перенести базу данных.
7. Настроить веб-сервер, окружение и зависимости.
8. Проверить проект на новом VPS до смены DNS.
9. Остановить изменения на старой площадке и выполнить финальную синхронизацию.
10. Переключить DNS на новый IP.
11. Проверить сайт, HTTPS, фоновые процессы и внешние интеграции.
12. Оставить старый сервер доступным на время наблюдения.

Упрощенно схема выглядит так:

Работающий старый сервер
          │
          ├── резервная копия
          │
          ▼
Предварительное копирование
          │
          ▼
       Новый VPS
          │
          ├── проверка без смены DNS
          │
          ▼
Финальная синхронизация
          │
          ▼
  Переключение DNS
          │
          ▼
 Проверка и наблюдение
          │
     ┌────┴─────┐
     ▼          ▼
  Всё штатно   Ошибка
     │          │
     ▼          ▼
Новый VPS     Откат

Где обычно возникает простой

Само копирование файлов редко является главной причиной простоя. Сложность появляется в момент, когда нужно получить одну согласованную финальную версию данных.

Предположим, в 21:00 администратор скопировал сайт и базу на новый VPS. В 21:15 на старом сервере появился новый заказ. Если в 21:30 просто переключить DNS на новый сервер, этот заказ останется только в старой базе.

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

Для небольшого корпоративного сайта такое окно может быть коротким. У интернет-магазина, CRM или другого активно изменяющегося приложения сценарий нужно продумывать внимательнее.

Когда перенос почти без простоя возможен, а когда потребуется техническое окно

Проще всего переезжают:

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

Больше подготовки требуется, если:

• сайт постоянно принимает заказы или заявки;
• пользователи загружают файлы;
• работают очереди и фоновые обработчики;
• приложение хранит локальные сессии;
• база большая и постоянно изменяется;
• даже короткая недоступность критична для бизнеса.

В более сложных системах вместо обычного dump/restore базы может потребоваться репликация или другая схема синхронизации. Это уже отдельная задача: без понимания архитектуры приложения универсальной команды здесь нет.

Что проверить и подготовить до начала переноса

Составляем карту приложения: файлы, база, веб-сервер и фоновые процессы

До первой команды копирования нужно понять, из чего на самом деле состоит проект. Каталог сайта — только одна часть системы.

Особенно внимательно проверьте данные, которые лежат за пределами каталога сайта. Например, код может находиться в /var/www/example/, пользовательские файлы — в /srv/data/, а служба приложения — в отдельном unit-файле systemd.

Если перенести только /var/www/, такой проект на новом сервере может просто не запуститься.

Проверяем версии ПО, зависимости и системные требования

Новый VPS не обязан полностью повторять старую систему, но используемые версии должны быть совместимы с приложением.

Перед переносом проверьте:

• дистрибутив Linux и его версию;
• версию PHP и необходимые расширения;
• Python, Node.js или Java, если они используются;
• версию СУБД;
• Nginx или Apache;
• системные библиотеки;
• дополнительные утилиты вроде ImageMagick или FFmpeg;
• локаль и часовой пояс;
• доступный объем RAM и диска;
• пользователей, группы и права на каталоги.

Не стоит без необходимости совмещать миграцию с большим обновлением всего стека. Если одновременно сменить VPS, дистрибутив, версию PHP, СУБД и веб-сервер, при первой же ошибке будет намного сложнее понять ее причину.

Если обновление не является целью переезда, сначала добейтесь стабильной работы проекта на новой площадке. Обновлять отдельные компоненты удобнее уже следующим этапом.

Делаем резервную копию и определяем точку возврата

До начала работ должна существовать резервная копия, из которой проект при необходимости можно восстановить.

Сохраните как минимум:

• файлы сайта или приложения;
• пользовательские загрузки;
• базу данных;
• конфигурацию приложения;
• конфигурацию веб-сервера;
• важные задания cron и systemd;
• текущие DNS-записи;
• настройки HTTPS;
• другие критичные параметры сервера.

При этом резервная копия и старый работающий VPS решают разные задачи.

Резервная копия нужна, если данные повреждены или случайно удалены.

Старый сервер нужен для быстрого возврата трафика на прежнюю среду, если после переключения новая площадка работает неправильно.

Поэтому переустанавливать или удалять старый сервер сразу после смены DNS не нужно.

Заранее уменьшаем TTL и фиксируем текущие DNS-записи

TTL определяет, как долго DNS-запись может оставаться в кэше DNS-резолвера. Если перед миграцией запись имеет большой TTL, часть пользователей после изменения IP еще некоторое время может получать старый адрес.

Поэтому TTL уменьшают заранее, а не за минуту до переключения.

Практический порядок такой:

1. Посмотреть текущее значение TTL.
2. Установить меньшее значение, если DNS-провайдер это позволяет.
3. Выждать как минимум прежнее время кэширования.
4. Только после этого проводить плановое переключение IP.

Проверить текущий DNS-ответ можно через dig.

dig example.ru A

Для IPv6:

dig example.ru AAAA

Если нужен только адрес:

dig +short example.ru A

Перед переносом полезно отдельно сохранить текущие A, AAAA, CNAME, MX и TXT-записи зоны. Даже если меняется только IP сайта, исходная конфигурация пригодится при диагностике или откате.

Подготавливаем новый Linux VPS

До переноса самого сайта на новом сервере нужно настроить базовую среду: создать пользователя, проверить SSH-доступ, установить обновления, настроить firewall и подготовить резервное копирование.

Подробно этот этап разобран в статье «Первичная настройка Ubuntu VPS после заказа: пользователь, SSH, обновления, firewall и резервное копирование».

Для миграции дополнительно убедитесь, что:

• на диске хватает места для сайта, базы и временных дампов;
• открыты необходимые порты;
• установлена нужная СУБД;
• созданы база и пользователь;
• установлена подходящая версия среды выполнения;
• созданы каталоги приложения;
• установлен и подготовлен веб-сервер;
• корректно работает системное время.

Если целевой сервер еще не выбран, сначала стоит подобрать Linux VPS под текущую нагрузку проекта и с запасом по диску, памяти и процессору. После заказа его можно подготовить как новую площадку и уже затем начинать миграцию.

Как перенести файлы, базу данных и конфигурацию

Первичное копирование файлов

Для переноса файлов между Linux-серверами удобно использовать rsync. Его плюс в том, что при повторном запуске не приходится заново передавать весь объем данных: можно досинхронизировать то, что успело измениться.

Пример первоначального копирования:

rsync -a --info=progress2 /var/www/example/ admin@NEW_SERVER:/var/www/example/

Здесь нужно заменить:

• /var/www/example/ — на фактический каталог проекта;
• admin — на пользователя нового сервера;
• NEW_SERVER — на IP или имя нового VPS.

Обратите внимание на завершающий слеш в исходном пути: для rsync он влияет на то, копируется сам каталог или его содержимое.

Параметр --delete на первом запуске лучше не добавлять, если вы не уверены в структуре каталогов. Он удаляет на принимающей стороне файлы, которых нет в источнике, и при ошибке в пути последствия могут быть неприятными.

После переноса проверьте владельца файлов, группу и права на каталоги, куда приложение должно записывать данные.

Перенос базы данных

Конкретный способ зависит от СУБД, размера базы и допустимого окна простоя. Для обычного сайта часто достаточно логического дампа.

MySQL или MariaDB

Для типичной базы MySQL с таблицами InnoDB можно начать с такого варианта:

mysqldump --single-transaction --routines --triggers --events -u DB_USER -p DB_NAME > database.sql

Замените DB_USER и DB_NAME на фактические значения.

Затем файл нужно передать на новый VPS и восстановить базу:

mysql -u DB_USER -p DB_NAME < database.sql

Опция --single-transaction хорошо подходит для согласованного дампа таблиц InnoDB, но ее не стоит воспринимать как универсальное решение для любой структуры базы. Если используются нетранзакционные таблицы или во время дампа меняется структура таблиц, сценарий нужно проверить отдельно.

PostgreSQL

Для PostgreSQL можно создать дамп в custom-формате:

pg_dump -Fc -U DB_USER DB_NAME > database.dump

На новом сервере его можно восстановить через pg_restore:

pg_restore -U DB_USER -d DB_NAME database.dump

Перед переносом PostgreSQL обязательно проверьте версии сервера, роли, расширения и права. Если база очень большая или простой должен быть минимальным, обычный dump/restore может оказаться не лучшим вариантом — тогда стоит рассматривать репликацию или другую схему переноса.

Конфигурация, переменные окружения, секреты и права доступа

После копирования файлов приложение может не запуститься просто потому, что часть настроек хранилась отдельно.

Проверьте:

• адрес и порт базы данных;
• имя базы и пользователя;
• Redis или Memcached;
• SMTP;
• URL внешних API;
• токены и ключи;
• пути к каталогам;
• домен приложения;
• настройки очередей;
• production-режим;
• секретные ключи;
• права на каталоги для записи.

Если секреты лежат в .env или отдельном конфигурационном файле вне каталога приложения, перенесите их отдельно. Не стоит ради переезда временно добавлять пароли и ключи в публичный Git-репозиторий.

Проверьте и задания текущего пользователя:

crontab -l

Если приложение запускает собственные службы через systemd, их также нужно перенести и проверить на новом VPS.

Как синхронизировать изменения перед переключением

После первого копирования старый сайт продолжает работать. Значит, к моменту переключения часть данных снова отличается.

Обычно перед финальной синхронизацией проверяют:

• базу данных;
• каталоги uploads, media или storage;
• сформированные документы;
• очереди;
• фоновые обработчики;
• локальные пользовательские сессии, если они используются.

Для обычного динамического сайта последовательность может быть такой:

1. Перевести сайт в режим обслуживания или запретить новые операции записи.
2. Дождаться завершения критичных фоновых задач.
3. Остановить workers на старом сервере.
4. Сделать финальный дамп базы.
5. Повторно синхронизировать изменившиеся файлы.
6. Восстановить финальную базу на новом VPS.
7. Запустить приложение и необходимые фоновые процессы на новом сервере.
8. Проверить результат.
9. Перейти к переключению трафика.

Именно поэтому предварительное копирование так полезно: в техническое окно попадает не весь перенос, а только работа с последними изменениями.

Как переключить сайт или приложение на новый VPS

Финальная синхронизация и короткое техническое окно

Перед сменой DNS еще раз проверьте:

• финальная база перенесена;
• пользовательские файлы синхронизированы;
• конфигурация нового сервера готова;
• старые фоновые процессы остановлены;
• нужные процессы на новом VPS запускаются;
• сайт работает при обращении к новому серверу;
• доступ к старой площадке сохранен.

Особенно опасно оставить два независимых сервера, которые одновременно изменяют одни и те же бизнес-данные.

Например:

• два cron отправляют одинаковые письма;
• два worker обрабатывают одну очередь;
• заказы одновременно попадают в две разные базы;
• два обработчика принимают один webhook;
• плановое задание дважды выполняет одну операцию.

Если приложение изначально не рассчитано на работу нескольких узлов, после финальной синхронизации должна остаться одна актуальная система записи.

Настройка веб-сервера и HTTPS

Перед переключением обязательно проверьте конфигурацию веб-сервера.

Для Nginx:

sudo nginx -t

Если проверка прошла успешно, конфигурацию можно применить предусмотренным для вашей системы способом.

Для Apache:

sudo apachectl configtest

Не пропускайте проверку HTTPS. Возможный порядок зависит от того, как выпускается сертификат.

Например, если Certbot подтверждает домен через HTTP, новый VPS должен быть доступен для такой проверки. В другой инфраструктуре сертификат можно получить через DNS-проверку или использовать уже предусмотренную схему управления сертификатами.

Если Certbot уже настроен, посмотреть известные ему сертификаты можно так:

sudo certbot certificates

После завершения настройки полезно проверить будущий механизм автоматического продления:

sudo certbot renew --dry-run

Если с продлением сертификатов возникают вопросы, отдельный порядок проверки разобран в статье «Автоматическое продление SSL-сертификата: Certbot, systemd timer и проверка обновления».

Проверяем сайт на новом сервере до смены DNS

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

Один из способов — curl --resolve:

curl --resolve example.ru:443:NEW_IP https://example.ru/

Замените example.ru на свой домен, а NEW_IP — на адрес нового VPS.

Если сайт используется и с www, этот вариант проверяется отдельно:

curl --resolve www.example.ru:443:NEW_IP https://www.example.ru/

Так можно проверить виртуальный хост, HTTPS, редиректы и ответ приложения до того, как реальные пользователи попадут на новый сервер.

Для проверки в браузере можно временно прописать домен на новый IP в локальном файле hosts своего компьютера.

Переключение DNS

Когда сайт на новом VPS проверен, можно изменить A-запись домена на новый IPv4-адрес.

Если используется IPv6, отдельно проверьте AAAA-запись. Иногда администратор меняет только A, а AAAA остается старой — в результате часть клиентов продолжает открывать прежний сервер по IPv6.

После изменения DNS можно проверить обычный ответ:

dig example.ru A

И отдельно посмотреть ответ конкретного публичного резолвера:

dig @1.1.1.1 example.ru A

Например, можно сравнить его с другим резолвером:

dig @8.8.8.8 example.ru A

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

Что учесть для почты, API, webhook и внешних интеграций

IP старого сервера может использоваться не только в DNS сайта.

После переезда проверьте:

• отправку почты;
• SPF, DKIM и DMARC, если вместе с сайтом менялась почтовая инфраструктура;
• webhook;
• платежные сервисы;
• callback URL;
• внешние API;
• IP allowlist у сторонних сервисов;
• CDN и reverse proxy;
• мониторинг;
• резервное копирование.

Например, внешняя система может разрешать API-запросы только со старого IP. В браузере сайт будет выглядеть исправным, но одна из интеграций перестанет работать сразу после переезда.

Что проверить после переключения

Проверка сайта или приложения снаружи

После смены DNS откройте проект так, как это делает обычный пользователь.

Проверьте хотя бы:

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

Одного HTTP-ответа 200 недостаточно. Главная страница может открываться из кэша, в то время как запись в базу, отправка формы или загрузка файла уже не работают.

База данных, загрузка файлов и фоновые задачи

После переключения обязательно выполните несколько тестов, которые именно изменяют данные.

Например:

1. Создайте тестовую запись или заявку.
2. Убедитесь, что она появилась в новой базе.
3. Загрузите тестовый файл.
4. Проверьте, в какой каталог он сохранился.
5. Запустите безопасную тестовую фоновую задачу.
6. Убедитесь, что эта же задача не продолжает выполняться на старой площадке.

Если используются Redis, отдельная очередь, object storage или другие внешние компоненты, их нужно проверять отдельно.

Логи, ошибки и использование ресурсов

Первые часы после миграции особенно полезно следить за журналами и ресурсами нового VPS.

Проверьте логи:

• Nginx или Apache;
• PHP-FPM;
• самого приложения;
• СУБД;
• systemd;
• workers и очередей;
• cron.

По ресурсам обратите внимание на:

• CPU;
• RAM;
• swap;
• свободное место;
• inode;
• нагрузку на диск;
• количество соединений;
• ошибки приложения.

Новый сервер может быть настроен правильно, но оказаться слишком слабым под реальную нагрузку. Если конфигурация VPS еще только подбирается, полезно заранее посмотреть материал «Как выбрать VPS: полное руководство по ключевым критериям».

Как переждать обновление DNS, не получив две расходящиеся копии данных

Старый VPS сразу выключать не нужно. Но оставлять на нем вторую независимую рабочую копию динамического сайта тоже опасно.

После финального переключения обычно стремятся к такой схеме:

• новый сервер работает в обычном режиме;
• старый сервер больше не принимает новые изменения;
• при необходимости старая площадка показывает страницу обслуживания или перенаправляет запросы;
• старые cron и workers остановлены;
• старая база больше не используется для новых записей.

Главная задача — не получить две базы, каждая из которых содержит свою часть новых заказов, заявок или других данных.

Как откатить миграцию, если после переключения появились проблемы

Когда лучше исправлять проблему на новом VPS, а когда откатываться

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

Если не хватает одного PHP-расширения, указан неверный путь или обнаружена ошибка в конфигурации Nginx, проблему часто проще быстро исправить на новой площадке.

Откат стоит рассматривать, если:

• приложение массово недоступно;
• есть риск потери или повреждения данных;
• не работает критичная функция;
• причину ошибки быстро найти не удается;
• новый VPS нестабилен под реальной нагрузкой;
• время диагностики уже выходит за допустимое техническое окно.

Удобно определить критерий отката еще до начала работ.

Например: если после переключения за согласованное время не удается восстановить прием заказов, трафик возвращается на старую площадку и диагностика продолжается уже без давления production-среды.

Безопасная последовательность отката

Откат — это не всегда простая смена A-записи обратно на старый IP.

Сначала нужно выяснить, появились ли на новом сервере новые данные. Если за это время пользователи успели оформить заказы, отправить заявки или загрузить документы, при простом возврате DNS эти изменения останутся на новой площадке.

Поэтому общий порядок выглядит так:

1. Остановить новые операции записи на новом сервере.
2. Зафиксировать изменения, появившиеся после переключения.
3. Понять, нужно ли переносить их обратно.
4. Вернуть трафик на старую площадку.
5. Проверить работу старого сайта.
6. Вернуть необходимые фоновые процессы.
7. Проверить целостность данных.

У статического сайта такой откат действительно может занять несколько минут. У интернет-магазина или другого транзакционного приложения он намного сложнее.

Когда можно окончательно выключить старый сервер

Универсального срока для всех сайтов нет. Старую площадку можно выводить из эксплуатации после того, как вы убедились, что:

• DNS стабильно возвращает новый IP;
• на старый сервер больше не идет значимый пользовательский трафик;
• сайт или приложение работает без критичных ошибок;
• новые данные записываются в правильную базу;
• фоновые задачи работают только на новой площадке;
• почта и внешние интеграции проверены;
• HTTPS работает корректно;
• на новом VPS настроено резервное копирование;
• мониторинг переведен на новый сервер;
• нужные данные со старой площадки сохранены.

После завершения миграции временно уменьшенный TTL можно вернуть к обычному рабочему значению.

Заключение

При переносе сайта на Linux VPS основная сложность обычно не в копировании файлов. Важно не потерять изменения, которые продолжают появляться на старом сервере, вовремя остановить фоновые процессы, проверить новую площадку до смены DNS и сохранить понятный путь назад.

Большую часть работы можно сделать заранее: подготовить VPS, перенести основной объем файлов, восстановить базу и проверить сайт через новый IP. Тогда непосредственно перед переключением останется короткая финальная синхронизация.

Старый сервер после смены DNS лучше не удалять сразу. Он пригодится, если во время первых проверок обнаружится проблема, которую быстрее решить откатом, чем диагностикой на работающем production-сайте.

Что почитать дальше

Если вы готовите площадку для сайта или продолжаете настраивать новый VPS, пригодятся связанные материалы:

• VPS для сайта: полное руководство — чем VPS отличается от обычного хостинга и в каких случаях переход имеет смысл.
• Как выбрать VPS: полное руководство по ключевым критериям — как подобрать ресурсы сервера под нагрузку проекта.
• Первичная настройка Ubuntu VPS после заказа — что подготовить на новом сервере до размещения рабочего проекта.
• Автоматическое продление SSL-сертификата — как проверить Certbot, systemd timer и дальнейшее обновление сертификата.

Когда стоит обратиться к специалистам

Если сайт небольшой, конфигурация понятна, а короткое техническое окно допустимо, перенос можно выполнить самостоятельно по описанному выше сценарию. В качестве новой площадки можно заказать Linux VPS IPWAY, подготовить его и перенести файлы, базу и конфигурацию своими силами.

Сложнее, когда сайт уже принимает заказы и заявки, пользователи загружают файлы или даже небольшой простой нежелателен. Здесь важно не столько скопировать сайт, сколько правильно выбрать момент финальной синхронизации, переключить DNS и сохранить возможность отката.

Если заниматься миграцией самостоятельно не хочется, для переноса сайта на новый VPS у IPWAY есть акция с бесплатным переносом сайтов. В этом случае можно выбрать Linux VPS, а сам переезд передать специалистам.

Кратко

• Не меняйте DNS до того, как новый VPS подготовлен и проверен.
• TTL уменьшайте заранее, а не одновременно со сменой IP.
• Основной объем файлов переносите до технического окна.
• Базу и изменяемые файлы финально синхронизируйте непосредственно перед переключением.
• Не оставляйте две независимые активные копии сайта, которые одновременно принимают новые данные.
• После смены DNS проверяйте не только страницы, но и запись в базу, загрузку файлов, cron, workers и интеграции.
• Старый сервер сохраняйте до подтверждения стабильной работы новой площадки.
• План отката лучше подготовить до миграции, а не придумывать его во время сбоя.