Перенос сайта и сервера с помощью rsync и mysqldump почти без простоя

При смене дата-центра, апгрейде конфигурации или переезде от другого провайдера больше всего беспокоят потеря данных и долгий простой. В этом руководстве описан проверенный на практике порядок миграции: инкрементальная синхронизация файлов с rsync, перенос базы данных с mysqldump и заблаговременное снижение TTL в DNS для плавного переключения. Для большинства сайтов это позволяет сократить простой до нескольких минут.

Ключевые выводы

• Плавный перенос сайта или сервера держится на трёх вещах: заблаговременном снижении TTL в DNS, полной синхронизации с последующей инкрементальной и тестировании на новом сервере до переключения DNS.
• Как минимум за 24 часа до миграции снизьте TTL A-записей сайта до 300 или даже 60 секунд, чтобы DNS-кэши успели истечь до переключения.
• Первую полную синхронизацию через rsync можно выполнять, пока сайт работает, а финальная инкрементальная синхронизация передаёт только изменённые файлы, поэтому проходит быстро.
• Для таблиц InnoDB параметр --single-transaction в mysqldump позволяет выгрузить согласованный снимок без блокировки таблиц.
• IMIDC предлагает бесплатную помощь с миграцией клиентам, которые заказывают облачный или выделенный сервер в Гонконге, Японии, Сингапуре, США или другой локации.

Для кого эта статья и что понадобится

• Исходный и целевой серверы работают под Linux (Ubuntu, Debian, Rocky Linux, AlmaLinux и т. д.)
• На оба сервера можно зайти по SSH под root или пользователем с sudo, и на них установлен rsync
• На целевом сервере развёрнуто такое же или совместимое окружение, как на исходном (Nginx/Apache, PHP, MySQL/MariaDB)

Установка rsync:

# Debian / Ubuntu
apt install -y rsync
# RHEL / Rocky / AlmaLinux
dnf install -y rsync

Чек-лист перед миграцией

Пошаговая инструкция

1. Заранее снизьте TTL в DNS

Зайдите в панель управления DNS вашего домена и измените TTL A-записей сайта со значения по умолчанию (обычно 3600 секунд и больше) на 300 секунд или даже 60. Перед фактическим переключением подождите как минимум один исходный период TTL, чтобы кэши рекурсивных DNS-серверов везде истекли. Текущий TTL можно проверить командой:

dig example.com A +noall +answer

Число после имени домена в выводе — оставшийся TTL в секундах.

2. Настройте SSH-ключи для передачи без пароля

На целевом сервере сгенерируйте ключ и добавьте его на исходный сервер (мы используем схему «pull», чтобы работать с новой машины):

ssh-keygen -t ed25519 -N "" -f ~/.ssh/id_ed25519
ssh-copy-id -p 22 root@SOURCE_SERVER_IP

Замените SOURCE_SERVER_IP в командах на IP-адрес исходного сервера.

3. Выполните первую полную синхронизацию файлов через rsync

Запустите на целевом сервере (пример синхронизации каталога сайта):

rsync -avzP -e "ssh -p 22" root@SOURCE_SERVER_IP:/var/www/ /var/www/

Параметры: -a — режим архива с сохранением прав, владельцев и временных меток; -v — подробный вывод; -z — сжатие при передаче; -P — отображение прогресса и докачка прерванных передач. Обратите внимание: завершающий / в исходном пути означает «синхронизировать содержимое каталога»; без него появится лишний уровень вложенности.

Перед реальным запуском добавьте -n (--dry-run), чтобы посмотреть, какие файлы будут переданы. Чтобы пропустить каталоги кэша или логов, используйте --exclude:

rsync -avzPn --exclude 'cache/' --exclude '*.log' -e "ssh -p 22" root@SOURCE_SERVER_IP:/var/www/ /var/www/

Первую полную синхронизацию можно запускать, пока сайт работает, — на бизнес это не повлияет.

4. Перенесите базу данных с помощью mysqldump

Выгрузите базу данных на исходном сервере. Для таблиц InnoDB параметр --single-transaction создаёт согласованный снимок без блокировки таблиц:

mysqldump -u root -p --single-transaction --routines --triggers --events --default-character-set=utf8mb4 dbname | gzip > /root/dbname.sql.gz

Передайте дамп на целевой сервер:

rsync -avP -e "ssh -p 22" root@SOURCE_SERVER_IP:/root/dbname.sql.gz /root/

На целевом сервере создайте базу данных и пользователя, затем выполните импорт:

mysql -u root -p -e "CREATE DATABASE dbname CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql -u root -p -e "CREATE USER 'dbuser'@'localhost' IDENTIFIED BY 'STRONG_PASSWORD'; GRANT ALL PRIVILEGES ON dbname.* TO 'dbuser'@'localhost'; FLUSH PRIVILEGES;"
gunzip < /root/dbname.sql.gz | mysql -u root -p dbname

Замените STRONG_PASSWORD на собственный надёжный пароль.

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

mysql -u root -p -e "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='dbname';"

5. Протестируйте новый сервер

Не меняя DNS, временно направьте домен на новый IP через файл hosts на своём компьютере (в Windows это C:\Windows\System32\drivers\etc\hosts, в macOS/Linux — /etc/hosts):

203.0.113.20  example.com www.example.com

По очереди проверьте ключевые функции: главную страницу, вход, загрузку файлов, колбэки платёжных систем. Когда всё работает, удалите запись из hosts.

6. Финальная инкрементальная синхронизация и переключение DNS

1. Переведите исходный сайт в режим обслуживания или приостановите запись, чтобы во время переключения не появлялись новые данные.
2. Снова запустите rsync. На этот раз передаются только изменённые файлы, поэтому всё проходит быстро. Если нужно, чтобы целевой каталог полностью совпадал с исходным, добавьте --delete (он удаляет лишние файлы на целевой стороне, поэтому используйте его осторожно).
3. Ещё раз выгрузите и импортируйте базу данных.
4. Измените A-запись в DNS на IP нового сервера. Поскольку TTL уже снижен, большинство посетителей попадут на новый сервер в течение нескольких минут.
5. Следите за логами доступа на новом сервере и, убедившись, что трафик переключился, верните TTL к обычному значению.

Рекомендуем сохранять исходный сервер как минимум 3–7 дней, прежде чем отказываться от него, чтобы при необходимости можно было откатиться.

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

Что делать, если передача rsync прервалась?

Просто запустите ту же команду ещё раз. rsync пропустит уже переданные файлы, а параметр -P позволяет докачивать большие файлы.

База данных огромная, и выгрузка идёт слишком медленно. Что делать?

Добавьте --quick, чтобы снизить потребление памяти, и используйте сжатие через конвейер, чтобы выгружать и передавать одновременно. Для баз размером в десятки гигабайт и больше рассмотрите инструменты физического резервного копирования (например, Percona XtraBackup или mariabackup) или перенос через репликацию primary/replica.

Почему после переноса на сайте отображаются «кракозябры» (например, вместо кириллицы или китайских иероглифов)?

Обычно это вызвано несовпадением кодировки при выгрузке и импорте. Убедитесь, что при выгрузке указан --default-character-set=utf8mb4, а целевая база данных тоже использует utf8mb4.

После смены DNS часть пользователей всё ещё попадает на старый сервер. Почему?

Так бывает, потому что DNS-кэши у некоторых провайдеров ещё не истекли; обычно это проходит само в пределах исходного TTL. Именно поэтому старый сервер стоит сохранить на несколько дней.

Итоги

Ключ к плавной миграции: «заранее снизить TTL, сначала полная синхронизация, затем инкрементальная, и переключаться только после тестирования». Если вы планируете перенести сайт или бизнес в IMIDC, мы предлагаем бесплатную помощь с миграцией: после заказа облачного или выделенного сервера в Гонконге, Японии, Сингапуре, США или другой локации создайте тикет с описанием исходного окружения и требований к переносу, и наши специалисты согласуют с вами конкретный план и временное окно. Если во время миграции возникнут вопросы, вы в любой момент можете получить поддержку через систему тикетов, работающую 24/7.

Читайте также

• Установка WordPress в один клик через aaPanel
• Как подключить и расширить диск данных на Linux-сервере
• Как подключиться к Linux-серверу по SSH