Перенос сайта на новый сервер без длительного простоя

Как минимизировать риски и не потерять данные и позиции в поиске

Зачем переносят сайт и чем опасен простой

Сайт переезжает на новый сервер по разным причинам: старый хостинг перестал справляться с нагрузкой, закончился срок договора, бизнес переходит с shared-хостинга на VPS или выделенный сервер, меняется CMS или инфраструктура, требуется более высокий уровень защищённости данных. Технически задача выглядит просто — скопировать файлы и базу данных, поменять IP-адрес в DNS. На практике же именно на стыке этих операций возникает простой: старый сервер уже недоступен или уже не принимает новые заказы, а часть пользователей всё ещё обращается по старому IP-адресу, потому что их DNS-резолвер не обновил кэш.

Для интернет-магазина, сервиса с онлайн-оплатой или B2B-портала даже 20–30 минут недоступности означают не просто неудобство, а прямые потери: незавершённые заказы, ошибки оплаты, обращения в поддержку, а для поисковых систем — риск временно увидеть сайт «лежащим» и понизить доверие к нему.

Что вообще значит «перенос без простоя»

Реалистичные ожидания

В инженерном проекте «перенос без простоя» означает заранее выбранный способ переключения и измеримый критерий доступности. Для сайта на одном сервере обычно планируют короткое контролируемое окно, а для системы с постоянной записью — репликацию или параллельное окружение. Продолжительность переключения определяют по контрольному прогону: объёму накопленной дельты, скорости её синхронизации, времени остановки фоновых заданий и проверке последних транзакций.

От чего зависит длительность простоя

Ключевые факторы:

• объём файлов и базы данных — чем больше данных, тем дольше идёт финальная синхронизация;
• активность записи в базу данных — интернет-магазин с постоянными заказами требует более аккуратного подхода, чем статичный сайт-визитка;
• используется ли CDN или обратный прокси перед сайтом — он может сгладить момент переключения;
• насколько заранее снижен TTL DNS-записей;
• насколько заранее протестировано новое окружение — большинство простоев на практике вызваны не самим переключением, а тем, что новый сервер оказался не готов к моменту переключения.

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

Роль DNS и TTL

DNS-запись домена указывает, на какой IP-адрес идут запросы браузеров. Пока не изменена A-запись (или AAAA для IPv6), все запросы продолжают идти на старый сервер. Проблема в том, что резолверы интернет-провайдеров и браузеры кэшируют ответ на время, указанное в TTL (Time To Live) записи. Если TTL равен, например, суткам, то после смены IP часть пользователей ещё до 24 часов будет попадать на старый сервер [3].

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

Отдельно стоит учитывать TTL для MX-записей, если вместе с сайтом переносится и почта — доставка писем зависит ещё и от повторных попыток отправки почтовых серверов, поэтому здесь также разумно снижать TTL заранее [3].

Синхронизация файлов

Для переноса файлов на практике почти всегда используют утилиту rsync — она работает по SSH, передаёт только изменившиеся данные и умеет докачивать данные при обрыве связи [7]. Синхронизацию делают минимум дважды: первый, «тяжёлый» проход выполняется заранее, без остановки старого сайта — переносится основной объём файлов. Финальный проход, непосредственно перед переключением, переносит уже только разницу (дельту), накопившуюся с момента первой синхронизации, и занимает намного меньше времени [2].

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

Для сайтов, где база данных почти не меняется (контентные сайты, блоги), достаточно сделать её дамп (например, через mysqldump) и импортировать на новом сервере во время короткого окна обслуживания. Для сайтов с активной записью — интернет-магазины, личные кабинеты, CRM-интеграции — используют MySQL-репликацию: новый сервер настраивается как реплика (slave) старого (master), первоначально синхронизируется полным дампом, а затем в реальном времени получает все новые изменения через бинарный лог [11]. В момент переключения трафика отставание реплики от мастера обычно измеряется секундами, что и позволяет свести простой к минимуму [12].

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

SSL-сертификаты

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

Российская специфика

152-ФЗ и локализация персональных данных

Если сайт собирает персональные данные российских пользователей — например, через форму заказа, личный кабинет или CRM-интеграцию, — до переноса проверяют физическое размещение используемых баз данных, договор с провайдером, состав обрабатываемых полей и применимые меры защиты. Для первичного сбора и хранения данных граждан РФ учитывают требования части 5 статьи 18 Федерального закона № 152-ФЗ.

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

Выбор нового хостинг-провайдера

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

Варианты реализации миграции

Ручной перенос через rsync и окно обслуживания

Базовый и наиболее универсальный способ для большинства сайтов на CMS (WordPress, Bitrix, Joomla) или самописных проектов с относительно небольшой базой данных. Последовательность: предварительная синхронизация файлов → настройка окружения на новом сервере → тестирование через файл hosts (без переключения DNS) → короткое окно обслуживания (сайт переводится в режим 503, отключаются очереди и cron-задачи, чтобы они не писали новые данные) → финальный дамп БД и финальная дельта-синхронизация файлов → переключение DNS [1]. Простой в этом случае сводится к длительности финального окна — обычно от одной до нескольких минут [2].

Репликация БД с последующим переключением

Подходит для проектов с активной записью в базу данных, где даже минутная блокировка записи нежелательна (интернет-магазины в высокий сезон, сервисы бронирования). Настраивается MySQL-репликация master → slave, новый сервер синхронизируется в фоновом режиме без остановки старого, а в момент переключения делается только «повышение» реплики до основной роли и обновление настроек приложения [12].

Blue-green через обратный прокси

Для проектов, у которых уже есть обратный прокси или балансировщик перед приложением (например, nginx), можно поднять новое окружение как параллельный «зелёный» стек, полностью его протестировать, а затем переключить проксирование одной командой reload конфигурации — без разрыва существующих соединений [16]. При проблеме можно так же мгновенно вернуть трафик на прежнее окружение [14]. Этот вариант требует более сложной инфраструктуры и оправдан для сервисов с высокими требованиями к доступности, а не для типового корпоративного сайта.

Практические этапы миграции

1. Инвентаризация и аудит. Фиксируется тип CMS, версия PHP/движка, объём файлов и базы данных, список внешних интеграций (платёжные системы, 1С, email-рассылки), список поддоменов и SSL-сертификатов [9].
2. Снижение TTL DNS-записей заранее — минимум за срок, равный текущему TTL, до даты переключения.
3. Подготовка нового сервера: установка нужного стека, настройка окружения, перенос конфигурации веб-сервера.
4. Первичная синхронизация файлов без остановки старого сайта.
5. Настройка репликации БД (для активных сайтов) или подготовка к финальному дампу.
6. Перенос SSL-сертификатов и проверка конфигурации HTTPS.
7. Тестирование нового сервера через файл hosts на локальной машине — сайт открывается по новому IP без изменения публичного DNS [1].
8. Финальное окно: заморозка записи, финальная дельта-синхронизация и дамп БД (или переключение реплики), переключение конфигурации веб-сервера или DNS.
9. Переключение DNS и мониторинг обоих серверов в течение переходного периода.
10. Поддержка старого сервера в рабочем состоянии ещё некоторое время — рекомендуется не удалять данные со старой площадки, оставляя её доступной для части пользователей, чьи резолверы ещё не обновили кэш [6].
11. Проверка индексации и технического SEO после переключения.

Ограничения, ошибки и риски

Технические ошибки

• Неверная конфигурация окружения на новом сервере (другая версия PHP, отсутствующие расширения, другие права доступа), из-за чего сайт после переключения работает некорректно.
• Забытое снижение TTL заранее — тогда переключение растягивается на часы или сутки для части пользователей.
• Продолжение записи в базу данных на старом сервере уже после того, как начат перенос дампа, — приводит к потере части данных (заказов, комментариев).
• Отсутствие плана отката: если после переключения DNS обнаружена критическая ошибка, важно заранее знать, как быстро вернуть записи на старый IP.

SEO-риски и потеря индексации

Перенос сайта — это событие, которое поисковые системы воспринимают отдельно от технической стороны дела. Наиболее частые причины просадки трафика после миграции:

• некорректные или отсутствующие 301-редиректы при изменении структуры URL или протокола (http → https) [20];
• случайно оставленный тестовый поддомен, открытый для индексации, из-за чего поисковый робот воспринимает основной сайт как дубль [21];
• ошибки в robots.txt или устаревшие адреса в sitemap.xml, которые мешают повторному обходу сайта поисковым роботом после переезда [20];
• временные ошибки 5xx или нестабильная работа сервера в момент переключения, которые поисковый робот может зафиксировать как признак проблем с сайтом [20].

Как выбрать подходящий вариант

Для сайта-визитки или блога с редко меняющейся базой данных обычно достаточно классического переноса через rsync и короткое окно обслуживания в несколько минут. Для интернет-магазина или сервиса с постоянными транзакциями оправдана репликация базы данных, чтобы не блокировать запись на время переноса. Полноценная blue-green-схема с параллельными окружениями нужна тем проектам, где даже минутный простой недопустим по бизнес-причинам (высоконагруженные сервисы, платёжные шлюзы, критичные B2B-порталы) — но она требует заранее выстроенной инфраструктуры с балансировщиком и обычно не является разовым решением «на один переезд».

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

Как может помочь «Пятый фактор»

Основная сложность переноса сайта обычно не в самом копировании файлов, а в грамотной оценке рисков конкретного проекта: какие интеграции завязаны на IP-адрес или домен, нужно ли настраивать репликацию БД, требует ли проект соответствия 152-ФЗ, и какие технические ошибки могут стоить позиций в поиске. Команда «Пятого фактора» может изучить текущую инфраструктуру сайта, предложить подходящую схему миграции — от простого переноса с окном обслуживания до настройки репликации или blue-green-переключения — и помочь с самой миграцией или технической консультацией на этапе подготовки.

Вывод

Полностью бесшовный перенос без единой секунды простоя — скорее исключение, требующее сложной инфраструктуры, чем правило. Для большинства сайтов реалистичная и достижимая цель — свести простой к нескольким минутам за счёт заблаговременного снижения TTL, предварительной синхронизации файлов и базы данных и короткого финального окна переключения. Отдельно стоит заранее закрыть три зоны риска: соответствие 152-ФЗ, если на сайте есть персональные данные; корректный перенос SSL-сертификатов; и техническое SEO — редиректы, robots.txt, sitemap.xml и проверку индексации после переезда. Чтобы обсудить задачу или получить консультацию, свяжитесь с командой «Пятого фактора» любым удобным способом.

Источники

[1] fastfox.pro — Миграция сайта на новый хостинг без простоя: пошаговый чек-лист — https://fastfox.pro/blog/reviews/zero-downtime-site-migration/

[2] fastfox.pro — Миграция сайта с rsync и переключением без простоя — https://fastfox.pro/blog/tutorials/rsync-ssh-site-migration-downtime/

[3] fastfox.pro — DNS TTL: как работает время жизни записей, кэш резолверов и «распространение» изменений — https://fastfox.pro/blog/tutorials/dns-ttl-cache-propagation-trace/

[4] fastfox.pro — DNS TTL: кэш, negative caching и безопасный cutover при смене IP — https://fastfox.pro/blog/tutorials/dns-ttl-cutover-switch-ip/

[5] fastfox.pro — Стратегия TTL для записей DNS: A/AAAA, MX и TXT — https://fastfox.pro/blog/tutorials/dns-ttl-a-mx-txt/

[6] enterno.io — TTL в DNS: оптимальные значения для каждого типа записи — https://enterno.io/articles/dns-record-ttl-guide

[7] mivocloud.com — Миграция на новый сервер: как переехать и ничего не сломать — https://mivocloud.com/ru/blog/Migratsiya-na-novyy-server-Kak-pereekhat-i-nichego-ne-slomat

[8] habr.com — Перенос сайта(ов) без простоя и потери данных между выделенными серверами — https://habr.com/ru/articles/155555/

[9] server.ua — Как перенести сайт на новый сервер без простоя и потери данных — https://server.ua/ru/blog/kak-perenesti-sajt-na-novyj-server-bez

[10] netrack.ru — Миграция с VPS на выделенный сервер: пошаговый план действий — https://netrack.ru/articles/rukovodstvo-po-migratsii-na-vydelenniy-s

[11] itldc.com — Репликация данных MySQL в режиме master-slave — https://itldc.com/ru/oldblog/replikatsiya-dannyh-mysql-v-rezhime-master-slave/

[12] plantagoweb.ru — 3 способа миграции MySQL на новый сервер — https://plantagoweb.ru/blog/3-proverennyh-sposoba-migracii-mysql-na-novyj-server-ili-v-oblako/

[13] tretyakov.net — Перенос сертификата Let's Encrypt на другой сервер — https://tretyakov.net/post/perenos-sertifikata-lets-encrypt-na-drugoj-server/

[14] habr.com — Синий свет — зеленый свет: релизим без даунтаймов — https://habr.com/ru/companies/oleg-bunin/articles/720986/

[15] toly.github.io — Простой zero-downtime blue-green деплой — http://toly.github.io/blog/2016/04/20/simple-0-downtime-blue-green-deployments/

[16] habr.com — Как я реализовал blue-green деплой с нулевым даунтаймом на Docker Compose — https://habr.com/ru/articles/1025776/

[17] cisoclub.ru — 152-ФЗ и персональные данные: локализация, отдельное согласие и штрафы — https://cisoclub.ru/izmenenija-v-zakone-152-fz-o-personalnyh-dannyh-i-objazatelnye-mery-bezopasnosti/

[18] wcr-consulting.com — Локализация персональных данных по 152-ФЗ: требования — https://wcr-consulting.com/blog/2026/03/13/lokalizaciya-baz-dannyh-personalnyh-dannyh/

[19] ic-tech.ru — Обязательно ли использовать российские хостинг-провайдеры для обработки персональных данных — https://ic-tech.ru/blog/faq/questions-152fz/obyazatelno-li-ispolzovat-rossiyskie-hosting-provaydery-dlya-obrabotki-personalnyh-dannyh/

[20] serptop.ru — Переезд сайта без потери трафика: пошаговый план миграции — https://serptop.ru/blog/migraciya-sayta-bez-poteri-trafika-kak-pravilno-perenesti-sayt-i-sohranit-pozicii/

[21] krupnoedelo.ru — 16 критических ошибок при переносе сайта, которые приводят к потере трафика — https://www.krupnoedelo.ru/usefull/16-oshibok-pri-perenose-sayta-kotorye-privodyat-k-potere-trafika/