Миграция Linux‑сервера: пошаговое практическое руководство

Быстрые ссылки

• Migration Strategies

• Installing Packages

• Transferring The Server’s Disk With rsync

• Transferring a Database

• Switching IPs To The New System

Стратегии миграции

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

Ключевые шаги стратегии:

• Развернуть новый сервер с нужной ОС и конфигурацией.
• Установить/настроить сервисы и зависимости.
• Синхронизировать файлы, конфигурации и данные.
• Подключить базу данных или восстановить дамп.
• Провести приёмо‑сдаточные тесты (smoke tests).
• Переключить трафик (DNS/Elastic IP/Load Balancer).

Почему это хорошая идея:

• Минимальный простой для пользователей.
• Возможность быстрого отката: вернуть трафик на старый сервер.
• Контролируемые изменения и тестирование в отдельной среде.

Важно: миграция — хорошая точка для принятия архитектурных решений. Подумайте о контейнерах (Docker), оркестрации (Kubernetes, ECS) и автоскейлинге. Эти подходы требуют первоначальной автоматизации (инфраструктура как код, CI/CD), но в будущем упрощают повторы миграций.

Когда blue‑green не подходит:

• Очень ограниченные ресурсы (нельзя поднять второй инстанс).
• Миграция локальных физических серверов без возможности быстрого подмены IP.
• Сильные требования к непрерывности транзакций в базе (без репликации может быть трудно).

Альтернативы:

• Канареечные релизы (gradual traffic shifting).
• Полная замена через backup/restore образа диска.
• Миграция в контейнеры с использованием томов или общих хранилищ.

Установка пакетов

Если вы не уверены, какие сервисы установлены на старом сервере, сначала получите список запущенных сервисов:

service --status-all

Это даёт быстрый обзор основных системных служб. Список установленных пакетов может быть огромным (включая зависимости), поэтому он часто менее полезен.

Чтобы увидеть все пакеты (например, apt/Ubuntu):

sudo apt list --installed

Или поиск конкретного пакета:

sudo apt -qq list program_name --installed

Рекомендация: составьте список только ключевых сервисов и пакетов, необходимых для работы приложения (например, nginx, php‑fpm, mysql/mariadb, redis, postgresql, docker). Для каждого сервера лучше иметь текстовый файл с перечнем пакетов и конфигураций — это ускорит автоматизацию.

Совет по автоматизации: используйте конфигурационные менеджеры (Ansible, Puppet, Chef) или скрипты shell для повторяемой установки и настройки.

Копирование диска сервера с помощью rsync

Для большого объёма данных tar может не подойти (мало места для промежуточного архива). rsync позволяет переносить данные напрямую по SSH и синхронизировать каталоги.

Пример синхронизации каталога nginx на удалённый сервер:

rsync -azAP /etc/nginx username@remote_host:/etc/nginx

Разбор флагов:

• -a — архивный режим (сохраняет права, символьные ссылки и т.д.).
• -z — сжатие по сети.
• -A — сохранять ACL (Access Control Lists).
• -P — прогресс и дозагрузка прерванных файлов.

Для копирования корневой файловой системы, исключив некоторые системные точки, используйте:

sudo rsync -azAP / --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} username@remote_host:/

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

Если нужно только несколько каталогов, удобнее создать tar‑архив и передать единый файл:

tar -czvf nginxconfig.tar.gz /etc/nginx
scp nginxconfig.tar.gz username@remote_host:/tmp/
# на целевом сервере
tar -xzvf /tmp/nginxconfig.tar.gz -C /

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

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

Для согласованной миграции данных часто используют дамп базы и восстановление.

MySQL / MariaDB — пример создания дампа:

mysqldump -uUser -pPass -hHost --single-transaction --routines --triggers database > backup.sql

Опции: –single-transaction полезна для InnoDB‑таблиц, чтобы получить согласованную копию без блокировок.

Восстановление:

mysql -uUser -p database_name < backup.sql

MongoDB — создание дампа:

mongodump --host=mongodb.example.net --port=27017 --out /tmp/mongodump

Восстановление:

mongorestore --host newhost --port 27017 /tmp/mongodump

Для крупных БД рассмотрите репликацию: поднять новый сервер как реплику, дождаться синхронизации, переключить роль на мастера. Это уменьшает время простоя.

Если база чувствительна к времени (финансовые транзакции), планируйте даунтайм или используйте методы zero‑downtime миграции (репликация, стриминг бинлогов).

Переключение IP и трафика на новую систему

После валидации нового сервера переключите трафик. Варианты:

• Изменение DNS‑записи — просто, но распространяется через TTL; может занять время.
• Переключение Elastic IP или Floating IP — мгновенное перенаправление без изменения DNS.
• Поэтапный перевод через балансировщик нагрузки — лучший вариант для безостановочной работы.

Если вы используете AWS и Elastic IP:

1. В консоли EC2 откройте Elastic IPs.
2. Action → Associate Elastic IP Address.
3. Выберите новый инстанс — ассоциация изменится мгновенно.

Важно: после переключения проверьте сетевые ACL, правила firewall/iptables и настройки reverse DNS, если они критичны.

План миграции — компактный чеклист для ролей

Роли: Системный администратор, DBA, DevOps инженер, Тестировщик.

Администратор:

• Поднять и патчить новый инстанс.
• Установить базовую безопасность (SSH ключи, брандмауэр, fail2ban).
• Синхронизировать конфигурации и сертификаты.

DBA:

• Подготовить дампы или настроить репликацию.
• Проверить консистентность данных и индексов.
• Выполнить нагрузочные тесты копии БД (если применимо).

DevOps:

• Настроить CI/CD и автоматическую установку пакетов.
• Обновить инфраструктурный код (Terraform, Ansible).
• Подготовить сценарии отката.

Тестировщик:

• Выполнить smoke и регрессионные тесты.
• Верифицировать интеграции (API, очереди, внешние сервисы).
• Подтвердить SLA / метрики доступности.

SOP: пошаговая последовательность действий для миграции (сценарий blue‑green)

1. Подготовка: создать инстанс с той же/более новой ОС.
2. Установка и конфигурирование необходимых пакетов.
3. Первичная синхронизация файлов (rsync) и конфигураций.
4. Создание и перенос дампа БД или настройка репликации.
5. Настройка окружения (переменные, секреты, SSL).
6. Прогон smoke тестов и проверки логов.
7. Финальная синхронизация данных (последний rsync).
8. Переключение трафика (DNS/Elastic IP/Load Balancer).
9. Мониторинг после переключения в течение оговорённого окна.
10. Утилизация/удаление старого хоста после стабилизации.

Критерии приёмки

• Все ключевые эндпоинты отвечают корректно.
• Все фоновые задачи выполняются как на старом сервере.
• Метрики: задержки и ошибки в пределах допустимого.
• Успешный прогон smoke и регрессионных тестов.

Риски и смягчение

!— Примечание: таблица качественная, числа не вымышлены —

Команды — краткая памятка (cheat sheet)

• Список служб:

service --status-all

• Список пакетов (apt):

sudo apt list --installed

• rsync (каталог):

rsync -azAP /etc/nginx username@remote_host:/etc/nginx

• rsync (весь корень, исключения):

sudo rsync -azAP / --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} username@remote_host:/

• Создание MySQL дампа:

mysqldump -uUser -pPass -hHost --single-transaction database > backup.sql

• Восстановление MySQL:

mysql -uUser -p database_name < backup.sql

• MongoDB dump/restore:

mongodump --host=host --port=27017 --out /tmp/mongodump
mongorestore --host newhost --port 27017 /tmp/mongodump

Когда миграция может провалиться — примеры и контрмеры

1. Неполная синхронизация конфигов: держите конфигурации в VCS и применяйте автоматом.
2. Секреты и ключи не перенесены: используйте секрет‑менеджер и проверяйте наличиe сертификатов.
3. Разные версии ПО: тестируйте в изолированной среде и фиксируйте версии пакетов.
4. Скрытые зависимости (локальные сокеты, произвольные cron): сделайте аудит на старом сервере.

Мини‑методология принятия решения

1. Оцените требования к простоям и критичность данных.
2. Выберите стратегию (blue‑green, canary, backup/restore).
3. Решите, автоматизируете ли вы установку (Ansible/CI) или делаете вручную.
4. Выполните тестовую миграцию и прогон тестов.
5. Планируйте окно переключения и отката.

Краткая сводка

• Blue‑green — приоритет для минимального простоя.
• rsync — основной инструмент для файловых переносов.
• Дамп/репликация — для баз данных.
• Используйте автоматизацию для повторяемости.

Часто задаваемые вопросы

Q: Нужно ли отключать старый сервер сразу после переключения?

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

Q: Что быстрее — DNS‑смена или Elastic IP?

A: Elastic/Floating IP переключается мгновенно; DNS зависит от TTL и может занять время.

Q: Как минимизировать риск потери данных?

A: Используйте репликацию, проводите тестовые восстановления и сохраняйте несколько резервных копий.

Глоссарий

• blue‑green: стратегия с параллельными старыми и новыми средами для безопасного переключения.
• rsync: инструмент для синхронизации файлов по сети.
• дамп: экспорт базы данных в файл для переноса или восстановления.

Изображение: общая схема шагов миграции сервера — подготовка, синхронизация данных, тестирование и переключение трафика.