Как перенести сайт на Linux на новый сервер с помощью rsync
Это руководство показывает, как перенести сайт на Linux, включая файлы и базу данных, на новый сервер с помощью rsync так, чтобы простой измерялся минутами, а не часами. Основная идея: копирование в два прохода. Сначала полная синхронизация, пока старый сайт продолжает обслуживать посетителей, затем короткая заморозка записи, быстрый дельта-проход и переключение DNS. Руководство рассчитано на тех, кто уверенно работает с SSH и командной строкой, и одинаково подходит для обычного PHP-сайта, WordPress или самописного приложения.
Зачем rsync запускается дважды
У одного большого копирования есть встроенная проблема: оно может идти часами, а в это время посетители продолжают загружать файлы и писать в базу данных. Если переключить DNS после одного прохода, все созданное во время копирования останется на старом сервере.
Схема с двумя проходами решает это. Первый проход переносит основную массу данных, пока сайт полностью работает, поэтому его никто не замечает. Второй проход выполняется после заморозки записи, и, поскольку rsync передает только то, что изменилось с первого прохода, он обычно завершается за секунды или несколько минут. Реальный простой равен длительности второго прохода плюс повторный импорт базы, а не длительности полного копирования.
Подготовьтесь заранее: TTL DNS и целевой сервер
Выполните эти шаги минимум за день до миграции.
- Понизьте TTL DNS. Установите TTL A-записи домена в 300 секунд. Резолверы кэшируют старое значение столько, сколько разрешал прежний TTL, поэтому, если запись публиковалась с TTL 24 часа, понизьте его минимум за 24 часа до переключения.
- Подготовьте целевой сервер. Установите тот же веб-сервер, ту же версию PHP или другой среды выполнения и тот же сервер баз данных, что и на старой машине. Расхождение версий: самый частый источник сюрпризов после переезда.
- Восстановите vhost и TLS. Перенесите конфигурацию сайта и установите сертификат. Если вы используете certbot, каталог /etc/letsencrypt можно передать rsync вместе с файлами сайта.
- Настройте SSH-ключи, чтобы старый сервер мог подключаться к новому без пароля:
ssh-keygen -t ed25519 ssh-copy-id root@IP_NOVOGO_SERVERA
Первый проход: копируем все, пока старый сайт работает
Запустите основное копирование со старого сервера. Сайт все это время остается в сети.
rsync -aHz --info=progress2 /var/www/example.com/ root@IP_NOVOGO_SERVERA:/var/www/example.com/
Флаги: -a сохраняет права, владельцев и метки времени, -H сохраняет жесткие ссылки, -z сжимает данные при передаче. Обратите внимание на косые черты в конце путей: они определяют, копирует rsync сам каталог или только его содержимое.
Снимите дамп базы согласованным снимком, который не блокирует работающий сайт, если таблицы InnoDB:
mysqldump --single-transaction --routines --triggers example_db | gzip > /root/example_db.sql.gz rsync -z /root/example_db.sql.gz root@IP_NOVOGO_SERVERA:/root/
На новом сервере создайте базу и пользователя с теми же учетными данными, которые ожидает приложение, затем импортируйте:
mysql -e "CREATE DATABASE example_db" zcat /root/example_db.sql.gz | mysql example_db
Перенесите и то, о чем обычно забывают: записи cron (crontab -l), измененные значения php.ini и юниты systemd, от которых зависит приложение.
Проверка через файл hosts
Прежде чем трогать DNS, посмотрите сайт на новом сервере ровно так, как его увидит посетитель: с настоящим виртуальным хостом, TLS и всем остальным. Добавьте новый IP в файл hosts на своей рабочей машине, а не на сервере:
# /etc/hosts (Windows: C:\Windows\System32\drivers\etc\hosts) IP_NOVOGO_SERVERA example.com www.example.com
Теперь ваш браузер направляет домен на новый сервер, а остальной мир по-прежнему видит старый. Пройдите по всему сайту: войдите в панель администратора, загрузите файл, отправьте форму, убедитесь, что HTTPS не показывает предупреждений о сертификате. Во время проверки следите за журналом ошибок на новом сервере:
tail -f /var/log/nginx/error.log
После проверки удалите запись из hosts, чтобы всегда точно знать, на какой сервер вы смотрите.
День переключения: заморозка, дельта-проход, DNS
Перед началом пройдите по контрольному списку:
- TTL держится на 300 секундах достаточно долго, чтобы старое значение везде истекло.
- Сайт на новом сервере работает при проверке через hosts.
- Задачи cron, исходящая почта и продление сертификатов настроены на новом сервере.
- Вы знаете, как остановить запись: режим обслуживания в приложении или остановка сервиса.
- Старый сервер остается нетронутым как путь отката.
Затем выполните переключение:
- Заморозьте запись на старом сервере: включите режим обслуживания в приложении или остановите среду выполнения, например
systemctl stop php8.2-fpm. Отключите задачи cron, которые пишут данные. - Запустите дельта-проход. Флаг
--deleteудаляет на целевом сервере файлы, которые были удалены на исходном после первого прохода:rsync -aHz --delete /var/www/example.com/ root@IP_NOVOGO_SERVERA:/var/www/example.com/
- Еще раз снимите дамп, передайте и импортируйте базу теми же командами. Учтите, что дамп каждый раз полный: если база занимает десятки гигабайт, заложите соответствующее окно заморозки или настройте репликацию.
- Поменяйте A-запись домена на новый IP.
- Проверьте:
dig +short example.com @1.1.1.1должен вернуть новый IP, а журнал доступа на новом сервере должен начать заполняться. При TTL 300 секунд основной трафик переходит примерно за 5 минут.
Для типичного сайта все замороженное окно, дельта-проход плюс импорт базы, занимает меньше 5 минут.
Оставьте старый сервер для отката
Не отменяйте старый сервер в тот же день. Подержите его одну-две недели:
- Если на новом сервере всплывет что-то серьезное, откат сводится к одной смене DNS обратно на старый IP: старый сайт был заморожен, а не уничтожен.
- Некоторые резолверы игнорируют TTL, поэтому небольшая часть посетителей может еще несколько дней попадать на старый IP. Его журнал доступа покажет, когда трафик стихнет.
- До завершения первого полноценного цикла резервного копирования на новом сервере это ваша последняя копия данных.
Та же процедура подходит и для переезда между провайдерами, и для апгрейда внутри одного. Если вы подбираете целевую машину, наши тарифы VPS закрывают большинство сайтов, а когда сайт вырастает из разделяемых ресурсов, выделенный сервер дает ему отдельную машину. Оба варианта работают в нашем собственном дата-центре уровня Tier 3+ в Риге, в нашей собственной сети.
Читайте дальше
Готовы начать?
Запустите за минуты или обсудите с инженером, что подходит вашему проекту.