Пошаговое руководство для DevOps-инженеров и системных администраторов: от аудита текущей инфраструктуры до переключения DNS. Реальный опыт переноса 1 200+ проектов за 2024 год.
По нашей статистике, 67% компаний откладывают смену хостинга от 6 до 18 месяцев — не из-за стоимости, а из-за страха перед простоем. Разбираем, откуда берётся этот страх и как его снять.
«Пользователи увидят ошибку 502». Правильно спланированная миграция проходит в окне обслуживания длительностью 30–90 секунд — столько занимает переключение DNS-записи. При использовании TTL 60 секунд часть пользователей даже не заметит переезда.
«Потеряем последние заказы и данные клиентов». Миграция строится на принципе двойной записи: старая и новая среды работают параллельно до момента, пока вы не убедитесь, что все данные синхронизированы. Расхождение контролируется автоматически.
«Не хватит компетенций внутри команды». Инженеры eMatch сопровождают миграцию бесплатно для тарифов Business и Enterprise. Мы берём на себя настройку репликации, перенос баз и финальное переключение — ваши разработчики могут продолжать работу над продуктом.
Прежде чем переносить что-либо, составьте полную карту того, что у вас уже работает. Этот этап занимает 1–2 дня и экономит недели на исправление ошибок.
Составьте таблицу: IP-адрес, ОС, версия ядра, CPU/RAM/диск, список запущенных сервисов, открытые порты. Поможет утилита nmap в связке с htop и netstat. Не забудьте про cron-задачи и systemd-таймеры — они часто теряются при переезде.
Зафиксируйте размер каждой базы, количество таблиц, индексов и среднюю нагрузку в IOPS. Для PostgreSQL выполните pg_dump —schema-only, для MySQL — SHOW TABLE STATUS. Базы тяжелее 50 ГБ требуют особой стратегии — репликация вместо дампа.
Подсчитайте объём пользовательских загрузок, бэкапов, логов и статики. Определите, что требует NVMe (активные данные), а что подойдёт для тёплого хранения на HDD-томах. Файлы старше 90 дней обычно можно вынести в объектное хранилище S3-совместимое.
Выпишите все сторонние сервисы: платёжные шлюзы, SMS-провайдеры, CDN, SMTP, API-ключи с привязкой по IP. Многие из них требуют добавления новых IP-адресов eMatch в белый список — сделайте это за 3–5 дней до миграции.
Проверьте, у кого из команды есть root-доступ, где хранятся SSH-ключи и пароли от баз. Миграция — отличный повод ротировать ключи и перейти на единое хранилище (Vault, 1Password, Bitwarden). Создайте отдельного технического пользователя для процесса переноса.
Проанализируйте трафик за последние 30 дней и выберите окно минимальной нагрузки — обычно ночь с воскресенья на понедельник, 02:00–06:00 МСК. Предупредите пользователей за 7 дней через email-рассылку и баннер в личном кабинете.
Разверните инфраструктуру-приёмник заранее — за 3–5 дней до миграции. Это позволит спокойно настроить окружение и провести предварительные тесты.
В личном кабинете eMatch создайте VPS или выделенные серверы, соответствующие или превосходящие текущие по характеристикам на 20–30%. Для высоконагруженных проектов используйте конфигурацию с несколькими серверами за балансировщиком нагрузки — это позволит масштабироваться горизонтально сразу после миграции.
Разместите серверы в том же регионе, где находится основная аудитория: для Москвы и Центральной России — ЦОД Москва-2 (площадка DataLine), для клиентов из Сибири — Новосибирск (Академ). Межсерверный трафик внутри приватной сети eMatch не тарифицируется — используйте её для связи между веб-серверами и базами данных.
Важно: включите автоматические снимки (snapshots) с периодичностью раз в сутки — это ваша точка отката на случай непредвиденных проблем. Снимки хранятся 14 дней без дополнительной оплаты.
Выбрать конфигурацию серверов
Разверните Nginx/Apache, PHP/Node.js/Python, Redis, Memcached — точно те же версии, что на старом сервере. Используйте готовые шаблоны eMatch: LEMP, LAMP, Docker-кластер разворачиваются в один клик.
Закажите или перенесите существующие SSL-сертификаты. eMatch подключает Let's Encrypt автоматически, коммерческие сертификаты можно загрузить вручную. Проверьте цепочку на SSL Labs до переключения DNS.
Откройте только порты 80, 443 и 22 (с ограничением по IP). Базы данных — только в приватной сети. Включите DDoS-защиту L3/L4 — она бесплатна на всех тарифах и активируется в один клик.
Самый ответственный этап. Стратегия зависит от объёма данных и допустимого окна простоя. Ниже — три проверенных сценария для разных ситуаций.
Для небольших проектов подойдёт последовательность: остановка записи на 5–10 минут → снятие дампа → перенос на новый сервер → восстановление. Для MySQL используйте mysqldump —single-transaction —quick, для PostgreSQL — pg_dump -Fc (сжатый формат).
Время процедуры: 8–15 минут для 5 ГБ. Приемлемо для большинства сайтов и внутренних сервисов с небольшой аудиторией.
Поднимите новый сервер базы данных на eMatch и настройте его как реплику текущего master-сервера. Репликация работает в реальном времени: старая база остаётся мастер-источником, новая подтягивает все изменения автоматически.
Когда отставание реплики (lag) стабильно держится на нуле в течение 30 минут — можно переключаться. Процедура switch: переводите реплику в режим master, меняете строку подключения в приложении, и готово. Даунтайм — 10–30 секунд на перезапуск пула соединений.
Для MySQL потребуется GTID-репликация, для PostgreSQL — логическая репликация (publication/subscription) или streaming replication. Инженеры eMatch помогут настроить любой вариант.
Для тяжёлых проектов (e-commerce, финтех, аналитика) используйте паттерн dual-write: приложение одновременно пишет и в старую, и в новую базу. Чтение первое время идёт из старой. После того как обе базы синхронизированы и прошли проверку, переключаете чтение на новую, затем отключаете запись в старую.
Этот подход требует изменений в коде приложения и занимает 2–4 недели, но обеспечивает окно простоя 0 секунд. Для критически важных систем — единственный надёжный вариант.
Обсудить стратегию с инженером
Для статики и загрузок используйте rsync -avz —progress поверх SSH. Запускайте в несколько проходов: первый — за сутки до миграции (основной объём), второй — в окно переключения (только дельта). Это сократит время финального переноса в 5–10 раз.
После переноса базы сверьте количество строк в критичных таблицах, хеш-суммы файлов и размер директорий. Для PostgreSQL выполните amcheck, для MySQL — CHECK TABLE. Найденные расхождения устраняйте до переключения DNS.
Держите старую инфраструктуру активной минимум 14 дней после миграции. Это страховка на случай отката. Если обнаружите проблему через неделю — переключитесь обратно за 5 минут. Стоимость содержания двух сред на 2 недели обычно не превышает 4 000–8 000 ₽.
Перед переключением трафика убедитесь, что новая среда полностью работоспособна. Этот этап занимает 2–4 часа и определяет, будет ли миграция незаметной для пользователей.
Привяжите домен к новому серверу через файл /etc/hosts на вашем рабочем компьютере и пройдите по всем ключевым сценариям: регистрация, авторизация, оформление заказа, загрузка файлов, отправка email, работа API. Проверьте логи на наличие ошибок — их не должно быть.
Прогоните автотесты (Selenium, Cypress, Playwright) с базовым URL нового сервера. Если автотестов нет — составьте чеклист из 15–20 критичных пользовательских путей и пройдите вручную. Фиксируйте время отклика — оно должно быть не хуже, чем на старом сервере.
Проверьте отправку почты: новый IP должен иметь корректные PTR, SPF, DKIM и DMARC-записи. Иначе письма попадут в спам. Инженеры eMatch помогают настроить всё это в рамках бесплатного сопровождения миграции.
За сутки до миграции установите TTL DNS-записей на 60 секунд (вместо стандартных 3600). Это позволит пользователям быстрее переключиться на новый сервер. Не забудьте вернуть TTL на 1 час после успешной миграции.
В назначенное время измените A-запись на новый IP. Включите режим maintenance на старом сервере (чтобы пользователи с кешированным DNS видели заглушку, а не ошибку). Мониторьте трафик через Grafana или панель eMatch — переход обычно завершается за 15–45 минут.
Если в течение первого часа после переключения появляются критические проблемы — возвращайте DNS на старый IP. Старый сервер всё ещё работает в режиме read-only и готов принять трафик. Откат занимает 2–3 минуты, включая распространение DNS.
Собрали 6 ошибок, которые повторяются в 80% случаев, когда клиенты мигрируют самостоятельно. Знание этих ловушек сэкономит вам часы отладки.
На старом сервере timezone Europe/Moscow, на новом — UTC по умолчанию. Время создания заказов съезжает на 3 часа, отчёты ломаются, cron-задачи запускаются не вовремя. Проверьте timedatectl до запуска приложений.
В nginx или PHP-приложении прописан путь /var/www/site, а на новом сервере данные лежат в /home/site/public. Приложение падает с 500 ошибкой. Используйте переменные окружения или относительные пути, а при миграции сохраняйте структуру директорий.
Рассылка писем, генерация отчётов, очистка временных файлов — всё это обычно висит в crontab. При ручной миграции про них забывают и вспоминают через неделю, когда клиенты жалуются на отсутствие уведомлений. Скопируйте crontab целиком: crontab -l > backup.txt.
Платёжный шлюз, CRM, сервис рассылок — все они знают ваш старый IP. После миграции запросы начинают падать с 403. За неделю до переезда уведомите всех провайдеров и добавьте новый IP в белый список. У некоторых согласование занимает 3–5 рабочих дней.
На старом сервере логи писались годами и занимали 40 ГБ. Их переносят целиком и новый диск заполняется за первый день. Перед миграцией сожмите или заархивируйте старые логи, оставьте только последние 30 дней. Остальное — в объектное хранилище.
Классика: переезд в пятницу в 22:00, чтобы «не мешать клиентам». Если что-то ломается — чинить приходится в выходные, когда команда устала, а часть разработчиков недоступна. Планируйте миграцию на утро понедельника или вторника: впереди вся рабочая неделя на исправление.
Не нашли ответ? Напишите в чат — инженер ответит в течение двух минут.
Небольшой проект (1–2 сервера, база до 5 ГБ) мигрируется за 3–4 часа чистого времени. Средний проект (3–5 серверов, база 20–50 ГБ) — 1–2 рабочих дня с подготовкой. Крупная инфраструктура (кластер, шардинг, базы от 200 ГБ) — 2–4 недели с поэтапным переносом сервисов. Точное время оценим после бесплатного аудита вашей текущей инфраструктуры.
Инженер eMatch проводит аудит вашей текущей инфраструктуры, составляет пошаговый план миграции с таймингом, помогает настроить репликацию баз, перенос файлов, файрвол и SSL. В день миграции мы на связи в выделенном Telegram-чате, контролируем каждый этап и помогаем с переключением. Услуга бесплатна для тарифов Business и Enterprise, для тарифа Start — 4 900 ₽.
Да, мы проводили миграции со всех крупных платформ: AWS, Google Cloud, Яндекс.Облако, Selectel, Timeweb, Reg.ru, FirstVDS. У каждого провайдера есть свои особенности — например, при переносе с AWS часто требуется замена Amazon RDS на PostgreSQL/MySQL на собственных VPS. Инженер eMatch учтёт специфику исходной платформы при планировании.
Старый сервер остаётся активным минимум 14 дней — вы можете вернуться на него за 2–3 минуты переключением DNS. Кроме того, каждый сервер eMatch поддерживает снимки (snapshots), которые хранятся 14 дней. Если проблема обнаружилась на стороне новых настроек — откатитесь к снимку за 5 минут. В критических случаях инженер поддержки подключается к серверу по SSH в течение 15 минут.
Windows Server 2019 и 2022 полностью поддерживаются на eMatch. Для миграции используем Robocopy для файлов и SQL Server Management Studio для баз (Backup/Restore или Always On replication). IIS-конфигурация переносится через export/import в appcmd. Лицензии Windows Server включены в стоимость серверов eMatch — дополнительных платежей не потребуется.
При миграции с сопровождением инженеров eMatch мы гарантируем окно простоя не более 5 минут. Если по нашей вине простой превысил этот лимит — начисляем сервисные кредиты из расчёта 10-кратной стоимости каждой минуты превышения. За три года работы ни один клиент не потребовал компенсации — все миграции уложились в заявленный лимит.
Проведём аудит вашей инфраструктуры, составим план переезда, настроим репликацию и будем на связи в день переключения. Без даунтайма, без потери данных, без нервов для вашей команды.