Представьте: вы решили переехать на новый сервер, чтобы увеличить производительность. Но в процессе переноса что-то пошло не так — дамп БД битый, файлы не скопировались, сайт упал на сутки. Это типичная ситуация для тех, кто пробует миграцию впервые. Инженеры нашей команды (5+ лет опыта) провели 200+ успешных миграций. Разработанный процесс гарантирует downtime не более 15 минут — используем параллельную работу и предварительное тестирование. Детально: перед переключением DNS поднимаем полную копию на новом сервере, проверяем все сценарии (авторизация, оплата, формы). Только после — меняем A-запись с TTL 300 секунд. Такой подход исключает потерю данных и долгий простой. При этом мы поддерживаем оба сервера активными до 72 часов после переключения — на случай отката.
Какие риски возникают при смене хостинга?
Неправильная миграция приводит к:
- Ошибки конфигурации веб-сервера (несовместимость версий PHP, модулей)
- Потере данных из-за неполного дампа БД или битого архива
- Долгому даунтайму (12+ часов вместо 15 минут)
- Битым ссылкам в контенте (абсолютные пути остались от старого сервера)
Мы решаем эти проблемы поэтапно и с избыточным контролем.
Как минимизировать downtime при миграции?
Ключевой принцип — параллельная работа (жарг. hot standby). Выполняем миграцию на новом сервере, пока старый обслуживает посетителей. После полной проверки через hosts-файл переключаем DNS с низким TTL (300 с). Средний даунтайм — 5–15 минут.
Сравнение методов переноса данных
| Метод | Скорость | Загрузка CPU | Надёжность |
|---|---|---|---|
| rsync | Высокая (инкрементальный) | Низкая | Высокая (сохраняет права, symlink) |
| tar + scp | Средняя (полный архив) | Средняя | Средняя (архив может повредиться) |
| FTP/SFTP | Низкая (1 поток) | Низкая | Средняя (не сохраняет метаданные) |
Rsync быстрее FTP в 5–10 раз при объёмах >10 ГБ. Мы используем rsync для первичной копии и tar для резервного архива. Дополнительно используем pigz для распараллеливания сжатия — ускоряет процесс на 30%.
Что входит в работу?
- Перенос файлов (rsync с исключением .git, кэша)
- Миграция БД (дамп + восстановление на новой версии СУБД)
- Настройка веб-сервера (Nginx/Apache) и окружения (PHP, Node.js, Redis)
- Установка SSL-сертификата (Let's Encrypt или ваш)
- Настройка cron, queue workers, переменных окружения
- Проверка через /etc/hosts до переключения DNS
- Мониторинг 72 часа после переключения
Типичные ошибки при самостоятельной миграции
Разработчики часто забывают:
- Синхронизировать
.envи права на storage (chmod 775) - Экспортировать базу с флагами
--add-drop-tableи--complete-insertдля InnoDB - Проверить редиректы (http→https, www→non-www) на новом сервере
- Обновить IP в настройках CDN (Cloudflare, Vercel)
Этапы миграции
Подготовка нового сервера
Устанавливаем необходимый стек (LEMP, Node.js и т.д.):
# Установка LEMP-стека на Ubuntu 22.04 sudo apt update && sudo apt upgrade -y sudo apt install -y nginx mysql-server php8.2-fpm php8.2-mysql php8.2-gd \ php8.2-curl php8.2-zip php8.2-mbstring php8.2-xml php8.2-intl redis-server # Для Node.js проектов curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt install -y nodejs Перенос файлов и базы данных
Сначала копируем базу данных, затем файлы — чтобы минимизировать расхождение данных:
# MySQL: дамп и восстановление mysqldump -u root -p mysite_db > /tmp/mysite_db.sql scp /tmp/mysite_db.sql user@new-server:/tmp/ ssh user@new-server "mysql -u root -p new_db < /tmp/mysite_db.sql" # rsync файлов (исключаем .git) rsync -avz --progress --exclude='.git' \ -e "ssh -p 22" \ user@old-server:/var/www/mysite/ \ user@new-server:/var/www/mysite/ Для PostgreSQL используем pg_dump/psql. Важно: для больших БД (50+ ГБ) применяем потоковый дамп через pg_dump -Fc и pg_restore -j 4 для ускорения.
Настройка на новом сервере
- Создаём virtual host (Nginx/Apache)
- Переносим .env с актуальными данными
- Устанавливаем SSL-сертификат
- Выставляем права на директории: storage, cache, uploads
- Настраиваем cron и queue workers
Проверка через hosts-файл
До переключения DNS проверяем сайт локально:
# На локальной машине добавляем в /etc/hosts (или C:\Windows\System32\drivers\etc\hosts) NEW_SERVER_IP mysite.com www.mysite.com Открываем сайт в браузере, проверяем формы, авторизацию, платёжные сценарии. Убеждаемся, что все функции работают.
Переключение DNS
За сутки до переключения снижаем TTL до 300 секунд. В момент переключения изменяем A-запись на IP нового сервера. После обновления возвращаем TTL к 3600+.
# Мониторинг распространения DNS watch -n 5 "dig @8.8.8.8 mysite.com A +short" watch -n 5 "dig @1.1.1.1 mysite.com A +short" Пост-миграционный мониторинг
Держим старый сервер активным 48–72 часа. Выполняем:
- curl проверки доступности
- проверка SSL-сертификата (openssl)
- проверка редиректов (http→https, www→non-www)
curl -I https://mysite.com echo | openssl s_client -connect mysite.com:443 2>/dev/null | grep "Verify return code" curl -I http://mysite.com # ожидаем 301 Почему важно тестировать на новом сервере до переключения DNS?
Если переключить DNS без предварительной проверки, вы можете получить сайт с ошибками: не работают формы, битый CSS, потеря данных. Мы всегда тестируем через hosts-файл, чтобы убедиться: новый сервер отрабатывает все сценарии, включая критические — оплату, регистрацию, email-рассылки.
Сроки и стоимость
Стандартная миграция занимает от 4 до 16 часов в зависимости от объёма данных, количества баз и специфики окружения. Стоимость рассчитывается индивидуально — пишите, оценим ваш проект. Мы работаем с хостингом любой сложности: от shared до dedicated.
Закажите миграцию под ключ — получите бесшовный перенос с гарантией работоспособности. Свяжитесь с нами для консультации.