Как перенести сайт на новый VPS и сократить время простоя

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

Ниже — практический план для сайта или веб-приложения с базой данных, пользовательскими файлами, Nginx и фоновыми задачами. Команды и названия служб будут зависеть от стека, но контрольные точки одинаковы: все данные учтены, новая среда проверена до смены DNS, записи во время финальной синхронизации не теряются, а старый сервер не удаляется преждевременно.

С чего начать перенос сайта на новый VPS

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

Затем сформулируйте допустимый результат. Например: сайт открывается по основному домену, вход работает, форма создаёт запись и отправляет уведомление, новые файлы сохраняются, фоновые задания выполняются только на новом VPS. Для каждого пункта нужен способ проверки. Формулировка «вроде всё перенеслось» не помогает принять решение о переключении.

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

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

Что нужно перенести кроме файлов сайта

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

Слой	Что проверить	Чем подтвердить перенос
Приложение	Код, сборка, зависимости, переменные среды	Процесс запускается без ошибок и отвечает локально
Данные	База, загрузки пользователей, документы, кэш с постоянными данными	Количество записей и файлов совпадает, контрольные сценарии работают
Система	Nginx, службы systemd, контейнеры, расписание, права и каталоги	Конфигурация проходит проверку, нужные службы активны
Доступ	DNS, TLS, SSH-ключи, firewall, почта, API и обратные вызовы	Домен, сертификат и внешние интеграции обращаются к новой среде

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

Зафиксируйте владельца и права каждого каталога. Архив может сохранить файлы, но восстановить их с неподходящим владельцем; приложение запустится, однако не сможет записывать загрузки или журнал. Для контейнеров учитывайте именованные volumes и bind mounts: данные могут находиться вне каталога проекта.

Как подготовить новый сервер до копирования

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

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

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

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

Конфигурацию Nginx проверяйте до перезагрузки. Команда nginx -t проверяет синтаксис и пытается открыть файлы, на которые ссылается конфигурация; это прямо указано в официальном справочнике Nginx. Успешная проверка не доказывает работу приложения, поэтому после неё нужен запрос к локальному адресу и пользовательский сценарий.

Как перенести файлы и базу данных

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

Режим rsync -a сохраняет основные атрибуты, но не включает автоматически ACL, расширенные атрибуты и жёсткие ссылки. Это отмечено в официальном руководстве rsync. Если проект использует такие свойства, добавьте нужные параметры и проверьте результат на тестовом каталоге. После передачи сравните состав файлов и, для важных данных, контрольные суммы.

Базу данных переносите штатными средствами самой СУБД. Для PostgreSQL это может быть логический дамп и восстановление, pg_upgrade или репликация — выбор зависит от версий, объёма и допустимого простоя. Официальное руководство PostgreSQL отдельно предупреждает, что данные разных основных версий нельзя считать совместимыми на уровне файлов; варианты обновления перечислены в разделе Upgrading a PostgreSQL Cluster.

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

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

Как проверить сайт до переключения DNS

Проверить новый VPS можно до публичной смены домена. На рабочем компьютере временно сопоставьте домен с новым IP в файле hosts или используйте отдельное тестовое имя. Первый вариант позволяет браузеру отправлять настоящий заголовок Host, но изменение действует только на выбранном компьютере. После проверки не забудьте удалить запись.

Если TLS-сертификат для основного домена ещё не установлен, браузер покажет предупреждение или соединение не установится. Не отключайте проверку сертификатов в рабочем приложении ради теста. Подготовьте сертификат допустимым способом либо проверяйте локальный HTTP через защищённое соединение к серверу, а HTTPS включите до финального переключения.

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

Проверьте мобильную версию, редиректы, canonical, robots.txt, sitemap.xml и генерацию абсолютных ссылок. Убедитесь, что тестовый домен не попал в метаданные и письма. Если временный адрес доступен из интернета, закройте его аутентификацией или сетевым ограничением, чтобы поисковая система не индексировала копию.

Сравните производительность нескольких типичных запросов без искусственного обещания «новый сервер быстрее». Отличие может быть связано с пустым кэшем, другим расположением базы или отсутствием фоновой нагрузки. Важнее подтвердить, что время ответа укладывается в рабочий диапазон и не растёт при повторении сценария.

Как выполнить финальную синхронизацию и сменить DNS

За несколько часов или дней до переезда уменьшите TTL изменяемых DNS-записей. Сделать это нужно заранее: старое значение уже могло попасть в кэш, и его срок должен истечь. AWS рекомендует снизить TTL, дождаться окончания предыдущего периода, затем изменить DNS и наблюдать трафик; порядок описан в руководстве Route 53 по миграции работающего домена.

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

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

Не включайте одновременно два планировщика и два обработчика одной очереди, если архитектура не рассчитана на параллельную работу. Дублирующиеся письма, платежные запросы и повторная обработка задач опаснее краткой технической паузы. Отдельно проверьте webhooks: внешнему сервису может требоваться новый IP в разрешённом списке.

Как подготовить откат и наблюдение после переезда

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

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

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

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

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

Пошаговый чек-лист переноса

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

После переезда полезно ещё раз пройти чек-лист настройки VPS после покупки: проверить доступ, обновления, firewall, резервные копии и служебные пути. Все материалы направления собраны в разделе «Серверы и инфраструктура».

Частые вопросы

Можно ли перенести сайт на новый VPS совсем без простоя?

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

За сколько времени до переноса уменьшать TTL?

Уменьшите TTL до начала переключения и дождитесь, пока истечёт прежнее значение, уже сохранённое в кэшах. Точный запас равен как минимум предыдущему TTL плюс время на проверку. После стабилизации верните обычное значение, чтобы не создавать лишние DNS-запросы.

Достаточно ли скопировать каталог сайта?

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

Как проверить новый сервер, не меняя DNS?

Временно укажите новый IP для рабочего домена в файле hosts на тестовом компьютере или используйте защищённое временное имя. Пройдите пользовательские сценарии и проверьте журналы. Удалите локальную запись после теста, чтобы не получать ложное представление о публичном маршруте.

Когда можно удалить старый VPS?

После того как DNS-кэши обновились, критичные сценарии прошли проверку, резервная копия нового сервера создана, фоновые задания отработали полный цикл и согласованный период наблюдения завершён. До этого старый VPS остаётся частью плана восстановления.

Что делать с TLS-сертификатом при переезде?

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