Как перенести сайт на новый VPS без простоя (Zero Downtime): пошаговый чек-лист сисадмина

Перенос работающего веб-проекта на новый VPS или к другому хостинг-провайдеру — одна из самых ответственных задач системного администратора. Любая оплошность грозит многочасовым простоем (downtime), потерей свежих заказов в интернет-магазине, рассинхронизацией базы данных и просадкой позиций в поисковой выдаче Яндекса и Google.

В профессиональной инфраструктуре концепция Zero Downtime Migration (бесшовный перенос) является обязательным стандартом. Сайт обязан непрерывно отдавать страницы пользователям и принимать платежи даже в ту секунду, когда данные перекачиваются между серверами.

1. Анатомия простоя: почему сайты падают при обычной миграции

Большинство вебмастеров переносят сайты по устаревшей схеме: архивируют сайт через zip/tar, делают дамп базы, меняют IP в DNS и ждут. Это приводит к трем классическим проблемам:

1. Кэширование DNS (DNS Propagation Delay): Пока интернет-провайдеры обновляют кэш записей (что может занимать от 2 до 48 часов), половина пользователей продолжает отправлять запросы на старый сервер, а вторая половина — уже на новый.
2. Разделение данных (Split-Brain): Если оба сервера активны и принимают заказы/комментарии, у вас образуются две несогласованные базы данных. Свести их воедино после миграции практически невозможно без ручного редактирования таблиц.
3. Ошибки конфигурации на «живом» трафике: Если на новом сервере забыли включить PHP-расширение, настроить права доступа chmod/chown или выпустить SSL-сертификат, все посетители увидят белые экраны или ошибки 502 Bad Gateway.

2. Фаза 1: DNS-подготовка и магия TTL (за 24–48 часов до переноса)

Параметр TTL (Time to Live) в DNS-записи указывает резолверам и браузерам, сколько секунд разрешено кэшировать IP-адрес вашего домена. По умолчанию у большинства регистраторов установлен TTL 86400 (24 часа) или 14400 (4 часа).

Если вы измените A-запись с TTL 86400, провайдеры будут опрашивать новый сервер только через сутки. Поэтому подготовку начинают за 1–2 дня до миграции:

Проверьте текущее значение TTL и резолв домена через наш онлайн-инструмент DNS Резолвер SysKit. Убедитесь, что все NS-серверы отдают новое короткое значение TTL.

3. Фаза 2: Развертывание и настройка целевого VPS

На новом сервере разворачивается полностью идентичный программный стек (или обновленные совместимые версии). Важно настроить веб-сервер, PHP-FPM, базы данных и права доступа до копирования файлов проекта.

1. Установка веб-сервера и PHP:

# Установка Nginx и PHP 8.3 со всеми модулями (Ubuntu 24.04 / Debian 12)
sudo apt update && sudo apt install -y nginx php8.3-fpm php8.3-cli php8.3-mysql \
  php8.3-curl php8.3-gd php8.3-mbstring php8.3-xml php8.3-zip php8.3-intl php8.3-redis \
  mariadb-server rsync ufw fail2ban

2. Создание директории сайта и пользователя:

# Создаем изолированную директорию
sudo mkdir -p /var/www/example.com/public_html
sudo chown -R www-data:www-data /var/www/example.com
sudo chmod -R 755 /var/www/example.com

3. Настройка виртуального хоста Nginx:

Создайте конфигурационный файл /etc/nginx/sites-available/example.com.conf. Вы можете воспользоваться нашим эталонным генератором Nginx FastCGI Config или настроить базовый блок:

server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/example.com/public_html;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    location ~ /\.ht {
        deny all;
    }
}

Активируйте сайт и проверьте синтаксис:

sudo ln -s /etc/nginx/sites-available/example.com.conf /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

4. Фаза 3: Первичная синхронизация файлов и медиа через rsync

Файлы сайта (особенно медиатека wp-content/uploads, каталоги товаров или пользовательские вложения) могут весить десятки и сотни гигабайт. Архивирование в .zip на старом сервере перегрузит CPU и забьет диск.

Используйте rsync — он передает файлы напрямую по SSH-туннелю с потоковым сжатием и сохранением прав владельца.

# Выполняется на НОВОМ сервере (стягиваем файлы со старого VPS):
rsync -avzP --delete \
  --exclude='*.log' \
  --exclude='cache/*' \
  --exclude='tmp/*' \
  root@OLD_SERVER_IP:/var/www/example.com/public_html/ \
  /var/www/example.com/public_html/

Поскольку сайт продолжает работать на старом сервере, первая синхронизация может занять от 10 минут до нескольких часов, совершенно не влияя на пользователей.

5. Фаза 4: Тестирование нового сервера через hosts до смены DNS

Критический этап: никогда не меняйте DNS-записи вслепую. Сначала протестируйте работу сайта на новом сервере со своего локального компьютера.

Способ 1: Локальный файл hosts

Файл hosts переопределяет DNS локально для вашего браузера. Добавьте в него строку с IP нового сервера:

• Windows: C:\Windows\System32\drivers\etc\hosts (открыть блокнотом от имени Администратора).
• macOS / Linux: sudo nano /etc/hosts.

# Добавляем в конец файла hosts:
NEW_SERVER_IP example.com www.example.com

Откройте браузер в режиме «Инкогнито» и перейдите на http://example.com. Проверьте:

• Открываются ли внутренние страницы сайта.
• Работает ли авторизация в админ-панель (WordPress, Bitrix, Laravel).
• Нет ли фатальных ошибок PHP в логах: tail -f /var/log/nginx/error.log.

Способ 2: Проверка через curl с подменой IP

# Тестируем ответ веб-сервера без изменения hosts
curl -Iv --resolve example.com:80:NEW_SERVER_IP http://example.com/

Установка временного SSL-сертификата (Let's Encrypt / acme.sh):

Пока домен резолвится в старый IP, утилита certbot в режиме HTTP-01 проверки не сможет выпустить сертификат на новом сервере. Решить это можно двумя путями:

1. DNS-01 Challenge: выпустить сертификат через Certbot или acme.sh с подтверждением через TXT-запись DNS.
2. Перенос сертификатов со старого сервера: просто скопируйте папку /etc/letsencrypt со старого VPS на новый тем же rsync.

После настройки проверьте корректность цепочки сертификата через наш SSL Чекер.

6. Фаза 5: Час «Ч» (Cutover) — перенос базы данных и дельта-синхронизация

Когда новый сервер полностью настроен и проверен, наступает момент финального переключения. Чтобы исключить рассинхронизацию заказов, переводим сайт в кратковременный режим «Только для чтения» (Read-Only) на 1–2 минуты.

Шаг 1: Блокировка записи на старом сервере

Для CMS WordPress можно временно активировать maintenance-режим или ограничить права пользователя БД на запись. В MySQL можно заблокировать таблицы командой:

-- Блокировка на старом сервере (в MySQL CLI):
FLUSH TABLES WITH READ LOCK;

Шаг 2: Создание консистентного дампа MySQL

# Выполняем на СТАРОМ сервере:
# Ключ --single-transaction гарантирует консистентность InnoDB без блокировки чтения
mysqldump -u root -p --single-transaction --quick --routines --triggers \
  example_db | gzip > /tmp/db_backup.sql.gz

Шаг 3: Передача дампа и развертывание на новом VPS

# Передаем дамп на новый сервер:
scp /tmp/db_backup.sql.gz root@NEW_SERVER_IP:/tmp/

# На НОВОМ сервере импортируем дамп:
zcat /tmp/db_backup.sql.gz | mysql -u root -p example_db

Шаг 4: Финальная быстрая дельта-синхронизация файлов

# Занимает 5-10 секунд, так как 99.9% файлов уже скопировано на Фазе 3:
rsync -avzP --delete \
  root@OLD_SERVER_IP:/var/www/example.com/public_html/ \
  /var/www/example.com/public_html/

7. Фаза 6: Проксирование «хвостового» трафика со старого IP через Nginx

Главный секрет настоящего Zero Downtime: Даже при TTL = 300 секунд часть запросов от застрявших DNS-кэшей будет приходить на СТАРЫЙ сервер.

Вместо того чтобы отдавать старую копию сайта, мы превращаем старый VPS в Reverse Proxy, который прозрачно пересылает весь входящий HTTP/HTTPS трафик на НОВЫЙ сервер!

Отредактируйте конфиг сайта на СТАРОМ сервере:

# /etc/nginx/sites-available/example.com.conf на СТАРОМ VPS:
server {
    listen 80;
    listen 443 ssl http2;
    server_name example.com www.example.com;

    # SSL сертификаты оставляем старые
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        # Проксируем все запросы напрямую на IP нового VPS:
        proxy_pass https://NEW_SERVER_IP;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_connect_timeout 10s;
        proxy_read_timeout 60s;
    }
}

Примените настройки: sudo nginx -t && sudo systemctl reload nginx.

8. Фаза 7: Переключение DNS и постмиграционный аудит

Теперь меняем DNS A-запись у вашего регистратора или в панели DNS-хостинга:

@    IN  A     NEW_SERVER_IP
www  IN  A     NEW_SERVER_IP

Постмиграционный чек-лист:

1. Удалите тестовую строку из вашего локального файла hosts.
2. Проверьте резолв домена из разных точек мира через DNS Резолвер.
3. Проверьте сетевой пинг и время первого байта (TTFB) через Пинг чекер SysKit.
4. Убедитесь, что порты 80 и 443 открыты, а SSH порт защищен через Сканер портов.
5. Проверьте логи доступа на новом сервере: tail -f /var/log/nginx/access.log — поток запросов должен плавно нарастать.
6. Через 24 часа увеличьте TTL в DNS обратно до стандартных 3600 или 86400 секунд.
7. Старый сервер можно безопасно отключить через 48–72 часа, когда в его логах access.log полностью исчезнут входящие запросы.

9. Сводный чек-лист готовности сисадмина

10. Часто задаваемые вопросы (FAQ)